Being a valuable team member when you’re inexperienced

I’ve been working at Pivotal Labs as a software engineer for six months now. Before that I was studying at Makers Academy, a twelve-week bootcamp in software development. Not long before that, I was studying Philosophy, Politics, and Economics at university, on my way into a corporate finance career.

I haven’t been in the coding world for very long at all.

I love my job but it has not been easy. We pair program 8 hours a day. This means that I’ve been in the fortunate position of being able to work on complex projects with languages and technologies that I’ve never used before and I am learning vast amounts. However, for 8 hours a day, every day, I’m constantly reminded of my inexperience. I felt a pressure to improve upon my technical skills and be as valuable a team member as I could be sooner rather than later. The pressure stemmed from feeling like I had to do this if I wanted to keep my job, as well as being someone that always wanted to perform at the highest level that I am capable of.

Instead of worrying about it, I decided to proactively work on it. There are certainly steps that you can take that will give you confidence that you are delivering value to your team no matter your perceived level relative to your teammates. The guidelines below are a mixture of approaches that I have tried and advice from some people that I am very lucky to have around me. I hope that you will find at least one thing to take away from them.

Whilst the points are framed in a technical context, I think that those in any industry can find helpful pieces of advice here.

Mindset

The first thing is not to be embarrassed about your current level.

Admit to yourself how little you know and celebrate in that ignorance. You got your job not because you know it all, but because you’ve got the ability to reason about problems and to think critically. You have got the potential to tackle complicated issues. Get excited by the potential opportunities open to you once you’ve got your mindset straight: you have nothing to apologise for, but everything to explore.

You will never learn it all and you will never get close to learning it all, and being comfortable with this fact is a big part of your mental preparation.

Communicate with your team about where you’re at

Start by being upfront to those that you’re working with about where you feel you’re at, what you’re struggling with, and what you want to know more about. Be ready to listen and keen to learn.

It doesn’t matter how long you’ve already been working with your teammates. It’s never too late to say: ‘Hey, you know what? I’m really not getting this. Can we take some time out where you break this down for me, please?”

Some months ago, I was rolled onto a client project that had been going on for months. The client developers just assumed I was around the same age, with experience from previous programming jobs or projects. Nothing explicit was ever said that gave me an opportunity to clarify these misconceptions. However, what I didn’t realise was a personal pressure that I began to place upon myself to perform to a higher standard than my actual experience allowed.

There was a moment when I became acutely aware of this unnecessary pressure that I was placing upon on myself and after discussing the matter with a colleague at Pivotal, I took the following approach: every morning, after I sat down with my pair, I would say “Just so you know, I’m very new to all of this. I’m actually struggling to make sense of how this app is working, so if you could bear with me whilst I piece it together, that’d be great. It’d also be very helpful for my progress if you let me take control of the keyboard and give me guidance where necessary.”

The response to this approach was far better than I thought it would be. Not only did my colleagues not mind about my lack of experience, they eagerly shifted into more of a guiding role, patiently explaining things and getting excited when they could see the pieces coming together in my head. Each day, I was able to pick up things more quickly and I was more relaxed, no longer feeling like I had anything to prove.

Being aware that most working environments don’t strictly pair program in the way that Pivotal does, I had a chat with a fellow Makers Academy graduate, Josh Hill, who is a software developer at Global Personals. He had the following to say with regards to non-pairing alternatives to getting the most out of being surrounded by more experienced colleagues:

•  Get a senior to support you on each project; be clear about what you hope to get out of their support and talk about your progress with them every day; instigate pairing sessions
• Use a rubber duck to help yourself get a better understanding of what’s going on
• Be proactive and explicit about what you want during code reviews; if you’re leaving a pull request, leave questions in it to attract the attention of more experienced developers to choices that you’re not sure about

Being upfront about how you’re feeling on a project is the first step to freeing your mind from any anxieties that you may have about how you’re performing. You create these pressures when you believe that you should be delivering at a level which you’ve not quite reached. When you accept that you’re at where you’re at, it goes a long way in enabling you to focus on the practical steps you need to reach a higher level and to enjoy the progress that you will inevitably make.

Questions, questions, questions

