Making a new developer productive as quickly as possible is most of the times challenging for the product team. I’ve heard stories about new on-boarding team members needing up to several weeks, or even months, until they feel comfortable or knowledgeable enough about the project and the code. This shouldn’t be the norm. Situations like these are detrimental to the project, wasting valuable time and resources that could be otherwise used to streamline those great features into production. And we all know it: there’s no place like production!

Recently, I found myself in the shoes of the new team member by joining  the Eventrix product team at MozaicLabs. Just like you, I felt the need to make myself productive as soon as possible, in order to deliver value to the project.

In this article, I will share with you more about my own experience, as well as tools and techniques that can be used to achieve productivity.

Easy project setup

First things first. When a new developer joins the project, one of the first things they need is to set up their development environment. And I’m not talking just about the IDE. It’s also about getting the source code, configuring the development environment variables, initializing and populating the database, deploying the artifact locally, etc., you get the idea.

What is the most common thing you hear when facing all of that? “Yeah, it’s going to take at least a few days, if not the whole week!”. Here is your first problem: not being able to get up and running on your first day on the job.

First step to quickly become productive when joining a team is automation. Computers are very good at executing the repeatable steps that we, humans, dread to do manually. And they do it faster, too! So write a few scripts, one for each complex task like the ones described in the paragraph above. The new team member will only need to execute those scripts on the local machine, go grab a cup of coffee while that’s running, and have the development environment all ready after a few minutes when the scripts are done.

To avoid those scripts becoming a huge mess themselves, it might help if everyone on the team was using the same kind of operating system, IDE, database management tool, etc. That way, the scripts wouldn’t break on subtle variations of the running system, and they wouldn’t need too much maintenance. Plus, the development environment consistency is useful when you need help from a colleague who won’t stumble because you’re using a different Linux flavor, or a different kind of IDE.

A high-level overview

The next thing on your list should be asking for a high-level overview presentation of the project from someone who has more knowledge about it. Typically, this person can be the architect, the technical team leader, or a senior developer.

During this session, your teammate can explain the following to you:

• the business value of the product, and the problem it tries to resolve for the end-user
• the easiest (or the most complex) business case scenario of the product
• why certain decision were taken during the project’s lifecycle
• the most common pitfalls that a newbie can get stuck into while working on the project
• the most sensitive areas of the code, in terms of high probability of bug occurrence
• the project structure, the software design, the most common classes encountered in the code (such as controllers, services, validators, entities, etc.) and how they interact with each other
• the frameworks and libraries used, and their typical use-case
• code conventions
• if and how the project deals with performance, security and scalability
• anything else that a new team member should know about the project before diving into the code

Mob programming

At this point, if you’re still fuzzy about how to start implementing that first feature on your own, you can ask for a mob programming session. That’s a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. If the team is large, projecting the screen onto a wall might come in handy.

So, pick a simple (but not too simple) feature from the backlog and implement it from scratch, together, as a team. Everyone should take turns at the keyboard every 15 minutes or so.

How is this session going to help you? Well, it will allow you to see how a user story gets translated into code, going through all the layers of the application: from the user interface all the way down to the database (and back again). At the same time, you can ask questions and gather insights from your colleagues about the code and the best practices to be used.

The downsides of the mob programming session are that:

• it can take quite some time, from a few hours to an entire day
• it can get tiring
• it puts on hold the other tasks that your teammates are working on
• you can’t organize more of these in a short period of time

Those downsides may look grim, but the amount of learning that you will acquire during such a session will prove to be invaluable in the longer term.

Pair programming

The smaller scale alternative to mob programming is pair programming. This is a software-development technique in which two programmers work as a pair together on one workstation. The driver writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

These pairing sessions can happen a lot more frequently than the mobbing ones. Nothing stops you from pairing with someone every day. In fact, all the downsides of the mob session are alleviated:

• it doesn’t have to take much time, it can be as short as an hour
• being short, it won’t get tiring; you can stop as soon as you feel losing focus
• no one else’s work is being put on hold
• as stated above, you can pair daily; moreover, every day you can pair with someone else.

Readable tests, executable specifications

You may have heard about Gherkin scenarios: business readable, domain-related specifications that let you describe the software’s behavior without detailing how that behavior is implemented.

A typical scenario follows the “Given – When – Then” syntax, and it looks like this:

Scenario: “Organizer updates session status to “Rejected””

Given

• “Alex” event organizer
• “Alex’s conference” event
• “Adi” event reviewer for “Alex’s conference”
• “Plato” is a speaker
• “Plato”s submission “Absolute Truth” submitted to “Alex’s conference”

When

• Alex is logged in
• Alex is on “Absolute Truth” page
• Alex updates session status to “Rejected”

Then

• Ensure that Adi views “Absolute Truth” session status as “Rejected”

These scenarios help you understand the business needs of a certain feature. The “given” section describes the preconditions that should be met before executing a certain operation. The “when” section describes the operation to be executed as part of the feature to be implemented. The “then” section describes the expected results after executing the operation.

Going into finer details, you should read the unit / integration / functional tests associated with the feature you are interested in. If those tests are well written, they will provide you examples on how certain classes are used, how they react to different inputs, and how they interact with other parts of the system.

Koans

Last but not least, if the project uses a specific programming language, framework or library that you have never worked with previously, you can get yourself up to speed by working on some koans. These are simple problems where the programmer is asked to “fill in the blanks”. They look a lot like unit tests. The aim is to make the tests pass, gradually using features of the thing you’re aiming to learn. By the end of the koans exercises, you should be feeling completely comfortable with that language / framework. If you don’t, feel free to re-do the exercises as many times as you need, or to search for other similar koans on that same subject.

In my case, I needed to refresh my memory regarding the Groovy programming language and the Grails framework. Towards that goal, I have worked on this groovy-koans project available on Github. By the end of it, I even managed to make some small contributions through pull requests to improve the project by fixing some typos, updating some outdated and incorrect links.

Conclusions

When faced with a [scary] new project, don’t get discouraged or feel overwhelmed. There are several techniques that you and your team can employ to tackle the seemingly impossible goal of being productive right from your first days. These range from using automated scripts to set up your project, getting educated through a project overview presentation or reading the specs and tests, up to experimenting with mob programming, pair programming and koans.

If you have any other useful techniques that you can share with us, let us know in a comment below.