Strive to be a 0.1x engineer
Don’t be the engineer who produces 10x the code. Be the engineer who produces 0.1x the code, but all of it matters.
That was the takeaway from an interesting discussion on HackerNews this week. Benji Weber wrote an article titled Why I strive to be a 0.1x engineer where he argues that the less code you produce, the better off you are.
Code, you see, has diseconomies of scale.
Traditionally speaking, productivity is measured as output per unit of time. So the more you produce in less time, the more productive you are.
But when it comes to code, the more you produce, the more cost you have in maintaining the codebase. The longer it takes to train new people, the longer it takes to grok what’s going on when fixing bugs, the longer it takes to train users, and basically the more code you have to deal with the more your life sucks.
My favorite comment [2] illustrates Benji’s point perfectly:
Throughout my career I’ve definitely been lumping the skills described in this article about not doing work in with the whole “10x developer” catch phrase.
Like:
Customer needs a CMS.
Clyde looks at the requirements for the CMS. He sets off to write hundreds of thousands of lines of code by himself, complete with CI, continuous deployment, tests and documentation because he is a very good developer. Through the course of the project he leverages his years of experience and background in CS and engineering to make a well-factored body of software that will be maintainable for years. He did this in only a couple months.
Bob looks at the requirements for the CMS. He thinks “I know, I will use a good application framework and an ORM”. Bob writes a couple thousand lines of code with all the tests and stuff that Clyde had. Bob’s tests and app code, however, are more focused on the customer’s needs, making in maintainable for anyone who can read the documentation of the software he’s chosen to use. It takes him a couple weeks.
Alice looks at the requirements for the CMS. She realizes the customer will do just fine with Wordpress with a couple of tweaks. She sets up a hosted blog so nobody has to actually maintain it. She has better shit to do with her time.
Alice did the least work but that doesn’t make her less productive. You’re solving problems. If you do work to solve those problems, fine, but having more “output” doesn’t make you go from a 1x to a 30x engineer.
This of course sparked a debate on whether Clyde, Bob, or Alice are the best engineer. The answer depends on externalities, but I think Clyde should get disqualified right off.
I’ve been a Clyde before. Don’t be a Clyde. You will never catch up to the state of the art. Never ever. Not in a million years of pouring your heart and soul into it.
Great way to learn though. Teaches you a lot about how to pick the best existing framework/CMS too.
A different comment [3] pointed out that sometimes how good you are doesn’t even matter:
Just like you can’t tell a high performance car from a low performance car in a school zone, so some businesses are not tackling hard enough problems to differentiate between programmers.
Something to think about. You’re building a basic CRUD app for a unicorn startup. Does it really matter how good you are?
Your startup is just a CRUD app when you really think about it. Do you really need to be so smug about who you do and don’t hire? Like, really?
Fundamentally, Benji says that a 10x engineer working on the wrong things and a 0.1x engineer working on the right things, have the same exact productive output.
Given the cost of maintaining everything we build, it would literally be better for us to do 10% the work and sit around doing nothing for the rest of our time, if we could figure out the right 10% to work on.
We could even spend 10x as long on minimising the ongoing cost of maintaining that 10%. Figuring out what the most valuable things to work on and what is a waste of time is the hard part.
Read the HN thread and article, it’s a wisdom treasure trove
What do you think, is it better to produce less or more? Write me an email (swizec@swizec.com) or tweet me (@swizec). I promise to reply.
If you liked this article, you’re going to love the one I send next week! Subscribe here for updates.
