Photo by Milad Fakurian on Unsplash

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

    🩺
    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>