Being the Only Pro Developer in a Team of Rookies Stops Progress
Photo by gerhard crous on Unsplash
In software development, it sometimes feels like we are in a pro ice hockey match. When you’re the MVP and playing with teammates who are not quite up to your level, things can get problematic.
If things get dire it can mean the game of tech development can get messy. How messy? Let’s see.
Sports, sports sports
Although The Secret Developer hates companies using sports analogies in tech development it appears they aren’t averse to using them themselves. In this example, the analogy works because we are all (pretty much) working in Agile teams with colleagues with different skills and abilities.
Standards, Standards Standards
In the fiercely competitive world of software development, being stuck in a team of less experienced developers can feel a lot like being a pro ice hockey player forced to skate with amateurs. The game changes; you’re not just playing to win anymore, you’re struggling to maintain basic standards and keep the puck in play.
In software development, instead of producing that cool refactoring PR, you’re slowed by your colleagues. It’s hard to get things done and work with colleagues when they are just slow, obstinate, or just inefficient at their job.
I’ve been really frustrated recently. I’m unable to change the codebase because (gasp) refactorings are often blocked with pointless comments.
“Can you remove that keyword”
Unfortunately, it’s required
“Just thinking, can you use our shared code here”
No, because this code performs differently
“QQ. Why isn’t this code at global scope”
Because it’s only used in one place. It’s a specific sorting algorithm that is highly unlikely to be used anywhere else. It needs to be at anything but local scope.
The list, sadly, goes on.
The Game
Photo by gerhard crous @crousg
The Slow Pass
Picture this: you’re on the ice, ready to make a fast break, but every time you pass the puck, it’s fumbled. In the world of software development, this is akin to the painstakingly slow process of getting Pull Requests (PRs) reviewed and approved by less experienced teammates. They don’t understand the code, leading to a bottleneck that could damage the project’s timeline and quality.
Defensive Plays
It’s a harsh reality that having a team lacking in experience isn’t just frustrating; it costs companies in more ways than one. First, there’s a direct impact on productivity and efficiency. Projects take longer, deadlines are missed, and the quality of work can suffer. But there’s also the less visible cost: the morale and development of your seasoned developers. Like a star player constantly covering for the team, they become overworked, disillusioned, and, ultimately, less effective.
Offside Strategies
Innovation thrives in environments where diverse ideas and experiences challenge and complement each other. When a team is uniformly inexperienced, not only is the quality of immediate work compromised, but the long-term growth of the team and its members is stunted. Opportunities for mentorship and knowledge exchange are missed, leading to a cycle of underperformance and a lack of innovation.
Solutions
The Team Rebuild
Just as in sports games, the answer to development problems hinges on building a balanced team. This means taking on some developers who are practiced in their art.
More experienced developers can mentor those less experienced and bring them up to speed quickly. They can also help to enforce standards in a project which will then be easier to maintain.
Wins all around, providing you have a mix of experience and youth.
Training
Experienced devs are expensive. Investing in training and development for less experienced members while also ensuring there are enough seasoned professionals to lead by example, mentor, and maintain the standard of excellence.
Investing in the less experienced members of staff means they might learn new coding skills that the experienced staff don’t know. That means that they will all be able to teach each other something.
Which would be great, wouldn’t it?
If only training was more than a link to a website, like the extent of training in my current role.
Diversity
Having a diverse engineering team provides better outcomes. Moving to more diverse teams produces better software simply and efficiently.
This isn’t limited to experience of course, but having different voices in the code room really is essential to producing better software. Worth looking at, surely?
Photo by Alex Korolkoff on Unsplash
Conclusion
Being surrounded by a team of less experienced developers is more than just an inconvenience, it’s incredibly annoying.
I’ve caught myself thinking that those I work with are idiots. That may or may not be true, but this is certainly a threat to productivity, innovation, and job satisfaction. Without a balanced team (and an investment in the team) creating software is a tricky challenge indeed.
In software development, every participant’s skills and experiences count to the whole.