When I took my first lead developer role I implemented a 15 minute rule. It basically said that if there was a technical problem that stumped a programmer for more than 15 minutes, then that programmer was to get some help from a coworker. The rule worked very well in a small web shop (pre-AJAX). Almost all of our programmers were students at a local engineering/science college, and while they were smart they did not have a lot of experience (nor did I). I put the 15 minute rule into place so small problems did not turn into big ones. It works very well.
Ten years later I find myself as a senior developer at my company. People come to me for help, and the problems are not typically the small “15 minute” variety problems. The software the my fellow developers and I work on today is much more complex. Fifteen minutes is probably not enough time for a developer to research a problem before getting help from someone else. Still, some line must be drawn. When does one quit spinning their wheels and ask for help?
With programmers, this can be a difficult decision to make. There are several things to consider. First, many of the programmers I work with now and have worked with in the past take pride in their work and their knowledge. Admitting defeat or a lack of knowledge is not easy for most people, and certainly not for these guys. There is also a level of tunnel vision that can occur when working on a problem. I have accidentally worked through lunch more times than I can count because I was focussed on a problem. This is not uncommon amongst developers.
I have always liked the idea of working in a team, but I also like the idea of self-reliance. I like to be able to figure stuff out on my own. It is fun (yet sometimes tedious) to learn a new concept. In ancient Japan, marshal arts were taught by example only. Any particular move, throw, kick or striking motion was not explained, but simply demonstrated. The student got the lesson wrong over and over until they finally got it right. Many traditional marshal artists that follow Ju Jitsu or Aekido today still believe that this is the best way to teach. They contend that the lesson you learn on your own is the one you have learned learned the best. Today’s business world is not ancient Japan and we, as business programmers, do not have the luxury of taking our time to learn a concept in this fashion. This is where the team comes into play.
How do we balance learning a new concept and getting it done on our own with relying on team members for help? I have found that drawing this line for myself can be very hard. When do I give up reading the web articles, books, etc, and go ask someone for help? When do I got to my boss and ask (beg) for training or a new book?
Drawing this line for someone else is a much more complicated issue. When a fellow programmer comes to me with a technical problem, I am expecting that they have done some amount of debugging and research on the issue. If this is the case then I am more than happy to help out. It doesn’t really matter how hard or simple the problem, if the programmer is a seasoned developer or hopelessly green. If that person has made the effort on their own to figure something out, and come to me for help, I feel obliged to offer whatever help I can.
Sometime this is not the case. What happens when you start acting as a crutch for another developer? If the other developer is not making any real effort, not trying to learn anything on their own, then I believe I am actually doing a disservice to that developer by helping them. When a developer shows up in my door with a bug and has not even bothered to step through it in the debugger, then the choice is obvious but not easy. In this situation, I need to tell the developer to go back to their desk and debug the problem. How to do this in a polite way is not always obvious.
The same is true for a developer that is truly learning a new concept, aka “on the job training.” I don’t feel it is my job to train developers. If a developer comes to me and asks, “How does Windows Presentation Foundation work?”, I would probably give them a 10 minute rundown of the technology and point out a few good books on the subject for them to use.
From a personal perspective, I have found that self-reliance has powered my understanding of software and technology. There is nothing like trying to do it yourself and failing, and failing, and then succeeding to drive home a lesson. The ancient Japanese were correct in this respect. If I have the time, I usually try to learn it on my own. The time spent usually pays off several-fold.
