Author: moritz

Today was interesting. But let’s digress first. When I was first using turn by turn navigation systems, one of the really surprising discoveries was that the shortest and the fastest route are not necessarily the same thing. There are quite some instances where they are actually completely different, like when you go for a longer […]

You need to deploy software all the time. That’s my believe, and here’s why. Let’s start at the beginning, though. What is a deployment? For the discussion here it’s basically the process of moving code from wherever it is to production. For software that means that hypothetical value turns into real value exactly at that […]

Have an idea? Write it down. Made a plan how to tackle something? Write it down. Disagree with something? Write it down. Writing is brilliant in that it does two things at the same time: It makes you express something in a form that is easy to consume for others, and it comes with a […]

There’s probably nothing cheaper than an idea. Truth be told, I’m not a particular fan of ideas. They are one of the most necessary things you want to have in your engineering team, but ideas need to be carefully managed. They should operate in a space somewhere between problems and actual solutions. They’re glueing two […]

People will, at one point in your career, talk to you (or with you) about the broken window phenomenon. That is an observation that, if windows are left visible broken in part of a town, the surroundings will usually start to deteriorate at a faster rate than if someone took the time to fix the […]

Monorepos, Microservices, Shared Libraries and other things to get really excited about. Or not, depending on quite many things. Let’s talk about the dynamics between teams, what they build and how they deploy – and how choosing the right or wrong technology for that might help or hold you back. Starting with a simple example […]

we software engineers build systems. Those can be small systems, big systems and anything in between. The most commonly associated activity that comes to mind when speaking about building systems is probably writing code. And debugging code, and testing code and deploying code. Of course, that’s pretty much spot on – would be very pointless […]

there’s few terms that mean so much and so little at the same time. Given my last post was a little biased on the "get shit done" side of things, I felt it was good to write a bit about collaboration. I don’t mind collaboration, I think it’s absolute key to getting meaningful things done […]

Forget consensus. Scratch making compromises. Fuck alignment. Don’t attend that one call where twenty people with no skin in the game don’t say anything meaningful, anyway. Build a solution in half the time it would have taken to figure out the right group of stakeholders. Make it easy to rollback. Make it easier to deploy. […]

Let me take you along for some kind of thought experiment. What if you completely ignore any kind of architectural – or system design decision making in your next project and only do one thing: focus on the next problem you actually have, and solve that. So instead of planning how your piece of software […]