Me

I’m a software engineer with a passion for library and backend service development. I’ll give you an insight into my skill- and mindset concerning software development, technologies and project organisation.

I aim to solve problems in a sustainable way. I don’t like trading 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 engineer that I am today.

Technologies

Java and its eco system

I have years of experience working with Java (starting from version 1.5). During these times I gained deep understanding of its internals, its standard library, the JVM and nearly all the relevant big frameworks and libraries. I do follow its latest releases and enhancements with great curiosity and pleasant anticipation. As such I’m well aware of upcoming features and the design ideas behind them.

Here is a non-exhaustive list of tools, libraries and frameworks that I have professional experience with:

Cloud & DevOps Experience

I came in contact with docker comparably late in my career but I quickly learned to love it. Having an immutable bundle of an application and everything that is required to run it is one of the key technologies that enabled the cloud computing business. I actually do run a single-node docker swarm “cluster” on my private V-Server, hosting multiple applications that I use for my daily needs. As those are dealing with sensitive private data (like files, contacts, calendars, finances and scanned documents), big care has to be taken regarding security and failure concerns. As such, I implemented automatic off-site backups and I regularly apply updates, do port scans and check the firewall rules to ensure flawless operation of all services.

Here is a non-exhaustive list of tools, libraries and frameworks that I have professional experience with:

JavaScript

I used “modern” JavaScript for front-end development in a few professional projects, but I never really acquired a taste for it. Thus I do know some of the concepts and technologies but I’m far from being an expert in any of them.

Here is a non-exhaustive list of tools, libraries and frameworks that I have professional experience with:

What I can do best

Libraries and APIs

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.

Web Applications

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.

Understanding (legacy) code

Having worked on multiple projects that I haven’t been involved with from the start, proved that I’m able to quickly understand existing code. I consider this a distinctive competence of mine because reading and understanding foreign code is one of the most common tasks there is in real world projects. Identifying architectural ideas and patterns from code has high importance when it comes to evolving an existing code base in a maintainable and economical manner.

Compiler construction

This rather 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…

Microservices?

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)

Test-Driven-Development?

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?

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)

rss facebook twitter github gitlab dev youtube mail spotify lastfm instagram linkedin xing google google-plus pinterest medium vimeo stackoverflow reddit quora quora