Skills Poor Programmers Lack • Hacker News Board

Re: Skills Poor Programmers Lack

#61

Post by vkaku » Sun, Jul 21, 2019, 5:28 PM UTC

I read it. To me, it came off more as edgy, brash and inexperienced than what it intended to do - to influence people on what skills they should pick up, so that they may, according to the author, not be a 'poor programmer'.

Often, there are two factors that lead to very different code than usual:

- Lack of time and hence taking shortcuts

- Simple code is different from clever code

And, the TL;DR that I wish to convey back is:

- All code sucks given the right circumstances

- A skill learnt over time: being a snob is not the way to influence people

- Everyone starts lousy and gets opportunities to learn and become better - even better than you

- The way people think and envision things is very different, and operating philosophies are very different. There are multiple pathways to succeed and the skills you mentioned do not appear in all of them.

Any time you wish to state such an opinion, please think about what would influence 'poor programmers' to do better than status quo.

Re: Skills Poor Programmers Lack

#62

Post by rowanG077 » Sun, Jul 21, 2019, 5:28 PM UTC

frou_dh wrote: post #27

adamparsons wrote: post #10

Kinda frustrating that an article calling out where programmers fall short was a non-responsive document that was almost unreadable on mobile. Mildly ironic?

https://news.ycombinator.com/item?id=9238739

An article about bad programmers by someone who is so bad that he can't handle putting up simple static text on a web page sanely is wildly relevant.

Re: Skills Poor Programmers Lack

#63

Post by DocEasyE » Sun, Jul 21, 2019, 5:30 PM UTC

stopped reading when it said in javascript bhauaua

Re: Skills Poor Programmers Lack

#64

Post by bryanrasmussen » Sun, Jul 21, 2019, 5:30 PM UTC

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 would be so arrogant as to say they don't know how expressions work.

Re: Skills Poor Programmers Lack

#65

Post by whiddershins » Sun, Jul 21, 2019, 5:31 PM UTC

drchewbacca wrote: post #46

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.

Is anyone willing to explain the second line? I get the first means "if isDelivered and isNotified are both true then set isDone to True, if not set it to false". However I've never seen a variable being set "isDone = isDelivered" as part of a logical test. Personally I think programmers who are "too clever" are cancer inside a codebase. Sure you saved a bunch of keystrokes but your code golf has locked the code fore…

It feels clever if you aren’t used to it but it is super common.

isDelivered && isNotified

always resolves to a Boolean, either TRUE or FALSE

So you are just saying

isDone = TRUE

or

isDone = FALSE

that’s all

Re: Skills Poor Programmers Lack

#66

Post by spamizbad » Sun, Jul 21, 2019, 5:33 PM UTC

dpeterson wrote: post #12

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…

People new to the industry aren't always aware of how those "good practices" are simply a product of the industry zeitgeist. If you've just now gotten your feet wet, you're fully up-to-date.

For example, a preference towards writing pure functions might have gotten called-out during code review as recently as 10 years ago. Immutable programming can result in a larger memory footprint and/or more GC activity and years ago that was considered a deal-breaker... even in environments with plenty of headroom RAM and CPU performance.

Re: Skills Poor Programmers Lack

#67

Post by pessimizer » Sun, Jul 21, 2019, 5:33 PM UTC

povertyworld wrote: post #3

Skills are nouns, but the list was all verbs. Weird.

Skills are generally gerunds, which are nouned verbs. "Nouned" is an adjective made out of a verbed noun.

Re: Skills Poor Programmers Lack

#68

Post by hooloovoo_zoo » Sun, Jul 21, 2019, 5:33 PM UTC

mettamage wrote: post #54

dpeterson wrote: post #12

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…

His CV suggests something otherwise. He is experienced. https://justinmeiners.github.io/files/cv.pdf

Still doesn't get opening quotation marks right though....

Re: Skills Poor Programmers Lack

#69

Post by LaserToy » Sun, Jul 21, 2019, 5:34 PM UTC

drchewbacca wrote: post #46

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.

Is anyone willing to explain the second line? I get the first means "if isDelivered and isNotified are both true then set isDone to True, if not set it to false". However I've never seen a variable being set "isDone = isDelivered" as part of a logical test. Personally I think programmers who are "too clever" are cancer inside a codebase. Sure you saved a bunch of keystrokes but your code golf has locked the code fore…

I tend to agree that, given compiler doesn’t care most of time, saving characters can’t justify decrease in readability.

Re: Skills Poor Programmers Lack

#70

Post by injb » Sun, Jul 21, 2019, 5:34 PM UTC

agumonkey wrote: post #50

onion2k wrote: post #21

Earlier quoted context omitted.

In my 20something years of writing software for a living I've seen both. And I find it very hard to care which one someone on my team uses. It's not something fundamental. Both lines work perfectly well. They do the same thing. The second is more concise and 'better', but if the only improvement you can suggest in a code review is something like shortening a line then the code is basically fine. A difference between…

You have a point but the issue with redundant boolean code like above is that it shows a lack of metalevel thinking. kinda like this python exagerated code: def sum(a,b): return operators.add(a,b) It can lead to bloat.

That's not really a fair comparison. The first example is a fairly natural way that a reasonable person could model the logic in their head. Knowing that your programming language provides a more concise way is an optimization. A basic one admittedly, but a mere optimization nonetheless.

In contrast, your example is kind of the opposite situation - it's an example of forgoing the most natural, human representation in favour of a highly Python-specific one. In other words, the first one happens when you know the abstract logic, but don't know your tools very well; your example happens when you know lots of useless details about the tool but you're struggling with the abstract logic.

Actually, the example from the article suggests to me that the author misunderstands what I regard as the most fundamental programming skill: knowing the precedence of correctness over all other concerns, including efficiency. It's better to attach the right parts together badly than to attach the wrong parts like a pro.