Synopsis

Following this simple piece of advice will probably have more impact on your code than anything else in this book!

How many times have you stared at the screen for hours, trying this and that in a vain attempt to fix a problem in your code? Finally, exhausted and desperate, you call over your cubicle wall: “Hey, Melinda, could you come over here and look at this?” When Melinda reaches your cube she sees in an instant what you, after hours, still could not see. Gosh, it’s like magic!

Except it’s not magic and it’s not mysterious at all. Remember: humans write software, so an understanding of human psychology is crucial to setting up processes that encourage quality software. We humans (especially the males of the species) like to get things right, like to solve our own problems, and do not like to admit that we don’t know what is going on. Consequently, we tend to want to hide our ignorance and difficulties. This tendency leads to many wasted hours, high levels of frustration, and, usually, nasty, spaghetti code.

Team leaders and development managers need to cultivate an environment in which we are encouraged to admit what we do not know, and ask for help earlier rather than later. Ignorance isn’t a problem unless it is hidden from view. And by asking for help, you validate the knowledge and experience of others, building the overall self-esteem and confidence of the team.

There is a good chance that if you spend 30 minutes fruitlessly analyzing your code, two more hours will not get you any further along to a solution. Instead, get in the habit of sharing your difficulty with a coworker (preferably an assigned “buddy,” so the line of communication between the two of you is officially acknowledged and doesn’t represent in any way acknowledgement of a failure).