Iora Health is transforming health care, starting with primary care. At Iora, we invest in relationships and provide patients with a team that respects and listens to them. So it’s no surprise that this philosophy translates to the way Iora nurtures and develops its own employees. One of the best things about working at Iora is the organization’s support for professional development and investment in its people. Transitioning from Product Management to Engineering, I have benefitted firsthand from this culture. In this post, I share some details and insights from that experience, as an exemplar of how to onboard and support junior engineers from non-traditional backgrounds in ways that benefit the entire team.
Moving forward while staying in place
Just a few months ago, I was a Product Manager with years of experience with online courses and hobbyist work but little formal training in software development. I had developed a passion for coding through resources like FreeCodeCamp and MIT’s open online Computer Science curriculum, but came to realize that it was something I wanted to commit to full-time, not just as a Saturday afternoon hobby. When I decided to make the jump to engineering, I was uncertain of two things: how could I possibly go from self-taught hobbyist to working programmer, and how could I balance my evolving career aspirations with my love for Iora and desire to stay put?
Iora Health is a remarkable place — the kind of organization where our cultural values are not just a footnote on the company wiki, but the cornerstone of every interaction. Iora’s primary care model is truly transformational, and our innovative collaborative care technology platform, Chirp, plays a major role in effecting that transformation. Working for Iora provides that rare glimmer of hope in the world of healthcare technology — the promise that we are actually making a difference in the lives of patients with the software we ship.
Luckily for me, the leadership of Chirp was both fully supportive of my hopes to stay on at Iora in a new capacity, and confident that there was a path forward to develop my after-work hobby into a more serious software skill set. Mere weeks after I first raised the idea, a plan to bring me into the wizarding world of Engineering was in motion.
“Everything is going to change and nothing is going to change,” commented Will Mernagh, VP of Engineering, leading up to the cutover date. But when I came into the office on April 2 and opened a terminal instead of Gmail, I was pretty sure everything had changed.
The first week was focused on easing into the environment: setting up my dev machine and learning our git processes, our application architecture, the ins and outs of HTTP, and so on. From Day One I was paired up full-time with a mentor — one of our Staff Engineers, Gerardo Pis-Lopez — to spend our days alternately discussing high-level context and delving into code.
By Week Two, we had begun to ramp up the actual coding. It was critical to have someone with deep experience there to provide context, guide the conversation in and out of subject areas and code paths, and put blinders on or elaborate where necessary. I had spent months prior reviewing the Chirp pull requests on my own and wondering how it could ever all make sense, but it was an entirely different experience to sit side-by-side with someone who could explain the area of the codebase, highlight what mattered and what didn’t, and answer questions about tools and code design.
Despite the incredible teaching and support I received, the first few weeks were tough. It felt like learning two foreign languages at once (which isn’t far from the truth), and by the end of each day my brain was completely fried. But as the weeks progressed, slowly but surely, things started to click. We shifted from a model where my mentor laid out the process and code to one where we talked through the approach and then ping-ponged between me writing code and pulling up for questions where necessary. Today (towards the end of Month Four) I am working independently on small and medium features and pairing as needed on the larger features or new areas of the app, steadily expanding my role as a team contributor.
Bringing on a Junior Engineer without formal training was an excellent learning opportunity for the whole team. Over the course of my first four months there have been things that worked and things that didn’t, and a few things that we are formally codifying into our training process as a result of the experience. A few of those insights include:
People over process
With my background as a process-focused PM, I came to the planning table with a dense Google Doc full of proposed milestones and a list of transition risks, which was met with… a collective shrug. Engineering leadership knew that the key to success was going to be the people, not the plan. One-on-one mentorship with a skilled teacher was the crucial element, but I also benefited from pair programming with a variety of senior engineers on the team. This is a standard for training up junior engineers at Iora that expands the diversity of opinions and styles to which we are exposed. While this approach can seem resource-intensive, we trust that the investment yields dividends by instilling strong habits (of both mind and code design!) early on and enabling valuable independent contribution as quickly as possible.
Responding to Change Over Following a Plan
While the high-level roadmap remains extremely useful to me as I progress, staying flexible and focusing on becoming a productive contributor to the Chirp product as opposed to a master Rubyist early on allowed me to quickly add value across a wide range of features.
Finding Mental Models That Work
Learning programming can be daunting, especially without formal training, but I found that certain metaphors and models helped me grasp some of the concepts at play and boost my confidence that this was a skill at which I could eventually excel. For example, some of my mentor’s most effective (and personally resonant) explanations were those packaged in literary metaphors, such as his description of the craft of coding as “half detective novel, half science fiction,” or one memorable explainer of the call stack likening it to Scheherazade’s role in One Thousand and One Nights — perfect analogies for someone who can’t write a technical blog post without a Dickens reference.
Slack in the System Accelerates Growth
It’s tempting to keep engineers working at 100% capacity in the hopes of maximizing productivity, but here at Iora we’re big fans of the Lean principle of slack in the system. We build in our own form of slack called Engineer’s Time for engineers to focus on whatever they choose for 30% of their total capacity. This allows us to keep technical debt down, make open source contributions, deliver experimental features, and most important for junior engineers, reflect and study outside of the standard feature work.
Keep Calm and Code On
Despite the incredible support and encouragement I received, the first few weeks were inevitably overwhelming. Shifting my perspective away from thinking catastrophically about all the technical knowledge I don’t (and may never) have, and instead focusing my attention on the progress I was making, allowed me to defuse the stress and become more productive in the day-to-day. Pulling up for weekly one-on-ones with my mentor and new manager was also key to obtaining objective feedback and ensuring that things were right on track.
I also continue to try to emphasize the qualities I do bring to the table, like being a female engineer with years of product experience and a degree in Psychology (you’d be surprised how often it comes in handy!). The world of technology is far too vast for any of us to master it all, so emphasizing your strengths and learning to be comfortable with where you are goes a long way.
It Takes a Village (or at least some seriously awesome coworkers)
After years of tinkering with code in isolation, the progress I was able to make with so much support was staggering. At one point or another I have received help and guidance from every single member of our 13-person engineering team, whether it be troubleshooting an environment issue, Socratic-style pairing sessions, or approving pull requests before I even knew I was finished with them. The Product and Design teams with whom we work side by side have been equally supportive, staying flexible with the user stories I first pulled and offering encouragement throughout the process. It makes all the difference not just to have people let you do something, but for them to be excited about it and invested in having you thrive.
Take, for example, the responses I received on my first pull request.
Nothing engenders confidence and self-esteem in a new programmer like having the support and enthusiasm of a team like that.
Becoming a software engineer is a lengthy process, one that might even last the rest of my career. But with focused mentorship, continuous feedback, and a supportive team environment, it has gone from being a pipe dream to my daily reality. Iora’s dedication to its employees and commitment to their personal growth makes it the best place in the world (in my admittedly biased opinion) to be a junior developer — and to continue to grow into whatever comes after that.