Skills Poor Programmers Lack • Hacker News Board

Re: Skills Poor Programmers Lack

#81

Post by avip » Sun, Jul 21, 2019, 5:52 PM UTC

The example is interesting.

  if isDelivered and isNotified:
    isDone = True
  else:
    isDone = false;

is not the same code as

  isDone = isDelivered and isNotified

in ruby, python, js (and more?).

[edit: while I'm nitpicking... breaking webpage text selection is also a clear sign of poor programming]

[Edit2: more unsubstantiated "absolute truth" from OP]:

  Using sleep(), cron jobs [...] is almost always wrong.

false. Any hw related code (most of the code humanity had created?) relies on such timing considerations.

  Another common mistake I see is generating a random file or identifier and hoping that collisions will never happen

false. This is a 100% valid approach, the odds of uuid collision are 0 to any practical consideration.

Re: Skills Poor Programmers Lack

#82

Post by chpmrc » Sun, Jul 21, 2019, 5:55 PM UTC

avip wrote: post #81

The example is interesting. if isDelivered and isNotified: isDone = True else: isDone = false; is not the same code as isDone = isDelivered and isNotified in ruby, python, js (and more?). [edit: while I'm nitpicking... breaking webpage text selection is also a clear sign of poor programming] [Edit2: more unsubstantiated "absolute truth" from OP]: Using sleep(), cron jobs [...] is almost always wrong. false . Any hw r…

Assuming those variables are all booleans why wouldn't it be?

Re: Skills Poor Programmers Lack

#83

Post by jdsully » Sun, Jul 21, 2019, 5:55 PM UTC

elwell wrote: post #79

> On the other hand, what if you generate storage files with random names and you have a collision? You just lost someone’s data! “This probably won’t happen” is not a strategy for writing reliable code. If the entropy is high enough, and the likelihood of collision low enough, then this is a very useful tool for certain situations, particularly distributed systems. I suppose IPFS (and even Ethereum) was written by "…

There’s a lot to get right here. I wouldn’t call using a UUID or its equivalent a random name. It has random components - sure, but the format is intentionally structured to reduce collisions.

Re: Skills Poor Programmers Lack

#84

Post by CodeWriter23 » Sun, Jul 21, 2019, 6:00 PM UTC

atmosx wrote: post #20

arwhatever wrote: post #16

The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. Too many software developers never progress beyond primitives and basic control structures - I call them Int, String, and For Loop Developers. Second biggest issue I see is failing to incorporate our cognitive shortcomings into code design, assuming that you'll remember these dozens of little details from…

Can you give a clear example on “thinking in types” approach ?

I can’t speak for the parent, but my take on it is a skilled programmer would define structs or classes, for example:

parent, student, address

While the unskilled would:

parentfirstname, parentlastname, parentaddress1, .... studentpostcode

Re: Skills Poor Programmers Lack

#85

Post by Zancarius » Sun, Jul 21, 2019, 6:02 PM UTC

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…

I agree, and that's a fantastic point (about arrogance in particular). Without asking the author of the code, it's impossible to determine why they wrote it as they did. It's easy to make assumptions about who write it, but it's much more difficult for some of us to step outside our own judgmental views long enough to consider that they might have had their reasons. When I was younger, I was certainly guilty of this; e.g. "What kind of idiot wrote this?" It takes a certain degree of mental maturity to recognize you may not have a complete picture of why the code was written the way it was. (Admittedly, it also helped me when I realized the idiot who wrote said code years and years was myself, but that's another story!)

This discussion reminds me of the ternary operators. I personally don't like using them except for very specific applications. Not because I don't know how they work, but because I think their overuse can lead to mistakes and maintenance issues as the conditional complexity grows. For simple statements, sure, but once you get into territory where you see 2 or 3 nested ternary statements with complex conditionals, it's easy to lose your mind (and much harder to follow the author's intent).

I'm with the other poster (humanrebar) too, in that one should strive toward writing maintainable code whenever possible. Make it clean and readable. The poor bugger who has to maintain it when you're gone will thank you!

Re: Skills Poor Programmers Lack

#86

Post by [deleted] » Sun, Jul 21, 2019, 6:04 PM UTC

UnpossibleJim wrote: post #44

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…

While I applaud this and would love this rule to be in production, it tends to go against (the majority of) marketing's golden rule of, "I need this done in an unreasonable amount of time with unreasonable requests on functionality" and a management structure that tends to only flex to its subordinates instead of other departments, like they're supposed to.... though, I might be jaded =) I have seen a few very good m…

[deleted]

Re: Skills Poor Programmers Lack

#87

Post by subjectsigma » Sun, Jul 21, 2019, 6:05 PM UTC

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…

>The temptation will be to blame the audience when in fact the failure lies squarely with the programmer doing the speaking or writing.

This is a popular claim on HN that I don't think is true. Where does the boundary end? Is it my fault they can't understand my program if they don't know any code at all? What about if they're a Python programmer hired onto a Java project? The point is you should make a good faith effort to write readable code, especially for your team members, but you're a programmer, not a teacher.

>Lack of empathy also leads to disregard for the needs of users and future maintainers.

This I agree with. Its a very underappreciated reason to build empathy as a programmer.

Re: Skills Poor Programmers Lack

#88

Post by sidlls » Sun, Jul 21, 2019, 6:06 PM UTC

moedersmooiste wrote: post #75

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…

In college they taught me that every line of code should do one thing and one thing only. So doing both a test and an assignment on one line would not be prefered over the first example(split over multiple lines). I don't have a lot of experience with programming so for now I do what I was taught. :)

The code is doing one thing: assigning the result of a boolean expression. It's not different in structure from, say, `x = a + b`.

Re: Skills Poor Programmers Lack

#89

Post by CodeWriter23 » Sun, Jul 21, 2019, 6:07 PM UTC

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.

Came here to comment on that too...and was surprised how many replies you had where the fundamental whooshed right over all these skilled programmer’s heads.

The shortcoming is failure to recognize your object has more than 2 states and the use of flags should be abandoned in favor of a state variable (or status bit vector, aka a state variable).

Re: Skills Poor Programmers Lack

#90

Post by gravypod » Sun, Jul 21, 2019, 6:09 PM UTC

> Using sleep(), cron jobs, or setTimeout is almost always wrong because it typically means you are waiting for a task to finish and don’t know how long it will take. What if it takes longer than you expect? What if the scheduler gives resources to another program? Will that break your program? It may take a little bit of effort to rig a proper event, but it is always worth it.

While I understand the sentiment of this post, which I feel is mostly correct, it's interesting to see how divergent this statement is from my experience building "modern" microservice architectures, devops, and distributed systems design is from this view point that I used to hold so true. Async background tasks that self-heal and are entirely outside of the serving path? Yes, please.