Author: moritz

solve the problems you have

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 […]

don’t add that button

We very recently bought a car. And I was surprised how many models are on the market that still use manual shifting. I know how to drive them, probably quite well even, but you couldn’t get me to buy one of those. The machine is just much better at shifting the gears up and down […]

the editor of no regret

So, I’m a person that’s rather sceptical of my own results and output. Vey often, I start writing a post or a tweet, and then just backspace the whole thought into oblivion, kind of self-regulating me to a silly extent. While I should probably go on and discuss that with my therapist, I found a […]

Decisions

Take a random situation, some every day scene – and make a decision. I feel that kids are born with the ability to just decide, at least that’s my take away when watching my kids making countless decisions each day. Vanilla or chocolate, Bicycle or Football, Indoor or Outdoor. There’s not as much deliberation and […]

Tools

Tools. So important. Imagine someone picks up woodworking and asks himself: What tool should I get? A hammer? A saw? Screwdriver maybe? The first answer is, probably, that it depends. The second answer is that you’ll likely need all of them on your journey. And someone else will probably throw in that if the only […]

the goldfish engineering experience

This is me being cynical. I’ve turned into a person that is more prone to disliking building new flashy things, and rather suggests to leverage existing things. Good engineering organisations don’t measure success by looking at the amount of things built, but by the value created. Two incredibly different things. One thing I find remarkable […]

how to bias to action

Without getting to hooked up on how you specifically call it, most organisations I’ve worked for had some notion of the idea of “bias to action”. Whether it was “get shit done”, “JFDI” (for just f**** do it) or “done is better than perfect”, the idea is pretty much the same – you want to […]

being adaptable

The only constant is change. Generally true, even more so in software engineering. Shit changes all the time. Requirements, Milestones, Team Compositions, Technologies, Best Practices. Nothing is static. That’s probably the reason why I’m so intent on leading my teams to a state where they are primarily really good at adapting to change – regardless […]

strong things and weak things

A little while ago a coworker pointed to the problem that he doesn’t understand how I come up with decisions, what my criteria are. There’s probably a million answers to that, but since the topic was system design, it got me thinking. What are my guardrails, my thought processes when it comes to designing systems […]

the thing about deleting code

Refactorings, clean ups, consolidations – doesn’t matter what you call it, but there’s something calming about finding ways to touch code without the intent to functionally change or improve it. It’s like cleaning the workshop. And much like cleaning the workshop, there’s an art to focussing disproportionately on actually: deleting code. Deleting code is the […]