What I learned in 2015

2015 was an amazing and again life changing year for me. This is an incomplete collection of things I have learned during the last twelve months.

I can build simple software that scales

During the last year I spent most of my time building Redbull’s Amaphiko platform, which by far is the hardest and longest project I have ever worked on, but it also turned out to be the most successful and fun one.

A key moment for me was when Eric joined our team and said that this is the cleanest codebase he has ever worked with. Simplicity remained while the code size increased steadily even when team members changed, the team size got reduced or time got taken away from the project.

In every other project I worked on before complexity evolved quickly, so that developers outside of the team and the team itself had a hard time figuring out what was going on.

The main reason why software quality didn’t decrease is that everything I had read about software architecture and clean code was put into Amaphiko’s foundation: modularity, composition, encapsulation, separation of concerns, single source of truth etc.

In the end applying all of these best practices and especially functional programming concepts has lead to one thing: the ability to locally reason about a piece of code. This ability is what makes code easy to understand and extend.

Functional programming reduces complexity

Using React as a basis for building Amaphiko has introduced me to functional programming. Having seen how applying its principles to JavaScript can make such a big difference in code quality, I got hooked and spend a lot of time learning more about it. The major benefit of functional programming to me is how it reduces complexity:

While reading code, the less things you have to keep in your head, the easier it is to understand. Functional programming addresses this problem by making implicit dependencies explicit.

Instead of going into more detail here I encourage you to read Kris Jenkins’ post where he explains in simple words and with examples what the benefit of functional programming is.

A good type system is beginner friendly

Moving from imperative JavaScript code to a more functional style using React was a major step in code quality. Then I wanted to get these benefits without much overhead and I started to learn Elm, which is a functional programming language that compiles to JavaScript.

I expected to get immutable data structures and pure functions in a nicer syntax and with less effort. I did not expect to again massively improve my code’s readability and especially its reliability because of Elm’s type system.

Learning Elm so that I can be productive with it, took a very short amount of time, because of it’s small syntax and helpful compiler messages. In addition whenever someone starts adding features to an Elm code base the compiler will find any errors that got introduced by the changes.

You’ll probably find me writing more posts about Elm in 2016. I was lucky to meet Evan in person while he was in London and we had a great time at the Improbable office. Until I publish more content about Elm on my site I recommend watching these talks for more information.

Today’s software engineering practices are based on anecdotes

This is a late realisation that I had at the end of 2015 after watching these two talks, which I also added to my favourite talks:

The software industry has very low standards of evidence in regards to engineering practices. I noticed this in my daily work too. I make claims based on my previous experience and my colleagues do the same. This means most of our practices and engineering decisions are based on one subjective data point.

Just because my last software project using an agile process was successful, does not mean agile made it successful. I know there are a lots of agile projects that fail, too. Even if a practice turns out to be helpful, wouldn’t it be great to know if there are practices that might be even better?

I was curious and found a study about the success of agile vs waterfall across 66 software projects. According to the abstract “agile and structured processes can be equally effective for globally distributed development”. If I want to claim that agile is better than waterfall I need to put at least the same effort into its evidence as this paper’s authors. To be fair this is not easy. It requires time, resources and that results of research like this is published for free.

These talks have opened my eyes for this huge opportunity to improve the standards of software engineering though. Programmers need to demand higher standards and companies need to spend more money on research. What I will do in the meantime is collecting as much data about my personal productivity as I can to at least make better decisions in the small.

Senior software engineers communicate clearly

In October I started working at Improbable to build something that matters and further improve my software engineering skills. I was especially interested how much of a difference working with people that used to create software at Google, facebook, Amazon and other big software companies is.

What impresses me the most is the way my colleagues communicate with each other. They are very good at bringing their concerns and thoughts across in simple words even for complex problems. This makes them very good teachers and helps a lot when talking to business people. It’s having an eye for improbable edge cases, their general knowledge of specifications and patterns plus the speed at which they learn new concepts, that makes them so valuable.

I’m looking forward to the things we’ll build this year while learning to become a better software engineer. There are exciting times ahead.

Thanks to everyone I learned from

To end this post I want to thank everyone I have worked with at edenspiekermann, especially the Amaphiko team. I’m very lucky to work with a lot of smart and nice people on a daily basis.

As expected I miss Berlin, as it is the city I consider home, but I don’t regret my decision. My life was extremely comfortable, but I felt that I stagnated. Therefore it was time to take risks again. I know that living some time abroad will help me to develop personally and professionally. This is an adventure and it has just begun.