Over the years you get to understand what 'works' for you and oftentimes you'll only later find that what works for 'you' often works for 'others' and is also known by 'others'. And sometimes, decades after you learn these tricks and techniques you discover that they are readily known and even recorded in print. Here are a few techniques that can improve your thought process, translating into better software products and contributions.
My first job in software engineering was at a 40-acre engineering facility, a series of buildings covered by a massive superstructure. Rain, sleet, or snow you had 40 acres of walking available, uncompromised by environmental conditions 24/7. The typical ritual was a lap around the facility after lunch seemed to evolve into a routine whenever you hit a mental block. Struggling on a design or implementation often meant figuratively, or sometimes literally, banging your head against the wall.
So there you are, trying to work out a troubling problem, frustrated and in time the frustration turns to a bit of anger. Surrounded by your office mates, your workspace is no place to lose your cool so you decide by happen-stance to take a walk, mostly just to relocate to a place you can grit your teeth and maybe cuss a bit under your breath. Your focus, still on the problem at hand, but now you're out and about thinking, venting while in motion. Like the sun pushing through the dark and stormy clouds a solution begins to emerge, first as a glimmer of possibility evolving into a full-blown solution. Now, armed with a solution you double-time it back to your desk reinvigorated and supercharged to prove it out.
Weeks pass, you find yourself in a similar situation; puzzled and frustrated, you take a walk, arrive back at your desk with a solution and implement it on your return. Again, and again, this proves to be an effective process for you, and as far as you're concerned it works exclusively for you. Later, you find your co-workers have arrived at the same process. Later in life, you learn this exercise-based thought process is well-documented by the likes of Scientific America and such.
In general, even mild exercise increases blood flow which energizes the old cerebrum and hippocampus and pull you out of your mental funk.
You spend a good portion of the day trying to solve something, but it continues to evade you. Tattered and defeated you pack up for the day, make your way to your car and begin your commute home.
You can get stuck on a small number of associations that aren't working when consciously trying to remember something. When you relax, your mind more freely and randomly associates, which gives it a chance to find a different association to the information then the fruitless ones you were consciously pushing on. A guilty pleasure comes on the radio and you proceed to car dance your way home to a Hungry Man's dinner and a cold beer. Mid-song you're hit square betweeen the eyes with a solution to your day's problem......BAM!! Like your 'take a walk' process, this happens again and again, and you're left with "why the heck does this work?".
Some say that the reason this works is that your brain is an association solving machine. Sometimes you get stuck on a small number of associations on the conscious level that won't solve your problem, but you continue to try to make them work and continue to fail. Then, your mind set free by a ridiculous radio song it is free to more freely and randomly find associations and possibly landing on a completely new thought that will solve your problem. Sometimes, the best way to solve a problem is to set it aside for a bit and 'background process it'.
You find yourself stumbling with a problem and under the prodding of your manager you reluctantly take a walk over to your coworker for an assist. You're not sure how to solve it and begin to explain the problem to your teammate, you describe the problem, you describe what you've tried and mid-sentence you stop, a new solution comes to mind and you return to your desk. The act of verbalizing the problem and your thought process opened new doors and didn't even require a contribution from your teammate. Sometimes simply talking the problem out outloud allows you to arrive at new solutions. A newly found thought trick, goes right into your personal toolbelt. In time, you later find others have arrived at the same tactic and it is often known as the 'rubber ducking' principle as described in the 'The Pragmatic Programmer'. The audience of your verbal mind-dumping can be a teammate, your bartender, a reluctant spouse/partner/date, your pet or your given choice of any given inanimate object.
I've never known a software engineer that likes authoring documentation, perhaps they exist and are but elusive, or perhaps they simply don't exist in this universe. Despite a general distaste of writing documentation, we tend to recognize its value and necessity to quality software and will do so reluctantly. I find, despite not liking doing it, that the sheer act of writing stuff down betters your design. You are forced to describe your architecture, your classes, their responsibilities, their interactions and you find yourself internally challenging your design 'why did i do this', 'what if i had done that', 'what are this particular classes responsibilities'. In doing so, you leave with a list of refactoring opportunities and/or changes to the design and make the time to incorporate them, ending with a more robust and sophisticated product. I find this likely a simple extension on verbalization, as it gives you the same benefits.
These are likely but a few tips and tricks for supercharging your thought process. To my knowledge these tricks appear to be pretty well-known, some well-established and documented, some passed along via developer palaver over drinks. My gift to you.
This post was originally published here