In the early years of my career, as a developer, my biggest problem was always an if condition or a complex JOIN query in PostgreSQL. In my eyes, the greatest achievement was writing and running a complex algorithm without errors. Nowadays, looking back twenty years later, I see that writing code has become the easiest part of the job.
This doesn’t mean code is unimportant, of course. However, the real challenges of a project often lie far beyond the lines we type at the keyboard. The main struggle now is with people, processes, and organizational flow.
The Easier Face of Code and New Challenges
Today, setting up the skeleton of an application with modern frameworks like FastAPI or Vue/React, or generating routine code blocks with AI-powered tools, is faster than ever. There are ready-made libraries and solutions for almost every need. This situation has technically simplified the act of writing code.
When I design a new operator screen in a production ERP, writing the frontend and backend code might take me a day or two. But ensuring that screen meets the operator’s real needs, correctly processes data from the production planning AI, and works seamlessly with other iSCSI supply chain integrations — these are the things I really need to think about. Code is just a tool; the real job is understanding the context and transforming it.
Invisible Barriers: People, Processes, and Policies
The real challenges come from the world beyond code. In a customer project, VPN connections were cut at 03:00 AM due to a new firewall policy from the security team. There was no error in the code, but the system’s integration flow stopped, and it took days to resolve this issue.
Years ago, when designing an OAuth2 flow for an internal banking platform, everything was technically perfect. However, the security expectations of different departments prolonged rate limiting decisions for weeks. During these processes, I didn’t write a single line of code or fix a bug. I just listened to people, persuaded them, and found common ground.
The Weight of Architectural Decisions
As a system architect, deciding between monolith or microservice when designing a software architecture, avoiding ORM pitfalls, or implementing the transaction outbox pattern requires much more thought than writing code. These decisions directly impact the project’s future, maintenance costs, and scalability. Choosing the right index strategies in PostgreSQL, configuring the connection pool, or anticipating WAL bloat issues demands much more than pure coding skills.
Lately, I’ve been working on AI applications. Setting up Prompt engineering or RAG architectures is more about finding the right data, understanding user intent, and developing multi-provider fallback strategies than it is about the model itself. Here too, code is just a tool; the real challenge is designing and managing the entire system.
Real Costs and Lessons Learned
Last month, I forgot to set a cgroup memory.high limit for a background process running in systemd units. It wasn’t a code error, just a simple configuration oversight. The result: an OOM-killed service in the middle of the night and a 3-hour debug session. This once again demonstrated the importance of mastering the entire system, not just the code.
One of the most important lessons I’ve learned in my career is this: my most expensive mistake was often not a line of code, but a decision I said “yes” to in a meeting without fully foreseeing its consequences. Or accepting a requirement without questioning it. The cost of these mistakes can be weeks of refactors, rollbacks, or missed deadlines.
Writing code is now the easiest part. The real mastery lies in understanding, managing, and optimizing the ecosystem in which that code breathes.
So, what were the moments in your career where code was easy, but its surroundings were difficult? What was the most expensive “yes” decision you made? I’d love to hear in the comments.