Twenty years in, still curious.

The short version

I studied Computer Engineering at Yıldız Technical University and started working as a developer before I graduated in January 2005. Nearly all of the two decades since have been spent in the financial sector — large enterprise applications in Java, the kind of systems where a rounding error is a serious incident and the code outlives the team that wrote it.

The first years were about learning the craft properly: object-oriented design, design patterns that earn their complexity, relational data modelling, and a great deal of SQL and PL/SQL. Then I moved into leading — lead developer, team leader, software architect — and did that for eight-plus years. That is where I learned the part nobody teaches you in engineering school: the hard problem is almost never the code. It is getting five people to agree on what "done" means, deciding which technical debt to keep, and knowing when the honest answer is "we built the wrong thing."

In 2019 I started ParionTech to build the things I wanted to build properly. And over the last few years I have moved most of my time into tutoring — Java, algorithms and Python, mostly with computer science students at universities in Europe and the US. Teaching one-to-one turns out to be the most direct way to pass on twenty years of expensive lessons.

How I think about software

Improvement belongs inside development, not after it. The idea behind ParionTech is that refactoring, testing and cleanup are not a phase you schedule when there is time. There is never time. They are part of how the thing gets built.

Design patterns are vocabulary, not architecture. Twenty years of enterprise Java taught me that the patterns are worth knowing precisely so you can tell when you do not need one. Most over-engineering I have seen came from someone applying a pattern to prove they knew it.

Boring technology wins. Java, Spring and a well-modelled relational database have carried systems I wrote fifteen years ago that are still running. I would rather spend my thinking on the actual problem than on the framework.

The data model is the real design. In financial systems especially, get the schema and the domain model right and the application code becomes almost boring. Get them wrong and no amount of clean code above will save you.