Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up.
I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on getting it over the net as simply as possible, the end result usually means less code that's easier to understand.
Example: junior dev needs to write a data transformation pipeline. They write a microservice and deploy it in Docker on Kubernetes. They do a lot of hand-wringing about reactive design and non-blocking I/O. They end up wrestling with the deploy and getting it done on time. All it needed to be was a simple single-threaded command line utility.
In 15 years, I've seen this story play out tons of times... I'm basically watching devs trip over themselves. I'm not saying I'm perfect either, this has happened to me too.
You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.
> You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.
100% true.
People love to dig at Test Driven Development, but it solves a common problem and is great for junior developers because it has 3 important rules.
1. Understand your requirements. And not in a wishy-washy hand-wavey way. But in an explicit, expressed as a single test verifiable/falsifiable requirement.
2. Implement the simplest solution that meets your requirements. Don't over-engineer anything, don't chase the latest fad, don't sleeve solve a way more complicated generic problem that you think we'll hit later, because you don't have enough experience to know how likely we are to hit it and the costs to make that tradeoff.
3. Keep you codebase clean and well factored. Don't let cruft and hacks build up.
Ignoring TDD, any junior engineer that can consistently exhibit those three behaviors is almost by no longer a junior engineer. Those are hard things to learn as an early coder.
Yes as you become mid-level and senior you should be more independent and break the above often - but at that point you have good foundations and the experience to make the tradeoffs to know when to deviate and by how much.
TDD is a very effective method for solving a problem that otherwise often takes a while to solve. Developing good fundamentals.
I feel obliged to mention that this very often goes against "do the stupidest thing that will work".
Most of the time in my career a clean codebase has naturally led to an intelligent solution which is definitely not the stupidest thing that will work.
Finally, it's also often the case that stupid code requires exorbitant amounts of comments or documentation, undermining the notion of it being simple to extend (which many conflate with the original premise). A little bit more intelligent code is usually self-describing.
I think it also takes experience to see that simple solutions can be more robust; the more natural response to foreseeing future problems (another trait) is to have specific responses for all of them, which generates a complex result.
I once had a boss who still coded, even though all the developers begged him to stop. His code was spaghetti, but worse was his inability to come up with more than one solution to a problem. If the first solution he came up with was complicated and error-prone then that's the one he proceeded with.
At this point, I'm extremely unconvinced the problem is just education or juniority/seniority. The "paper factory" is just doing what companies are demanding. The real problem is a general lack of competence being used to market products, be they good when used properly (e.g. GoF, where many readers only look at design patterns and completely forget "composition over inheritance"), or snake oil.
I completely agree with you.
I'm sure there's some range of nuance to your point, but it's also in line with the iterative philosophy isn't it? Do you find patching/revising things later to skew better/worse or some other downstream consequences?
It seems like you find that approach more efficient overall?
The whole point of design reviews, code reviews, senior devs, and more is to ensure that stuff that doesn’t work or can’t be maintained doesn’t get deployed.
That part (especially the second: maintenance) is endlessly contested in calls until some of us just give up and let the others reinvent the wheel for themselves because they don't listen to experience.
Blaming all your issues on more junior members of the team is a huge red flag, and this article doesn't really offer any insight into how to bridge the gap between "amateur" and "professional" (which, imo, falls on the senior members of the team).
Senior members should set and enforce the standards via best practices, code reviews and setting the definition of done e.g. unit tests, data, deployable etc
And although it took me a while to understand what the author is getting at, I do kind of see his point which in my mind could be summarized as: slow and steady wins the race. Or: In order to speed up (in the long run), slow down (in the short term). Be conservative, be thorough, understand that developer productivity isn’t about that LOC per x unit of time.
One analogy that comes to mind for me is Formula 1. Sure, it would be faster, right now, to just not pit. You would have to drive into the pit, stop and wait for the tyres to be changed and drive out again. Meanwhile your opponents are zooming past you out on the track. But if you don’t pit, soon enough your tyres will be worn down and it becomes impossible to keep heat and performance in them, and after a while longer you might even have to stop completely due to a puncture.
The ‘pitstop’ could be anything that ensures productivity in the long term and as such helps in reaching the final goal, and those are the things that take a professional to understand the importance of.
I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).
Now maybe they did and the other person refuses to listen (not common in my experience), but I always wonder... you can't just make up 'rules' and expect folks to magically write good code because they followed a rule.
I wonder what his recruitment pipeline looks like where 80% of engineers end up not being productive.
Sounds like he's hiring wrong to begin with.
If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.
Practically the requirements are "have software that works, and will be sustainably developed and improved for 5 years". Making the trade offs in terms of "perfect code" to "good enough code" is what makes a software developer (in most settings) go from "good" to "great". Good software engineers can see all the edge cases and future paths. Great software engineers can prioritize those against business goals.
Just like "global variables and goto statements" is bad, so is "perfect, provably correct, and overtested" code in the vast majority of business settings.
You gotta think long term (usually)
This line is packaged to sound really insightful, but is it?
The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things.
If I write no software today, I've also written no new bugs. But have I made any progress toward achieving the mission?
Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility. It may be a necessary role at his organization, but I just don't agree with the cynical and depressing message.