Years ago I read a quote about how to be a 10x developer and it stuck with me:
There’s another, more common way to be a 10x programmer: generate technical debt at a rate that requires ten other developers to clean up the mess. The real magic is that this feeds back on itself: you look more productive while producing garbage, and everyone else is less productive, because they’re bogged down in your disaster. Management then directs more resources to you, and less to everyone else, since you’re a ’10x programmer’ who is ‘getting things done’.
https://www.leadingagile.com/2017/08/search-10x-developer/
How it was
This stuck with me because I worked with a person who I thought was a prime example of this behavior. He was pleasant, a smooth talker, and everyone generally liked him. Many people thought he was super productive and a real go-getter, but I’d worked with him long enough to believe differently.
I distinctly remember getting a call from our project lead because I wasn’t at the end of sprint happy hour and I was in the lab working. I tried explaining that I wanted to fix all the stuff that was broken (by our 10x developer) so I wouldn’t have to go in over the weekend, and was told that I shouldn’t be a downer and to go out with the team. In the end I ended up just coming in over the weekend.
My frustration was two fold:
- The person responsible for making this mess was out the door sharply at 5 and never worked weekends.
- He never had to deal with the consequences of the messes he made.
The short of it was that I was constantly bogged down in his disaster. It felt like the work of cleaning things up wasn’t valued the same as his generating garbage. But, as we all know: “Nobody gets promoted for the complexity they avoided”.
How it is now
Perhaps because of the above experiences, I’ve developed (pun intended) a knack for fixing issues and cleaning up messes. I definitely enjoy the feeling of taking a file that is a mess and doing several passes of refactoring until it’s pristine. So often in software it’s hard to see your impact, and this is one of the few ways that you can quickly see that your work added value.
As a consequence, I’m often the person on code reviews with lots of suggestions on little things that make the code better. Things like “We could use logging instead of print here” and “We can simplify this logic by doing X, Y, and Z”. This was fine for a while, as my team is pretty awesome and everyone is happy to help makes things better.
We recently hit a turning point though, and I don’t think there’s any going back. As our team has adopted AI assisted development more and more, I’ve noticed a definite dip in quality. The code still does what it’s supposed to, but it follows the style guide and conventions we have laid out less and less.
Some of the things are just really weird approaches that, technically, don’t go against any rules (explicit or implicit) we have, but still just don’t feel right. Odd code smells and weird choices that make the code harder to follow and understand. These make code reviews take longer. As these have become more common it’s been getting harder and harder to really sit down and parse them all to see if there is indeed a better way.
Every code review I have to choose to let more and more small things that I’d normally try to correct pass just so that I can focus on the larger issues. The larger issues seem to be growing in frequency as well. Code reviews are growing in size an complexity, as it’s easier than ever to come up with more code that does more complex things.
The short version is that I am, like so many, drowning. I can’t keep up and I know it will only get worse over time. We’re all 10x developers now, and we’re bogging each other down in the disaster our AI tools are helping us make.
What can we do?
We need to start by working with our teams. To try to educate them to identify these issues themselves, as early as possible. It’s much easier for me to fix an issue I catch in my own code than it is to put that burden on my team.
I have found that the most effective way to write good code is just to make it harder to write bad code. Linters which run on save, formalized style guides, builds which fail on any issues, good tests, pre-commit hooks, quality thresholds, etc. All of this takes effort to stand up, but it’s really the only way to move the needle reliably. Automate it as much as you can.
We can also work to configure our AI tools to follow as much of the above as possible. There’s no reason these tools can’t adhere to the style guide and linting rules. This would help in reducing the cognitive debt that your team faces.
Finally, I think we need to just accept that sometimes code will be worse now. Trying to maintain an elevated level of craft on all generated code is a losing battle. You will only burn yourself out. Channel your inner Elsa and Let It Go.