Recently, I announced that we were hiring a software developer for Code School's internal team:
The good Philip Arndt answered that:
It's a fair question since the meaning isn't self-evident. To me there are two basic circumstances in which you build software:
- the one where you build the software you own
- the one where you build the software somebody else owns
I think it's reasonable to call the first is "product work" and the second "client work". It's true that client work often still caters to an end-user that isn't directly your client, but with product work you are the owner. There is no interface between you and your end-user.
There's a certain appeal in the kind of freedom that product work affords. While you trade one client for thousands, it's much easier to say no to these thousands of clients, even if they're vocal. It imparts you with much more control over your priority.
I think of people who write software as tool builders. It follows in my mind that a tool builder should know how to construct a better tool. That doesn't mean the intended users of that tool are clueless about what exactly defines a good tool. It also doesn't mean that the user of the tool can't define constraints, requirements and suggestions to whoever builds it for them. Yet, what the user (or customer) pays the tool builder for is their expertise in the crafting of reliable and useful tools.
Now, what do I mean by "product gardener"? Well, just like a tool maker, there is a specific set of variables a gardener has to account for when building and maintaining a garden. When planting something, they need to prepare the ground properly; use the right kind of soil; the right amount of watering. As time goes by, a gardener can't just sit, enjoy the fruits of their initial labor, and move on to something else. In order for their garden to thrive, they have to follow a discipline. They have to attend to what they've planted; every day, every week, every month, every year. If they don't, well, the product of their labor will disappear. And despite my allergies, I really like gardens, so that makes me sad.
I think this silly analogy helps to outline the tension here. If you're excited by initial struggles, but tend to find the long-term work of sustaining something to be tedious or unfulfilling, then there's a good chance you're not made to be a product gardener. Maybe you're an explorer, opening new paths for people who couldn't find or see them before. That doesn't make you less valuable. Michael Lopp would describe you as a "volatile", then explain how crucial you can be to an organization's ability to innovate.
I once thought of myself as this kind of explorer. Somehow, I was able to crank out work from scratch in an afternoon, something I find very difficult to do today. Yet as the years passed by I kept stumbling on half-finished remnants of "good ideas" that had ignited fiery passion from me for a few hours or a few days or a few weeks. But that fire burned too quickly, it exhausted all the fuel. I honestly thought I would never be able to commit to any project that would last more than three or six months.
Then something clicked. Maybe I changed. Somehow, though, I feel like I've always had this constant gardener seed inside of me. It was just unfulfilled for a long time because I hadn't yet found a discipline and an environment where it could blossom.
I think that environment was Envy Labs, and especially Code School. I found a place where I didn't have to waste energy convincing my peers of things that I felt should be normal. Instead I could focus on my work. Oddly the nature and specific function of my work within Code School has evolved very often over the course of two years. I spent quite some time on support, so I was in direct contact with our end-users and their needs.
I think getting lost in the forest of people who use the tools you build is a rejuvenating experience. At first it might seem noisy. It's easy to let yourself be swayed by the people that complain the loudest. But eventually a sort of music emerges. You stop hearing the voices of individual people, instead you start sensing a breeze of discontent here, a buzzing of excitement there. In a very cheesy New Age kind of way, you start getting in touch with the nature of your users. A mix contexts, problems and potential solutions.
I could pursue this little metaphor yet further, but I think I've planted the seed of that idea firmly at this point. Now, concretely, what it means for us to be product gardeners is that we have to be careful not to lose ourselves by taking on too many tasks at once. Our main task is to sustain what has grown so far, and make sure people remain our priority. We have to accept that we can't be everywhere at the same time and that sometimes things must die so others can survive.
For example, in the past two years I've wanted to go on a rampage and build new features for Code TV, our repository of screencasts: to add @replies and better notifications, a full-text search feature, mark videos as watched only when people watch are done watching them, or provide subtitles and transcripts of all our episodes for people with disabilities or who don't speak English as a native language.
There are many more things I want to do. But eventually I had to resign myself to the fact that, while I want them, I don't need to build them right now. Somebody else can, and certainly will.
While talking with our team I often say that we should try to become the owners of whatever makes us lose sleep at night. While unfortunate, the absence of the features I listed above doesn't make me lose any sleep. But many more things do, and I have to make time for these.
If any of these thoughts made you sit up, shake your fist in the air and yell "YES! That!" at your screen while passers-by raised their eyebrows with concern at your rapidly declining sanity, then I beg you, send me an email, and come help us tend to our little garden.