If you’ve got it in your head that constantly asking questions is found to be annoying, then you’re wrong. As long as you are asking useful questions and paying attention to the answers, this will form part of being a valuable team member.

If something is mentioned that I don’t understand, particularly an acronym I’ve never heard of, I ask what it means. If someone explains how the team is going to approach a problem in a way that makes it sound as if it is trivial but I still don’t understand what it looks like in practice, I ask for the steps to be broken down. When I’ve read something technical the night before that I couldn’t quite grasp, I bring it up during a break the next day and ask for someone to explain it to me.

What I’ve found to be revealing are the number of occasions where the response has been ‘I’m not too sure myself. Let’s look into it together’. My teammates have celebrated my questions sometimes as I may have unveiled a flaw in their plan or uncovered a misconception.

What do I mean by the ‘right’ questions?

• Whenever you don’t understand something, ask for clarification
• When your team has decided to go in one direction, ask why and ask what the alternatives are
• When someone expresses an technical opinion, whether it is related to your codebase or not, ask why they’ve come to their conclusion and what developers who disagree might say
• When you have a suggestion for an approach, ask if it is a valid one; follow up with why or why not

By asking the right questions you will most likely find that you:

• Uncover misconceptions or a lack of knowledge within the team
• Unveil flaws in plans of action
• Open up previously unconsidered methods for tackling a problem
• Learn a lot!

Finding focus

When you’re feeling like you’ve got a lot to catch up on it can be overwhelming figuring out where to start. Try and find a particular area that you can focus on that will be very useful to any team that you find yourself working with.

For example, say I wanted to be the person that could look at the codebase and help with the cleaning up and maintenance of the code and tests, I might:

1. Read the RSpec documentation
2. Read ‘Refactoring Ruby’
3. Read ‘Domain Driven Design’

The idea behind this is that no matter what team you are on, after studying the codebase, you will be able to help write effective tests, make useful abstractions whilst refactoring, and make suggestions on how the team could think about improving the overall structure of the application.

Having a strong command of whatever version control system you use (e.g. git) or a tool specific to your team will always be useful. For example, we use something called BOSH on the Cloud Foundry to install packages on virtual machines and those that know how to use it very well often help the team out of sticky situations .

The other thing to recognise is that you can be an effective team member in a way that is removed from the code. For example, as touched upon earlier, you can always be the one that asks the useful questions and makes your team take the time to think and plan their direction more carefully. I’ve always been praised for my positive attitude and enthusiasm. I used to take this as a negative indication that my code wasn’t the area where my main contribution was stemming from, but having an optimistic eagerness and energy during the work day is incredibly refreshing and inspiring. Having this great attitude and delivering quality code are not mutually exclusive things.

Side project

Over the working week, you’ll be exposed to a multitude of concepts and technologies, particularly new ways to use technologies that you’re already familiar with. Whilst you might understand these things as they are being explained to you, I have found that you only really grasp something once you try it out yourself. Therefore, it becomes very useful to find a technical side project that you can work on outside of office hours.

If you want to master a particular framework, start by building a simple app in it before moving on to something more complex. Perhaps you’ve wished that a certain tool or app existed – even if you think it’s too challenging for you, start trying to build it and when you get stuck ask someone for help.

Apart from helping your technical skills, as this blog post discusses, there are many benefits to having a personal project outside of work.

Summary

I hope that you’ve seen many ways that you can bring value to a team when you’re the least experienced and may be feeling a lack of confidence.

As pointed out in this post by Alicia Liu: “One of the biggest differences between experienced and novice programmers is that experienced programmers know more things to try.“ I’ve definitely found this to be the case and have had my inexperience highlighted when I struggle to suggest ideas for next steps. The steps I’ve discussed above can go some way in helping you to alleviate this problem:

• Accept that you don’t know much and that you have a long way to go
• Share your inexperience with your colleagues and be keen to learn more
• Continually ask the ‘right’ questions
• Focus in on one thing you want to improve on
• Start a side project

Remember that you have a whole network of people around you that are there to help. Take advantage of this resource where you can. Any great team members will be excited to help you reach the next level of your career.

A big thank you goes to Josh Hill for his detailed comments and contributions to this post, as well as to Makis Otman for reading the initial draft.

Finally, thank you very much to Jesse Heitler, for all of our wonderful conversations.