The War On Waste - or Why I Focus On Libraries

Skip this if you're not in a philosophical mood. It's a 1000-word soliloquy about personal goals and regrets.

Also, despite the next section, I am pro-Microsoft. My personal goal is to make developers happier and more effective on whichever platform(s) allow me to do so. Also, vendor loyalism in software often hurts the vendor - insular feedback is tremendously destructive.

Background — Waste

During my pre-2008 loyalist phase, I wasted precious years struggling with sub-par tools and writing mountains of boilerplate code. I trusted my peers (and even — foolishly — technical evangelists who've since moved on) to know which tools were best — after all, they'd been in the business much longer than I.

In defense of my peers and I; when one works exclusively on a platform of black boxes, guessing only through inference of results how they operate, one tends to stop questioning the manufacturer's guidance. Belief systems usually form, evidenced by code rituals and cargo-cult behavior. Shotgun programming proliferates, and manufacturer advertising is absorbed as if it were truth. Logic, without good data, is useless to every mind. Software, without source code, is an endless quantity of bad data. Demand source code for everything you touch. As the depth of the software stack increases, vendors who don't provide source code and transparency will reach a paralysis point.

Our planet is being revolutionized by software, but in a horrifically primitive way. Man-decades (sometimes centuries) of human creativity — per business — are spent to reinvent line-of-business software, which is used improperly (if at all) by a handful of people, and thrown away after a few years. Meanwhile, projects and organizations with a demonstrably positive influence on the world struggle to accomplish their (often unique) software goals. Despite an explosion in the number of software developers in the last two decades, very little has changed about what wastes our time and energy. For a profession that builds its own tools, it's extremely shaming that leaky abstractions are still so prevalent and that code reuse is so rare.

Software has a human cost

As developers, we tend to pour our mental energy and health into our work, leaving us so mentally drained that we are often ineffective at life itself.

I admire and envy those who balance work and life easily, who can leave problem-solving at work. I've never been able to. I shower thinking of algorithms. I shave while trying to simplify interfaces or APIs. To expel a problem from my brain, I have to read an extremely absorbing book — or replace it with a better problem.

Based on those I've met, I don't think a healthy balance is the norm for software engineers.

Software has a human cost, but that cost is different for everyone.

For me, it first struck after 4 years as a paid developer. I was 18. I take 4 medications and 5 supplements every morning as a result. My eyesight is slowly worsening. My daily visits to the gym are driven by my desperation to recover; to be around when my son is grown.

Minutes in which I have mental energy to expend are precious to me now; I don't take an hour of coding for granted.

No sum of money could justify what I (or countless others) have put into software. Our best hope to balance the scales is to translate our past, present, and future time into as much net happiness for others as we can.

Open source

I can't force the world to adopt or create open-source. Economics (at best) suggests a slow erosion of proprietary systems, but at the current rate it could be decades before we see code reuse exceed duplication — if such a thing occurs.

The sheer demand for software developers is also two-edged sword. It raises salaries, but also makes it that much harder to fund software that doesn't generate revenue.

Open-source tackles waste head-on, often fighting against massive advertising budgets with only agility and developer altruism. And somehow, it's winning against more wasteful models.

I think many confuse the enemy here. It's not Microsoft, not Apple, not closed-source software. It's waste itself. Our enemy is the squandering of human creativity, the art burning in piles of discarded one-use software.

To me, the Apache and MIT/BSD licenses are the most effective at reducing waste.

I can't find the GPL attractive. What benefit can be had by preventing closed-source programs from using your library? Developers aren't in charge of business decisions; they're just trying to get their job done. They're probably more grateful than most for what you've built, and almost as likely to contribute back. Excluding the average developer doesn't help you, them, or anyone.

There is no war between open and closed source software; only against waste.

What drives me

Lacking influence or riches, I focus on building tools.

I patch (and build) libraries to save developers time and frustration. You should, too.

Good ideas are contagious, even when implemented in the briefest manner possible. Show just one person what could be, and soon it will be what is.

Simplify the complex. Eliminate leaky abstractions. Reduce code noise. Automate the mundane.

Help developers focus on the unique parts of their challenges, and you've multiplied how much they can accomplish with their time.

Remove useless disruptions so they can spend more time in the flow, and you've made them happier people (clinically proven). Flow is one of the primary causes of happiness; leaky abstractions make it harder to be happy.

This is a goal every developer can achieve. Fixing a bug might save 100 people 30 minutes of frustration. That's a massive win in terms of net happiness, even if it was hard for you.

Just the psychological effect of a pull request is enormous to a library developer. It's a concrete validation that their library is useful, worthwhile. And as an extension, that they have been.

Select your tools with ruthlessness; repair them with consideration. Require source code to everything you touch. Optimize for net happiness.

Published on

About Nathanael

Nathanael Jones is a software engineer, father, consultant, and computer linguist with unreasonably high expectations of inanimate objects. He refines .NET, ruby, and javascript libraries full-time at Imazen, but can often be found on stack overflow or participating in W3C community groups.


If you develop websites, and those websites have images, ImageResizer can make your life much eaiser. Find out more at


I run Imazen, a tiny software company that specializes in web-based image processing and other difficult engineering problems. I spend most of my time writing image-processing code in C#, web apps in Ruby, and documentation in Markdown. Check out some of my current projects.

More articles