Re-Purposing Day Job Work to Make Career Moves

Last week, I passed the AWS Cloud Practitioner exam (hooray!). I've had a very specific strategy for learning AWS at work and re-purposing that knowledge for content and my long-term career trajectory. It occurred to me that sharing this strategy might be really helpful for some people, as I get asked quite often how to balance work with building your personal brand and career (especially since DevRel tends to blur those lines).

My AWS Learning Strategy

At a high-level, I always try to re-purpose my time. At every job I've had, I've tried to learn skills that were related to my current job but could be a bridge to my next career goal. When I worked part-time for a real estate brokerage in college, I would watch video courses on building a professional network when the phones weren't ringing so I could find a better job. When I worked in finance customer service, I found an excuse to learn to code (it's a long story but TL;DR the brokerage had a software department) which led to my first dev job. In Portland, I learned about ngUpgrade for a job and then turned that skill into a video course, which led me to DevRel and got me my first remote job at Auth0.

When I got into to DevRel a few years ago, I started looking for ways to keep my engineering skills sharp. Even though DevRel involves coding sample applications, building projects for content, and some open source, it's easy to get caught in a loop where you don't challenge yourself or can't figure out if your skills are relevant in a production environment.

I had been interested in learning AWS and cloud engineering, but it was just one of many things on my list that I couldn't find time to learn. Last summer, I had some opportunities come up at work that I knew I should take advantage of. Auth0 uses AWS extensively and I needed to deploy a new app for DevRel. This meant I needed to learn and use a bunch of core services in AWS like EC2, Lambda, and CloudFormation.

I decided to re-purpose this learning for my own benefit in two ways:

1. Content
2. Certification

To be honest, I haven't done as much content on AWS as I originally set out to since I made these goals prior to taking over the management of my team. I had a vision of incorporating AWS into my Auth0 DevRel content which I could then use as a springboard for more general AWS content on egghead and my site. Life has a funny way of not going as planned, though, as I now spend most of my time building DevRel strategy and helping my team members however they need me. So far, the big pieces of AWS content I've created are my egghead course on deploying Ghost to AWS and my article Where to Start with AWS as a Developer, which I'm turning into a talk for conferences like REFACTR.TECH. By the way, you can also find all of the resources I used to pass the Cloud Practitioner exam in that article.

The certification for me serves two purposes. First, I want the certifications to boost my overall career, though I don't necessarily have a goal in mind. I love my career in DevRel; I'm not necessarily looking to move into DevOps or Cloud Engineering. It's good to have options and future-proof yourself, though. I don't want to rely too heavily on Angular, React, or even JavaScript to make a living. I always want to make sure my skills are growing.

Second, certifications are a tangible way for me to see that my skills have improved. In DevRel, I'm not shipping production code. I don't get to see those improvements in my code when I look back over a product six months or a year at a time. I miss that a lot. Getting a certification is a nice way for me to say, "Hey look, I have proof that I grew as an engineer."

How to Build a Career Bridge from your Day Job

How can you start re-purposing your day job work for your career? Let me break down some strategies and tactics for you.

The main strategy is to use what's in front of you to build a bridge. Let's say you are doing React right now but really want to get a job doing Go. If your job doesn't use Go but uses C#/.NET instead, what would you do? First, think through where learning Go might intersect with your current job. You would want to build up your general backend experience regardless of the language, so you could start taking some backend tickets and learning C# and API architecture. You would still need to learn Go in your free time, but you could use what you're learning at your day job to fuel that education. For example, you could try to recreate features you've built in C# in Go. If Auth0 used GCP or Azure, I would have just learned that instead of AWS since there's a huge conceptual overlap. If I ever needed to make the leap to AWS specifically, it would have been much easier than starting from scratch.

Where do you go from there? If you're trying to get a better development job or switch to DevRel, you're going to want to create some content and build some sample projects to demonstrate your growth and supplement your resume. In most jobs, you will have some constraints you need to watch out for:

• Learning on the job has to support getting your work done, not get in the way of it.
• You can't directly re-use content you create for work (e.g. re-posting the same content on your site or personal YouTube channel)
• Code you're working on for your job might be private, so you can't use it in articles (plus it's company property)
• You can't get paid for something else while you're working (no double-dipping, so you'd have to take time off for paid work like consulting)
• You can't create on company property (office or laptop) or company time unless it's for work

Obviously I'm not a lawyer so make sure you get good advice for your situation. Whatever your set of constraints are, there are ways you can be creative. Even though the specific deliverable (code or content) can't be re-purposed, the skill that you're building is yours forever. If you're stumped on how to do this, here are a few techniques you can try:

1. Go generic. If you're learning NextJS at work and run into a bug or a cool feature, go home and write about it. Just remove any references to code from work. Recreate the bug or feature with a simple demo application.
2. Go up a level: "How to choose a JavaScript framework"
3. Go meta: "How to learn a new JavaScript framework"
4. Go down the stack. If you're focused a lot on frontend but your job uses MongoDB, start learning and creating content around NoSQL and MongoDB. Not only will you make yourself more valuable at work, you'll also learn a new skill you can carry with you.

I feel like I need to add a big caveat here: you only need to do this stuff if you want to and if you are trying to make a leap from where you are to somewhere else you want to be. I'm in no way suggesting that everyone needs to be coding or creating content on the side as a normal practice. Most of my biggest growth has come from daily development work at a job, even though at the time it didn't feel like it because it was a little boring and monotonous. I didn't realize how much I was learning in the moment. Even so, sometimes you need to make some moves and get to the next level, and that's where these skills come in handy.

What do you think? Have you used strategies like these before?

As always, please let me know if you put any of this in practice and if it's helpful.

This article started its life as an issue of my newsletter Developer Microskills. If you found it helpful, sign up here to receive a practical, actionable way to improve as a developer and developer advocate every week.