Taking the lead; going from zero to hero in the course of a single project

Tackling new projects can be a daunting task. More than often by the time that you start one, most of the planning may already be done. Whether it be projects in which you are the on a team or personal projects, you often have the freedom to control direction of how you grow from the very beginning more than you realize.

Just because you may start out as a junior on a project, or you are working with tools that you have never used before, doesn't always mean you will end at the same spot. Whether your co-workers come and go or priorities change on who works which projects, or you think you just don't have what it takes to learn what's needed for what lies ahead, you may not always be the learner forever.

Preface

To help paint a picture of what this scenario may look like, I'll explain the most recent scenario I've encountered at the workplace. This story has quite a few twist and turns. From switching to a new development team and adopting an entirely new toolset in addition to going from the learner to the maintainer, I learned to be prepared for the unexpected, and to make the most of it when it happens.

I went into this project knowing little to nothing about the tech stack I would be using or the processes I needed to learn for the new team I would be working with. This would be quite a stark contrast from how things ended up by the end of the project.

Development

Per the onboarding requirements of the new team I've been working with, the beginning of the development process involved several weeks of learning. Changes to my normal environment included a new backend, higher programming standards, and introduction into an in-depth code review process that I had no prior experience to. While this part of the process did involve some programming in a few places, it was honestly a good week or two before I began any work beyond reading tutorials, showing up for pair programming sessions, and tagging along to understand the process of code review.

After basic knowledge of the new tech stack was established, I began to branch out and began tackling entire segments of the project on my own, and went from working with other developers on the same problem to working separately but keeping collaboration as we branched off into different areas. While I began to gain more independence in the work I was doing, it was still common for me to reach out to others, whether it would be for feedback needed to understand business requirements better, or to save me from myself when I had questionable ideas when it came to certain development approaches...

After the project had been going for some time, I was added to the rotation the new team uses for code review. Essentially it's randomized process daily that picks two people, one that fills the hat with actual code review, another more towards the quality assurance(QA) aspect when it comes to testing.

These roles would then subsequently review all merge requests posted for the given day. They would use both their own knowledge within the tech stack in addition to the standards laid out by the team to ensure that all code submitted followed these guidelines. While having new code tested was not a new concept to me, having direct developer reviewing of my code was a far more effective process in my opinion to better weed out potential bugs and tech debt resulting from poor design choices.

Besides having the opportunity to experience being a reviewer, I found it helpful in code that I would subsequently submit myself for future review. Since I know from experience what code review will be looking for, it helped me better understood the importance of enforcing code standards and make better test scenarios that will make it less painful when it comes to the QA side of the review.

As the project began moving closer and closer to release, we eventually reached the point in which deployments would begin reach the desk of the business side of application testing. While I've had experience with this area before as previously stated, I did not know what to expect this time around with the integration of more code review, better programming standards, and more collaborative teamwork.

Spoiler... it was better...

While there were occasional bugs that slipped through, I find the process much more straight forward for several reasons:

1. Far easier to find a specific issue in a well-maintained codebase
2. Additional round of review to fix the issue to ensure it is for-sure fixed before I would resubmit for business testing
3. Could immediately dive into the problem either myself or pair-program with a co-worker to additionally reduce the time to find bugs

While the business side may not necessarily understand the significance of these points, as a developer, it helped me save far more time in addition to making releases in general be far less stressful than in the past.

This flow made it far easier come to the official release day. Compared to past project, I can say without a doubt this one went far smoother and in all honesty, was one of my most relaxed days in the 6+ months this project was in development!

Outcomes

Unfortunately, in the process of moving to the position of 'expert' on this project, the one who trained me left our company. While it was a bummer to get used to the next phase of this project and somewhat a disbanding of those I spent months working with closely, it was empowering to know that even with the original maintainer gone, I didn't feel terrified stepping up to the position. In reality, I was excited beyond belief. Months of work and training to the point where my name become a little more synonymous to the project than I wanted to in retrospect, but still reassuring to know that people consider me a reliable asset. Little do they know just a few months prior, It would have been crazy to me to consider such a request.

Going into this project, I knew very little both about the tech stack I would be working in and the processes of the team I moved to. If you had told me at this point last year that I would learn a new tech stack, learn how to fit the role of a code reviewer and QA based on standards you have no knowledge on, and I would be the maintainer of the project by this time next year, I would say that would be a very ambitious goal. The fact that all of this happened in half the time even yet proves with solid teamwork and a supportive team, you can get a lot done.