In my previous blog post, I have stated that communication is very important for programmers, and maybe essential for successful teams. Today I want to clarify this subject by defining jet another guideline: Two heads are smarter than one. What this means is that two people are more likely to solve some problem faster and better.
Let’s put this in context of real programmer’s working day: you are trying to solve some problem, you cannot find good enough solution or you cannot decide which alternative solution to choose or how to organize your code, you aren’t sure will underlying technology cause problems…
What can you do about it?
You can do your best to focus, you can “google” solution all day long, you can pool out your hair trying to fit all that information in your head at once… or you can just ask for help person sitting next to you.
Often it is enough to try to explain some problem to another person and to see for yourself where you have gone wrong. If this doesn’t do the trick, your colleague already has advantage over you in solving the problem because he is approaching it from a different angle. It can be that colleague is more expirience with that kind of probelm, or that he is the developer who wrote original peace of code. Maybe he has already solved that problem, maybe he read something about it on the Internet, or maybe he knows that someone else in firms knows solution. It may also be that he is smarter than you, which again is great thing because what’s important is that problem is solved with little effort and that you learned something.
If all of these positive sides of communication didn’t solve the problem in first 2 minutes, you and the colleague are left to use power of brain storming, to inspect solution variations and alternatives. The catch with programming is that it is very complex and that if some problem is not solved 100% than it isn’t solved at all. You can’t say to your customer, “I can obtain all data you need but I don’t know how to show them to you, can you pay me half?” Sometimes you solve 95% of the problem for few minutes, and can be left struggling to solve rest 5% for days. Maybe your colleague has 50% of the solution, but it includes your missing 5%.
Other great thing about this rule is that motivates people to share problems. Beside the advantage of collective problem solving, it is great means for informing others about project state and sharing knowledge patterns in form problem -> solution. This way, some programmer is less likely to get stack solving problem that someone have already solved.
Few years ago my friend Aleksandar Mirilovic gave me an advice "No mater how small and easy project is, never work alone". At first I wasn't happy with idea but today it is an apsolute truth for me. What happend meanwile is that I have been working on mantaining a large project for two years. During that time I learned that some times you colleague can solve the problem you are working on in few minutes and that without his help you would be working on a problem for whole day.
So if it is that simple, why don’t we use it then?
Maybe it is because of our ego, because we like challenges or because we are afraid we will look stupid. The real chalange is to finish you task in simplet and fastest form using all available resources, and colleague sitting nexto to you is friendliest and most user friendly resource you will ever have. Use your colleague and don’t worry, he will share his adventures with you soon enough. Programming is hard enough, don’t make it harder on your self, use all the help you can get.