Skip to content
Home » The Why of Building Software

The Why of Building Software

I’ve been writing my upcoming talk for FOSDEM and it’s made me confront the last twenty-five years or so that I’ve been professionally developing software. From the early days of learning the UNIX command line, shell scripting, vi, C and X11 primitives through being a paid software developer for the first time, an Open Source contributor, a start-up founder, getting into systems administration and configuration management, leading projects, leading development teams, designing products, logos, websites, writing, recording, talking.

Wow. Why do I feel the need to do all of this stuff? And when was I the most productive in terms of doing stuff that connected with me?

Fundamentally, the most engaged times working in software have always been when I’m given freedom, responsibility and support (from managers) in equal measure. Working with the freedom to explore ideas, responsibility to deliver as part of a team, and support to do both. At those times, I feel that I can contribute at my best. Working with people you care about, to build something you care about.

You have to be involved in the product – whether the product is music software like Rosegarden, or building accounting software for a global bank.

When I was building Rosegarden, I was also the customer.

When I worked in a bank, I worked with accountants. I eventually got to like and understand accountants. Learning what they need is learning their domain.

A few exceptions aside on moral grounds, I have no objection to which company I work with. Why? Because all domains are complicated, and all mean something to someone. The job of a software engineer is to conquer that complexity. If you don’t believe me then you should read Eric Evans’ Domain Driven Design.

As engineers, we are privileged to work with experts of all kinds, learn their ways, and provide them with software which fits their needs.

If you can, join me on Sunday for a deeper dive!