When you have a nail in your eye, everything looks like a nail
15 Jul 2013
The instinct of most developers, myself most definitely included, is to gravitate towards technological challenges and hope that a product challenge or two gets solved along the way. When all you have is a new kind of ultra-scalable hammer that everyone on Hacker News is talking about, then you go around hitting everything with it until all your possessions crumble to dust and everyone you love is dead from massive head traumas.
When you don’t think about your code as a product then you fall back to thinking about and believing in it as technology. You don’t know how to move the dial on your user numbers, so instead default to whatever seems fun and programatically challenging. You build to scale to 100 million users before you have 100. You create a desperately terse Domain Specific Language before you have any real understanding of the Specific Domain your language is for. Maybe everything you’ve been doing for the past 3 months will be canned in a week because the market for hiring badgers via SMS was not as mature as you had hoped. But you built some sweet tech and had an intellectually intense time doing it, so at least you won’t feel like your time was wasted. Of course there is nothing fundamentally evil about said sweet tech. Even writing code with little merit beyond helping you understand Arel and practice using Vim is a great idea if you want to get better at Arel and Vim. It’s a terrible idea if you want to build a product, but when you have a nail in your eye, everything looks like a nail.
Thinking about your code not as technology, but instead as part of a product, means that you are positively overjoyed to fix the tedious problems staring your users right in the face. You make sure that they receive emails at the right time, that language is consistent, that error messages are informative. Maybe sometimes you get to work on a complex programming problem or two, but only if it’s what’s in between you and a genuinely improved user experience. You don’t assume that the solution to your abysmal numbers is allowing your future power users the ability to slice and dice and import and export their raw data in all sorts of innovative and creative ways. You instead see that no one really knows what your product is meant to do, and that you should probably just improve your homepage copy and add in a rudimentary onboarding flow.
I’m building a side project to allow teams to make sure code review gets done (KanbanCodeReview - sign up for beta access). And I do feel good about my code as a product. It codifies and enforces the way we do review at Copyin, and several people have said that they will use the crap out of it once it’s ready. But I still don’t really, really believe in it as a product yet. I still want to mount a little Sinatra app that processes Github hooks asynchronously and I still want to build an algorithm to automatically determine the most appropriate team member to review a given commit. And all the while I haven’t written any notification emails yet.
If you are an interested and easily intrigued person, it takes an enormous amount of energy to keep yourself focussed on the product in front of the technology. This energy is precious and very hard to come by. It can come from blind belief, future-customer-driven belief, or the fact that your code is being used or at least acknowledged by real people and so has become a product first and foremost whether you like it or not. So even if launching your app or feature early doesn’t teach you a single thing, it will keep you honest. It will remind you that your code is a product, and that you should be looking for and solving product challenges.
But noodling too far down a technological rabbit hole leaves you marooned from reality and the market. Technology won’t tell you it loves you. When it turns out you’ve gone down the wrong burrow and are knee-deep in an unidentified but pungent sludge, you won’t remember why you even started down this stupid hole in the first place. You will close your eyes, lie down in the toxic slime that lines the floor and await the suffocating embrace of rabbit faeces.
(thanks to Peter Nixey for the title)
The instinct of most developers, myself most definitely included, is to gravitate towards technological challenges and hope that a product challenge or two gets solved along the way. When all you have is a new kind of ultra-scalable hammer that everyone on Hacker News is talking about, then you go around hitting everything with it until all your possessions crumble to dust and everyone you love is dead from massive head traumas.
When you don’t think about your code as a product then you fall back to thinking about and believing in it as technology. You don’t know how to move the dial on your user numbers, so instead default to whatever seems fun and programatically challenging. You build to scale to 100 million users before you have 100. You create a desperately terse Domain Specific Language before you have any real understanding of the Specific Domain your language is for. Maybe everything you’ve been doing for the past 3 months will be canned in a week because the market for hiring badgers via SMS was not as mature as you had hoped. But you built some sweet tech and had an intellectually intense time doing it, so at least you won’t feel like your time was wasted. Of course there is nothing fundamentally evil about said sweet tech. Even writing code with little merit beyond helping you understand Arel and practice using Vim is a great idea if you want to get better at Arel and Vim. It’s a terrible idea if you want to build a product, but when you have a nail in your eye, everything looks like a nail.
Thinking about your code not as technology, but instead as part of a product, means that you are positively overjoyed to fix the tedious problems staring your users right in the face. You make sure that they receive emails at the right time, that language is consistent, that error messages are informative. Maybe sometimes you get to work on a complex programming problem or two, but only if it’s what’s in between you and a genuinely improved user experience. You don’t assume that the solution to your abysmal numbers is allowing your future power users the ability to slice and dice and import and export their raw data in all sorts of innovative and creative ways. You instead see that no one really knows what your product is meant to do, and that you should probably just improve your homepage copy and add in a rudimentary onboarding flow.
I’m building a side project to allow teams to make sure code review gets done (KanbanCodeReview - sign up for beta access). And I do feel good about my code as a product. It codifies and enforces the way we do review at Copyin, and several people have said that they will use the crap out of it once it’s ready. But I still don’t really, really believe in it as a product yet. I still want to mount a little Sinatra app that processes Github hooks asynchronously and I still want to build an algorithm to automatically determine the most appropriate team member to review a given commit. And all the while I haven’t written any notification emails yet.
If you are an interested and easily intrigued person, it takes an enormous amount of energy to keep yourself focussed on the product in front of the technology. This energy is precious and very hard to come by. It can come from blind belief, future-customer-driven belief, or the fact that your code is being used or at least acknowledged by real people and so has become a product first and foremost whether you like it or not. So even if launching your app or feature early doesn’t teach you a single thing, it will keep you honest. It will remind you that your code is a product, and that you should be looking for and solving product challenges.
But noodling too far down a technological rabbit hole leaves you marooned from reality and the market. Technology won’t tell you it loves you. When it turns out you’ve gone down the wrong burrow and are knee-deep in an unidentified but pungent sludge, you won’t remember why you even started down this stupid hole in the first place. You will close your eyes, lie down in the toxic slime that lines the floor and await the suffocating embrace of rabbit faeces.
(thanks to Peter Nixey for the title)