Jeremy Kahn's Dev Blog

There's always a method to my madness.

Software and Amplification

Programmers exist to automate work. This isn’t a new idea, but it took me a while to understand this simple concept. Programming with automation in mind has subtly caused me to make smarter, clearer decisions when designing a solution. This idea of automation has also helped me make better UX decisions. Even as a strictly non-designing developer, I have to do some degree of UX design in my work — sometimes a mockup takes a UX detail for granted, or I’m just working on a personal project without the help of a designer. In any case, keeping my automation imperative in mind has resulted in more effective results.

It’s extraordinarily useful to have a guiding motivation or philosophy. This is the single most valuable lesson I’ve learned from Bret Victor. I realized recently that, as a software developer, I have the potential to not just automate work with machines, but to amplify my efforts though other people.

Amplification, in a general sense, means to take a signal and increase its strength. Lots of tools allow us to amplify ourselves. Amplifiers in the context of music create a greater sound signal, but this is just a literal way of interpreting the concept. The printing press allowed Johannes Gutenberg to amplify the message of the bible in the 1400s, and radio amplified the reach of popular music in the 1900s. In either case, technology amplified a message in such a way that many more people were able to receive it than was previously possible. To me, the amplification potential of the web is what makes it the most interesting technology in human history.

There is more to amplify than ideas, though. Software, thanks to trivially easy digital reproduction, allows us to amplify processes. If I find a solution to weird CSS bug, I can make a Github Gist and share it with the world about as quickly as I can type it. If my solution becomes ubiquitously known, nobody ever has to spend the time to solve that problem ever again. This is why you don’t ever have to worry about CSS resets. A software solution can be reused an infinite number of times. As a mortal, I think that’s pretty cool.

While this is all nice and idealistic, things get a little more complicated when you consider that quality is amplified as well. High-quality software solutions can make the world a much better place. Linux, Firefox, and jQuery come to mind. These projects aren’t perfect, but their positive impact on how the world works is undeniable. On the other hand, low-quality solutions can create significant problems that last for decades.

At Jellyvision, I build JavaScript frameworks all day. This is a dream job for me, but it’s also a huge responsibility. I develop tools that the rest of my team depends on to work and be effective. If I do a good job, everybody is happy and productive. I do a poor job, everyone is slowed down and my code is quickly considered “legacy software.” Because of this, I work very carefully. I spend as much time writing documentation as I do code. I iterate on my ideas and don’t ever consider something “done.” I also make sure to share my work frequently and get feedback from the people who will be depending on my code. This works out nicely, as it doesn’t just result in better work, it makes my job easier and more enjoyable by providing clarification and direction.

If you build tools, you are amplifying your solutions through others. Lots of people using a high-quality tool results in high-quality collective output, but the inverse is also true. There’s a growing sentiment in the software world of ”just ship it.” Shipping is important, but it must not preclude quality. The code you write may be used by millions or even billions of people, and it may happen faster than you think. When you consider how much collective human time your work may cost or save, it isn’t unreasonable to take a breath, reconsider your ideas, and get the job done right the first time. I’m not advocating that we all spend an inordinate amount of time tweaking and perfecting. With all things, balance is key. Ship, but don’t ship shit. And remember that finding out who introduced a bug or made an ill-considered design decision is just a git blame away.