For a year and a half I’m working in a growing and ever-changing team of senior developers, where - by years anyway - I’m the least experienced developer. How to judge seniority, and how important years of experience are to reach seniority, is a topic for another post.
Where seniors are superior
From the true seniors (hello Antonio, Francisco, Timo) I learned a ton about practices like pairing, code code review, how to harness the power of git, how to apply testing, and how to keep standup hygiene. Those were areas where I lacked due to the way I learned coding.
They also showed me how true experts in the profession can be three or four times more productive than the average junior to midlevel developer. The areas where those valued team members super-seeded most were:
- A drive to truly understand the code. Sometimes they would invest a few hours for research, but then were able to come up with designs that easily saved the amount. It’s part of a healthy “let’s keep calm and think it through”-attitude that also allows the true seniors to debug issues much faster by always remaining logical and asking the right questions.
- Respect for other developer’s time: For a two week story they might spend a day rebasing the git history to tell an easy to follow story to the team member who would review the code. This increased clarity of the PRs so much that it overall saved time.
- A good nose for technical debt that actually impacts delivery speed. Sometimes they would stop for three days to start an unplanned refactoring in the middle of implementing a story. By the time they’d open a PR it became visible that they saved most of that time within the story due to the more solid base, but also made progress easier for everyone who’d follow them.
- Optimization of the personal workflow. You will not find them the mouse needlessly. They knows their tools of work and shaped them to fit their exact needs, e.g. by scripting any repeated action and mapping them to easy shortcuts. For a few months I had two freelancers on the team who wrote their own keyboard drivers to map more efficient shortcuts for coding.
Pitfalls in a group of seniors
I’ve also seen a few less productive traits seniors show sometimes:
- Once you get them going in a discussion, they embrace it. There’s a joy in sharpening the own judgement by competing in a discussions with other intelligent, knowledgable colleagues, that’s hard to pull out of.
- They spend so much time thinking about and applying practices that they are convinced to have found their optimum. They are passionate about and attached to their practice, and preach it to others.
- Sometimes they think about their craft slightly too much as art. This can let trivia like code formatting and linting rules become ground for hour long combative arguments.
- A few seniors are so proud about their work that they become unable to not deliver the best quality they can anymore. This can be a hindrance when implementing MVPs, where perfection doesn’t add much. This can be especially damaging when it comes to taking architectural decisions: Some seniors will try to design the perfect system on day one, even if the business is not stable. This might also result in premature optimization like adding layers of abstractions before it’s proven that they are required, and breaking systems into micro services too early on.
- Some seniors are not nimble enough to do repetitive tasks that are not novel, and become visibly bored if forced to execute them. Some might chose novel / suboptimal technologies out of curiosity and turn the result into their personal pet project, creating knowledge silos and technical debt.
To be clear: those “pitfalls” of seniors are kicking in for 10% of situations at most, and usually are by far out-weighted by the productivity benefits.
Recommendations
Overall, it’s good to keep in mind that a group of senior devs will exhibit different types of behaviors and group dynamics compared to more junior developers.
From my experience, there’s a couple of things which help to “get the most” out of senior team members:
- Encourage them to pair with more junior team members. If there’s a good personal connection between the two, pairing will increase satisfaction and mastery of both.
- Be super transparent about product requirements. Senior developers will not over-engineer, if they have clarity on which aspects will likely be changed in the future, and whether the goal is to test an hypothesis quickly.
- Tough, but realistic deadlines can be motivating as well, as they require to use the skills to be most efficient.
As a business it’s important to have the right mix of experience level in the team for the current situation:
- In a more mature product without too many tough technical challenges: Don’t employ too many seniors, they will grow bored and won’t add more value to the business than less experienced devs.
- When you need to create something from scratch fast: This is where senior’s shine. Being able to move without having to explain patterns and best practices to less senior devs too much is beneficial.