It’s been about half a year since I wrote my last post, and I wanted to reflect back on some of the goals I had set for myself.  In a nutshell, I wanted to 1) Grow HSV tech community, 2) learn some cloud technologies, 3) build something, and 4) read more theoretical books.

So halfway through the year, I feel like the HSV tech community has been growing, and HSV.py is still going strong.  I still have a surprise coming, so stay tuned.  But what has derailed most of my other goals is that in April, I started a new job: Software Engineer at Canonical!

I’m working on the CPC team which focuses on public and private cloud deployments.  I mostly do Python library work and Jenkins pipelines to transform Ubuntu images to their suitable cloud images.  It’s been great, because 1) I can work in Python and 2) I am getting to learn about a lot of cloud technologies along the way.

But, this is only my third ever job.  The first time I moved jobs, I had 3 years of experience; now I have 12.  I feel like there is a lot of advice out there for when you are new and swapping jobs, but not so much when you’re a senior engineer.  Here are some tips I’ve discovered in the three months of working there.

Languages/Frameworks Don’t Really Matter

I was going to a Python job, which I felt pretty good about, but every once in a while, you are going to switch jobs to a language you don’t know too well.  Or you might be going to a familiar language or a completely different framework.  Either way, I’m trusting that you, as a senior engineer, know how to learn a new language/framework quickly and start contributing.

Where I struggled was that even though I could contribute, I could  not at the pace that I was used to.  I have to do a fair share of Bash scripting as part of my new job, and my Bash is, um, not great.  I mean, I can read it just fine, but I just don’t have enough time writing it to really get nuance.  I have to google quite a bit.

But, if you’re in this position, don’t fear; use your tried-and-true tricks to help you learn quickly.  Find ‘best practices’ guides (I’m going through Bash Cookbook at the moment).  Use linters, unit tests, code review, and any other good practice that help you catch stupid errors.  You don’t need the <X> for Basics resources; you need to learn how to be effective past a beginner.

Focus on the Intangibles

The toughest part of starting a new job as a senior engineer for me was not feeling like I didn’t feel useful for a while.  In a new job, you typically have a whole new domain, new codebase and new team to learn, on top of getting your work done.  However, hopefully as a senior engineer, you’ve been cultivating skills that don’t require you to acquaint to any of the new-ness.  Clean code, good design, documentation, community building, testing.  Any of these can be impactful from day one, even if you aren’t coding.  Focus on your strengths outside of a specific technology, and use that to contribute.

Get To Know Your Team

I really believe the people you work with is the greatest indicator of mental health at a job.  Working closely with a high-functioning, friendly team is great.  Get in on code reviews as early as you can, even if you don’t understand the code yet.  Meet with team members 1-on-1 and ask questions.  Learn who does what well on your team and lean on them.  Find the person who most recently joined the team and learn what worked well from them.  Pair program as much as you can.

Offer To Do the Tedious Boring Grunt Work

This sounds counter-intuitive, shouldn’t this be for junior engineers?  I say no.  These often are great tasks to pair up with someone.  Most tasks have something that is slow (maybe the testing, maybe the data entry, maybe a very uninteresting library.)  By picking this up, you’ll build a rapport with whomever you’re helping, and you’ll learn some things that could be automated, streamlined, or otherwise improved.  You’ll also get more domain context for what you’re working on.

Document/Automate Everything

There is always a plethora of things that could be automated or documented.  Always.  Make things easier for the team and you’ll feel like you’re contributing quickly.  Document the things you do, so that you have a clear communication point to explain what you’ve done, and that will also serve as on-boarding material for the next person.  Put things on wikis, internal forums, READMEs, and whatever else you can.  Over-communicate, and you’ll find that you’ll learn what you really know and don’t know early, drive important conversations early, and also just improve Quality of Life afterwards.   If you don’t have a great on-boarding process, help create it for the next person.

Wrap-up

A lot of this advice applies to junior engineers as well, but if you’re a senior engineer swapping jobs, you’ll probably have a greater feeling of inadequacy until you get back up to your normal productive speed.  Fill in those gaps with anything you can; you don’t have to be working on code to be productive.  If you can make other people productive, that counts too.  And remember, someone will get hired on after you, so you want to continue to pave the way and make it better for the next person (make sure to reach out to them and share these tips and any others you found effective as well).