I’m a software architect with a strong passion for library and backend service development. This page will give you an insight into my skill- and mindset concerning software development, technologies and project organisation.
I’m the kind of developer that solves your problem in a sustainable way. You won’t see me trade developer experience, code quality or test coverage just to hold a miscalculated deadline. Letting go of these factors will inevitably degrade your project’s and your developer’s performance in the long term. Instead I consider it my job to facilitate my team to ship high qualitive software at a faster pace, ultimately reducing frustration and decreasing the time to market of new features. This can be achieved by making sure that every team member understands and actively supports the architectural decisions. As an architect I do not believe in just spitting out abstract theoretical concepts and leaving the implementation “as an excercise” to the team. I take the lead in solving complex challenges together with my team, giving them confidence and building a relationship based on mutual trust. Actively avoiding complexity and employing straight forward and simple development processes will result in a clean code base that is easy to maintain and fun to work with.
I do not fear going down the rabbit hole to solve tenacious bugs. When it comes to nasty application misbehavior, a deep understanding of the involved components is the key to resolving it. I will happily debug into the deepest framework method or perform detailed performance analyses to find out what is going on under the hoods.
Mentoring younger or unexperienced developers to allow them to reach the next level is a very important task for a lead developer or architect. Writing blog posts and having worked as a tutor during my computer science study, I found great pleasure in teaching others and sharing my experiences. On the other hand I also love to argue with other opinionated developers over software design and architectural decisions, thus allowing me to constantly question and reappraise my former technical choices.
I gained a lot of experience not only during my professional carreer but also while studying and through multiple personal side projects. Each of these fields contributed to my versatile set of capabilities and made me the confident developer that I am today.
Library development is one of my biggest passions in software development. I love not only to work out proper abstractions and to create developer friendly APIs but also to design working maintenance, release and deprecation strategies. Enabling numerous developers and teams to build on my well-conceived artifacts sparks a lot of joy for me.
I have a long history in developing web applications. I feel most comfortable designing and implementing scalable backend services that implement your business logic. I’m well familiar with the aspects that needs to be considered when implementing a web service, like security, scalability, performance and load characteristics, resilience and concurrency. Despite having worked on web front ends (both server- and client side rendered) I’m not a typical fullstack engineer. I’m not especially talented when it comes to designing and implementing a stunning user interface.
This exotic topic of computer science fascinated me since my early days of programming. It started all off by wanting to know how to program a simple calculator and peaked in implementing refactorings for a C++ AST and type inference for an academic programming language. I strongly believe that knowing the internals of compilation helps big in understanding how computers really work.
What is my opinion on…
Great, if done right. Awful if done wrong. Mostly overhyped. Microservices to me, are just a technical detail to implement a well designed domain driven business model. It is likely that you can implement the same well designed business model using a modular monolithic application without all the disadvantages that microservices bring with them. Microservices don’t solve technical problems, they cause technical problems. As such, they are meant to solve the organizational problem of developing applications in independent teams. If you don’t have independent teams there is nothing to win with using microservices. (Compulsory reference to Conway’s Law omitted for brevity)
It is not important whether you write a test before or after the implementation, as long as you write one. Both can work and both can be combined. There is no value in religiously pursuing one or the other. Tests, in order to provide real business value, must be reliable, fast to execute, easy to write and immune to structural changes of the application. If your code base is designed to allow tests like this, it really doesn’t matter when your test case has been written. TDD allows you to go in slow, small steps to explore the problem space and approach the final solution in slow motion in case you are precarious about the behavior of your code. On the other hand, if you are pretty familiar with the problem space, nothing should prevent you from doing bigger steps and moving faster.
Agile processes like Scrum or Kanban have experienced an awful development. Companies wanting to go agile by any means just because it must be cool have added to the fact, that the term has lost its original meaning and has become a questionable business model of shady consultant companies. To me, agile means developing a software in increments and shipping those increments as often as possible (peaking in actual continuous delivery). Being agile must enable the team to move forward in a fast pace and to react to requirement changes easily. If your agile process does not actively support these goals it sparks no real business value and it doesn’t matter whether you call it Scrum, Kanban, Scrumban, Kanscrum or what ever is cool today.
“Individuals and interactions over processes and tools!” (Agile Manifesto)