The most expensive mistakes of my career weren’t a line of code or a system architecture choice. Often, I paid the biggest prices in moments when I said “yes” while my gut was screaming “no.” This situation had serious impacts not only on my workload but also on my learning curve, personal development, and even mental health.
Looking back today, there’s a lot I’d like to tell young Mustafa. These aren’t the details of a programming language or the intricacies of a network protocol; rather, they are lessons shaped by field experience, reflecting on “how to work” and “how to be an engineer.”
What is the Power and Cost of Saying “No”?
As a junior, I was prone to accepting every task, every project, every request that came my way. This stemmed both from a “I can do it” motivation and a desire to prove myself. However, over time I realized that saying “yes” is easy; the real challenge, and what truly propels you forward, is learning to say “no.”
Once, at the beginning of an ERP project that was already 5 years old, I was asked to simultaneously develop a new module and solve a performance issue with an existing integration. They said both were urgent. I said, “I’ll do it.” The result was both tasks being left unfinished, and both I and the team experiencing significant stress. At that moment, I clearly understood that my resources were limited and I needed to prioritize.
Is Technical Debt Not Just About Code, But Also My Career?
We always hear the concept of technical debt in the context of codebases and architecture. It’s defined as the future costs incurred by producing quick solutions. But in my experience, this concept also has an equivalent in our careers. Topics we postpone learning, deficiencies we don’t address, moments we don’t step out of our comfort zone – all accumulate as “career debt.”
While working on a production ERP, designing an AI-powered production planning module, I found myself deep in PostgreSQL. GIN indexes, WAL segments, Vacuum parameters… these were topics I had previously thought “the DBA will handle it anyway.” Yet, as the architect of the application, I couldn’t make correct decisions without knowing these details. To pay off this debt, I spent weeks reading documentation and running tests. If I had done this earlier, the project would have progressed faster, and I wouldn’t have experienced that stress.
Why Are Human Relations and Organizational Flow So Important?
I spent years pondering software architecture. Monolith or Microservice? Event-Sourcing or CQRS? However, over time I realized that the success of a software project often depends more on organizational flow and human relations than on technical architecture. The code we write reflects how people work and how they communicate with each other.
While developing an internal platform for a bank, the biggest challenge wasn’t technical, but the silo structure between different departments. Each team defended its own truth, and we struggled to establish a common language. Even the best-designed system remains on paper if there isn’t proper communication flow between users and teams. That’s why engineering isn’t just about writing code, but also about understanding people and uniting them around a common vision.
Beyond Continuous Learning, What Does It Mean to Learn to Unlearn?
In the tech world, “continuous learning” is already a cliché. However, I believe that “learning to unlearn” is at least as valuable, if not more so. What we know can sometimes prevent us from seeing new solutions. Old habits can hinder us from perceiving new paradigms.
Last month, I was trying to solve a performance issue in the backend of the financial calculators, which are part of my side product. With years of habit, I immediately dove into PostgreSQL queries and indexes. Hours later, I realized the problem was caused by a simple Redis OOM eviction policy setting. My old knowledge had led me down circuitous paths instead of directly to the problem. Sometimes, you need to set aside old “truths” and look at the problem with a completely fresh perspective.
Why Is Investing in Yourself Not Just About Getting Certificates?
As a junior, I mostly saw investing in myself as learning a new language, getting a certificate, or mastering a popular framework. These are important, yes. But the real investment is in problem-solving ability, critical thinking, and adaptability. And of course, the investment I made in financial literacy and time management to better manage both my career and personal finances.
While working on projects like the anonymous Turkey data platform I added to my own site, I saw not only the technical challenges but also my shortcomings in data analysis and presentation. This pushed me not only technically but also to gain knowledge in a new field. Investing in yourself means not just “writing better code,” but “being a better problem solver.”
So, if you were at the beginning of your career, what advice would you give yourself? What was your most expensive “yes” or your most valuable “no”? I’d love to hear it in the comments.