June 5, 2016
Nine months later, I'm my company's technical lead. I'm also the most junior person there. I'm also the only developer, period. A team of one.
When I share this with people, I sometimes get congratulations for accomplishing so much, achieving such independence, in so little time. (This usually comes from non-technical individuals.) More often, I get shocked looks. “How does that…work?” Overwhelmingly, however, the most common response has been looks of pity. “I'm so sorry.” “Are you okay?”
Spoiler Alert: It's Not Easy
For the majority of the time with my company, we've had a two-person development team: myself and one other coworker. Over time, we fostered a shared workflow and communication style that really worked for us–as a team typically does. Our work preferences and strengths balanced each other out in a way that helped me learn and grow at a very quick pace. Then, all of a sudden, the other half of my team left. In addition to my own work, I had to take on his as well. I had to pick up everything.
No, sometimes I'm not okay. Some days the pressure of fixing all the bugs, performing all the maintenance, overseeing every deploy, researching every new feature implementation, writing every single line of code, being the authoritative voice on all technical matters, well, it does get to me. It'd be pretty strange if it didn't. Knowing that I'm accomplishing half of what my team used to a month ago? Well, that really wears on a person.
Things are falling through the cracks and I know it, which is the most frustrating thing ever. I'm trying to make myself more accountable (to…myself, which sure is weird). Working alone means a lot of the checks and balances of multi-person development teams aren't in place. Thus, I'm not following typical development processes; they're overkill for a team of one. I don't need to have estimation meetings with myself and my PM; there's really no point. A formal stand-up report would consist of me saying “I did a little of everything yesterday. I'll be doing more of everything today. I don't have blockers to report because I resolve my own blockers.”
Consequently, the past month has been an extreme exercise in self-control, responsibility, and organization. I'm completely living my work life by lists: maintenance tasks, functions of a new feature, research topics–all kept track of in lists. The lists help, but ultimately I haven't found a replacement for having another person there to catch me when I fall, to point out whatever I inevitably forget.
What I miss most is having another person to bounce ideas off of. Does this structure make sense? Is this good or bad program design? Do I really need to be taking these extra precautions, or are they overkill? Is there an easier way to accomplish what I'm trying to do? Is there a way to do it that will accrue fewer infrastructure costs? Can you review this code before I deploy to production? Will I go crazy by asking myself all these same questions?
But Boy, Is It Rewarding
Yes, this is a lot to handle. But having a lot of responsibility also means there's a lot to be proud of.
In the span of just two weeks, I discovered and smashed bugs across multiple different repositories. I worked with Typescript, Python, and PHP in a work context for the first time. I made myself intimately familiar with two different codebases that I mostly did not write. I put both of those in production. I made the transition of our API to version 1.0. I put that in production, too. I am now writing and maintaining four customer-facing products on my own.
While I've learned countless technical lessons, the majority of my learning is happening on a level far removed from code. I'm gaining so many “soft skills” that are intangible, like knowing when you've spent too much time on one problem and need to move on. Or knowing which technologies are most appropriate for specific scenarios. Or which search terms will yield you the best results while doing research. Obviously, I'm still far from saying I've mastered these skills; right now, they're just instinctive hunches. But the more I have to make these important decisions on a daily basis, the better defined they become. I can't wait to be able to put these instincts into words. I'm eager and excited and empowered.
I slip and fall sometimes, yes, but so do multi-person teams. I've reached a level of self-sufficiency I would have previously thought impossible; being able to show myself what I'm really capable of has done wonders for my confidence. Sometimes I feel like my own personal superhero.
No, Really, I'm Good
Every day I make a choice to keep coming to work, to keep plugging away, to keep trying harder. I make a daily choice to continue learning all I can and to keep helping my company in the best way I can. I'd be lying if I said this choice was always easy; it isn't in the least. It would probably be easier to find another job where I'm not entirely responsible for the health of the company's technical ecosystem, or all the architectural decisions, or the code quality. It'd probably be easier to have a position where I can get paid more to do less work. But I've never been about doing things the easy way.*
In the one year of my tech career, I've gone from Hello World to all of this. I have to solve problems that “junior” developers rarely ever have to face. I'm faced with an immense amount of responsibility in maintaining this company's technology and building something meaningful. A year ago, I didn't really know what I'd do with my life. Now, I can't imagine doing anything else.
If you take away one thing from reading this post, please let it be an appreciation for the people you work with. Please place an emphasis on communication in your company and your teams. It's what makes you distinctly lightyears better than caffeine-crazed individuals working in the dark.
So, when I tell you I'm a one-woman development team and you feel my pain and wonder if I'm okay, don't worry about it. No, I don't want your pity. But I will accept gifts of chocolate and coffee ♥*Unless it's the most practical choice for a project based on cost, effort, design, etc. But you know what I mean.