Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skills Poor Programmers Lack

justinmeiners.github.io

Post reply on HN
Print view View original

201–210 of 211 posts

Re: Skills Poor Programmers Lack

#201

Post by yellowapple »

Advising against sleep(), cronjobs, etc. seems insane to me, and I don't understand the rationale here. Wanting to yield until there's more work to do (or poll periodically), or run things on a schedule that need run on a schedule, etc. are all very common and very valid use cases. Unless the author's recommending using something else?

Maybe that's just because I'm a poor programmer, though :)

EDIT: I guess in the context of waiting for something to asynchronously finish happening, it'd be more ideal to check for an actual indication of success (e.g. via an await, or by listening for a response message) instead of doing a sleep(5) and hoping for the best. Unfortunately, there are disturbingly many scenarios where that ain't exactly possible (or it's "possible" but not practical), especially when interfacing with external systems written by poor programmers :)

Still, the author should probably clarify how the "cronjobs are bad" opinion fits into that context, because without further elaboration it sounds really silly.

Re: Skills Poor Programmers Lack

#202

Post by FrankyHollywood »

"There are no tricks or rules that you can follow to guarantee you will write good software. As Alex Stepanov said, 'think, and then the code will be good.'"

Excellent conclusion, can't think of anything else. I don't know how many times I've seen programmers apply latest patterns and use trendy libraries only to make a terrible mess out of thing.

I literary heard a guy say last week "we should use MongoDb, it is better than SQL". No context, no arguments, just read a blog entry or I don't know what.

There are no golden bullets, think, and then the code will be good :)

Re: Skills Poor Programmers Lack

#203

Post by coldtea »

allannienhuis wrote: post #173
coldtea wrote: post #123

Earlier quoted context omitted.

Which is not really needed here. isDone will be boolean, and the other ones are still Truthy / Falsey values...

if the first term is undefined, isDone will be undefined, not false. At least in Javascript. && returns the falsy value on the left side of the expression if it evaluates to a falsy value (undefined && true) evaluates to undefined correspondingly || returns the truthy value (which might be an object) on the left hand side if evaluates truthy. That's useful for expressions like this: const a = b || 'default value'; !!…

True, !! is still needed to get a True/False instead of the truthy/falsey value...

Re: Skills Poor Programmers Lack

#204

Post by meowface »

bastijn wrote: post #110
humanrebar wrote: post #25

Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various skills involved in doing it successfully, including writing, automation, design, seeking quality peer review, and a few other things. Similarly, writing code that can be deleted is an important skill. Using "good design" and "knowing your language" are fairly neb…

Writing code that is well designed but not over-designed is a great skill. It is in every engineer to write the gold plated car, as it is in marketing and sales to always need the future tomorrow to gain competitive edge. The number of times I wrote beautiful code are quite numerous, the number of times it is still not used to its potential as well. In the end I spent too much time over engineering for a disastrous m…

There really needs to be a blog post about this. (I'm sure there have been, but I feel like this isn't talked about enough.) A good percentage of HN readers probably already know most of the advice about bad design, but once you're at that more experienced level, you run into the inverse problem of knowing too much for your own good and wasting cycles over-designing and over-engineering.

I've definitely been guilty of this, both at the level of high-level system/project/solution design, and at the level of code design and code abstractions. I've blown a ton of time and effort over-engineering things which never end up getting used or looked at at all years later, or even just to make things look nicer despite no one else ever using, reading, or modifying my code other than me.

It can sometimes be hard to really accept YAGNI and be able to just move on even if the code isn't quite as elegant or DRY or abstracted as you might have preferred. When you're creating abstractions upon abstractions, you can lose sight of the original goals.

I'm still learning to know when to stop, but I'm getting better.

Re: Skills Poor Programmers Lack

#205

Post by afarrell »

saidajigumi wrote: post #102
afarrell wrote: post #26

Earlier quoted context omitted.

Mise-en-place is so important. Inexperienced engineers sometimes find themselves in teams which don’t appreciate it. Because confrontation can be nausea-inducing, they sometimes don’t endure the discomfort to insist on it. ——— When a customer walks into a restaurant, does he ask about the temperature of the fridge the chicken is stored in? Does he ask if the kitchen is clean and organized? No. Thats the chef’s job to…

