Learning adjacent technologies

As a software engineer, even a highly experienced one, there will always be technologies adjacent to those you regularly work with that you have limited or no real knowledge about.

It may be something in a layer below that is being abstracted away by a framework or library that you are using, like an ORM. It may be something that was set up for you by someone else, like a CI/CD pipeline.

As busy engineers, it’s great to not have to think about these things and have them “just work”. But with this productivity gain, by treating them as a black box there’s also that fear of going near them if something goes wrong or a change is needed.

As Scott Hanselman points out here:

Learn how to question how things work. Learn that everything new and simple hides something large and complex. You can choose to live in a world where things just work, or you can choose to dig a little… you don’t need to be an expert in everything but know that you can learn.

I’ll share some examples of things that fell in to this category for me over the past few years:

  • How a multi-account AWS Organization with SSO is set up from scratch. This is often something that is already done by someone else, but I wanted to learn how to help small startups without in-house AWS platform expertise to do this, so I learned OrgFormation. I find that not having to rely on others to do something for me is always a great motivator to learn how to do it myself.
  • How IAM really works. I always kinda just learnt enough to get by but when I worked on a project with a large enterprise client in an extremely locked down environment, I was forced to dig deeper. (The Effective IAM book really helped here)

Here’s a little exercise for you to try and uncover areas that you might want to dive deeper into. Consider the tech stack and environment that you’re working with in your main place of work:

  • What areas of your codebase are you reluctant to touch because it uses a technology/approach that you don’t fully understand?
  • What libraries or architectural components do you treat as a total black box and would struggle to debug?
  • Is there something in your job where you’re dependent on someone else to do something for you? If you had to do this yourself, would you know how?
  • Do you understand all the steps involved between you pushing your code to your team’s Git repo and it being deployed to production?

If you’re open to sharing any of your answers, I’d love to hear them. Just hit reply.

— Paul

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    Free Intro Call

    Book a free 30-minute introduction call with me to see how I can help your team with serverless.

    Select a time for our call

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>