Written by Bryan Powell. Founder of Metabahn, developer of Pakyow. Follow me @bryanp or email me here. Subscribe to the feed for updates.

!Magic

Making Over Preference

January 03, 2013

I recently tweeted three related thoughts:




This deserves more than 140 characters of context, so here we go.

When I was 9 years old my dad showed me how to write a program in BASIC that would solve some rather repetitive math problems. I probably didn't understand the program very well; it was a magical concept at the time. But the very thing that seemed magical to me then is why I learned to code and why I still code today: to make things that solve real world problems.

Many of the discussions between software developers center around the tools, techniques, and patterns behind software development. Preference often plays a large role in these discussions, sometimes creating arguments. None of this is wrong; discussion and debate can be productive and preference is important. I do think it's worthwhile though to consider what we decide to focus on.

Tools matter most in context of making. The sharpness of the axe doesn't matter if you don't plan to chop down a tree. A beginner might start with a dull axe, only to realize hours later that there must be a better way. So next time he sharpens the axe first (or acquires a chainsaw).

Even poor tools can be used to solve problems, and experience teaches how to find and use the better tools. This is a natural process; the desire to make good software leads to the best tools for making.

Using a tool because it helps solve a larger problem changes the conversation from what I prefer to how we can make better software. The desire to make software better is at the heart of a lot of the dissension-causing disagreements within communities of developers. Most developers are interested in moving beyond the tools so the real problems can be found and solved. Few just want to have an argument, and those that do are best ignored.

Dissension is not a requirement.

The problem, then, is one of perspective. As developers we should avoid viewing tools, techniques, and patterns as matters of preference. Instead we should view them from the perspective of making and leave room for many preferences. There's comradery to be found here, and a lot less conflict, I think.

PREVIOUSLY full archive