(This post originally appeared on thetimelydeveloper.com)

How do you measure up against the other members of your team? Are you seen as a figure of authority that can be relied upon, consistently getting a lot done and teaching others to do the same? Or do you find yourself struggling on a daily basis to keep up with your talented colleagues, constantly being challenged by the work you do?

In their book Apprenticeship Patterns, authors Dave Hoover and Adewale Oshineye encourage readers to make the most of being the worst in a team. At first, this seems like a backwards notion; after all, who wants to be the worst at something? We are often taught to compete against each other and to try our hardest to be the best; by definition the opposite of being at the bottom.

Today’s article will discuss the topic of being the worst and what you can get out of it.

(This post is part of a series inspired by the book Apprenticeship Patterns. Find the rest of the series here.)

What does being the worst look like?

First let’s talk about what being the worst means in this context. The most important thing to keep in mind while reading this article is that being the worst does not necessarily mean being bad at something.

Unless you have only just started learning something, you are unlikely to be objectively bad at it. Once you have put some time and practice in, you will gradually become average or even skilled in the area.

Regardless of skill, there will always be an opportunity to be the worst in the team. The authors make the following suggestion:

"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, Apprenticeship Patterns, D. Hoover & A. Oshineye

So, being the worst means being surrounded by people with more knowledge and experience than you. Even if you have, say, 10 years of experience working with C#, you can seek out people with more.

Remember as well that being the worst at everything is improbable, if not impossible; there will always be something that you are better at than your peers. You might not understand the ins and outs of infrastructure yet, but you could be a better presenter than your team’s Kubernetes expert.

A diverse team is a strong team, and you can be the worst at one skill while contributing to such diversity with another.

What are the benefits of being the worst?

The quote above encourages you to be the worst so that you have “room to grow”. I don’t think this is the best choice of words, because everyone has room for growth; there is no upper limit to personal growth in my opinion.

It creates opportunity

I think a better way of phrasing it is that you have more opportunity to grow. You will always have room to grow, but with fewer opportunities and resources it will be harder. Without the support of an experienced and challenging team, you must rely on yourself more. This naturally raises challenges when it comes to gathering useful feedback and assessing your own abilities in order to grow.

Being surrounded by those more experienced than you solves this problem. They have already been through what you’re going through and have collected the scars. They can give you solid advice on how to progress, and will work at a pace and level of understanding which will force you to grow.

I recently attended the birthday party of an old friend of mine who has become an accomplished pianist over his life. At the party, his dad gave a speech which included a part in which he described how my friend’s step-mother would know exactly how hard to push him and his boundaries such that he would rise to the challenge.

A good team provides you with the opportunity to do the same.

It forces you to challenge yourself

Consider what the opposite of being the worst looks like. You’re the most knowledgable and talented person on your team, and everyone comes to you for answers. You get through most days without much of a challenge and know that there’s no real pressure on you to grow.

Settling there in the comfort zone is the easy option, and lots of people choose to do it. On the other hand, confronting yourself and giving up on that comfort to jump into the deep end is a terrifying and character-building thing to do. If you can do it on a regular basis, you will learn more long-lasting lessons than you will by avoiding challenge.

It will teach you how to learn

Have you ever heard of Parkinson’s Law? It states that “work expands to fill the time available for its completion”. We can all relate to it; just think back to those late nights spent cramming for a school exam, or to the last project you worked on which pushed right up to its deadline.

I believe that a form of this law applies to learning in a team. That is, the slower the work pace of your team, the longer you will take to learn new things. To invert the idea, if your team works at a faster pace, then you will learn faster.

Don’t get me wrong, I’m not talking about faster typing and less thinking, or more lines of code per minute. What I’m saying is that if you are part of a team who know their tools and their language and how to work efficiently with them, then you will have to learn a lot in a short amount of time or else fall behind.

As the old saying goes, necessity is the mother of invention.

How do you stay the worst?

Perhaps by now I have convinced you of the value of being the worst in a team. You might be wondering, however, what practical ways there are for achieving it. The authors of Apprenticeship Patterns don’t go into too much detail about how you can do this, instead focusing on the benefits of the pattern. Here are some ideas I have on how you can go about it:

Look for unfamiliar work and teams within your organisation

A lot of organisations have more than a single team that you can have the opportunity to work on. If this is the case for you, see if you can find a team which is working with an unfamiliar tech stack and ask to join them. If, for example, you have been focussed on the backend or infrastructure side of a project, see if you could try working with the frontend team for a time.

There are also countless non-functional requirements in the world of software that it would be valuable to learn. Choose one which is new to you and start to learn from those around you who already know about it. Here are a few examples to get you started:

• Accessibility
• Security
• Privacy
• Durability

If you are a student, consider choosing a module which is completely different to anything you’ve tried before. Another approach for students is to ask a professor who specialises in an unfamiliar topic if you can volunteer to help them with their work/research.

Try out higher-level roles

This point goes against the spirit of Apprenticeship Patterns a little, since the book encourages readers to focus on personal growth and becoming a better developer rather than seeking to climb the promotional ladder. Regardless, I believe that there is no shame in looking for promotion if you see it as an opportunity for growth and challenge.

If you struggle to find teams in which you are the worst developer, promotion may give you the opportunity to be the worst in other ways. You might be an expert Python developer, but can you lead a team or manage stakeholder expectations? Are you able to direct the technical vision of a project from start to finish?

Promotion usually involves taking on new and challenging responsibilities, many of which you will initially be the worst at when compared with your peers.

Leave your company

Sometimes there’s nothing for it but to leave the job you currently work at, either because there are no opportunities to be the worst or you simply need a change in environment to inspire growth.

This might also make deliberately moving from a position of expertise and seniority to one in which you are the novice easier, since people will have fewer preconceptions about what you know.

Consider finding a company which is working on something completely new to you in terms of technology, industry, or problem domain.

My experiences being the worst

Being at the start of my career, I am lucky in that I have plenty of opportunities to be the worst and there is usually little expectation for me to be the best. When I consider the experiences I’ve had so far, however, there are two that stand out more than others; one bad, the other good.

The bad

The first experience happened when I was a graduate developer. I was put on a side-project as part of a development team made up of just myself and another grad. My team-mate was a brilliantly intelligent thinker and seemed to pick up an understanding of the technology and problem with ease.

I was the worst in this situation and didn’t have such an easy time. I struggled with trying to learn a language I had never seen before (Ruby) while also trying to keep up with the pace of my colleague. All in all it was a stressful and demoralising experience for me.

On reflection, I think this was primarily because the team was made up of two junior developers. Without a more senior team member to help guide my development, there was more pressure on me to provide that direction and challenge to myself, and I failed to rise to the occasion.

The good

More recently, I have been working on another side-project with another highly intelligent and talented colleague. Though we are at the same level of seniority, his depth and breadth of knowledge far exceeds my own. Compared to the first scenario, I feel as though I have grown a lot more both professionally and technically, and there are a few reasons for this.

First is that my colleague has many years more experience than me, and so is more prepared for supporting a junior team member. His depth of knowledge also means that he is often recommending and using concepts that are completely unfamiliar to me, exposing me to new approaches.

I also find that when we are pairing I tend to put more pressure on myself to work more efficiently, as I discussed above. While this can sometimes feel stressful and is by no means intended by my colleague, I think it is a vital part of the learning process for me. Without that pressure, synthetic or not, I may well make less of an effort to expand my skills and grow.

These two examples hopefully demonstrate the dangers and opportunities that this can provide.

Let me know your experiences!

Have you been in many situations in which you were the worst on your team? What did you learn from that experience?

Let me know in the comments below!