2B || !2B - That WAS the Question
Over twenty-four years. In the world of technology, that can seem like several lifetimes. When I started my journey with .NET, the framework had barely had a minor version release (1.1) and I was learning how to design systems (something you're not really taught in school). I look back on how it all got started and I remember staying up late, studying with my girlfriend at the time til 2 am or 3 am getting ready for the MCAT and how I got into the wild world of tech. Looking back from the era of .NET 8 and cloud-native microservices, the landscape is barely unrecognizable to me...and yet, it still seems "familiar".
If I could send a message back to my younger self starting out in the early 2000s, it wouldn't be about syntax or specific APIs. It would be about the mindset required to thrive in a constantly evolving ecosystem. Here is what I know now that I wish we knew then.
Code is for Humans First, Machines Second
In my early years, I took a lot of pride in building "clever", "compact" code. I felt like "elegant" meant "complex." It wasn't until I learned how to engineer systems that my code went to the next level. Part of taking your code to the next leavel is keeping it simple.
Pro Tip: Readability is the ultimate feature!
Avoiding complexity will make your code 10x more readable and comment like your life depended on it; becuase it probably will 😉. Here's a simple rule of thumb:
Pro Tip: Write your code as if the person maintaining it in three years is a cartel member who knows **EXACTLY where you live!
Use descriptive names, keep methods small, and don't over-engineer abstractions before they are actually needed. This is one sign that you know what you're doing.
Don't Marry Your Framework
I remember when web pages used to be coded in VBScript or Javascript. I've built DTS packages. I remember when C# collections first came out. I've seen the rise and fall of Winforms, then WebForms, then Silverlight, then MVC. If you tie your entire identity to a specific library, you’ll be obsolete as soon as the wind shifts. Not coding for 3 to 6 months is a sure fire way to put yourself out to pastuer. When you start thinking in terms of designing systems, you "decouple" yourself from frameworks and focus on solving the problem. That's what separates the architect from the coder.
Instead, master the fundamentals:
- Dependency Injection and Inversion of Control.
- The SOLID principles.
- Asynchronous programming patterns.
- Distributed system design.
The framework is just a tool; your architectural thinking is the product.
Soft Skills are Your "Hardest" Asset
As an engineer, it’s easy to think your value lies solely in your GitHub contributions. It doesn't. Your ability to translate technical debt into business value for stakeholders is what gets projects funded and promoted.
Learn to speak "Business". Understand the "Why" behind the "What." A perfectly architected system that doesn't solve a user problem is a failure. So be sure you understand the problem you're trying to solve.
Continue to Learn
I'll be honest, I wish I had spent time in my younger years building a bad @$$ portfolio of projects I have worked on. Nothing says you can do the job better than doing the job. Building a decent portfolio goes a long way to show you can walk the walk, not just talk the talk. Come up with a good study routine, plan on spending time OUTSIDE work working on YOUR OWN projects and NEVER be afraid to try something new!
Summary
The journey from .NET 1.0 to today has taught me that technology changes, but the need for clear communication, simple design, and continuous learning remains constant. Here’s to the next 24 years.
Comments
Loading comments...
Leave a Comment