The 10x programmer in action
The 10x programmer is a controversial topic and has been discussed a lot. It’s a myth. No, it’s not. Most often, it’s blind men and an elephant. The truth is a bit of this and some of that.
Let me narrate a small incident that spanned an hour’s time. Repeat this over and over again, and you end up with 10x impact.
Click, whirr
So the microservice, tested and ready, was deployment to staging. It had to go live today. The Kubernetes pod started, and then the program crashed.
What happened next is a glimpse of how the 10X programmer operates and why it’s such a big deal. It all happens so fast, you have to slow down and examine this in “bullet-time”.
The instant the pod came up, the programmer ran the migration scripts to update the database. “Hmm,” he scratched his chin with zen-ish calm.
He wasn’t flustered or disappointed when a long error trace appeared. Shit happens. For a reason. He quickly scanned the error message to see what was the problem. In a flash, the culprit was identified. The error was related to the use of a JSONB field type.
While most databases were using PostgreSQL version 10 database, this particular one was a 9.3 version. But, our programmer isn’t aware about the version on which this instance was running.
Here’s how the mind computed: We have a JSONB error, but this is tested code that has worked well in dev and test. So it looks like an environment issue, and in this case, it’s the database server we should focus on. Yes, it’s a database version issue.
“Looks like we are working on an old version of PostgreSQL,” opined the programmer.
See that? In 10 seconds the programmer accurately diagnosed the crux of the problem. An even more astounding fact — this code was not even written by him! To understand the 10x programmer, you need to see how this situation would have unfolded with th 1x or 0.5x programmer.
First, they would be disappointed. Then they would stare at the error as if it would make it go away. Then, self-doubt would manifest. A process of trial and error would begin without understanding what’s happening. A few wrong hypotheses would be made and wrong solutions tried. The really smart ones would copy the error and try to google why this happens and get a hint.
After having wasted an hour, they would approach the team-lead and get unstuck. One hour vs. 10 seconds. That’s not 10x but 360x. Let’s move on.
Our protagonist now has a hypothesis. I know for a fact that it’s true and said, “Yes, you’re right, that database is running PostgreSQL 9.3”. But our programmer doesn’t want to waste time without establishing the truth. He makes a phone call to the DBA and confirms the hypothesis.
Great. The problem is now known, and we are 50% on our way to the solution.
There are only a handful of people throughout my career that I have worked with and would call 10x. The one trait that they hold in common is not that they type faster, it is rather than they don’t get blocked and lose time. Even when taking on harder problems, being able to efficiently diagnose and treat the problem is a hallmark of 1/10x thinking.
— Andrew Lucker, The 10x programmer is a myth
A Lapse
By the time the phone call is completed, the 10x programmer knows what needs to be done. If we have to support old database versions, we shouldn’t be using JSONField but use TextField instead.
Because the turn around time is so less, our hero slips into mechanical mode, fixes the code, goes through the build cycle and a new deployment ready.
But it’s a lapse. Not because the work done was wrong. It’s right. But it wouldn’t help in this particular situation. The new version is deployed, and it fails yet again. Same error. But yet another situation to shine a light on the 10x programmer.
A chain of thought races through the mind — “while we have fixed the problem in the code and update the migration scripts, the problem is embedded deep in the migration history. There are 19 migration scripts, and the problem is in the 9th migration script. It’s not possible to redo the migration scripts as it will impact other deployments. We will need to fix this in an ad-hoc way.”
Once again clarity in understanding the root causes, an understanding of how to address the issue and finally having the pragmatism to pick the right solution. All this in no time.
The key contrast between a 10x programmer and a 1x programmer is the speed and accuracy with which you get back on the track versus the cluelessness.
You know the 5 Ws: “Who, what, where, why, when.” While these all apply to software development, I want to focus on the three characteristics that define 10x developers. These three things differentiate the average developer from the 10x developer: what, why, when
There’s more
The programmer decides to patch the migration scripts for this instance and move ahead. But it’s not possible to edit files from within the Kubernetes pod since it’s a stripped down Linux image. The experienced programmer is aware and edits it from outside and overwrites the file. After getting into the pod to run the script the programmer realized one more file had to be edited. There’s yet another trick up the sleeve. So what if you can’t edit the file when you have sed -i s/x/y/g abc.py
?
The 10x programmer is adept with his toolset and uses the right tool at the right time to get the job done. The rookie meanwhile struggles at every step and can benefit with a push and a lift every so often.
Soon, the problem is fixed, and the service is operational. Another productive day, another feather in the cap. Ho hum.
To be sure, we shouldn’t confuse the 10x programmer with a programmer with 10 years of experience. A programmer with just 2 years of experience can be a 10x programmer while a 10-year programmer may still be a 1x or 2x programmer.
It’s the high-velocity learning skills, scientific attitude, habits, tools and the mind-set that set programmers apart.
Goodies
Here are some more good reads about the 10x developer.