Coding is not enough
Or: my philosophy towards software and development.
When I was younger, I was fascinated by computers. Playing with computers was like going on an adventure in your neighborhood and discovering the wonders of every little corner. It didn't take long before I got bored of the possibilities my computer had to offer: I wanted to make my own software instead of using that made by others.
Over the course of the last twenty years, I've noticed that my philosophy about software and the development thereof differs significantly from many other software developers and IT people. To me, software has always been about the people. While the technical aspects of making software is fun, software derives its main purpose from being useful to people.
Lots of developers and IT people value things like "clean code", "technical simplicity" and "elegant architecture". They want to work with cool technologies. They also tend to hate things like marketing, sales and promotion. And in an organizational context: they want to focus, skip unnecessary meetings, avoid procedures, etc. All very understandable. I'm like that too – up to a point.
But where I seem to differ from many others is that I consider all those things to be of secondary importance, not primary. Since I believe software's main purpose is to be useful to people, I would do everything I can to e.g. achieve better usability or meet organizational goals, even if that means less elegant code or more complexity. When making software, I consider the whole product – including marketing, documentation and people/organizational concerns. Not just the parts developers typically enjoy or technical elegance. Software isn't complete without all the "fluff" around it (which I don't consider fluff, but equally essential parts of the whole thing).
In other words: I believe software should just work, and should be simple from a user perspective, not necessarily a technical one. And I'm willing to do boring work to achieve that goal. Attending "boring" meetings? Yep, if that serves an organizational purpose. I just do whatever it takes.
I remember having a discussion on a developer forum in the early 2000s about writing software in Java. I pointed out a major problem with Java, namely that it imposes a bad installation experience. It is confusing to users if one has to tell them that they need to install a JVM first. Plus, a JVM is a multi-MB download (back then broadband was scarce). Other developers gave me virtual blank stares: they couldn't imagine what I was worried about. Though to be fair: maybe they were strictly thinking about business use cases where installing a JVM is no big deal, but I was thinking about use cases with average users.
More recently, I pointed out another major problem with JVM-based apps: bad startup experience. Starting Java apps always take more time than I'd like, so it feels very annoying. JVM developers tell me: that's not a problem, once the JVM is warmed up everything runs very quickly. Yes that is true, but that's not the point. Subjective user feelings are just as important as (if not more than) objective metrics. Besides, the JVM warmup argument does not apply to the use case of CLI apps.
My philosophy is embedded into one of my most prominent works, the Passenger application server. We've gone into great lengths to:
- Autodetect the system setup and give OS-specific advice during the installation process.
- Autodetect application properties in order to avoid needing the user to configure things.
- Autodetect OS bugs and application bugs in order to give actionable advice.
- Provide OS-specific packages such as DEBs and RPMs.
- Integrate with Nginx and Apache, instead of requiring the user to setup and connect a separate component.
- Write pages upon pages of documentation.
All of this took an incredible amount of boring and painful work to achieve (I'm looking at you, you abomination called "Debian packaging"). It also made the Passenger codebase more complex. No other software in this field that I know of goes into such a great length for the sake of user happiness.
I have recently discovered that "entrepreneur-programmer" is a thing. Yes, I think that's what I am.