Engineering Managers have, arguably, the toughest role. They have to know how to write the nitty-gritty code and, concurrently, be able to communicate effectively about the said code, in a way that all parties involved understand, no matter their background. This “middleman” is the EM, a coveted role at the Georgia Tech chapter of Bits of Good (BOG). Read on to find out how Michael, who was as an engineering manager last semester and now serves as Engineering Co-Director at BOG, handles the EM-specific challenges that come his way.

Merge Conflicts, Merge Conflicts, and more Merge Conflicts!

Every developer makes a clone of the “main branch”, or the stable, production ready version of code. They’ll work on their changes and request to merge it back into the main branch. Before they can do that, the EM must go through and resolve any errors that come up. Suppose a developer writes code that conflicts with another developer’s code, or overwrites it. As an EM, Michael goes through and chooses which version of the code works better with what’s already in production. The difficult part is that even if there’s no merge conflicts detected by GitHub, code could still break other code, as it could reference or attempt to change already completed portions. Going through and resolving these conflicts takes up a sizable portion of his workload!

The dreaded Code Review.

Michael starts with a checklist of requirements side by side with the code. He checks for everything: variable names, clean comments, utilization of separation of concerns, design patterns, and general code quality. He really emphasizes a principle known as layering, by which database, service, and application layers are separate and each have their own responsibilities . Then, he tests the code. Essentially, this boils down to forcing bugs. By forcing code to break, he sees if it can handle the pressure. If it passes all of his tests, then Michael deems the code worthy to move to the next stage.

Technical Debt vs. Feature Development

How does the EM decide what features are technically feasible given the developer skill level, and which features are above the scope of what BOG can do? For example, Michael recalls choosing between two features: the “forget password” logic of a login screen and an option for text message notifications. Both were pretty high on technical overhead, requiring many sprints to perfect, but decided to fully prioritize the “forget password” logic to task his team, as it would be much worse for an unauthorized user to login than not having a text message reminder sent directly to your phone. Decisions like these make up part of an EM’s role and are one of Michael’s favorite parts of the position!

“What’s the most important skill that you learned?”

“Definitely strong leadership skills: Being responsive to my team, timely communication, and peer mentorship are some of things that make a great EM. It’s one thing to care about the vision of the project, and another to care about the personal growth of each and every member of the team. Making a team member feel valued, giving constructive criticism, and leaving insightful comments on their code are some of the practices that I employ day to day to ensure the successful execution of a project, and confidence that Michael has helped curate better engineers for the future!”

Communication is Key.

Michael applauds BOG developers on their communication and tenacity. It’s important to note, however, that it’s difficult to capture every single detail developers need at the beginning of the sprint. The Figma software tool is used to capture and communicate UI/UX design ideas and is pretty comprehensive and easy to use, but if developers have any questions, they will go to the EM, who can then address it, or redirect it to someone who is better able to answer.

“Why do you love BOG?”

“I resonate with BOG’s mission deeply and my love for organization, working with talented individuals, meeting new and interesting people from many different backgrounds, and just generally, having fun whilst making an impact! I have found that I’ve grown as an engineer, a leader, and most specially, as a person.”