11–20 of 211 posts
> 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.
Skills are nouns, but the list was all verbs. Weird.
——
EDIT: for example, the notion of a language “working” in a mechanical sense has only been around for the past 60 years. If there is a specific noun to refer to understanding those mechanics as you type, it is obscure. This 28-year old software engineer who has worked in both the US and UK has not heard it.
This centers on tooling and documentation, especially the README. I want a README that gets me set up and running as quickly and in as few steps as possible. Recently I needed to test out some stuff one of my teams was working on. It was a somewhat complex Wordpress project. I was able to get set up using our documentation, but a couple key steps were missing making it error-prone and unnecessarily aggravating.
Anthony Bourdain explains it as only he can:
The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.”
https://books.google.com/books?id=XAsRYpsX9dEC&lpg=PA65&ots=...
> 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.
Oh, yes, I saw stuff like this in Big Blue Company's source control. At a different company, I found stuff like: ZERO_INDEX = 0 ONE_INDEX = 1 return arr[ZERO_INDEX]
The solution to this problem is to add some sort of `NOLINT` comment to that line or, if possible, the comment that turns off that particular check. Then you link to the design document describing what "arr" is and how its interface involves accessing indices 0 and 1.
Or you could wrap "arr" up in a class or function of some sort so the code is theoretically more self documenting.
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 today forever, and failing to enforce or make explicit one's "today knowledge" in the code.
Kinda frustrating that an article calling out where programmers fall short was a non-responsive document that was almost unreadable on mobile. Mildly ironic?
What problem are you experiencing?
Earlier quoted context omitted.
Oh, yes, I saw stuff like this in Big Blue Company's source control. At a different company, I found stuff like: ZERO_INDEX = 0 ONE_INDEX = 1 return arr[ZERO_INDEX]
That's usually a sign of overly aggressive linters and static analyzers. They probably got a "no magic numbers" diagnostic. The solution to this problem is to add some sort of `NOLINT` comment to that line or, if possible, the comment that turns off that particular check. Then you link to the design document describing what "arr" is and how its interface involves accessing indices 0 and 1. Or you could wrap "arr" up…
The reason we got code like this was because of outsourced contractors cargo-culting something they saw elsewhere.
> 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.
> return a && !(b || c) || d;
I've seen (pardon the formatting, I'm typing on my phone):
> if (d) {return true}
> else if (a) {return !(b || c);}
> else {return false}
It's usually a choice to be verbose for clarity.
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…