software engineering principles

If you need to cut a piece of wood, measure twice before doing so. If you measure wrong and make the cut, you may need to cut again, or even use a completely new piece of wood. Cutting wood has consequences. Writing code has, too. But most often not very drastic ones!

When choosing a tech stack for your startup (or any project in a new business domain), you need to balance several objectives: reducing time-to-market, reducing development and maintenance time, and having a secure ecosystem. Here's how to choose the right tech.

There are many ways you can write your code. We have best practices and linters, opinionated frameworks and architecture patterns. The very big and very small decisions. Stuff you decide on the team-level. Then there's a middle ground. That's what happens while you implement a larger feature or a smaller service by yourself.

It feels like we can never learn enough in our field. As software engineers, calling ourselves an “expert” in any area just doesn't feel right. How could we ever know everything about a specific language or framework? Here's why I believe this is a good thing.

Generic error messages suck. As a user, we encounter them all the time. “An error occurred, please try again later“. Often just to find out the problem wasn't some server outage, but something on our side. A typo in our email - and the server couldn't send that verification email, resulting in a 500 internal server error. Here's a simple but effective way to API error design.

When I'm programming, I'm often making notes or scribble on paper or a whiteboard. It helps me explore and keep track of my options. For small or big architectural decisions (which we're making all the time), it's hard to keep all options …

The more complex your infrastructure the more can go wrong. Let's look at Terraform as a way to automate tedious infrastructure setup (and to make it explicit).

The best code is no code at all. Second best is simple, easy-to-read-and-understand code. “A complex system that works is invariably found to have evolved from a simple system that worked...