An announcement!

I started a new job on Monday! I’m super excited to be working at Drip on an incredible team working to power the ecommerce rebellion.

This is a big shift for me, because the stack, languages, and frameworks at use at Drip are totally different than those that I’ve worked within before. I spent a solid five minutes on my first day trying to figure out how to right click on a Mac, as a lifelong Windows (and occasional Linux) user.

I knew I was going to take this job, if offered, during my final interview. My interviewer asked why I was most excited about the role after my interviews, and what made me most hesitant. There were a lot of positives - but the hesitation for me was that I knew it would mean trading in a certain level of mastery.

In the Microsoft stack, I’ve now worked on enough prod systems that I don’t have to think much about the language or tooling. Basically, it’s comfortable for me working in C#. There is a joy in that! However, there is not as much learning.

Anyway, my interviewer’s response was really thoughtful when I admitted that my only hesitation was fear of dropping down and giving up my mantle of expertise. He said “yeah, I get that and there are times in my career too when you pause growing - but if you care about growth, then the best way to attain it is put yourself in a new space.” (That was the gist anyway).

Ugh I thought, he’s right…

UGH because in my experience, intense learning involves pain.

^ Replace “life” with “learning” and you basically have my philosophy of education

The Pain of Immersion Learning

Taking an experienced dev job in a completely different language and stack is basically an experience in immersion learning. I don’t hear it discussed that way in tech, but it’s a common tactic in world language education. And immersion learning, despite being the fastest way to gain fluency, can be punishing.

When you are only allowed to communicate in a language you are new to, you lose a lot of things that you don’t even realize contribute to your sense of identity. Jokes, for example. It’s really hard to be funny when only have the basics of communication. Same with code. The big concepts might be familiar, but suddenly doing little things is hard and takes time.

When I was studying world languages, Middlebury had a reputation as one of the best language acquisition programs - because they were total immersion. You signed a language pledge to only communicate in the target language for the duration of the program.

I feel like this quote from The Magic of Middlebury pretty much sums it up.

“We don’t pretend it’s easy at all. As a matter of fact, the place is often called a boot camp. The Russian school is often referred as the gulag,” said Stephen Snyder, Dean of the Middlebury Language Schools. “We know now that [students] experience immersion stress…essentially an entire year of language learning in seven or eight weeks is almost unbearable for some.”

The folks I know who made it through programs like that, including myself, did so by leaning into the pain.

Strategies for Leveling Up When you Don’t Understand the Language

Mostly to remind myself, there are some particular approaches I used when learning Arabic that also apply to picking up a new code language. Here are 3 that I know are impactful whether you are learning a world or programming language as a newcomer:

1. State your Ignorance - “I don’t understand”

One of the first things I would emphasize with my world language students was that it’s okay to say “I don’t understand” or ask for repeated information. Some classes punish this and students (and humans in general!) quickly learn to try to hide their confusion. When I taught world languages, I would give credit explicitly to beginners for both saying they didn’t know, and for noticing when the person they were conversing with looked confused or responded in a way that indicated they had missed something.

A super common impulse when you are in a conversation and don’t understand the other person, is just to agree. You’ll hear exchanges like this frequently: Questioner: “I read the blog post on immersion learning yesterday after class. What did you think about tactic number one?” Responder: “…Yes!”

However, the question will often be something that can reasonably be answered with a yes/no response, or the agreement might come out a little more nuanced - such that their confusion isn’t obvious. I’m not trying to bash the person agreeing without understanding - they aren’t at the level of the questioner, they are still trying to figure out what half the words in the question mean, so the choice isn’t meaningful yet.

You have probably also done this, in non-language situations. Have you ever been in a conversation that is over your head with someone who seems passionate about their perspective? I bet you felt a social impulse to agree, especially if this was someone you liked, admired, or otherwise wanted to impress. There is a percieved (and sometimes real) status or social cost to revealing you don’t understand in such situations. And it takes a lot more polish to disagree gracefully than to agree.

What this means for me in tech situations is to remember that not understanding something (yet!) isn’t a reflection of my inherent abilities. It’s beneficial to call out things that don’t make sense and ask questions - even basic ones. Although I try to take notes and pick new skills up without much repeat, it’s even okay to ask something more than once when you’re learning.

