Article summary
Joining a team as a young developer on a large project is a fantastic way to lower your self-confidence—especially if you’re also new to the framework in which the project is written. It’s hard to make meaningful contributions until you’ve read through a substantial portion of the codebase and made a lot of mistakes trying to change it. Making those mistakes is embarrassing if they’re too public, and it can be downright costly to a client if you don’t keep them carefully isolated.
What’s a budding consultant to do? Use git, and regain your confidence.
Overcommit
When I step into a project for the first time, I have to be ready to switch what I’m doing at a moment’s notice. If one of the other developers unexpectedly invites me to pair on a new section of the code, I want to be able to jump at that opportunity without losing my place.
For a while, I tried using git stash as a kind of pseudo-commit to put my work away when I had to switch my focus during a pairing session. This worked for quick diversions, but I found that when I was away from my changes for more than a few minutes, it became increasingly difficult to remember what I’d been thinking when I stashed it in the first place.
Then I tried committing before switching tasks and found that it worked better. Leaving myself a sentence or two helped me recreate my mental state later, but it was cumbersome because I was in the habit of waiting until the code was in a good state before comitting. By the time I needed to switch contexts, I had written enough that stepping through all of the changes took an unreasonable (by software developer standards) amount of time.
Committing was accurate, but too onerous. Stashing was never a viable option because when I’m learning a new project, the amount of things vying for space in my L1 brain cache is high enough as it is. Any solution that involved the phrase “you just have to remember…” was likely to fail miserably.
Instead, I threw out all the heuristics that I normally use to pick the right moment to commit and ran git commit like it was going out of style.
On new projects, whenever I stop what I’m doing, whether to run the tests, get another cup of coffee, or just come up for air, I take a few seconds to step through my changes with git add -p and then make a commit. Usually, the messages aren’t very long—just enough that the future me knows what the past me was thinking. They don’t have to be perfect, grammatically correct, or even good, because they aren’t for public consumption. They’re just notes to myself to help recreate my mental state after a context switch.
Then, when I’m finished with a change and ready to push it to our continuous integration server, I run git rebase -i on my local branch to squash the commit madness into something sensible for the rest of the team.
Now, instead of slightly dreading a context switch, I revel. I spend a bit more time writing commit messages than I used to, but I’m able to switch contexts much more quickly and confidently than I ever could before.
Branch Out
Breaking things and then fixing them is one of the best ways I’ve found to build my understanding of the way that a project works. Unfortunately, breaking things in the main development branch is also one of the fastest ways to earn the right to leave a project.
So when I’m starting a new project, I generate a ton of branches. Any time I have a question about how the code works, I take a few seconds to commit my progress (see above) and then check out a new branch where I can try to answer it.
Asking for help from a more experienced developer on the project is a great way to learn, but sometimes there’s no replacement for just trying something a couple of different ways and seeing what happens. In an unversioned system, this would be extremely tedious, but with git, it’s really easy. I use a simple naming convention to group these branches together for easy cleanup later. Every couple of weeks, I go through the repo and git branch -D anything that starts with trying/. Most of my branches never make it to our shared git server, but by trying lots of little experiments in the safe environment of a local branch, I’m able to be much more confident in the changes that I eventually share with the rest of the team.
Neither of these techniques are groundbreaking by any means, but by making these two small tweaks to my normal workflow, I’ve been able to contribute changes more confidently than ever before.