Things I learned in Software Engineering 2017

I'm writing this post as a sort of personal recap of 2017. Writing down some of my thoughts before I forget them next year. At the start of this year I finished the courses I had left on my Master degree. In the middle of the summer I moved to Berlin to live with my girlfriend and started working full time at a Berlin-based startup. In the downtime I also helped out with Security Without Borders, mostly programming work on the website.


Unfortunately, I have become more skeptical of using new "tech". This could be frameworks or programming languages. It has been a common theme in my life to take over code that someone else wrote. There is almost always some issue in how to set up the project and just build the code. I'm lucky if there is any testing or documentation in most cases. So where does my newfound skepticism towards new things come in? Well, some of these projects at the time of their creation what would probably be considered very hip tech.

New frameworks or programming languages seem to super quickly become outdated. If after just one year the project is broken then maybe reconsider your choice of tech. Most of the code I've written this year has been in Python, JavaScript or PHP. I've actually started to slightly miss the properietary world of C#/.NET, because I never really had these same issues on that stack. Although only slightly.

In addition to this, I feel like these projects also misuse the tech they build upon.

Collecting something to take away from these complaints: I really appreciate a robust project. It doesn't matter too much if the framework or language is old and boring, because I think it's more important that it can be easily picked up and maintained by future developers.


Through python I've become really used to writing tests. When contributing to open source packages I learned more about testing and code coverage, because in well maintained packages they are required before a pull request will be considered.

I've started to become a code coverage nazi. Whenever I make a new package or project I now try have some sort of testing done too. At the same time, I'll be a bit snobby and generally be a bit suspicious when I see packages with no coverage or tests.


I've really come to appreciate well written documentation. Not so much the typical API endpoint documentation, but rather the documentation of the development process: How to set up the project, how to run the tests, what the general structure of the project is, good and up to date code examples of how to use the framework. Things like endpoint documentation should in my opinion be generated automatically. I'm used to having it automatically generate in Java/C#, but perhaps it's not as easy in dynamic languages like JavaScript or Python.


My current job is the first job where I get to experience working on a microservce architecture. In the past all the projects I worked on were usually monoliths web backends, sometimes with separate client (android/iOS) repositories. In some cases they would perhaps be split into several repositories for e.g. specific purposes.

Some things I've found to be important: Ease of deployment Logging Healthchecks / Availability Testing Securely storing environment variables outside of the project code. *


  • Docker
  • Redis