You might be a smart developer. You might be someone who gets things done. Unless you’re a lone programmer working in your bedroom though, that’s not enough. Collaborating and cooperating with your teammates is vital to keeping your project moving forwards and to ensure it’s extendable and maintainable.
In this series I’m going to talk about how small changes to your coding style, small changes to your communication and small changes to your working practices can make a huge difference to those you’re working with. A lot of these tips are common sense, some of them you’ll already know, but hopefully some of them will make you think and might make your life easier.
If you’re fresh out of university and joining a team of programmers with 30 years experience then you will probably get there and think “WTF!” about some aspect of their working practices. Most of what you read about programming is of the “here’s a shiny new toy” variety. If you immediately started using everything you read about not only would you probably go insane but you’d also annoy your coworkers immensely.
In a project with a reasonably sized team, especially one with people of different abilities, consistency is key. If you’re starting a project in a new company which has never written software before then you’ll have the opportunity to do things right. If you’re rewriting an old project from scratch then not only can you improve the code but also you can improve the working practices too. The first of those possibilities is unlikely, while the second is rare. What is much more likely is that you’re working either to maintain or to incrementally improve an existing code base.
Improving code and practices is an incremental process. Try to change too much too quickly and your coworkers will find it hard to keep up with the changes given the mixed state of the code base. How to stage the transition from old and broken working style to best practices is something I’ll discuss later.
Vim or Emacs, Windows or Linux, Mac or PC. Computers are full of ideological wars that will probably never reach a cease fire. This is a good thing. Arguments spur people on to ensure that their chose side is unquestionably better than their foe, and we all win as a result. When you’re working in a team though, arguments of this nature are trivial and can undermine the success of your team. In a future post I’ll talk about how to control these arguments so they remain productive.
In my next post, I’ll talk about rude code, how to deal with it and how to avoid writing it.