How I work as a software engineer

People sometimes ask what "senior" actually means. After building software since 2018, from consulting projects to product teams at a fast-growing scale-up, my honest answer is: it is less about knowing more frameworks and more about having a reliable way of working. This is mine.

1. I start from the problem, not the ticket

A ticket is someone's guess at a solution. Before I write code I want to know who is affected, what they are trying to do, and what "done" looks like for them. Very often the best implementation is smaller than the ticket, and sometimes the right answer is not to build it at all.

My first question is almost always: what happens if we don't do this? If nobody can answer, we probably have a better use for the week.

2. I make the work small enough to finish

Big tasks hide risk. I slice work until each piece can be built, reviewed and shipped in a day or two. Small pieces get reviewed properly, they are easy to revert, and they give the team a steady rhythm of progress instead of one dramatic merge at the end of the sprint.

3. I write code for the next reader

Most code is read many more times than it is written, and the next reader is often me in six months. So I optimise for clarity:

• Names that explain intent, not implementation.
• Small functions with one reason to change.
• Comments that explain why, never what.
• Boring, consistent patterns over clever one-offs.

Clever code impresses for a day. Clear code saves time for years.

4. I treat errors as part of the design

A crash in a game is annoying. A crash in a payment flow, a booking or a health app is a broken promise. I design the unhappy path first: lost connections, slow devices, partial updates, and users doing things in an order nobody expected. Good error handling is not defensive programming; it is respect for the person on the other side of the screen.

5. I automate the boring parts early

Formatting, linting, tests, builds and releases should run without anyone thinking about them. A solid CI/CD pipeline is not overhead; it is what lets a small team move fast without breaking things. The earlier it exists, the cheaper it is.

6. I own it in production

My work is not done when the pull request is merged. It is done when it works for real users. I look at crash reports, read customer feedback and talk to the people using the product. That loop, from code to users and back, is where most of my best product decisions come from.

7. I communicate more than feels necessary

Most project problems are communication problems wearing a technical costume. I write short updates, flag risks early, explain trade-offs in plain language and ask questions when something is unclear. Speaking at conferences and organising community events made me better at this, and it pays off every single day at work.

8. I leave things better than I found them

Every time I touch a file, I try to leave it a little cleaner: a better name, a missing test, an outdated comment removed. Small, continuous improvements beat the big rewrite that never gets prioritised.

The short version

Understand the problem. Ship small. Write for humans. Design for failure. Automate the boring parts. Own the outcome. Talk to people. That is how I work, whether I am building a mobile app, a web platform or an AI product.

If that sounds like how you want your team to work, send me a message.