Learning to ask for help
Everybody should take pride in the work they do. Software developers spend a lot of time studying, training and practicing. So when we hit a tough problem we tend to grind on it. We’ll google, search MSDN, try bits of sample code, everything. Well, everything except ask people nearby for help.
I’m not entirely clear on the reasoning for this behavior. I’m not sure if it is a pride thing or something else. In many ways I lean toward something else. Specifically, people (everybody in general) don’t keep track of time. How many times have you set out to do something that will only take 5 minutes only to discover it took all day?
How do you stop the cycle so you don’t waste time? You can’t really learn everything there is to learn so studying harder isn’t the answer. Carrying around a stop watch won’t work either because how do you know you need to start it?
I don’t really think you can avoid the small time sinks we run in to through the course of the day. Fifteen minutes here, forty five there. It does add up, but it is generally manageable and good PMs are able to factor this in to their schedules. It’s the big two or three day sink that needs to be avoided. Things like status reports, daily scrums and time boxes can help bring them to light. Others on your team may not be able to solve the problem for you, but by raising the awareness of the problem you help set expectations and avoid surprises.
I hate being on a project that looks like it is on time but then during one meeting you discover that a critical feature isn’t done and needs about three weeks of work to be completed. My favorite line goes something like “yeah, we slipped 6months on the schedule last night”. Literally, you got to a status meeting on Monday and everything is good to go. On Tuesday the new architect starts asking questions and you discover that what appeared to be a safe and sane project is in fact way off schedule or worse – can’t even be measured.
Being up front about problems you are having on a project is a safer bet (but somewhat uncomfortable at times) than delaying notification. Yeah, it sucks telling your client that you are having a hard time with a project. It sucks worse losing the client because the project because nobody confronted the problems to get the project on track.