These statements are about my self-conception as a software engineer and platform architect.

Process

For me, writing software is a twofold process. On one side, it is a creative act, much like writing text, or giving a talk. The other side of it is a structurable task, something that can be defined in terms of specifications, conceptual models, and (semi-)formalized development processes.

When it comes to expressing yourself to someone else (or something else, for that matter), I can see a lot of similarities between a natural language and a formal language — both demanding a certain level of precision and abstraction to be well understood. Likewise, both can suffer from the use of incorrect abstractions, useless repetitions, lazyness, and time pressure.

Language

The language itself is just a means, a medium to transport intentions. As a computer scientist, I am able to use a variety of formal languages to get things done. Just like it is in natural languages though, there are things that can be expressed more concise in one language than in another.

Researches have shown that the source line of code (SLOC) productivity of a programmer is not related to the language used. This means that writing code in a language that offers more high level abstractions can lead to a significant productivity boost and a reduced number of potential bugs and security problems. This is why I prefer to write code in Python, whenever possible.

Development model

Having a strong root in academics, I believe in classical software engineering development models like waterfall with feedback and the spiral meta model. At the same time though, my practical experience with both closed and open source software shows that agile methods, refactoring, and design-while-you-go can be as valuable — depending on the complexity of the actual subsystem and its place in the (typically layered) software stack.

Cross-layer Integration

Since most software products are distributed and stacked nowadays, they’re composed of a multitude of systems, subsystems, and layers. Every strong software team needs someone dedicated who is aware of cross-layer issues and has experience with choosing technologies, libraries, protocols, and what glues them together. Without someone like this you risk engineers implementing solutions in wrong layers, duplicated work on multiple layers, or even subsystems that contradict the efforts done in other subsystems.

Platform

I know well that in the software industry it is usually all about the products and not about the platform. I also know that products do not just magically emerge out of a platform, however when I’m working with a software team in a long-term project, my engineering goal is always to make sure that software products are built in the way that leads to a durable platform. A platform allowing for simple ways to innovate — internally and externally. I believe this is a major technical requirement for coming up with successful products — especially once you factor long-term engineering costs and engineering performance into the bill.