51–60 of 211 posts
Kinda frustrating that an article calling out where programmers fall short was a non-responsive document that was almost unreadable on mobile. Mildly ironic?
Earlier quoted context omitted.
Does blocks of text need responsiveness in order to be readable on mobile? What problem are you experiencing?
The text is very, very small on a mobile device (XL devices may be easier). Requiring anyone with a small/normal sized device without near perfect vision to zoom in and swipe left/right to read a single line of text. For example I'm on a normal sized device and can't read the text at a zoom level that shows an entire line without my glasses (and my vision isn't too bad, I'm legally allowed to drive without my glasses…
The text is using good oldfashioned html markup (basically just h2, p, code, a, em).
So there's no reason why you should have to use the stylesheet provided by the site, and with a sensible browser you don't have to.
To extend on that point, I think that better programming happens when you don't simply apply prefab design patterns to every problem or be overzealous with those patterns.
This is where things like object-orientation, MVC, SOLID, DRY, abstraction, inheritance, overly-organized code with lots of categories for different things, decoupling, etc. can be taken too far or be applied to the wrong problems.
Basically, don't believe in any one thing. Just understand different approaches and realize that nearly all of them have a % probability of succeeding. That can even mean writing things in a more procedural way.
This article says more to me that the author(s) are inexperienced themselves rather than shed any light on the practice of software development. I'm imagining some recent boot camp graduates attempting to conflate their months of programming experience into something more than that. "Hey old dudes in company I just joined, I found some things I think are basic so I'm going to write an article to indirectly shame you…
It is quite idealistic view, in reality you have to realize you never know how everything works, otherwise you will spend a lifetime in academia.
On Software Engineering side (not just programming), the most important skill to me will be curiosity towards business, not just code. Endless devs are dying in arguing over tabs vs spaces, when their job is to deliver for the business, not for their ego. Surprisingly, it is a common decease (based on my Google and other companies experience). They create their wonderful world of logic and sense, and think that everything that violates it is stupid (like business person asking for a feature).
The skill poor engineering lack is actually common sense.
Sadly that's still debated and you can only get piecemeal ideas from blogs and job postings.
There's no central authority to approve developer skill levels that says "these skills every programmer should know before joining the profession - after that, it's up to the specific job" and then it's legally enforced via certifications and official exams.
Right now, it's up to specific jobs and blogs and you have to figure that out.
It's ambiguous and that frustrates people who like exact and measurable goals when learning things.
I know it seems like one blog isn't a big deal, but I've read many blogs that add things like "10 things every programmer should know" and this language just never ends.
If you took a union set of all the things from every "things programmer should know" article, you'd be studying for about 6-8 years before you got a junior position.
>For example, if a successful login generates a session token and it collides with another token, you could reject the login and have the user try again
Eh, don't even go back to the user. Collisions should be a rare occurrence that you can make a second call to the token generator and just replace the bad one. If you get common collisions, you need a better token generator.
This article says more to me that the author(s) are inexperienced themselves rather than shed any light on the practice of software development. I'm imagining some recent boot camp graduates attempting to conflate their months of programming experience into something more than that. "Hey old dudes in company I just joined, I found some things I think are basic so I'm going to write an article to indirectly shame you…
Who gives relational databases flack? The RDBMS and SQL is the cleanest, simplest, and most productive technology stack I've ever used.
> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.
> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.
I felt momentarily bad about it, and myself, and then realized I have a reason:
The codebase I am maintaining is intended to be readable by people who have extremely varying levels of skill, and who have no intention of ever being professional programmers.
When possible I write stuff so you don’t have to “think like a programmer” to understand it. I’m pleased I use the conditional version more often than not, because I believe it is far more intuitive.