About me

I got into programming in 2004. From the start, I worked on systems with direct impact on business operations. Fairly early on, I understood that delivering features is only part of the job. The more important part lies in thinking through the consequences of technical decisions – for data, processes, and people who rely on the system daily.

Development was never an isolated technical activity for me. It was always part of a broader context of operations, responsibility, and real-world impact.

My work has gradually shifted from implementing individual parts to designing solutions that hold up in real-world operations. I don't see these as jumps, but as connected phases:

• Enterprise systems and ERP – operations, processes, and data in daily reality.
• Global platforms – core business logic and rules that must remain consistent over time.
• Banking and energy – stability, security, auditability, and responsibility for production operations.
• Healthcare – software that must work reliably in specific situations.
• Independent practice – the role of technical partner and working with long-term benefit.

The first significant part of my career was connected to enterprise systems in real-world operations. It wasn't isolated development, but systems used daily by people across the company – from operations to management.

I experienced situations where a bug made it impossible to sell or produce, where invoicing was blocked, or where incorrect data got into accounting. The fix itself was often quick, but testing and safe deployment to production took additional hours. The difference between "fixed" and "safely in production" was very concrete in these moments.

Not all critical problems had purely technical causes. Often it was a combination of system complexity, unconsidered connections, and decisions made outside development. In such situations, the goal wasn't to find someone to blame, but to understand the entire chain of causes and return the system to a stable state.

Sometimes this meant controlled database interventions. Always as a last resort – conscious, traceable, and executed with a clear plan for how to prevent the same type of problem from recurring.

On a global ERP platform, I contributed to developing core business logic, especially the tax engine. This was a central part of the system that influenced the behavior of the entire platform across different document types and scenarios.

Every change was an intervention into existing system behavior. Writing the code was often the easier part. The harder part was thinking through the impacts of a change and ensuring the system remains consistent even after further modifications. Changes were introduced at clearly defined dates and often included transformation of existing data.

For me, responsibility didn't end with a merge request. What mattered was for the system to remain predictable, maintainable, and understandable for further development long-term.

In the banking environment, I worked with extensive architecture and strict security policies. Systems were divided into many parts and required coordination across teams and roles.

My role involved development, navigating the architecture, and finding solutions that were technically correct, secure, and feasible within existing processes. For higher-risk changes, I didn't concentrate decisions just on myself – I consulted them and actively sought counterarguments.

Some decisions were unpopular, but I considered it more important to bear short-term tension than long-term consequences of a poorly chosen solution.

I've worked in teams for most of my career. It's rare that I work completely alone. I often serve as a mentor – currently I collaborate with about ten people across projects and technologies.

When a team lacks direction or technical leadership, I help set up a framework: goal, priorities, decision-making approach, and how to verify impact. Not formally, but practically – by creating structure in which the team can function effectively.

Already in my first job, I became deputy head of programmers. In the NetSuite environment, I was the first developer on the project and gradually technically led a team composed of developers, QA, and business roles. It wasn't about managing people from above, but about clear direction, decision-making, and predictable deliveries.

Mentoring and technical leadership aren't roles for me, but a natural consequence of how I work.

I contributed to developing a mobile telemedicine application in React Native. The app was used by patients and doctors in situations where there was no room for complexity or ambiguity.

Emphasis was on data security, stability, handling connectivity issues, and intuitive controls. This experience reinforced my belief that a good solution isn't necessarily the most complex one, but the one that works reliably when it really matters.

Since 2022, I work as an independent developer and technical consultant. Clients often reach out when they need to stabilize a system, find the cause of a problem, and safely return operations to normal.

When I take on responsibility, I don't do it impulsively. I do it when I understand the problem, can calculate the risks, and see a realistic path to a solution. If I don't believe in it, I don't take on the responsibility – not because I avoid it, but because false confidence is dangerous in critical systems.

In crisis situations, I protect my space for concentration. I openly communicate what I'm doing, when I'll check in, and what the next step is. Unnecessary pressure and constant interruptions are a risk – not to me, but to the outcome. Calm and concentration are part of the solution in these moments.

Long-term, I advocate for incremental delivery of changes. Delivering too many changes at once significantly increases risk while reducing the ability to quickly fix the system if something goes wrong.

I treat projects as collaborative work on solutions, not as a list of tasks. I'm interested in context, goals, and the impact of decisions. When something doesn't make sense, I say so openly and present it as input for discussion.

There are boundaries I won't cross. If a system is to be changed without a clear goal, without understanding the impacts, or under pressure to "just do it fast", I consider it my duty to say so. I never trade short-term peace for long-term risk.

I use modern tools including AI assistance. They help me speed up analysis and handle routine work, but architecture, decisions, and responsibility always remain with me.

I don't stay on projects out of inertia. I stay where I see my own contribution.