Inc published a great article a while back which enumerates four secrets of great critical thinkers. I find the concepts in this article are totally relevant to designing software or software architecture even though that's not what the article is about. So I’m adding my programmer's take on these four secrets:
Slow Down
One of my main gripes about meetings is making a decision on the spot. At least for me, my best thinking occurs somewhere else after the fact. I need time to consider the implications and possibly see alternatives before I can be certain it’s the correct decision. So to make the most effective decisions, postpone immediate decisions as often as possible. Make the time to explore the alternatives.
Break from the Pack
This is the basis of one of the main arguments by Ted Neward in his keynote at Codemash 2012 that I already covered. The “best practices” are found in books, on the web, in corporate documents. Generally, these can get the job done. But I doubt it’s always the best or right solution to a problem. It’s certainly the safest. If that’s the goal, then go that way. But in business we are always looking for an advantage, and I doubt the best practice gives you the advantage. More likely, it’s a starting point which you should use to find the best solution. Slow down and think about how the best practice solves the problem and if that is really the solution you need.
Encourage Disagreement
I have long used this as a metric in my interview process. I want team members who will express their opinions. Usually the best answer to a problem is not the idea of a single person, but an amalgamation of ideas or compromise between multiple ideas. If no one can disagree with the boss/tech lead/manager then you might as well adopt only the best practices and call it done.
Engage with Maverics
I think this one is a little harder in an enterprise environment, since often a big corporation is not the home for maverics. I think what you need to do here is actively engage with people whose viewpoints are not aligned with yours. People who think differently about a problem may provide you with some insight you may have missed or not considered properly. I have always thought of code reviews as a source for this. I approach code reviews as a way to see someone else’s problem solving at work. I’m not interested in telling them how they did it wrong, but seeing what they did well and adapt that to my problem solving toolkit.
I try to revisit these topics and remind myself to practice these concepts as I do my work, it's too easy to get lost in the moment writing code. I hope you can do the same.
Top comments (0)