What is this blog about? π
With this blog, I intend to fill a gap in software engineering documentation. There exists a lot of useful material for engineers to get started with software engineering. But with increasing seniority, great sources become scarce. As the challenges become more architectural, the sources become less concrete. With this blog, I intend to give concrete answers to challenges that senior and staff level engineers face. Always based on and accompanied with working code. Always precise and to the point, without buzzword bingo and empty sentences.
Why me? π
In past roles, I have continuously driven technical and architectural advancements. Starting with an early adoption of the Stream API in Java 8, over the correctness-proven creation of a functional algorithmic OCaml application towards the introduction and implementation of micro frontends. Always carefully considering new technologies, I am proficient in a variety of programming languages and paradigms and comfortable with different frontend and backend stacks. This wide experience I can apply to craft logical and simple solution to complex problems.
What did I create so far? π
The frameworkless enterprise-ready Node.js guide is a multi-part series that is read by hundreds of engineers each day. In this series, I provide solutions to common challenges like authentication, logging and error handling and assemble these into a working enterprise-ready software application.
The talk Micro Frontends with Angular covers in 1h40m an approach to migrate from a frontend monolith to web-component based micro frontends.
A variety of standalone posts give solutions to different problems I faced in the past.
Frameworkless. Enterprise-ready.
Read Node.js guide
Guide for
Node.js server appsThings
Explore posts
you didn't know about
your favorite toolsMigrating
Watch micro frontend talk
from
monolith to micro frontends
What can you expect in the future? π
Beside of standalone blog posts, there are a couple of bigger projects I see value in implementing in the future.
- A decision guide for frontend frameworks: To enable engineers to apply their criteria, make a decision, explain it to management and bootstrap an application.
- A guide for real-world functional programming and FP architectures.
- Small simulation games that playfully explain concepts like the Team Topologies team structure to a larger non-technical audience.
- A text- and code-based TikTok that allows to browse to curated timeless advice with the option to access an underlying blog article for more information.
- A framework-agnostic platform to run a micro frontend architecture.
- More decision guides that guide engineers to the full process of making concrete important architectural decisions in an organization.
All these projects require a significant amount of time. An article of the Node.js guide including the development of the code takes in average 8 hours. The creation of the micro frontend migration guide took about a 5 day week with two people. For these projects, there already was an implementation to base the efforts on.
I believe that huge value exists in deep-dive high-quality guides. Projects under this theme is what you can expect in the future.
How can you support this? π
If you would like to see these projects realized, you can enable me to spend more time on them by sponsoring me on GitHub or "Buy me a coffee". If I reach a steady side income, I will be able to continously do this as a 20% job.
If you represent a company and would like to support my work, send me a mail. We might be able to figure something out to give the perks of a sponsorship to multiple employees with a single company sponsorship.
Do I need to be a sponsor to access your work? π
At the moment, only regular GitHub sponsors get access to the GitHub repo of the Node.js guide. Everything else is freely available. There might be more perks in the future that I make exclusively available to sponsors. These might be convenience features (like the code in a GitHub repo), enterprise posts (how do I run this in Kubernetes?) or posts regarding propietary tools (how do I manage feature flags with tool X?). I aim to keep the crucial parts of my work freely available.