I'd argue that missing on mise en place is symptom of a team leadership failure, as well. Allowing excessive tribal knowledge vs. repeatable process (docs, dev tools, tests, well organized code, etc.) is an organizational risk. There's the efficiency loss side, but also the possibility that an incapacitated team member becomes a critical business loss – the team becomes unable to meet goals or worst case, to ship at…

I agree deeply.

Re: Skills Poor Programmers Lack

#206

Post by beernutz »

techslave wrote: post #165
apo wrote: post #73

The skills cited in the article are: 1. Understanding how the language works. Additionally understanding how the language infrastructure interfaces with the computer. 2. Anticipating problems. Prefer solid foundations over veneers that appear to get the job done. 3. Organizing and designing systems. Essentially, SOLID. Two things on this: First, bad code often results from conflicting goals. Moving goalposts and on t…

> Second, the most valuable skill a programmer can have isn't technical, but rater social: empathy. couldn’t agree more! but the term you’re really looking for is perhaps a strongly developed theory of mind. whereas empathy really is referring to emotional awareness. the worst and also most annoying programmers i know, to a person, consistently fail to see other points of view. their way is the right way, period. the…

Maybe empathy comes in when trying to frame criticism in a constructive way that the receiver will internalize and find helpful?

In some cases, it might be better to ask them about reasoning around a particular bit of code than to offer alternatives right away. In others, a good idea or anecdote about something you found useful in that spot, might be better received.

In my experience, there is a good amount of empathy (or emotional awareness) involved in offering advice that will be accepted in a constructive spirit, and not seen as an attack.

After all, we ALL write bad code sometimes. A bit of code might seem like a good idea at the time, but could just be overly "clever" upon later inspection. A good review comment that does not point fingers seems like it would fall under the "empathy" umbrella.

Re: Skills Poor Programmers Lack

#207

Post by [deleted] »

bryanrasmussen wrote: post #64

Well, where he says "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 " I think that's a matter of style, I prefer the isDone = isDelivered and isNotified style myself, and I think the people who write the other way have very poor style but as arrogant as that sounds I don't think I woul…

[deleted]

Re: Skills Poor Programmers Lack

#208

Post by zshrdlu »

bryanrasmussen wrote: post #64

Well, where he says "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 " I think that's a matter of style, I prefer the isDone = isDelivered and isNotified style myself, and I think the people who write the other way have very poor style but as arrogant as that sounds I don't think I woul…

This is a silly example altogether.

First, it doesn't necessarily imply that someone writing code like this doesn't understand how expressions work. The author is trying to psychologically model people who code in this manner. I could similarly claim that the else there is unnecessary since the boolean is false by default. If it's a language that doesn't require variables to be declared first, I could claim that the assignment is itself unnecessary. I could then make a further claim that a person who codes like this doesn't understand expressions.

Second, the problem is taken out of context. What happens next? There'll be an if(else) statement somewhere to determine what happens next, and then the if(else) the author has painstakingly avoided will be back.

Re: Skills Poor Programmers Lack

#209

Post by Izkata »

detaro wrote: post #130
coldtea wrote: post #121

Earlier quoted context omitted.

null (or None) is still a valid Falsey value, and in both examples isDone will be a boolean (strict) value, as it is the result of a boolean operation (and). So the point of the comment is moot...

JS: undefined && undefined -> undefined Python: None and None -> None

On top of that, truthy values also propagate, so if isDelivered or isNotified are something else that's truthy (such as a 1 from mysql), isDone will not be True either and risk failing in more interesting ways down the line.

Re: Skills Poor Programmers Lack

#210

Post by Izkata »

userbinator wrote: post #107
cgriswald wrote: post #4

> 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've seen plenty of if(!(var != true) == false) and the like --- some people just seem to not really understand the concept of booleans.

It often goes much further than that.

I was a teacher's assistant in the intro-to-programming courses in college for 3 years, and eventually realized what students were seeing. Now, with some new hires, I'm seeing the same thing:

They think the expression is "if (.. == ..) { .. }"

Not "if (..) { .. }"

The simple explanation of what boolean expressions are, and that any boolean expression can go in those parens - and that it's the same thing as storing the result to a variable and then using that variable - is like a lightbulb suddenly blinks in their head.

Post reply on HN