17 years ago, I wrote my first line of C# code (.NET Framework 3.5).
It was in the IT school.
12 years ago, I wrote my first application in .NET and pushed it to production.
It worked, but it had bad code. I did not know it at the time, but I would spend the next few years learning how to improve.
Over more than 12 years, I have shipped buggy releases.
I have over-engineered features nobody asked for.
I have argued about tabs and spaces in pull requests.
I have debugged distributed systems on weekends, missed estimates, and watched "future-proof" architectures rot into legacy.
Some lessons were painful.
Others were priceless.
None of them came from a textbook; they came from real projects, real bugs, and real teammates who pushed me to be better.
Today, I want to share the 40 most important takeaways I have learned over my career.
Let's dive in.
👉 Read original article on my newsletter: https://antondevtips.com/blog/40-lessons-i-learned-in-12-years-as-a-dotnet-developer
0. The best code is the one you don't write
Every line of code is a future liability.
It needs to be read, tested, debugged, deployed, and maintained for years.
The cheapest, safest, fastest code is the code that never gets shipped.
Before writing anything new, I ask myself: do we really need this? Is there a simpler way? Can an existing tool, library, or feature solve the problem instead?
Many projects fail because they have too much code.
Less code means fewer bugs, faster onboarding, and less time spent maintaining things nobody uses.
1. You're not paid to write code - you're paid to solve problems
Code is just a tool. The real product is the value you deliver to the business and to the users.
I have seen developers spend weeks polishing a feature nobody asked for, while a critical bug stayed in production.
I have seen teams build complex frameworks when a simple script that runs in 5 minutes would have done the job.
The best engineers I know start with the problem, not with the technology.
They ask questions, understand the context, and only then choose the right tool. And sometimes that tool is no code at all.
👉 Read original article on my newsletter: https://antondevtips.com/blog/40-lessons-i-learned-in-12-years-as-a-dotnet-developer
Top comments (1)
Great start, and lesson 0 resonates with me. I’d add a security angle: every line of code, and every dependency, is also attack surface. Less code means fewer vulnerabilities, a smaller supply chain to audit, and less to patch at 2 a.m. when a CVE drops.
Lesson 1 matches what I see in data work: the best solution often isn’t a model at all. A simple rule, a query, or a baseline you can explain frequently solves the problem, and you only reach for something heavier once the simple version has proven insufficient.
Thanks for sharing the lessons from 12 years. Which of the 40 took you the longest to learn?