// what I actually build function solve(problem) { const system = design(problem); const code = build(system); return ship(code, "production"); }
"I want to understand what you're actually trying to solve before I open an editor." The part of the job that doesn't show up in a stack trace.
A few years in sales and marketing before engineering means I'm comfortable in front of a customer, a whiteboard, or a pull request — and I know how to move between the three.
I'm a software engineer first. Most of my working week looks like anyone else's in the role — designing systems, writing and reviewing code, working through APIs and integrations, and getting things into production.
What's less common is what came before it. I spent several years in sales and marketing, which means I've sat across the table from customers, translated vague requests into concrete requirements, and explained technical decisions to people who don't particularly care how they were made — only that they work.
That combination is useful in practice. It means I don't just take a ticket at face value — I ask what it's actually for. And when a technical solution needs explaining to a non-technical stakeholder, that's not a separate skill I have to reach for.
Based in Akureyri, Iceland. Open to remote, international, and project-based work.
I don't think of these as two separate jobs. Most of the value I add is in the space where they overlap.
Designing and building software that has to actually run — not just demo well.
Making sure the thing that gets built is the thing that was actually needed.
Organised by how I use them, not as a keyword dump. Darker tags mark the technologies I work in most.
Designing and shipping systems, not just tickets — from backend logic to the interface on top of it.
Connecting systems that weren't built to talk to each other, cleanly and without duct tape.
Comfortable going deep into a hard bug, and comfortable stepping back to question the approach.
Reading a business problem correctly before writing a line of code to solve it.
I've spent years learning how software works, and a few years before that learning how people and businesses actually operate. Technical problems rarely exist in isolation — there's usually a customer, a deadline, or a business reason sitting behind them.
Having worked on the commercial side means I don't need a project manager to translate between engineering and the rest of the business. I can sit in that conversation myself.
In practice, that shows up as fewer misunderstood requirements, clearer explanations to non-technical stakeholders, and a habit of asking why before I start building.
Outside of work I'm a father, which has a way of putting deadlines in perspective. I climb when I get the chance — Akureyri isn't a bad place for it — and I'm a fairly committed board-game enthusiast, which is really just problem-solving with better company.
I'm open to conversations about engineering roles, solutions engineering, and anything in between — remote, international, or project-based.