Recently this email went out to our technical team. I thought I'd share it un-edited.
problem solving is the number one service we provide. over the years i've developed some high level ideas about it that i've found consistently leads towards good solutions, of which there are always many. you may or may not find these ideas useful but i wanted to share them regardless: - understand the problem completely. if there is even a small lack of clarity ask questions and dig deeper. in fact, all problem solutions stem from ruthless application of just this one principle. that one small word the client or manual mentioned you were embarrassed to ask about - ask about it. that one small line in the code you didn't quite understand is likely the source of your problem, don't ignore it. - talk about the problem *out loud* with someone else. it's surprising how often framing a problem in english, outside mental constructs, will automatically suggest a solution. - never debug alone. buy someone coffee or beer. call a team member up. it's nearly always a waste of time to debug by your self. a corollary: stop whatever you are doing and help if it looks like someone else is stuck on a problem. - when there is a problem check these things, in order, *every single time*: read the code, read the manual, google it. this is the opposite of what most people do. put another way "check the highest quality sources first" because low quality sources lead to further confusion. i cannot stress strongly enough the importance of becoming a religious code reader. - never take the low road. if you think "this is a hack but..." stop and ask for help. - don't fight the future. a solution doesn't have to be complete but it should at least take one single step towards being complete. track partial solutions with #FIXME, #TODO, a card in redmine or a conversation with a co-worker. - leave turds. if your work doesn't make artifacts that people can either re-use or re-edit it's probably a band-aid and not a solution. making re-editable code is quite a bit easier than making re-usable code. avoid solutions that are neither like the plague. - don't get angry. your brain shuts down if you get mad at a problem. nothing we do has lives hinging on it so lighten up. so you trashed the data. have a laugh and then get back to recovering it. - avoid early adoption by being an early adopter. the way to understand the sweet spot between bleeding edge and crufty stability, ironically, is to ruthlessly explore and understand new solutions. you have to be an early adopter to understand when you should avoid it. FUD (fear uncertainty and doubt) should never be a motivator to avoid new and shiny, but a deep understanding of technical flaws *should be*.