Learning AWS as a Former ESL Teacher

Until three years ago, I was an English as a Second Language (ESL) and math teacher, and my relationship to technology mostly involved opening the copy machine and pulling out a paper jam right before class started. During the height of the pandemic, I retrained to be a data engineer. As a mid-life career changer, I assumed I’d be starting from scratch and that none of the skills I’d developed over the years in classrooms would be applicable. But it turns out there are some parallels between data engineering and teaching math to ESL students.

Teaching ESL has two facets: teaching language and teaching content. Teaching language means you’re taking concepts your students already know (such as family, school, food, transportation) and giving them the vocabulary and grammar to articulate those concepts in English. Teaching content means you are taking concepts the students don’t know (such as graphing on a Cartesian coordinate system) and presenting them with these new ideas via a language they haven’t yet fully mastered. The general methodology for teaching content is to first teach the vocabulary students need to know to access the topic (origin, axis, point, coordinate), to bring in as many visuals as possible so students can create mental models, and to build on what they already know. 

As a data engineer, I have been tasked with learning AWS solutions architecture, which is a dense system of interconnected ideas expressed in technical language I’m only passingly familiar with. It is also deeply abstract. You are architecting things that you cannot touch.

For those who don’t know, AWS stands for Amazon Web Services, which is Amazon’s global cloud infrastructure. To achieve the AWS Cloud Practitioner certification, you have to learn how to log on to the AWS system and interact with a plethora of services. Each service has a host of sub-services so that every conceivable use case is covered. And you need to know all of them to pass the test. 

This seemed a daunting task for someone new to technology, but I found some parallels between learning a language and learning AWS systems that have helped guide my studying. Both involve working through a fair amount of uncertainty to slowly gain fluency in a foreign system. 

When I set out to learn AWS architecture, I had to start with the language. AWS is rife with acronyms. The first thing is to find out what each acronym stands for. I would learn, for example, that EKS means Elastic Kubernetes Service. Knowing what this acronym stands for didn’t help me understand the concept, mostly because I didn’t know what Kubernetes meant. After some research, I learned that it’s a container orchestration system. This was still not enough information because I needed to know what a container was in this context. A bit of reading later and I learned that it’s a stand-alone unit that contains everything you need to run a program, including the operating system, the environment, the code, etc. I picture it as a cabinet full of organized computer components.

Each piece of the AWS puzzle not only has an acronym, but also an associated glyph. This, for example, is the EKS glyph:

The glyphs are combined into mappings to create the grammar of a Virtual Private Cloud (VPC). To read the diagrams, you need to know what the glyphs represent and how they can relate to each other. Thus, AWS is a set of concepts presented in a hybrid alphabetic and logographic language. Being able to understand how a VPC works means making sense of the sentences created by the glyphs. Here’s an example of a very simple VPC grammar:

I would translate the pictures into words: a request from the internet goes through the gateway and hits the load balancer. The load balancer then sends the request to the instance that is the least busy.

As I studied, I relied less on translating the glyphs into language and found I could understand the meaning of the pictures directly. When learning a language, an important milestone is articulating thoughts in the language without the need for translation. So I knew I was making progress.

Besides lacking foundational knowledge, I had another challenge; AWS has some linguistic quirks. For example, many of their services are called ‘serverless.’ This does not mean that they don’t run on servers. Everything ultimately runs on servers. It just means that AWS manages the servers, and you have no way of accessing them. ‘Runtime’ sometimes means how long it takes a process to run, but at other times it means the programming language you use for a Lambda function. This is like navigating homophones and irregulars as you try to make sense of how the plural of axis is axes. 

At times when teaching ESL, a student would say, “I dreamed in English last night.” Our brains are plastic; they’re constantly pulling in new information and reworking themselves to fit new concepts. When students finally dreamed in English, it meant that English had bored its way into the framework of their thinking. 

I had my first dream about AWS last night. I dreamed I was cooking with my younger daughter and I told her to go to the cupboard to get the flour, sugar, and a bastion host. She did, and the bastion host was a glowing pink square. She placed it neatly inside the rectangular cutting board we were using. 

When I woke up, I realized my brain had made a connection between cooking and VPC architecture, and the rectangular cutting board was the same as the rectangular representation used in diagrams of VPCs. I had incorporated AWS into the framework of my thinking, and I dreamed in the language of AWS.

I used the mental framework I have for learning language and applied it to learning AWS. I went from the foundational state of learning the basic vocabulary to the intermediate stage of being able to understand grammatical sentences without translation to AWS becoming such an integrated part of the way I think that my mind mixes it up with my other knowledge in my dreams.

Anna Shomsky – Data Engineer

@aws_partners @aws

Commerical Team

Leave a Comment