About me

Before writing anything I try to understand the problem behind the request. The initial ask and the real problem are often two different things, and finding that out at the end is expensive.

I care about the whole product, not only my slice of it. Knowing who it is for, what it has to solve and how it reaches the user changes technical decisions that would look interchangeable if you only read the code.

With clients I would rather talk plainly and early. Say where something stands, flag a date that is not going to hold, and admit when I do not know something. That is how trust gets built, not by over-promising.

I work in small pieces that can be reviewed and tested on their own. I would rather ship something that works and grow it than show a finished project when there is no room left to change it.

I adapt to whatever process the team already has. If the project runs on Scrum I take part in the ceremonies and the sprint rhythm without friction; if it is something lighter, I do not overcomplicate it. What matters is that everyone knows where each thing stands.

When there is pressure I try to keep it out of how I deal with people: prioritise, flag the risk, keep going. And learning quickly is part of the job rather than a bonus: there is almost always something in the project I do not know yet.

I document the decisions that are not obvious and keep the code readable for whoever comes next, which is usually me three months later.