Part of my job is doing market research, and keeping up on developments in technology. A lot of that means reading dumb shit people have written about tech.
This delightful piece sets out to debunk a few common "myths" about technology, development, blah blah blah. Which is fine, as a concept.
Unfortunately, like goddamned near every article on software written by someone who don't know shit about development, it quickly goes off the rails.
"Myth" 1: The myth of the 10x software engineer. The article argues against "the claim of “10-fold differences in productivity and quality between different programmers with the same levels of experience."
This is a myth? Horseshit. There is absolutely this level of difference between someone who knows what the fuck they're doing and regular jackoffs. I have worked with people who did fantastically shitty work, to the point that everything they touched for weeks had to be thrown out rather than finished by someone competent. On occasion, I have been that jackoff, when fiddling around with a very poorly understood system.
Can code reviews and better methodology help with this? Absolutely.
Who is going to have to spend time mentoring the underperformers? The 10x developer who would otherwise being squashing bugs or gluing together a new feature. Now the codebase isn't getting shit all over it, but new stuff is happening at a much slower rate.
Being able to solve a problem, correctly, and implement that solution in a bug-free manner will save at least 10x the time as having a half-assed "solution" that doesn't work or takes another 3 weeks to debug.
"Myth" 2: "the “exponential defect cost curve,” that is: the claim that if it costs $1 to fix a bug during requirements, it will cost ten times as much to fix it in coding, a hundred times in testing, a thousand times if the software reaches production"
Jesus fuck. This entire concept is why we leave comments in the goddamned code. Shit you fix up front, when the code is fresh in your mind, is a thousand fucking times easier than trying to re-work what's going on in detail several weeks or months later. Every time you go back into the code to fix a sufficiently complicated widget, you run the risk of introducing new bugs. Also, you will piss off your customers if these bugs make it to production. That means they stop being your customers. That means you get to look for a new fucking job, you stupid bastard.
Unclear requirements lead to shitty decisions made that will influence future development. If things are fucked from the get-go, it is an order of magnitude more difficult to fix them later since you have to either
a) re-write everything
or
b) write the fix around the existing bullshit without breaking anything else
The hippies will lie and tell you that everyone is magical and special and equal at writing code. They are fucking liars. This is why Geocities sites looked like shit, and professional stuff does not.
Clearly defining what needs to be done before you get halfway through it saves an unbelievable amount of time. This is why you don't build half of a fucking house before you have blueprints for the other half.
