How to Survive and Thrive in a New Project
Part 1: On-Boarding
Orientation & Map-Making
If you've ever joined a large & complex software development project, that was well underway, you may have felt a little bit like you had been dropped in the middle of the Amazon Jungle - without a map. Although you have skills in the technologies used in the project, there are many other things necessary for successfully building great software to serve your customers' needs. For example, you also need to understand the problems that the application is meant to solve, you need to understand the sorts of people who will use the app and how they will use it. You also need to understand the app's data model and the application architecture.
But, those aren’t the only considerations necessary to create a successful relationship and product. Knowing the values of the people writing your checks, the culture of the people you're working with, the constraints that affect how decisions are made in the project, the processes currently used on the project, the team members you'll work with and their roles in the project, the ancillary tools chosen for this project, and so on are extremely important as well. Not least of all, you need to know how the code is organized, what different parts of the code do, and how they all work together.
It is commonly assumed that having skill in the app's programming languages is sufficient to begin being productive as a programmer, but that assumption overlooks these many project-specific areas of knowledge. If you had been a botanist sent to discover new species of plants in the Amazon, a PhD in botany would not help you know which path to take through the jungle to find a spring with fresh water. Unless you specialized in Amazonian flora, you would probably have no idea which plants are edible and which are poisonous. You would have a great deal of valuable expertise, but you would lack local knowledge. To succeed in your venture, you would want to make a map, and find a guide.
As a programmer, your needs are in many ways very similar. Knowing the technologies used in the project is a little bit like being able to identify every plant you see, every type of soil you walk on, and being able to start a campfire and build a shelter. These may be necessary skills for survival, but they don't change the fact that you don't know the terrain. The ability to filter water is only useful if you can’t find fresh water in the first place.
Even if you know every item you encounter on the terrain, you don't know your way around this particular piece of land. The old hands on this project know the terrain itself. But for you, for optimal success in navigating through the wilderness, nothing can exactly replace the benefits you'll get from a map. Therefore, one of the first things you'll want to do is begin to make—or otherwise obtain—a map of the terrain you find yourself in. But even more than that, you need to find people who know the project well, and can answer your questions. The answers—both those they give you and those you figure out on your own—are what make up your map of this new project.
The Question to Everyone's Answer
The project team may have an on-boarding process, and you'll want to take full advantage of it. But—in my experience—you'll need to have your own plans to supplement it. Sometimes referred to as "the curse of knowledge", the more a person knows about the project, the harder it is for them to see how to explain their knowledge. Things that seem obvious to them will not seem obvious to you. Things that they figured out over time are now forgotten, and have become part of the way they perceive the world around them. They don’t even realize they have this knowledge! Rather than expecting them to provide all the answers you need, plan to ask questions. The answers to these questions will form your map of the terrain of this project.
I recommend making a list of questions as early as possible. Don't wait until after the official on-boarding to ask yourself "what did they miss?" Start at your point of greatest ignorance in the project, and ask yourself "What do I need to know in order to be successful in my role in this project?"
If you already have a list of questions to ask you’re ahead of the curve, but if you don’t, I'll be posting a list of questions soon that I’ve come up with that has helped me. You may find it helpful too. Feel free to use it as-is or tweak to suit your needs, but definitely make it your own by making sure it has questions you feel are important.
Once you have written down as many questions as you can think of (including any of those I post that you find pertinent), group them by topic. This can help you put questions together that a single person can answer. One person might be well suited to answering your questions about processes followed on this project, but not about details of technology. Another person might be well suited to explaining the UX design choices, and another the purposes behind the application, and another the details of the app's various features, and so forth.
Once you have your questions organized, and before you approach anyone for answers, identify the most important question—at the moment—for you to get an answer to.
If it's not yet obvious, find out who can answer this question (and probably this group of questions). The others on the project who are most accessible might not be the people with the answer, but they are probably the people who can help you find the person with the answer. Ask them "Hey, I've got some questions about _______; who would be the best person to give me good answers?" Write that person's name on your list of questions for that topic, as you are likely to have more questions in the future, and it's good to know who to go to.
When you're ready to talk to them, I've found it most helpful to have a face-to-face conversation. If that's not possible, a phone call or video conference is next. Email correspondence falls several levels down near the bottom. (Okay, perhaps smoke signals are at the very bottom.) Email communication drains a lot of time, and because of this most people do not put sufficient thought into how to express their ideas when they compose email messages. You don't want to spend several message volleys trying to clarify what they didn't explain well, as this can eat up days over email, but could be resolved in a minute in a face-to-face conversation. Slack or HipChat is a better option than email, but still not the first thing to ask for or the first tool to reach for.
Ask for some time from the potential answerer, and lead the conversation with the most important question, since its answer might fill more time than you expected, and you don't want to find you've used up all the time they can afford and still don't have an answer to something you need to know right away.
Some of these questions will be answered before you ask them, probably during whatever planned on-boarding process the project has. Some will be answered by "That's a good question—I don't know the answer." Some you will be prevented from asking, because someone has decided that there's something more pressing for you to be doing right now. Some questions will arise after you have begun working on the project. Throughout the project, you should continue to
Write down all of your questions (even those that don't seem terribly important).
Identify the most important questions on the list.
Find people who you think may have answers, and ask them the questions, and
Write down at least some rough notes on what you learned.
This will not only help you, but it will allow you to make on-boarding easier for the next developer to come along. Your notes don't have to be legible to anyone else, but they need to mean something to you, so that you can at least verbally pass on what you've learned. (You may find time to create "proper" documentation at some point, but do not let a lack of such time now prevent you from writing anything down. Just because it's chicken scratch at the moment doesn't mean you shouldn't record it.)