When I read about the 10x programmer I think, “That’s nice, but it isn’t everything.” They are the big guns that cause a lot of damage, but they don’t aim themselves.
I’m interested in The Curious Programmer, who is less understood, but just as valuable.
The curious programmer is, well… curious about things.
The curious programmer
- is independent and self-motivated.
- is modest as they know they are never done growing.
- asks why are we building something. What is it for?
- does experiments to find the right way to build something.
- doesn’t accept the current assignment as what actually needs to be built.
- builds because building is fun.
- increases the value of an entire team, not just themselves.
The curious programmer cannot stop being curious.
If you are lucky enough to find a 10x programmer, you should hire thon. Most hiring managers, though, don’t recognize the curious programmer (which is just as rare) and let some real gems slip through their fingers.
Jon is a programmer I’ve worked with on and off for the past 15 years or so. He had moved into management for a while and was unhappy dealing with politics and such.
In one of our ongoing 1:1 lunches, the only time he lit up was when he showed me his cycle-accurate Apple II emulator that he’d built from scratch. Why had he built it? Because he wanted to preserve his old code that he wrote in high-school. And because it was hard. And because it was fun.
In his own words…
The Apple II emulator I built is actually pretty pedestrian in comparison with some of the other ones out there. Cycle accurate simulation is entry level in that space, and doesn’t suggest any particular expertise on my part, just a lot of interest in doing things right (that was probably your point, but it wasn’t “super hard”). There are some pretty crazy emulators out there that will actually work out the appearance of scan lines and some of the NTSC artifacts that are inherent in Woz’s goofy video DAC design - so you really feel like you’re looking at an Apple II monitor. That’s some serious dedication. I never had any interest in going that far.
The one unique thing I did in the Apple II emulation space was a cycle accurate model of the disk hardware, including a software simulation of the disk controller that could be hooked up to a logic analyzer. This allowed me to capture copy-protected disks and emulate the copy protection accurately so that they would run properly in the emulator. Most of the other emulators expect people to strip the copy protection in order to run software, but since I’m emulating at the level of the read head pulses - with timing - things are pretty high-fidelity.
See the modesty there? This was seriously hard stuff, but he knows it could have been better. That is curiosity at work driving a programmer ever forward to continue learning and keep growing.
Sometime over lunch, I suggested he go back to programming and focus on having fun. He went on to build Xbox-One’s multi-vm/graphics aware memory manager and worked closely with David Cutler on the hypervisor. Just as importantly, he constantly asked questions about why were we building this or that and he helped focus the rest of the team on what was important. There are many great examples here, but they will have to wait for another time/year/decade…
Jon is becoming a 10x programmer (if he isn’t already), but he also improves everybody around him by asking the ‘why’ question. His curiosity made the entire core OS team more efficient.
I follow Oona Räisänen, @windyoona, on Twitter because she is an obviously curious programmer. In her blog post Mystery signal from a helicopter, she had noticed a weird noise in a youtube video and then proceeded to decode the digital signal that leaked into the audio track. Nobody asked her to do it. She was just curious. She has many other posts describing her explorations in signal processing, security, and more.
This sort of activity is how you grow. She’s early in her career, but shows the hallmarks of somebody who pushes themselves and grows rapidly. Because she can. Because she is curious.
I don’t care how much specific experience she has in any field. She’s the type of person you make a long-term investment in.
As for myself, I’ve always tried to have at least one extra-curricular project going at any given time. These range from various physics simulators, to thermoelectric devices, to building a web search engine. (sort of, but not really - it does a specific thing that I wanted and couldn’t find anywhere else)
I didn’t think about those as being curious until recently, but I do know that some of the best lessons I’ve learned came from these projects.
Every time, I’ve learned something new or met someone (or usually both), that experience has helped me grow. For example, when I built the search-engine-not-really thing, one of my goals was to learn how the non-Microsoft world works. I have since learned the joys of Ruby on Rails, have a much better understanding of web crawlers/stemming/stoping/reverse-indexes/etc, and practice MUCH better test methodology through minitest and/or rspec.
One of the best things about curious programmers is that they make the teams around them better. A 10x programmer can do some crazy-good work. A curious programmer can make a whole team crazy-good.
The way they improve a team is by asking questions. Why are we building this? Is the user really going to care about this thing we are putting effort into? (often the answer is no.)
When everybody is just doing the work they are assigned, you end up spending a lot of effort on things that don’t matter. I don’t care how good you are at understanding users and designing products. You will benefit from having a curious programmer who is deep in the implementation asking some hard questions.
The curious programmer also naturally does experiments to determine what is the best path to take - before investing in the final/real solution.
Teams can get annoyed that the curious programmer is asking all these questions instead of just getting to work and banging out some code. Don’t fall for that. Take the time to answer the questions and be open to cutting work that you probably don’t need to do.
The personal benefits of allowing yourself to be curious are profound. We learn by doing. It doesn’t matter if it is doing something you are assigned or something you just want to do.
If your work involves doing the same thing over and over, you’ll get good at it - and then stop growing. Time to spin up a personal project focused on something you’ve never done before.
Don’t just focus on the thing you are building. Experiment with test methodologies. Learn minitest or rspec. Use a different database. Build some hardware. I don’t care what you pick. Just pick something that sounds fun or scratches an itch.
The fastest growing programmers I know do projects that weren’t assigned to them. They end up with higher salaries more quickly. The things they learn on the side usually translate to better performance on the job, often in ways they didn’t expect.
Interviewing for Curiosity
It is easy to interview for curiosity, and it is a wonder that most hiring managers don’t do it.
Simply ask: “Describe a project that you worked on that you didn’t have to. A hobby, or a passion or something like that.”
Most people can’t describe a single project that they worked on independently. Something they did just because they wanted to.
Those that can, display their passion and curiosity quickly. The curious programmer can’t turn it off, so it comes through loud can clear.
Most teams, and most managers are overly focused on interviewing for the specific skills they need right now. They undervalue the affect people will have on the team around them and they don’t consider rate-of-growth over the course of whatever project they are working on.
In other words, there are under-valued people out there that you can get for your team.
I think you should let yourself explore personal projects. Building something because you want to shows ambition, curiosity, and a desire for personal growth.
Hiring managers should be aware of curiosity, especially when interviewing programmers. Once they are on the team, the manager’s job is to foster questions, and help the rest of the team to not get annoyed that they are being asked.
I’m pretty sure curiosity is part of that vague quality of being google-y. Teams that embrace curiosity end up being more efficient and build more customer focused products in the end than teams that focus on short-term efficiency or just building to the plan.
Curiosity projects can be something at work, but it doesn’t count if it was assigned to you. It needs to be something that you chose/proposed, and followed through on your own.
Because you wanted to.
Because you are curious.
Some good discussion happening on Twitter.
Non-technical or non-coding projects totally count! The point is to stay creative by working on things you are personally interested in.
Also, too many companies discourage personal projects for various reasons. If they are worried about getting every tiny bit of productivity out of someone, then that is a misplaced goal. People do their best work when they are rested physically, mentally and creatively. Curiosity time is part of that.
The person you are looking to hire (or have already hired!) isn’t on your team for an instant in time. They will/should grow and become more valuable to you. The goal is to identify a high rate of growth and encourage it. Many managers look for growth, but then put in place rules that clamp it down.
My personal projects made me MUCH more effective at work even though they had nothing to do with my work either officially or in subject area. The fact that I was investigating ideas and tech (Ruby on Rails) that were completely divorced from work led me to unexpected learnings that I was able to apply on the job.
Another reason projects shouldn’t look like work is that you don’t want to burn yourself out. Projects should be fun time, not work time. Too many programmers I know drive themselves to the point that their actual efficiency drops to the floor, even though they can say they are working crazy hours. The quality of their work suffers. See this blog post by @LiaSae.
Quality beats Quantity when it comes to both lines of code and hours worked. Rested, healthy, happy programmers are the best programmers.
Crunch time can happen, and may need to happen occasionally. However, it isn’t sustainable in anything but the short term. Long hours worked does not mean quality hours worked…