Monday, 17 November 2008

Ask, but not all at once.

Asking questions can get you answers, but every time you interrupt a fellow coder, it can break their flow. Some programmers don't skip a beat, others are made angry, you'll have to figure out which ones are which. Oh, and they can change depending on what they're working on, how interested they are, and how long they've been doing it.

So, in case of an unanswered question, first try google, then try

If you still don't have an answer, or it's game specific, formulate an e-mail. Sometimes, writing the e-mail can focus you long enough to answer the question yourself. It's called rubber ducking, and it's the process by which you can access details of a problem by trying to talk it out with a unresponsive entity. These can be great tools for solving simple, sometimes complex, but not presently obvious problems.

Personally, I'm big on flow. So is Joel Spolsky, Tom DeMarco, and Steve McConnel. This is why once a question is asked of me, I tend to go off long and hard into the wherefores and whys, because I've already lost any flow I had, so there's no benefit in being terse or concise. I find that I'd prefer to teach something useful if I can, because hopefully it will reduce the number of future flow breakers.

Flow is what makes my day. I can have a day full of pain, but if I get into flow, it makes it all okay. Flow is when you're no longer working a job, but doing your thing. Flow is a musician playing music that makes you feel. Flow is an artist unable to describe how he's painting what he's painting. Flow is using your highly tuned skills to concentrate on too many different aspects of the same thing to think about stupid stuff like phones, e-mails, food, or going to the toilet. Flow is the magical extended moment of pure creativity usually only experienced by the highly skilled artist. It's what makes my job worth doing.

No comments: