Life as an Internal Instructor

Typically, when going down the path of software development, it's common to take the following route:

1. 🎉 Junior Developer - First Steps
2. 🤓 Developer - Experienced
3. ✨ Senior Developer - Leadership and Mentoring
4. 🏗️ Architect - Project Scaffolding and Monitoring
5. 🗒️ Management - Bridge Between Devs and Customers

In addition to the word "developer" being interchanged with "engineer", the community has also seen a few new titles appear:

• 🥑 Developer Advocate - Public Voice and Support of Company Product(s)
• 👩🏽‍🎤 UX Engineer - Develops According to Design Specs and Consumer(s) Experience
• 👨🏽‍🏫 Internal Instructor - Upskills Team Members in Project Tooling and Development

I currently wear the last two hats at my company, however being an Internal Instructor is what I've been for the past 3 years, and will be the focus of this post.

Breaking Down the Role

Being an Internal Instructor encompasses a few different hats. Some days I'm "head down, headphones on" because I'm developing an example to help teams understand a complex problem, other times I can be seen mumbling to myself because I'm rehearsing my presentation.

Often times, I feel like a Developer Advocate, even if it's only for my company to see. The biggest difference however, is that it's common for my deliverables to be in the form of a two-week workshop. In fact, I've had groups of 12 for 6 hr/day for 3 months, and now with physical distancing taking place, I just ended a 2 hr/day, 2-week workshop for 30 individuals. It was crazy!

The multiple formats, skill levels and topics are the best and most challenging aspects of the position.

How Does One Become an Internal Instructor

Some find it surprising that I carry no degrees. I attempted to become a teacher after college. However after 1 1/2 years and realizing I couldn't pass my classes with track and field records, I flunked out.

After a few interesting career paths, and a few failed attempts at teaching myself Java and Objective-C, I found my niche in frontend development.

Shortly after, I joined a local meetup group with the goal of not just attending, but also giving a presentation. Once I was able to check that off, I started helping other new developers on their path as well. Whenever I was asked a question I didn't understand, I researched and would send them a long Slack message with the answer.

It wasn't long before I realized that some didn't learn through long messages. Eventually, text became images, images became video, and video became live presentations. After a while, I wasn't just helping one person, but many.

Being able to take a problem, solve it, and explain it in a user-preferred format is a skill that translates to not just development, but also to other areas such as group projects, parenting, city government. All hats I've had the honor of wearing.

This of course, is my experience. However as an introvert who enjoys getting paid to pretend to be an extrovert, it's been rewarding. Note that the path towards this career doesn't have to be conventional..but that's programming in general and a rant for another day🙂

🚨Restrictions May Apply🚨

In my years involving this position, I've learned many hard lessons. Some were when I would underestimate the time it took to prepare a lesson. Others were when I would overestimate the knowledge baseline for an individual or entire class. However, I see those as learning opportunities and can strive to do better.

However, as an Internal Instructor there is one mistake that could immediately jeopardize your position:

Not abiding by Intellectual Property

Let's take a warmup scenario:

After talking with several team leads, I understand why a reusable component is built the way it is, and I write a blog post on Dev detailing that reasoning, along with the source code so that others may learn from our mistakes.

Ok, that's simple enough. Discussing internal methods and sharing private content (such as source code) is a big no-no.

Alright, how about this one:

As an Internal Instructor, you get assigned to deliver an upcoming JavaScript course. While working on the course, you come up with a really nice example of how to explain something complex. You make a video about it on your work laptop, BUT upload it to your personal youtube account. When it's time to deliver the course, you embed the video.

This is the same as the first scenario except reversed. A couple things to note:

• The example was discovered on company time
• The solution directly relates to what you were tasked to do
• The content you created on company time was embedded in company material
• The clear end all be all: It was done on a work laptop

🗒️ Anything you do on a work computer is your employers. Anything.

Ok, this is getting fun. Last one:

Prior to becoming an Internal Instructor, you start off as a UX Engineer. During onboarding, you see in a readme file that you can run the command:

nvm install node --reinstall-packages-from=node

to bring over your global packages from another version of node.

You then tweet this awesome discovery

So this is not a violation, as the nvm package is open-source, and this example is in their documentation. However, reading company documentation and then tweeting it--when you've just started as a new employee, is enough to get a chat with management😅

These scenarios won't typically apply to just Internal Instructors, but work in general. I bring them up because our industry doesn't talk about them enough for those new, and also because once you understand the rules, you can have meaningful, transparent conversations within your organization about bending them.

For example, even though I create internal frontend content, I am now allowed to post content to YouTube, Dev, and Egghead. However I do so knowing that I am trusted with making responsible educated decisions. Again, it's all about being transparent and when in doubt -- over communicate.

If interested, I'd be happy to create a followup post on how to navigate those conversations with management. The key however is trust, credibility, and political capital.

This is just a brief perspective on my line of work. Note that because of the word "Internal", the exact requirements will differ slightly between orgs. However, if you're interested in finding this as a career path, I'd love to hear from you, and if you are a trainer within your organization, I'd love to hear your thoughts as well!

I'll be posting more often 🎉, so be sure to follow, until next time!