Ask just about any programmer why they like to write code, and I’ll bet you a giant slice of chocolate cake that every single person will give at least one of these answers:
- “I love making things!”
- “I love learning how things work!”
- “I love solving problems!”
Of course, this isn’t an exhaustive list of the reasons why people like to write code, but the exclamations in this list have reliably and recurrently come up when I get into conversations with fellow developers. Often, these developers will tell me that not only do they love making things, love learning how things work, or love solving problems, they have actually always enjoyed these things, even in their childhood.
This unique collection of interests — building, learning, solving — is the longstanding core of my identity.
How it started
In elementary school, Mrs. Elliott was my daycare provider and watched over me and a gaggle of other kids after school and during summer breaks. Each summer, she would make holiday-themed crafts to sell at the local winter holiday boutique. I would sit at her craft table for entire afternoons, completely zoned in, and watch her make all kinds of things by hand. It was a great day when she’d pull out beads or papier-mâché for us kids so that we could assemble little projects to proudly reveal to our parents. These are the first memories I have of being obsessed with making, constructing, and creating.
In college, I developed an intense interest in real estate. Whenever I came across a vacant storefront or building, I would consider my surroundings and imagine what type of business would do well in that spot. Since I lived in the same area for several years while I was an undergrad, I had the opportunity to revisit these places to see if my hypotheses bore out. I felt immense satisfaction when they were correct and would refine my hypotheses when they weren’t. These were my first true experiences interacting with problem-solution sets in the real world.
Despite having what I now call “the markers of an engineer-in-the-making,” and despite having a grandfather who was a laptop battery engineer in Silicon Valley during the 1990s, no one close to me knew to interpret my early interests as those of an engineer. No one suggested to me that I could explore engineering while I was growing up.
How I landed on software engineering as a career path is a long and winding story for another day. I eventually finagled my way into a Python-based coding bootcamp, and it wasn’t until I was mid-way through it that I truly recognized myself as an engineer at heart and a software engineer by training.
The hardest part about becoming a software engineer was not the code. It was not knowing what I didn’t know; not knowing what was possible. The types of things I was worried about in the bootcamp evolved in the first few weeks and give a revealing look at my growth:
- Wait, I can tell the computer what to do without clicking on icons? (Using the CLI)
- Wait, dictionaries are cool, but how do I get to that nested value? (Bracket notation)
- Wait, how is my app showing up in my Chrome browser if I’m not even on the Internet? (Running a server on localhost)
- Wait, OK, my app runs locally, but how do I get it to show up at a domain? (Deploying)
Having a live instructor was essential to my learning at this point. Even the most well-intentioned online tutorials inevitably leave small things out, like which directory you should be in when running a CLI command. These small, omitted details can derail and frustrate new developers, sometimes to the point of giving up. Because of this, I began to think very intentionally about how to communicate technical concepts, especially to fellow beginners.
How it’s going
This drive to explain things clearly so that even a brand new programmer could follow along has been an undercurrent in most of the work I’ve done since completing the bootcamp. It’s led me to teaching gigs with notable organizations, working to get more people into tech from underrepresented groups. I’ve had the opportunity to produce video courses for a prominent professional learning services company. Once I landed my first code-all-day software engineering role, I participated in hiring processes, advocated to hire candidates from non-computer-science backgrounds, and mentored them through their first few projects.
The love and sensitivity I have for the transitional stages in a developer’s growth propel me to ensure folks are supported at these times. Developers’ needs change as they move through the stages of newbie, coder, programmer, engineer. This is why I’m emphatic about creating tutorials that don’t make assumptions about the fundamentals and are equally accessible both to people who are just learning how to use the CLI and to those who deploy code to production applications.
As a newly-minted Twilion, I’m excited to carry forward this personal mission and combine it with some of the truly incredible API technologies Twilio has developed that help humanity stay connected to each other. It’s my goal to create tutorials that feel so frictionless—regardless of the reader’s skill level—that those who complete them feel like they were born to be engineers.
I can’t wait to see what we build, together.
August is a Pythonista on Twilio's Developer Voices team. She loves Raspberry Pi, real pie, and walks in the woods.
Read on to learn how to build a SMS chatbot using OpenAI's DALL·E 2, Twilio Programmable Messaging and Python.
Learn how to view the SMS messages that come in on your Twilio number as convenient desktop notifications.
Learn how to use GitHub Actions to automate sending daily positive quotes via SMS.
Learn how to tell if a phone number is a Twilio number using Twilio's Lookup API line type intelligence package.
Learn how to create a personalized holiday card that you can send out by email.