You’ve just joined an interesting new project. Congratulations! Except that everything looks different and nothing works the way you expect. Stay calm and remember that technology doesn’t change as fast as conventional wisdom dictates.
Coming up to speed on a new project or technology is a critical skill for any creative professional, but especially for software developers. I’ve worked on a lot of projects in my 25-year career, and I’ve found an approach that makes me productive as fast as possible. It opened opportunities when I was younger and reduces the effect of ageism for me now.
Before I Start: Introspection
Awareness of my strengths and limitations is crucial to being confident and resilient in an unfamiliar situation. It’s an on-going, long-term awareness that I update every time I see something new, not just something I do for a few minutes a day. I’ll get back to this later, but for now, think of this as my inventory of the fundamental, important concepts I’ve mastered.
These are big generic ideas like pure functional programming, agile development, object modeling, or relational databases. Major inventions happen rarely and are slow to be adopted, so it’s easy to keep track. They form the touchstone concepts that I link everything back to.
I imagine these concepts as the pure core of a world surrounded by a deep, crufty, commercial mantle. Many developers wander about the surface thinking it’s a huge diverse space, but Sturgeon was an optimist: way more than 90% of everything is cruft.
New Project: The First Hour
Now, on to joining that new project. Knowledge, or filling in the gaps in my knowledge, will be the main battle, but there are soft skills that make it easier. These are traits I always try to follow and are especially important now:
- Be humble.
- Pay attention.
- Ask good questions.
- Do the homework.
- Get plenty of sleep.
More controversially, I try to minimize the effect of ego depletion by clearing my plate of as many distractions as possible. For example, if you are on a diet, it’s a good idea to pause it for a while.
Atomic Object has a lot of experience in this area, so it’s not surprising Shawn Crowley has also shared good ideas for successfully joining a new development team.
The First Day
Next, I go through the mechanics of setting up the project on my laptop. This is the easiest part of joining a project, so I do these steps in parallel with, or as a break from, the harder steps in the next section.
- Check out the project.
- Install the development toolchain.
- Follow the build instructions.
- Review documentation such as the issue tracker, scrum board, story maps, etc.
If there aren’t any build instructions or documentation for setting up the project, I write down what I’m doing in a README.md as I go. It’s also handy to keep one terminal or screen session up only for this project. That gives me a clean command history to see what I’ve done. Always try to leave the project better for the next person!
Until I’ve come fully up to speed, it’s best to follow the project conventions and cadence of other developers, regardless of my initial impression. It’s also best to use the existing development toolchain. However, you’ll only be new on a project once, so remember your impressions to improve things later.
The First Week
After I’ve settled in, I find out where my skills are a good fit and where I need to do some short-term skill development. The following steps aren’t a precise algorithm, but it’s a good place to start. Remember to be honest with yourself and try to find a win-win scenario for everyone on the project.
- Quickly survey the project to discover all technology.
- Read the build and deploy scripts.
- Search for package imports.
ackhas replacedfindandgrepfor most of my searches. - An IDE may be helpful, but it’s probably just a distraction at this point.
- Google everything from the discovery.
- Bookmark one primary source for each technology. Avoid blog posts and tutorials because they distort the distance metric used below.
- Don’t skip over things you know; human memory is not reliable, but it can get you close to an answer extremely fast.
- Don’t read anything in detail yet; instead, build a big list as quickly as possible. It’s like taking a test and finding all the easy questions first — don’t get stuck early and leave low-hanging fruit.
- Scan those sources for concepts you know, recursing until you hit a touchstone. The distance you need to go before you find a strong match is a useful metric for estimating how easily you can work with this technology:
- distance 0: immediate strong area.
- distance 1: can become strong with modest investment of a few hours practice.
- distance 2: can become competent with higher investment of a few days study.
- distance 3+: your skill set is not usefully connected to this concept.
- Read the code to learn the structure of the project and the technologies that matter most.
- Find the main entry points, then find the center or most important code.
- Reading tests may be helpful, but often they obscure the big picture, so don’t accidentally get bogged down in details too early. Acceptance tests are a nice place to start and a good sign the project is well designed.
- Rank the relative importance of the technologies.
- Go deeper in areas that are both important and play to your strengths. This makes it easier to connect to areas that you don’t know as well.
- Make a mental list of the areas where you can provide value immediately and a TODO list for areas you should invest in.
- Pair with an experienced developer to further learn the project and confirm what you’ve learned on your own. Some teams don’t have a culture that supports pairing, but it’s usually easy to justify pairing to even the most skeptical management while bringing new people onto a project.
At this point, no more than a few days in, you’ll be productive, but not comfortable and definitely not efficient. The details of unfamiliar technologies are accumulating in your working memory, and you’ll start to become familiar with the project domain. Depending on how far outside your comfort zone a project is, you may have to spend a couple hours a night reading about and practicing with new tools.
Long-Term Skill Development
Once you start paying attention to your skill gap on the projects you’ve worked on (or want to work on!), it’s much easier to decide where you want to improve. A combination of refining existing strong skills and completely new skill development works best for me. Both things will set you apart from developers who don’t invest in themselves, but you have more flexibility with a mixture of specialized and general knowledge.
When choosing general knowledge areas, I reuse the distance metric as a measure of connectedness so I can judge how much something would expand my abilities. You will quickly find things like Lisp, even if you’ve never heard Paul Graham say that using Lisp gives you a competitive advantage.
Developer conferences that specialize in generalizing are extremely useful for quickly building self-awareness and learning your limitations. Strange Loop and Code Mash are two of my favorites. Conferences are also good at refining existing strong skill areas, but I don’t find them very good for deep learning general ideas.
Whatever it is I’m learning, I find it vital to practice with real world examples. It’s not enough to just listen to a podcast, you have do some work and make mistakes on your own. Open Source projects are perfect for this kind of practice.
Good luck!