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.<\/p>\n
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.<\/p>\n
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<\/em> what happens beforehand.<\/p>\n <\/p>\n 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<\/a>:<\/p>\n 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<\/em> 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.<\/p>\n In the end, the code worked, the project was done far quicker than originally imagined, and I had time to 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.<\/p>\n 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<\/em> of brilliant ideas to failures – most good programmers I’ve spoken to reaffirm that it’s a very workable hit-miss ratio.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading \n
kill<\/strike> post this article.<\/p>\n