In some environments, this will be unpleasant - but it’s the fastest way to gain that knowledge. And the kind of people I want to work on development projects with will appreciate this approach as well. It means they get to explain something cool to me!

If you’re on a team or in an environment where exercising this approach results in people making fun of you, or reduces your status in other ways, that’s miserable. And a real thing. I’ve been there. I’m probably too hesitant of this approach as a result. For what it’s worth though, if you learn the skills (and this will help you gain them faster), other opportunities will be available to you in the future.

Plus, the more you admit you don’t know and still prove valuable in other ways, the safer you are making it for your colleagues to also admit when they don’t know. You might have more impact on that culture than you would guess (if you can weather the rough part). I hate this because I don’t think the newcomer should be responsible for fixing toxic culture elements, but I have seen it’s impact.

My icon for this skill was one of my grad school classmates in software engineering who was also changing careers. He spent so much time in the professor’s office asking questions after class, that by November the professor was joking he might as well invite the student to Thanksgiving dinner.

2. Seek out cultural experiences linked with the language

In world language environments, this used to be an afterthought to acquiring vocabulary or learning grammar rules, but it’s increasingly accepted that an integral part of learning the language and becoming proficient is engaging with the culture.

For world languages, this means eating the food, celebrating holidays and events, and exploring or learning about important places. Ideally, you do this in the language, but the point is that words and grammar are so tightly coupled with the cultural context in which they are used that the experience of that culture is part of how you reinforce and deepen language acquisition.

In tech, that might mean engaging with local user communities for a language or framework. Presentations and documentation tend to have a unique flavor for different programming ecosystems. The very approach to development and tooling often varies with the language because of the context and purpose for which it’s mostly used.

When I was in college, a friend recommended I try Python. I joined PyLadies in my city, and one weekend rented a car and we all road-tripped to the PyOhio conference. I learned more through that exposure than I would have picked up from a Hello World tutorial (or directly trying to apply the language to my coursework without learning more about it from a broad view first).

3. Be Visible in your Efforts

This is basically just “don’t be a perfectionist”. If you want to learn, you have to make your work visible. You have to say something out loud that you know is clumsy. You have to push the code that works but feels kludge-y.

It’s painful, because as an adult learner who already knows one language super well, being inefficient in another one is often something you are hyper aware about; this is part of why immersion world language education is so popular for kids. Children pick up spoken fluency faster not (just) because of greater brain plasticity, but because they aren’t as worried about looking stupid. Part of that is they don’t yet have an understanding of formal grammar in any language.

Here’s the thing though. All those studies about how children learn languages better? They are mostly focused on vocabulary acquisition. Adult learners actually pick up grammar and syntax more quickly in a second language than children, because they have a framework of comparison.

The same is true with programming courses. In your first encounter with coding, you probably wrote stupid and terrible solutions but were just so dang proud to get it working. Once you’ve reached a level of expertise in one language, it’s hard to work in another and feel that same excitement when you know there has to be a better way of doing it.

Leveraging that intuition for when something just feels wrong in code is a great opportunity for feedback. Pushing the messy solution shows that you are engaged, you are learning something, and gives those who are experienced in the language the opportunity to help you.

One of the hard things about onboarding less experienced coworkers is just figuring out where they are at - what things they understand and are picking up independently, and where they need more resources or help. Sharing things as soon as they are functional is a much faster way to negotiate the feedback loop than beating your head against it individually.

Fast Days

When I first changed careers from teaching to software development, I read this article Screw Mastery by Hanna Rosin that really resonated with me.

When I was feeling especially incompetent, I tried to remind myself of what they say in the books: You will gain inner grit! Reimagine your life! Autopilot is death! And some evenings, as I was walking home from work, I could feel that these things were true. Every day I was exhausted, the way you are when you visit a foreign country. You don’t speak the language and everything takes too much time and the people don’t act the way you expect them to and you are functionally a child. But the days go by fast, because novelty is a kind of drug.

It seems relevant again now. I also try to remember, when I’m feeling incompetent, that the opportunity to constantly learn is one of the things I love about the tech industry.