In March 2017, I started working at Flatiron Health as a medical informaticist. As time went on, I came to understand and become fascinated with the challenges that our software engineers face on a daily basis related to designing, building and troubleshooting systems for our oncology data. It didn't take long for me to realize that I wanted to make a transition into software engineering. Fortunately, our internal mobility program is designed to handle these cases, and so, in July 2018, I started on this journey. I knew upfront that I had a long road ahead of me, one teeming with lessons to be learned. In an effort to help others who may be thinking of a similar move into software engineering, or those getting started in the field, I took a look back at the past year and outlined some of the lessons that stood out the most to me.
#1 Imposter syndrome is normal, and you can beat it
Imposter syndrome, or the feeling of being a fraud despite one's skills and accomplishments, is no stranger to the tech industry. A 2018 survey from the social network Blind found that 58 percent of tech employees report experiencing imposter syndrome. And if you're like me, transitioning into software engineering with no formal computer science degree, you may find yourself suddenly in that 58 percent.
Here are some things you can do to help:
-
Get yourself an onboarding buddy you can trust. Your buddy should be a peer on your team who is ideally more senior and can provide mentorship. Confide in this person. Ask them all of your seemingly "dumb" questions. They will be your single most important resource, and a significant factor in gaining confidence and getting your feet wet with your team's projects.
-
Become completely unafraid to ask questions. This is paramount! No one knows your knowledge gaps better than you, and any assumptions of your knowledge by your teammates should be squashed as soon as possible so that you can be better supported.
-
Keep track of small wins. Spot a small error doing someone else's code review? Learn a new concept in Python that helped complete a ticket? Write it down and refer to these wins at the end of the week. Your confidence will grow as you see the progress you're making.
#2 Get ready to put in extra time outside the office
This is perhaps the most predictable tip, but still worth discussing. You are likely coming into a position where you lack some foundational knowledge that others on your team may already have. Does your team use Python even though you only know Java? Have you worked in Windows all your life and now need to support applications running on Linux?
If so, while you should designate some time in the office to build this knowledge, you may need more time than can be afforded during working hours to do so. If you're a morning person with extra time or have a long public transit commute, take that time to read relevant blog posts or articles. If you're an evening person, skip a night here or there of rewatching Game of Thrones and instead progress through your online course. Your company or alma mater may even provide access to online learning resources or trainings, so be sure to ask.
#3 Leverage existing strengths but be aware of old habits
Having trained in human factors engineering in my earlier days, I'm biased towards user-centered approaches to design. This approach actually came in handy recently. I was code reviewing a command-line interface for a metadata application, but we took a step back and discussed how we were handling metadata versions supplied by the user, and if they should be optional and/or auto-incrementing. What does the user expect to happen when this argument is left out, or included but already exists? Outside perspectives and diverse thinking make teams stronger, so utilize your experience, however unrelated you may think it is, to your team's advantage.
On the flip side, be aware of old habits. If in the past you never gave too much thought to proper error handling, then now is the time to start educating yourself to meet the expectations of your new role. Or if you're used to fully spec'ing out a design and planning it to a T before getting feedback, and now your new team is of the fail fast nature, be sure to start getting feedback on your designs as soon as possible to iterate quickly.
#4 Observe and learn best practices for how to approach problems
In the past, I assumed that seasoned engineers just knew it all. Major issues come up and they've seen it before, so they simply know what to do and how to do it. While the latter may be true in some circumstances, more often than not, these engineers are just really, really good at figuring out how to diagnose and solve problems. They may not know the solution immediately, but they'll be damned if they don't know how to figure it out eventually.
Case in point: our team is on call for systems and infrastructure that other teams at Flatiron depend on, such as our implementation of Apache Airflow that we lovingly call "Wario." Occasionally, a new day might bring the unfortunate news that some of our data pipelines aren't behaving like they should, and we initially won't know why. Well, I found out pretty quickly after joining the team that there are tools and strategies for diagnosing these types of issues! We use DataDog for monitoring our Airflow hosts, and we also rely on command line utilities to debug connection issues to client source databases, both of which I had never used before. Sitting with my teammates and watching them progress step-by-step using these tools to diagnose and fix these issues allowed me to get up to speed quickly.
You'll be best positioned to succeed by observing the best practices of your teammates, and learning the tools and strategies they employ on a daily basis to solve problems.
#5 Be vocal with your manager on what works and doesn't work
Be open and honest with your manager on your experience and evolving interests. Good companies have leaders who want their employees to succeed and grow. And if you've already chosen to work for a good company, then you should be upfront about your journey and give actionable feedback along the way. This will not only help you but others who may follow in your footsteps.
In the beginning of my transition, my manager and I met once a week with frequent, smaller touch points along the way, and we often discussed where I needed support but also what was going well. I realized a few things very early on:
-
Having an onboarding buddy was the best approach to getting acclimated to the team's work
-
Transitioning to a team that had no work overlap with my previous team was ideal since I did not have the crutch of familiar projects and essentially had a fresh start
-
Certain concepts were foreign to me that were fundamental to our team's work, such as distributed computing, orchestration and Linux host maintenance
Discussing these lessons with my manager helped us craft a plan to fill the gaps (e.g., I ended up buying books and focusing on tickets that would fill my knowledge gaps). Our Engineering Leadership Team also found our process helpful with determining what may work for others who decide to make a similar transition in the future.
