Getting Back on the .Net horse

How My “Bro-mance” with Microsoft Began

My first job out of college was writing “old school” ASP code, back in the early 2000s. It was an honor for me to support the Marine Corps as a contractor during Operation Enduring Freedom. I spent a lot of time messing with Microsoft Access, Microsoft SQL Server, and IIS. That eventually led to a handful of years working with SharePoint, and then writing applications in C#. I was deep in the Microsoft stack. I stopped doing full-time .Net development just as MVC was hitting critical mass, so it’s been a hot minute.

I work for a company filled with very smart people. Our brand is built on expertise and extremely high customer satisfaction. Honestly, I was a bit intimidated when I started with SingleStone. At this point in my career, “holding my own” isn’t good enough. I’ve been fortunate to have worked with some very talented software engineers, project managers, and business analysts. Some of those folks have been mentors for me. My goal is to lead technical teams and become an Agile Technical Coach. My desire to write code all day, every day is not as high as it once was. But, as I started working with my current company, I was asked to jump in and start writing .Net code and revert to being an individual contributor.

This actually turned out to be good for me. Several things worked in my favor. I was placed on an established team of talented people with a veteran Project Manager and an extremely capable Technical Lead (we’ll call him JB). Our team is Agile, which is something I’m very familiar and comfortable with. The scope of work was clear and the backlog was in place. My love of Visual Studio was quickly rekindled. It is the best IDE on the market. Period.

Getting Back to the Future

When you open that first solution, and the code you’re reading looks like Klingon, have a 3-second internal freak out moment and move on. Getting caught up on C# 7 has actually been pretty fun. I’m already looking forward to some of the features to be released in C# 8, such as nullable reference types, async streams, and default interface implementations.

Getting back on the .Net horse will probably involve slowing down in order to speed up. You will get to a point where you’re feeling good about things and possibly take some things for granted. A rush to click that “Deploy” button may result in some undue angst. Slowing down and checking the details will prevent unnecessary debugging. Time is expensive.

You may experience another wrinkle in your comeback: inheriting and updating your client’s code. They have the right to do things their way. Unfortunately, this can sometimes create a steeper than expected learning curve for you, in addition to everything else at which you need to quickly gain proficiency. It will be necessary to work on your craft. You have to want to be really good, if not great. Also, don’t shy away from taking ownership. It’s easy to hide behind someone like JB on your development team.

Realistic Expectations

If you’ve been out of the game for a while, you’re going to look pedestrian compared to the folks that have been writing code at a high level (like JB). Let your ego absorb it. Don’t be afraid to ask questions. We can’t always pick our teammates, but we can definitely pick how we interact with them. A positive attitude + results will pay dividends. You’ll have to figure some stuff out on your own so that you don’t create too much of a distraction for your other teammates. But when that user story you’re working doesn’t move out of the “In Development” column after a few days (without a documented reason), you could put yourself in a tough spot. I was really irritated when I had to roll a story across sprints because I hadn’t finished development. I didn’t want to disappoint my team. The only thing to do was finish as quickly as possible and move on to the next story. Progress feels great.

I am always in a position of learning and improving. It’s humbling. I fumbled through updating a Code First migration. I felt like banging my head against the wall while debugging an Azure webjob. I watched helplessly while my deployment failed in Octopus. But… I embrace the joy and pain of software development. The satisfaction of seeing working code demoed to a happy client and project manager is exhilarating.

If you find yourself having to dust off development skills that have been dormant for a while, keep in mind that the fundamentals of writing good code haven’t changed. Keep it simple and lean. Get familiar with Azure (or your cloud provider of choice), if you haven’t already. Consider using Test-Driven Development (TDD) to ensure that you understand the problem or user story, and reinforce unit testing. And don’t be too proud to ask JB for a code review, outside of your team’s sprint cadence.