The Non-Productive Programmer (NPP)

We all know them: programmers with long term experience stuck on a low-level of our craft not corresponding to their quantity of experience. Great programmers are creative workers and problem-solvers and one of their most important traits is: never stop learning – but getting stuck in its own comfort zone and becoming reluctant to change is deeply wired into human nature (Humans are hard-wired to follow the path of least resistance).

Reading List for the mindful Software Engineer

Abstractions are essential in order to build complex systems and keep complexity under control. Especially in software development we rely on many abstractions to make our life easier. Although good abstractions do not “leak”, it’s always helpful to understand the background and the details behind them.

Emacs as RSS reader

Do you have a list of websites you visit regularly? Just to find out nothing new was added. This manual scraping is often a waste of time. Worse yet, scanning and filtering these websites for new interesting content is even more time consuming.

Product Management Quotes

I collected my favorite quotes about product management: We need teams of missionaries, not teams of mercenaries. Marty Cagan, Inspired It doesn’t matter how good your engineering team is if they are not given something worthwhile to build. Marty Cagan, Inspired

Writing better Code

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.

Google Testing Toilet Collection

In my one of my previous posts i wrote about Good Unit Tests. During my research i discovered the famous Google Testing on the Toilet posts which provide great advice. The Testing-on-the-Toilet articles are short (~3min reads) and give hands-on examples, ready to be applied immediately.

Programming Quotes

Over the years i collected some (funny) programming quotes. Lean back and enjoy: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Why and How to write better Unit Tests

TL;DR Good unit tests build the foundation of a maintainable and high-quality codebase Unit Tests should help developers to be productive Unit Tests should be fast Unit Tests should be isolated Unit Tests should be deterministic Unit Tests should focus on a single unit Unit Tests should be enduring Unit Tests should be clear, concise and complete Avoid complex control flow logic like nested ifs or loops Unit Tests should follow a consistent naming pattern like UnitName_StateUnderTest_ExpectedBehavior Unit Tests should comply to a consistent structure Unit Tests should be DAMP not DRY Unit Tests should give developers confidence to deploy and to refactor Test Doubles help to make tests fast and deterministic The overuse of Mocking makes test hard to read and brittle Prefer state verification over interaction verification Prevent brittle tests Prevent flaky tests Read more: Software Engineering at Google Kent Becks’s Programmer Test Principles Microsoft’s Best Practices for Unit testing Why good unit tests are important TDD and test engineering culture is considered best practice these days.

ESlint + Prettier + Typescript = Consistency

Consistency is one of the most important factors in a codebase. It gives new developers an orientation and direction how to write new code. It keeps the code understandable, clear and free from bikeshedding, so developers can focus on real problems instead of indulging in discussions on their preferred codestyle and individual taste.