C# .NET ASP.NET Core WCF EF Core SSMS Azure Azure DevOps CI/CD Pipelines Docker Kubernetes Elastic Stack OpenTelemetry Microservices Domain-Driven Design

Building software
that lasts.

FULL-STACK .NET DEVELOPER

I'm a Stockholm-based developer working mostly in .NET, across back-end services and the interfaces built on top of them. I like systems that stay readable once they grow.

Selected work

Projects

My professional work is covered by NDAs, so I can’t share it here. These are personal projects, each starting with a problem I wanted to solve or something I wanted to understand properly.

Background

About me

Full-stack developer in Stockholm, working mainly in .NET. I care more about how software holds up a year later than how fast the first version ships.

What drives me

I like both ends of the stack, for different reasons. Front-end work is immediate: you change something and you see it. Back-end work is where the structure lives, and getting that right is what keeps a project workable later on.

Whether it's splitting out a service, working through a slow query, or adjusting an animation until it sits right, the job is the same. Understand the problem properly, then keep the solution as simple as it can be.

Before the code

Most of what decides how a project goes happens before anything gets written. Understanding the domain, asking the awkward questions early, and getting agreement on what the thing actually needs to do. The implementation is the easier half once that is settled.

Influences

Books I keep coming back to:

Clean Architecture Robert C. Martin
Clean Code Robert C. Martin
Domain-Driven Design Eric Evans
Software Engineering Ian Sommerville

How I work

01

Reuse before repetition

If the same thing turns up in three places it usually wants to be one thing. I pull those out when the pattern is clear, not before.

02

Patterns when they earn it

A pattern should answer a problem you actually have. Applied early it just adds indirection and makes the code harder to follow.

03

Principles, not rules

Most engineering principles are good defaults. Knowing when a project is better off breaking one is part of the work.

Say hello

Contact

Drop me a line.

If you have a project in mind, a role you think fits, or you just want to talk shop.

Send me an email