The most expensive mistake in my career wasn't a line of code; it was a "yes." Twenty years ago, at the beginning of my career, I was saying "yes" to every opportunity that came my way. Yet, looking back now, I know some of those "yeses" should have actually been "no." This post isn't advice; it's 7 lessons, bearing the scars of my own experiences, that could have guided the 2006 me, and indeed many tech professionals since.
This journey is filled not just with technical skills, but also with human relationships, choosing the right projects, and knowing your own limits. What I've written here has never been a dry list of advice; each point is an experience I've pondered for hours, reviewed hundreds of times, and ultimately shaped my career. If you're ready, let's look together at these seven lessons I didn't know then, but now see the truth in every line.
1. Saying "Yes" Isn't Always Moving Forward
When I was young, every new project, every new technology was exciting. While writing the backend for a manufacturing ERP, I always had more features, more complex solutions in mind. On one hand, I was doing iSCSI-based supply chain integration, and on the other, designing new UI elements for operator screens. At that time, saying "yes" to an opportunity meant taking another step in my career. However, this sometimes led me not in the right direction, but just down a busier path.
ℹ️ Accumulating Experience
When saying "yes" to a project, it's critical to question how much time it will take, which priorities it will delay, and what it will contribute to my career in the long run. Sometimes saying "no" to a project opens up space to say "yes" to something more important. In 2006, this balance was hard to strike, but 20 years later, I see how crucial it is.
This situation was particularly evident in enterprise software development. Instead of constantly adding new features, improving the existing codebase, optimizing performance, or patching security vulnerabilities was just as valuable as developing new features. But back then, these "background" tasks weren't very appealing. As a result, for years I entered a "just add more" cycle in many projects.
2. Not Every Technical Depth Is Valuable
When designing network infrastructure, I always sought the most complex and efficient solution. When doing VLAN segmentation, I would consider not just basic networks, but special subnets for each department and even separate VLANs for each server. While this depth was great in some cases, it often made management excessively complex. In switching and routing configurations, understanding the path of every packet in minute detail took up a large portion of my time.
⚠️ Seeking Simplicity
The more complex a system, the harder it is to find and fix faults. Especially in a manufacturing ERP or a critical enterprise application, complexity directly translates to operational risk. In 2006, I mistook complexity for an indicator of skill; now I know that simplicity is the greatest virtue.
For example, if a company's gateway has 3 different ISPs, voice packets are bound to drop if DSCP marking is not done correctly. Such fine-tuning, while optimizing network performance, can also lead to serious problems if not configured correctly. At that time, focusing on these intricate details gave me a sense of expertise, but in reality, I was just creating more room for error.
3. Creating Your Own "Side Products" Is the Fastest Way to Learn
Developing financial calculators on my own VPS, making a spam blocker for Android, or setting up an anonymous data platform... These are things I did many times in the early years of my career. Back then, I saw them only as personal projects. But now I understand that these "side products" were what taught me the most. What I learned while working on a manufacturing ERP was valuable, but the problems I encountered while building a system from scratch on my own were completely different.
💡 Becoming the Architect of Your Own Projects
Instead of saying "yes" to a project, you can turn your own project into something you say "yes" to. This allows you to take control of your learning curve. Finding an idea and bringing it to life develops not only your technical skills but also your problem-solving and decision-making abilities.
Tinkering with PostgreSQL database settings, experimenting with Redis's OOM (Out Of Memory) eviction policies, configuring Nginx as a reverse proxy, or doing simple orchestration with Docker Compose... All these experiments gave me unique experience in system administration. You might not get the chance to experiment so freely in a corporate project.
4. Security Is Not a Module, But an Architectural Imperative
Early in my career, I often saw security as a "patch" added towards the end of projects. After developing an application, I would think, "now, how do we secure this?" I thought topics like kernel module blacklisting (e.g., against vulnerabilities like CVE-2026-31431), writing fail2ban rules, or understanding JWT/OAuth2 patterns were details added later. However, I quickly realized how wrong this approach was.
🔥 Cost of a Security Vulnerability
The cost of a security vulnerability can be much more than a simple data leak. Reputation loss, legal liabilities, and operational disruptions can quickly jeopardize an entire project. Therefore, it is essential to make security a part of the design from the very beginning.
Indeed, issues like switch hardening (with features like DHCP snooping, DAI, IP source guard), routing authentication (in protocols like OSPF/IS-IS), or Zero Trust Architecture (ZTNA) are architectural decisions that need to be planned from the outset. Mistakes like insufficient calculation of VLAN numbers when designing network segmentation create security vulnerabilities that are much more costly to fix later. Security truly is a layer that must be considered from start to finish.
5. Learning From Your Mistakes Is the Best Teacher
Once, while trying to solve a WAL bloat issue in a system, I accidentally changed the autovacuum settings, and the system nearly ground to a halt. The WAL rotation alarm rang at 03:14 AM, and I didn't know what to do. Such moments were the most instructive in my career. Solving problems I created myself taught me much more than debugging someone else's code.
ℹ️ Don't Be Afraid to Make Mistakes
Mistakes are a natural part of the career journey. The important thing is to learn from these mistakes and not repeat the same ones. Openly admitting to problems you created and documenting your solution process creates an invaluable knowledge source for both yourself and your team.
As another example, I once got OOM-killed by using the sleep 360 command in the wrong place. This simple mistake taught me the importance of the polling-wait mechanism. Such concrete experiences are much more lasting than abstract theoretical knowledge. Understanding which symptom, which error, when and how it occurs helps you anticipate future problems.
6. Organizational Flow Is More Important Than Software
When developing the ERP for a manufacturing company, one of the most challenging things for me was not the software itself, but correctly understanding the company's operational flow. How purchasing, production, shipping, and invoicing processes would be reflected in the software was often a more complex organizational problem than the software architecture. Choosing a database index strategy was easy, but determining "how an order would be included in the production plan" was much harder.
💡 Understanding the Business Flow
Software architecture is often a reflection of the organizational flow. Before digitizing a business process, it is necessary to deeply understand the process itself. This requires not only technical skills but also business analysis and communication skills.
Therefore, the key to success in software development projects is not just writing code, but also grasping the business logic and organizational dynamics. More critical than a "monolith vs microservice" decision is the question, "how will we integrate this new feature into the existing workflow?" This was a major epiphany for me, especially on the manufacturing ERP side.
7. Knowing Your Limits and Asking for Help
Early in my career, I thought I could solve everything on my own. In a network problem, a database performance issue, or a security vulnerability, my first reaction was to dive in myself. But sometimes, I realized I needed an outside perspective or a different expert's viewpoint to solve a problem. Especially in complex systems, for example, understanding why a BGP routing decision was wrong could take me hours alone.
⚠️ Asking for Help Is Not a Weakness
Asking for help is not a weakness, but a smart strategy. Knowing your limits and getting support from the right people when needed saves time and helps you produce more robust solutions. This is also a fundamental part of teamwork.
This also applies to modern security architectures like "Zero-Trust." When setting up predictive or anomaly-based monitoring systems, instead of relying only on what I knew, researching different approaches and talking to experts yielded much better results. Accepting my own capabilities and the limits of my knowledge made me a better architect and a more effective problem-solver.
If I could give these seven lessons to my 20-year-ago self, I'm sure my path would have been a bit smoother. However, these scars are also my most valuable lessons that brought me to where I am today. Each one is a truth pondered, lived, and proven.
Now I ask you: Looking back at your career, what 3 things would you tell your 20-year-ago self? Or what was your biggest "scar"? Share in the comments, let's discuss.
