Is 'be the worst' ever limiting?
One of my favourite patterns from Ade Oshineye and Dave Hoover’s 'Apprenticeship Patterns' is 'Be the worst' which is described as follows:
Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow. Be the Worst was the seminal pattern of this pattern language. It was lifted from some advice that Pat Metheny offered to young musicians: “Be the worst guy in every band you’re in.” Pat’s advice struck a chord with Dave, and was one of the reasons he started writing this book.
Since I started working at ThoughtWorks it hasn’t been that difficult to follow this pattern and I’ve been the least experienced developer on the majority of teams that I’ve worked on.
I always thought this was a pretty good thing as since I’m always surrounded by people who know much more than I do about various aspects of software development the opportunity to learn is very high.
Recently conversations with several different colleagues leave me questioning whether at some stage we need to move away from this pattern, perhaps temporarily to improve skills in other areas.
The authors do cover this a bit in the book:
Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think. It’s only when you work on your own that you will see how much your team increases your productivity and realize how much you have learned.
Making technical decisions
One area in which I’ve noticed that this is true is when it comes to making technical decisions on a project. Quite often I find that even though I have an idea of what the solution to a problem should be I end up deferring the decision to someone more senior in the team.
I don’t think there’s a problem with discussing solutions with others in the team but it certainly seems that it would be a better learning experience to be in a situation where I was forced to make the call and then see how things went as a result of that decision.
It’s certainly possible to engineer a situation where you have to make that type of decision by working on open source projects but it’s still useful to get experience on real projects as well.
I guess the easiest way is to be on a team where you aren’t the worst so that by default you’ll end up in a position where you have to make those calls.
An alternative is for more senior people to encourage others to make decisions with the knowledge that at least they will be there to help recover the situation if it goes wrong. I’ve seen some of my colleagues use this approach and it seems to work reasonably well.
It’s still not a perfect approach though because often someone more experienced may know intuitively that an approach isn’t going to work but will struggle to explain why they know that.
Solving problems
The other situation where 'be the worst' is perhaps limiting is when it comes to solving problems on a team.
At the first sign of being 'stuck' there is a real temptation to ask someone for help even though you might be able to solve the problem alone given enough time.
A colleague in my first job suggested that whenever I got stuck it was worth struggling with it for an hour before asking for help. I don’t know if that’s too prescriptive but there certainly seems to be some merit in the idea.
I’d be interested in hearing others' thoughts on this and whether there is in fact a point at which you can grow more by focusing less on learning all the time from others and more on stretching yourself to find situations in which to take the responsibility for making decisions based on that knowledge.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.