Switching Careers to Software Engineering: Six Months Update

Lessons Learned

Now that I’ve been in my role for a while, it’s time to reflect on that period and try to put it in context of being in a fully different role roughly 1 year ago.

The skinny:

• I don’t regret it at all.
• There’s a lot I don’t know.

…and that’s basically it. I’m learning a lot every day. If you were expecting some sort of sea change in who you are after you get the job, it’s likely not going to be there. It’s a new set of challenges.

You’re Good Enough

The thing that’s taken me aback most of all upon switching to a full time software engineering role was how comfortable it feels. There’s a lot of practices I held near and dear to my heart on a personal level that have translated well into an engineering practice.

My takeaways:

• You’re likely a good enough engineer.
• You probably know more about engineering as a job than you think that you do.
• Your teammates are happiest when you’re resourceful. Research your questions before bugging people. Look for novel solutions. Use what’s available to you.
• It doesn’t hurt to be open about what you’re looking for / dealing with.
• Don’t be too entrenched in your opinions.
• The real world of engineering is different than whatever source of information you’re reading about online.

Don’t Expect Things to be Easy

Like any job, software engineering comes with its own set of frustrations. You’re likely going to have to use software you don’t want to. You’re probably going to have to revive long-dead code that’s uncommented and unloved. You may even use unsexy languages / frameworks / approaches.

That’s well-known enough that it should’ve been obvious, but until you’re there it’s much too easy to write things off.

I’ve noticed the things that I struggle with the most aren’t even technical challenges. Sure, those are there. The majority of the issues, however, come from trying to be productive as a team. Solving things not just for myself but for the entirety of the organization. If I find a script that helps me debug something, that’s great, but it may only help me. Whereas a little bash script you use on your own machine may have been helpful before, there’s a lot of added difficulty if you want to share it with others, automate it, or make it a standard practice.

Motivating and working with groups of people is not an easy practice, and there will always be discrepancies in what people believe is the best approach.

Don’t Stop Learning

Software engineering is a role where you can find yourself in a life of learning. Finding the job doesn’t mean that part is over, it means you’ve just passed the first level.

There’s a lot you can do in your spare time, but the best thing you can do is occassionally challenge yourself to learn something new and try a different technology. I’ve found that the times I’m most productive are when I can recognized a pattern in one approach based on something I’ve done somewhere else. It’s a satisfying thing to see your curiosity rewarded, doubly so in programming.

The obvious suggestions:

• Take a course on Coursera, Udemy, etc.
• Build a personal project.
• Try to see if you can improve something you wrote in the past in a new framework / language / paradigm.
• Benchmark something and see if you can make it faster.
• Refactor an old set of code for maintainability. Make it easier for others.

This is not comprehensive, nor does it fit everyone, but it should give you an idea of things you can do that aren’t just the “Get ticket, do ticket” type engineering it’s easy to fall into. People love to see you excited about things, and being passionate will make you happier.

What’s next?

Frankly, I don’t know. I’m optimistic.

I’ll follow this up with another check-in at the one year mark.