People are either cut out to be programmers or they’re not. How to know, what to do if you’re not, and where to go from there is a huge issue and not the subject of discussion. But one of the signs of a good programmer is good programming instincts. The right instincts can save hours of work and provide creative solutions to even the most difficult problems; and “gut feelings” in programming are not something you should ignore lightly.
One of the first thing Computer Science teachers drill into the heads of their students is that it’s important to map everything out beforehand. Design the algorithm. Draw the UML diagrams. Decide the entire flow of data and the relationships between everything before you even touch the IDE. While this is integral advice for anything above a small-complexity project, there is an exception: if you have a gut feeling, follow it.
For instance, the other day I sat down to write a simulator for a MIPS datacache, with different replacement policies. “Ideally,” the planning procedure would have involved designing the sequence diagram, a flowchart detailing the method used by the cache to determine expired entries, and generally-speaking a lot of time down the hole just visualizing what happens beforehand.
While mulling things over for a minute or two in my head to gather my thoughts, I found myself scribbling three phrases on the PostIt note in front of me:
- Access times -> FIFO
- Access times defined by unique tag
- Reading memory == dequeue item
These were spur-of-the-moment analyses of the caching procedure. Just thinking about the caching methodology brought these ideas to mind, with no particular “thinking through” of type. Looking back at them, I couldn’t (instantaneously) recall why I felt that access times should be removed FIFO from the data structure on read, but I figured it must have made sense on some subconscious level and plowed ahead right into the code.
In the end, the code worked, the project was done far quicker than originally imagined, and I had time to kill post this article.
Any good programmer you talk to will have a similar experience to share. The only reason I trusted my instinct in the first place on this matter (keeping in mind that the implementation of “random” algorithms can be a huge timesink if they don’t actually work) was because trusting my coding instincts has generally proved to be the right thing in the past – this is simply the most recent example.
Of course, every once in a while an impromptu idea may not be perfect; indeed, it’s possible that they’re fatally flawed. Whether it’s because the problem itself wasn’t initially understood or simply a matter of arriving to the wrong (hasty) conclusion, mistakes can (and have) occur. But it’s important to bear in mind the ratio of brilliant ideas to failures – most good programmers I’ve spoken to reaffirm that it’s a very workable hit-miss ratio.
Certainly programming by instinct has its drawbacks. For instance, these “strokes of brilliance” make up the majority of what we refer to – in retrospect – as quick and dirty solutions. There’s a time and a place for using them; and being unable to figure that part out can end up hurting you and your program. Typically speaking, using the first thought that occurs to you when structuring your program (what classes, how they interact with one another, etc.) isn’t such a good idea. Things like this need to be refined non-stop (until you get that warm, fuzzy feeling when you look at your code ;-) and quick solutions won’t help you there.
It’s usually within individual functions when you need to get something done based on the state of one or more other objects that instincts prove handy. To put it another way: when the code you’re working needs some measure of creativity and out-of-the-box thinking, don’t ever pass up on a gut feeling. Programming gives experience and insight, much of it subconscious. Patterns and ideas may leap out at you in ways that aren’t immediately obvious, but even if we don’t fully comprehend how the ideas came into existence it doesn’t mean they don’t have a substantial amount of intricate logic and supporting foundation to back them.
The next time an idea flashes into existence, like the proverbial lightbulb flickering on above your head, take a minute to appreciate its glow. Realize that you’re lucky to have such inexplicable moments, and trust them to take you and your code to the next level.
While the idea that programmers should trust their instincts is correct, your assumption that a programmer either has good instincts or not is deeply flawed.
These instincts are not in your genes – they’re the result of a lot of experience of doing things “the slow way”, internalising the processes that you are applying analytically, and then letting your subconscious do that work for you once it is familiar enough with it.
I think you will find a quick read of the basics of the Dreyfus learning model of interest. Here’s a link:
http://www.codinghorror.com/blog/archives/000203.html
Enjoy!
Daniel
Thanks for the link, Daniel – it’s one Jeff’s few that I hadn’t had the pleasure of reading before.
If you read the article with these concepts in a sort of “reverse” psychological manner (the kind of people that become “Level 5” verses the kind of people that remain stuck at “Level 1”), then the two points converge into one.
I guess it would have been more prudent to phrase it differently, i.e. if these instincts haven’t been developed after much effort, then one may not be cut out to be a true programmer…
As for the genes – it could be argued that the instinct comes as an accumulative result of both the genes and the experience; especially if you assume that the “traits” of a good programmer are coded in one’s genes and that only good programmers will – in good time, as you so kindly pointed out – experience these instincts.
“People are either cut out to be programmers or they’re not.”
Must feel great to live in a world _that_ simple eh?
That’s not my opinion, but rather one shared by people far wiser and more experienced than myself.
If the instinct turns out to be wrong and things get delayed, the Project Manager gleefully rubs his/her hands and gets ready to .. well, use your imagination 😉
Hum the art of programming could be as the sport. You can practice for years any sport, but there are people that simple are cut out to be good at that sport, they got a natural talent. So when you got that natural talent to program, but you also need to develop that instinc through practice.
Stumbled on this, and I feel that there are multiple types of “programmer” each with different strengths. It’s way more complicated that “you’re cut out for it” or “you’re not”, some are math people who can’t design an extensible/maintainable solution to save their lives, some are more visually oriented who are great at design but suck at math. Most are in between, and may have other strengths. Experience also plays a big part in how well one does the work.
As far as going with a gut feeling on a small solution like the one you worked up, sure, ok, but it sounds like it was a pretty small project to begin with. I guess in that instance you don’t need design very much at all. That however, should be implicit, and really doesn’t require a blog entry to explain how clever you are. If I’m wrong and it was a big solution that you just don’t think will be subject to the forces of change, then I think you’re giving some pretty risky advice.
The people who can actually competently design and defend a cohesive solution, in my experience, are pretty rare. I’d much rather hear about your experiences trying to accomplish that.