Getting the Jokes: My First Year as a Software Engineer
Shortly after starting my first job as a mechanical engineer, I became exasperated with the repetition and slow pace of energy modeling. I turned to my mentor and told him I didn’t think I could make this my everyday experience. “Well,” he sighed, “you could always make your own program and use that.” He turned back to his monitor. I did too, but it stuck with me — the idea that I could be on the other side of things, making great software instead of struggling against the programs we used and continued to use, simply because we had always used them.
Fast forward 7.5 years or so — March 2019 — my first day as a software engineer. While I’m not writing energy modeling software, it’s been so much fun to marry my consulting engineering experience with programming here at Outer Labs, a company that builds tech for architectural design at scale. And now that over a year has passed, I’ve done a bit of reflecting on what the transition has been like. I’ve:
- Essentially learned a whole new language (and not just the programming languages themselves).
- Picked up a new quiver of tools.
- Returned to being in the question-asker seat.
It’s been a great, humbling year, and I hope my learning can provide a view into what it’s like to change careers — especially into software engineering.
Learning the Lingo
When I started at Outer Labs, we were beginning a new project where early software system design decisions still needed to happen. It was perfectly timed for me to hop in — and not understand much. I got the individual words — for the most part — but I found myself scrambling to even keep track of what I didn’t know. My prior software experience — mostly through online courses and hacking my way through automating some of the more mundane parts of energy code compliance modeling — had not prepared me for all of the options available to us for tools. And who knew there were so many ways to test code? I sure didn’t!
In order to keep track of all of the things to look up later, I started a Google Doc (titled “Ongoing Programming Notes” which still feels like a good title to this day, as it is truly ongoing). This list serves both as a way to keep track of things to look up later, but also as a way to reflect on how far I’ve come. Luckily, I work on a team of super smart folks who’ve been gracious enough to spend a lot of time going over a bunch of the items on my list, which started with — really — what the difference is between “back end” and “front end.” Even though it can feel like I still have so much to learn, when I reflect back on basics like this that I didn’t know at first, it makes me feel like I’ve come a long way.
Looking back, it shouldn’t be surprising to me that I had to start with the basic lingo of software engineering in order to write software, given that I had an almost identical experience starting out as a consulting engineer. While I had spent my entire education in mechanical engineering, none of it focused on buildings, so I had a lot to learn about the built environment when I started working. My notes from my first day of work in 2011 show just how much I had to learn, how much jargon I had to pick up, and how prevalent acronyms were.
I had to start from the basics of the lingo, and work my way up to being a self-sufficient mechanical engineer. Software engineering is no different. There’s an entire language to learn beyond the programming languages themselves, which I feel I’ve only started to crack. Keeping track of what I’ve learned is a powerful way to remind myself of my progress.
Getting the Basic Tools
I took my first Spanish class in my freshman year of high school. Every day, our teacher started class with a new phrase written on the chalkboard. After a few months, we’d made it through our initial round of verb conjugation, hitting the regular verbs and a few irregular ones, along with a spate of seemingly random vocabulary lessons. We knew some animals. We knew some foods. One day, we entered the classroom to see our first joke written on the chalkboard:
Un pez le dice a otro: “Tu padre, ¿Qué hace?” “Nada.”*
*We all know that explaining a joke really draws out the humor, so let’s start with a quick primer on what “nada” means. It can mean both “nothing,” and is also the third person present tense conjugation of the verb “to swim.” So, this joke translates to: One fish says to another, “What’s your dad do?” “Nothing/He swims.” See? It’s hilarious!
Sure, it was the dad joke of Spanish jokes, but here’s the thing: for the first time, I understood a joke in another language. It felt like a sign that finally — after months of hard thinking — I was making tangible progress toward understanding a new language.
Similar to Spanish verb conjugation, learning Git was a bit of a mind bender for me. For those of you unfamiliar with the term, Git is software which allows for version control of your code, and it is especially helpful if you’re writing code with others. It’s simple, but extremely powerful, and it felt (and still feels at times) like a spiteful overlord, ready to send me into Git purgatory at the mis-stroke of a command. I took some excellent courses on Git through Udacity which helped demystify the process a bit, but still — I found myself wary to do anything to upset the Git gods. I managed to stay out of too much trouble until I had to do my first rebase with a merge conflict (which meant I needed to make some code changes manually in order to merge my code with the larger codebase). I googled around to see if I could find some way around the conflict, and stumbled upon this meme:
And I got it! It was funny! Just like my Spanish fish joke epiphany, understanding this meme made me feel like I was becoming a real software engineer. Thanks, mystery internet person, for making this meme and making me feel included! And for the record, I’m sure I ended up asking for help from one of my very capable coworkers.
This may be surprising, but learning Git has helped me do much more than just understand this meme. Together with learning enough bash and command line trickery to be dangerous, these tools have been vital in my software engineering journey. I had heard of Git before starting at Outer Labs, and had seen a Unix shell here and there, but I didn’t need them daily. I now use these two pieces of technology every day, and would recommend that anyone interested in software development start with these tools. They’re not as sexy as diving straight into the language du jour, but they’re what make more sophisticated programming easier in the long run.
Asking All of the Questions
One of the awesome parts about Outer Labs is that we’re a completely distributed team. There’s no home office, and we have teammates all over the world. While this setup is fantastic for flexibility and work-life balance (if you respect your own working hours, which is, admittedly, more difficult when working remotely — a topic for another post), this setup isn’t necessarily conducive to starting a new career. But, it’s doable, as long as there is a culture of “no question is a dumb question.”
This culture isn’t necessarily unique to remote onboarding of new folks. Asking questions is an important part of any learning process. However, working remotely does make it easier to hide. It can be hard to admit when I have a question that feels too basic. But, with practice and a supportive environment, I’ve found that it gets easier and easier to just ask. Similar to my experience with learning the lingo over again in a new career, it shouldn’t have surprised me that — just like as a new consulting engineer — learning to be okay with having lots of questions is an important part of starting out as a software engineer. The responsibility to address questions rests partly on the workplace environment, but it’s also the responsibility of the new person! No one knows if you’re having trouble with something, especially in a remote environment, unless you speak up.
Something that helped me accept the volume of my questions, especially in my first few months, was to tell myself it was my job to become the best software engineer I could become, and part of that meant asking questions. Of course I tried to respect my coworkers’ time, and grouped questions together whenever possible, but I also recognize how lucky I am to have such experienced and smart coworkers. Why not squeeze as much knowledge from them as possible? I look forward to hopefully being able to help a future new starter in a similar way down the road.
Trying Something New
After years spent on one career path, it was a leap of faith to try my hand at something completely different. It hasn’t been easy, but it’s been so much fun, and I’m so glad I joined Outer Labs to take this whole software engineering thing for a spin and make the improvements I want to see for AEC (the architecture, engineering, and construction industry). Whether you’re a programming pro, a programming-curious person mid-career, or just someone considering a career change, I hope my process of trying something new — and how starting from true noob status doesn’t mean you’ll be a noob forever — can help you reflect on how far you’ve come and how far you’ll go, too!
Content originally published by outer labs
May 21, 2020
Don't miss out on future articles from the Outer Labs team. Follow us on Twitter or LinkedIn to stay up to speed on our latest thoughts on how to scale your real estate design, construction, and operations.
Read More Insights From Outer Labs
Rethinking Workplace Reentry
Reentry post-COVID challenges our longstanding assumptions about design for workplaces.
Efficient Spatial Relationships with Z-Order Curves
Use z-order curves to break large spaces down into addressable units.