Software development is a loser’s game

I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe.

What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. Whoever had written this project before me wrote no tests, and basically brute forced features to work. A dropdown box that loaded options dynamically based on other user selections had 18 variables buried in the code where 8 of them were either unused or redundant. For a fucking dropdown box?

I told the PM 1 week in that I'm not going to make the delivery deadline and he should be advising the client of such.

---

I don't want to talk bad of my coworkers so I'll just say this. I'm the only developer in my company with a software background. Everyone else is electrical engineering/tech and it shows when you review their code. Comparing this "Amateur" vs. "Professional" article to what I am currently going through feels almost cathartic knowing this is something widely experienced in the field.

I truly love my job, but some days, like these last days, really make me want to unplug from the world and go live in the wild because not only do Amateurs make these mistakes, they're also blind to the Professional ways of approaching work. It almost felt like an argument at times convincing him that this "extra" work that was neglected previously is necessary and should be factored into everyone's projects, not just mine.

When I was a junior dev I had a tendency to want to rewrite everything. I remember thinking that most the code I was working on at the time was overly complicated and could be done with far fewer lines of code. Recently I realised I might now be the guy that now overengineers and writes overly complicated code. I think this is common trend for devs too, as you mature you get really good at anticipating future problems so tend to write code that doesn't just meet the current requirements, but can scale into likely future requirements.

I feel like I've kind of gone full circle and now and I'm starting to question if there is a middle ground between the simplicity of writing simple code to solve a very specific problem and the extra time required in writing code that scales. The reason I say this is because I realised devs working on my code often don't fully understand the reasoning behind what I've written anyway and I and the devs working on my code often don't have the time to read / produce documentation explaining the code in detail. I also can't guarantee I'm always available to review PRs and ensure the code quality is maintained, so perhaps most of the time it's wasted effort.

Also often you just don't know what kind of constraints devs are working under. I know for a few projects with tight time constraints I've been asked to do the bare minimum to patch certain bugs or add some functionality so we can ship ASAP. I'll normally push back on this if I feel it's a bad idea, but code quality isn't always the most important consideration.

I realise I'm much more open minded when reading code now because after 15 years as a dev I'm still not sure I always do things right myself.

While the rest of the list is valid the author could have stopped at the first item Standards and still have made his point.

Perhaps the most perfect example of that is why JSON won versus XML for data serialization. Many people will claim that it's because XML is bloated. After all this was the primary argument of JSON's inventor Douglas Crockford. They aren't wrong, but its not why JSON won.

JSON won because it's specification is tiny. When all the boilerplate is scrapped off the latest version is about 5 tiny pages of text any high school student can understand: https://tools.ietf.org/html/rfc8259

Compare that to XML:

* XML - https://www.w3.org/TR/xml/

* XML Schema - https://www.w3.org/TR/xmlschema11-1/

* XSL - https://www.w3.org/TR/xsl11/

Those are HUGE and they are written to conformance precision for implementation engineers. No high school student will ever read any of that for pleasure. I remember reading those when I first entered software development and absolutely everybody thought I was out of my mind and promptly discarded everything I said if they didn't already know it. I remember that being particularly frustrating because ever recommendation or proposal had to read like a pitch deck to a VC, but if I wanted to do that instead of engineering or product development I would be brand evangelism or merchandising.

XML for a data conveyance medium is extremely powerful, but in practice this is completely irrelevant. XML is a world unto itself in all of its capabilities and potential, but that doesn't matter if nobody is using it.

Most Americans, regardless of their actual educational attainment read at a 9th grade level (high school freshman). That applies to entry level software developers as well. Computer scientists and inventors are not the average of software developers. On one hand this is great, because I truly believe anybody can be a software developer and write really bad code. On the other hand this is horrible, because many people are code monkeys that write either bad code only or are fundamentally limited to a small subset of solutions limited by a small subset of tools.