The Tools vs. End Product Spectrum

It's no secret that there's an ongoing, accelerating proliferation of tools for makers of software, especially if you write code. New and evolving programming languages, frameworks, libraries, databases, PaaS offerings, and more show up seemingly every day.

Some of us are energized by this explosion and chase the bleeding edge. Some ignore it as much as they can and stay mostly in their comfort zone. Most people live somewhere in between, but there aren't many people who make software who don't care deeply about the tools they use to do that job, no matter where they fall on that spectrum.

Over the last couple of years I've noticed a shift in my own thinking and behavior along that line that makes me wonder about a potentially more interesting axis: the spectrum of the tools used vs. the end product produced with those tools.

I'm a (mostly lapsed) guitar player. In the guitarist community there's a common phenomenon called "GAS" or gear acquisition syndrome where people who are really into guitar can't get enough of buying yet another guitar, amp, pedal, or processor in search of the perfect tone. I've had serious cases myself¹. But, Kurt Cobain played era defining riffs on a cheap Fender mustang running through a $30 boss DS1 distortion pedal. Sometimes the guitar isn't the thing in the way.

Great tools can make a big difference, but these days I'm mostly interested in balancing learning of new tools in concert with using the ones I already know in order to efficiently produce the end result I'm after. That, and making progress in less calendar time.

How many side projects would have gotten off the ground if I didn't try to tie that project to also learning a new tool in parallel? What if I split out small, breakable toy² projects from my "I want to make this thing" projects?

When I recently wrote about finally learning Ruby on Rails, I wrote from a perspective where the learning material didn't match the web development world I lived in. But, what if it does match a much wider world that still serves the huge need for server side generated, shorter session web sites vs. high engagement, long session, single page web applications? Maybe good old Rails is still the fastest and best solution to that problem and a great solution to many others, and that's the point?

This past fall I was thinking about devoting my full time and effort into my software consulting business, and I got a great piece of advice to take a free email course from Brennan Dunn called Charge what you're worth, which among many other things³ urges freelancers to stop calling themselves (X tool or language) freelancers and position their value based on the end results you can create for people - something which is a key insight for way more than just consultants.

While I didn't take that path as my main focus, I have gone so far as to fully shift my primary day job role from software engineering to product management. However, I do still have a burning need to directly make things. And so, my toolbox still has to evolve to help me make those things.

The question I'm asking myself and other makers of software these days is: what are your favorite tools now? What is the next tool you are looking to learn how to use? Now, what are the things you can make with those tools that you couldn't before? I want to hear everyone's answers to those questions - and the more I tease that question out, the more I think there might be an underserved community on the other side.

If this resonates with you, email me. I think there are more of us than you might think, and we might be able to help each other and our friends and colleagues build better things.

Tags

• product
• technology