softwareengineering

Clean Code by Robert C. Martin is a seminal programming book. A whole generation of developers, including myself, became better programmers by Uncle Bob’s advice. But after almost twenty years, does the book still hold up to its high standards? Was some advice given by Clean Code questionable or even wrong? Are there better alternatives nowadays? To be fair, the author himself claims in the preface that “some recommendations in the book are controversial and people might disagree”....

Most software projects end up in a big ball of mud. The major cause is neglecting internal quality and focusing on adding features with dirty hacks because of unrealistic timelines. Code has the natural tendency to erode if you don’t launch countermeasures permanently. This observation applies to all systems and is also known as the the second law of thermodynamics: Systems tend to arrive at a state […] where the entropy is highest […]...

Modern applications run typically in the cloud. As good residents, distributed applications must fulfill many requirements in order to enable reliable operations and maintenance. This article summarizes the most important points in order to go live and to keep applications healthy over their lifetime. Twelve-factor app All modern cloud applications should comply with the 12-factor app principles: Codebase is tracked in a version control system, the same code will be deployed in different environments Dependencies are shipped with the deployable artifact Backing Services can be detached and re-attached without code changes (e....

TL;DR Command-Query Separation Extract Use Cases (Clean/Hexagonal Architecture) Domain Events (with Eventhandlers and Composite Pattern) Cross-Cutting Concerns (with Decorator Pattern) Many backend applications end up as a big ball of mud where small changes ripple through the whole codebase. The root causes are high coupling and low cohesion. The best remedies against those are Domain Driven Design (DDD) and the SOLID principles which are well-known, but often wrongly applied....

TL;DR Write code Read Code (Written) Communication Learn concepts – not technologies Learn Lisp Master your tools Control complexity (Simplicity) Read books (but don’t forget to practice) Understand the problem domain Learn to write good tests (or how to design well and write decoupled code) Introduction I am always pondering what practices, tactics, behaviours and approaches make up the most successful software engineers. After 15 years working in the industry, in small and big teams, with waterfall and agile processes, and after thousands of written lines of code, I present here an opinionated way of how to become an effective engineer....

TL;DR Modern Terminal with nice (Nerd) Fonts ZSH oh-my-zsh Modern Prompt with starship Modern CLI tools (fzf, ripgrep, bat, tmux, jq) Fast editor (Emacs, Neovim, Helix) Organize your dotfiles with GNU Stow The Unix shell/Command-Line Interface (CLI) is an ancient tool. Despite being around forever, the shell is highly customizable and with a good configuration, it is on par with modern graphical IDEs. Because it is configurable, you can make it truly your own, thereby surpassing out-of-the-box experience of IDEs....

This article contains a list of my favorite books with a major impact on my Software Engineering career. The books are categorized in: Software Engineering Programming Brian Kernighan’s Books Modern Classics Learning Management and Leadership Unix Books From Stevens Software Engineering A Philosophy of Software Design by John Ousterhout Link to book A fabulous book to level up your software design skills as an experienced engineer. The book is full of great advice....

Introduction Most of the breakthrough inventions in historic and modern Software Engineering are related to feedback loops. They are essential for productive software development, Developer Effectiveness and Developer Happiness. Remember the dawn of computing when computers were programmed with punch cards, programmers had to turn in their cards over night and the next day they got the result – often with a compile error 😞. Unlike back then, today’s computers compile whole codebases in seconds....

In Joel Spolsky’s blog post “The Joel Test: 12 Steps to better Code”, he describes a test composed of twelve simple yes-no questions. For a yes you get one point. 10 points are acceptable and 12 are perfect. If you have less than 10 points, you will get in trouble with your software – sooner or later. For a quick self-check, these are the original questions: Do you use source control?...