Idea dump - Things I learned (the hard way)Idea dump - Things I learned (the hard way)

This article is continously updated


Do not create high levels of abstractions early on, the same way you don't build the full product with all features for your startup, but go with an MVP. You don't know what needs the future, and here we are talking about hours not years, will bring. Stay low level until you see patterns emerging. If an abstraction will save you time, implement it. And this has nothing to with a clean code architecture.

Interface and boundaries

Everything is an interface. Interfaces and clearly defined boundaries are the secret sauce to a scalable software architecture your future self will enjoy working in.

"Write modular code and monolith vs. microservice architecture becomes an implementation detail"


First you deny it, then you fear, then you try it, then you can't live without it. But it doesn't make sense to apply it before you don't understand software architecture well.


same here

  • Most chaotic codebases get born because files get created in random locations, without any structure. In addition, those files contain functions that serve multiple purposes and handle data of various formats - no knowing which layer the actually belong to. Humans need structure, patterns - in order to be able to think and make sense of something. The larger and more interdependent a system gets, the more important that clear structure becomes. The lack of good architecture won't be noticable during the first days, weeks, sometimes even months. But then it bites. And uh, do those bites hurt. They hunt you at night, make you sleepless, force you to deepen your coffee addiction. It's rarely "just a simple project", an "MVP", a "PoC". Build solid, build for the future, save tears (there sure are moments where those are needed, and coding shouldn't be one of them).

Vertical sliced vs. horizontal architecture

Feature flags

  • Feature branching etc
  • Only makes sense with a good testing strategy and software architecture

Architecture > Technology Choices

Doesn't matter if you use GraphQL or Rest, when the underlying API is a mess. The other way around though, adding GraphQL to a well architected API, or switching from Node to Deno, is straightforward, because a good architecture is resilient to change in infrastructure.

Do not name Experiments "Test[...]"

Small thing I noticed even doing myself sometimes. Calling an experimental code (e.g. a React component) "TestXYZ", e.g. TestComponent. It should rather be called ExperimentalComponent

Everything is an API ... or why you need incremental testing

...and you always develop an SDK for your future self or your team. Just the way of calling that API/SDK might differentiate: A normal function you import, a React Component, a REST or GraphQL API. They belong to different layers for sure, but might be re-used in all different places. So make sure to make them testable and mockable right from the start. -> Incremental Testing

Well-architectured monorepos

Monorepositories without layered architecture and a good testing strategy will turn into an uncontrollable spaghetti mess, which will feel like you just dumped your whole code into one giant file.

Some concepts to write about

  • No library typesafe State Management for React

AI Project Ideas

Store and analyze code base abstractions - to develop new features; with enough abstractions the LLM can lookup (e.g. from a Vectore Database) everything relevant and develop whole features. We just need a documentation of all internal APIs and our design system, so the AI could potentially just write features on it's own.

Keep Reading

You don't need GraphQL or tRPC
web development02 Mar / 2024

You don't need GraphQL or tRPC

WIP01 Mar / 2024opinion

Moduliths in a Monorepo

Moduliths in a Monorepo