31–40 of 211 posts
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…
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…
I don't think these accusations are fair. The author has been programming since at least 2009, and is degreed in math. They also wrote the "think in math write in code article" that people here seemed to like quite a bit last week.
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…
(1) Most engineers we notice could be blowhards. They tend to be a minority of any particular engineering community.
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…
I have a feeling you felt hurt on those points?
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…
> 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.
let isBoolean = false
if (booleanComparisonOrComputation) {
isBoolean = true
}
...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…
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
Earlier quoted context omitted.
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…
We had no linters enforcing the "no magic constants" convention. If we did, I'd question the sanity of the engineer who added that linter. The reason we got code like this was because of outsourced contractors cargo-culting something they saw elsewhere.
Correcting this sort of stuff is the job of a senior engineer, though. If it's extremely frustrating, I'd become independently wealthy or stay away from technical leadership positions.
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…