Sometimes I’m surprised that I’ve learnt to work in a team as a developer. As with most programmers when I started, even as a professional, I was mostly a lone wolf. Over the years I’ve gradually become more of a team player as my environment around me grew and as I grew. In some ways it’s slower, but on the whole my standard practices mean I find it a lot easier to collaborate with others, even on projects I hadn’t planned on sharing. Who’d have thunk I’d become a team player!
When it comes to developing in a team there are a few habits worth adopting.
- Check in frequently, at points where things work, in small increments. Don’t worry that things aren’t finished. Waiting for big chunks of functionality to be complete before collaborating means you make yourself a blocker on the project. If you are working on something major and it’s not ready for prime time stick it in a branch, but make sure it’s still checked in and on the server. Sometimes colleagues need to work on the incomplete big stuff, and sometimes they don’t. At least it’s there if they need to see it. While you ultimately want to always check in working code, if you have to move onto something else for a period of time make sure you check in what you have. Code is no use in your working directory on your machine only. Even commented out code can be more useful. Even if you’re the only one who comes back to it.
- Don’t worry if the code is ugly, if it works check it in. You can make it pretty next. If making it pretty breaks it you can always roll back. Working together means you need to tolerate ugliness, both other peoples code and your own. Don’t be too precious.
- Check in experiments. They might not work right now but you often find yourself wanting to use something useful you developed as part of the experiment, months after. It also makes it a lot easier to share ideas with other colleagues about the experiments and avoid duplicate work.
- Make sure what you’re doing doesn’t just work on your machine. Either have a 2nd machine or get someone else to periodically check your code at least builds, and ideally that the program works from time to time. If you’re at a small company and have a laptop make sure things build on that too. If you’re on a large team think about continuous integration. It’s often when you try to get things going on the second machine that you remember the dependencies you’ve added and that’s a good time to document them.
- Make sure there is documentation for how to set things up / Build scripts. Start with documentation and then codify it in scripts. Keep these up to date as you ensure it works on more than just your machine. Dependencies are the biggest pain when collaborating on projects. Remove that pain for your colleagues by at least documenting them.
- Make sure there is nothing stored solely on your machine.
- If you send an email to a colleague on ‘how to get started’ check it after you’ve sent it. Often you’ll find there is information in the email that’s not in the project documentation. Paste it into that documentation.
- Store the documentation in source control with the source or in a wiki. Either way it’s version controlled and accessible and available from more than just your machine.
- Make sure there are at least some basic tests against the library/project/application. They will help you check a development environment is working on a new machine, as well as the other obvious reasons for testing. It can be quite a good way of smoking out dependency issues when you’re first setting up a dev environment.
All of these habits actually turn out to be useful even if you’re a sole developer. Making sure everything is checked in, documented etc. all means that after you’ve been distracted for a month from the project you can come back to it with a new laptop knowing you can get it going again with a minimum amount of fuss.
It does take a little extra time doing the things like making sure it will work on a second machine, but it means when you do need to deploy/share/move machine you can do it at a snap and whenever you want to, rather than having to schedule time for it at some point in the future. There’s not much more frustrating than blocking someone from being able to help you on your project simply because you don’t have time to hand it over because of all the other work you are doing on another project.