About
I’m Konstantina Karponi, a Director of Software Engineering. This site is where I write down what I’ve learned along the way.
My story
I started out writing code, and for a long time that was enough — I just wanted to write the best code I could. I spent a lot of hours beyond the working day reading, rewriting things I’d already shipped, and chasing the version of a solution that felt actually right, not just correct. That habit is probably still the one that shaped me the most.
Somewhere in there, the questions I was asking changed. Writing good code stopped being enough; I got pulled into why a system was shaped the way it was — the trade-offs behind an architecture, the decisions that are invisible until something breaks. Software architecture became less of a topic I studied and more of a lens I couldn’t turn off.
One thing that came out of those early years: once you’ve internalized the fundamentals — not a specific language or framework, but how to actually think about a problem — the tech stack stops being the hard part. I’ve moved between languages, paradigms, and domains more times than I can count, and it’s never been the obstacle people expect it to be. The basics travel. That’s given me a kind of flexibility I’ve come to rely on.
And at some point, the job itself shifted — from writing that code myself to helping other people write it well. That turned out to be a much harder problem. Code either compiles or it doesn’t; a team either trusts you or it doesn’t, and there’s no compiler for that. I’m still learning it.
Code either compiles or it doesn’t; a team either trusts you or it doesn’t, and there’s no compiler for that.
Lately, I’ve been pulled toward a different kind of question: what AI actually changes — both in how software gets built, and in what gets built at all. I’m as interested in how AI-assisted development is reshaping the craft as I am in the new category of AI-native products it’s making possible, and what either of those means for the engineers doing the work. I don’t think the fundamentals stop mattering. But I do think the shape of the job — and the shape of what we build — is shifting again, and I’d rather be paying close attention to that shift than catching up to it later.
Engineering philosophy
Growth doesn’t happen by standing still, and that’s true for me as much as for anyone I work with. I’ve never been comfortable sitting on what I already know — I’d rather go find the new pattern, the new tool, the better way of doing something, and figure out where it actually fits before I trust it.
It’s also what I look for in the people I work with. I have a lot of respect for engineers who stay curious rather than coasting on what already works — but curiosity on its own isn’t enough. The ones I enjoy working with most also have the judgment to know where a new idea actually belongs and where it’s just noise. Curiosity without that judgment is just chasing trends.
And I think the biggest thing a lead can do is protect the space for that kind of growth in others — not managing it too tightly, but trusting people with something slightly bigger than what they’ve already proven, and letting them get it a little wrong on the way to getting it right. That’s usually how the judgment part gets built in the first place — not by being told the right answer, but by being trusted to find it.
Get in touch
I’d genuinely like to hear from you — about the writing, your own work, or anything in between.