Productive Programming

<i>"When approaching debugging, I first find out where the problem is, i.e. the exact line of code or config file or whatever that is causing the problem. That </i>should not take long<i>, and before you ask anyone else about it you should know exactly where the problem lies."</i><p>For crashes: Get backtraces! Knowing the line and the state of the callstack makes many common errors trivial to fix. Some languages (Java, Python) are helpful and generate them automatically. Others (C, C++) require a debugger. I've seen lots of programmers ignore gdb or Visual Studio and spend minutes with printf() looking for the exact line of a crash. Code crashes all the time. Dealing with it methodically and effectively will add minutes - or even hours - to your day.

One of the most productive programming techniques that I have used (it's saved my ass) is to make sure that most of my code is unit tested. In the short-term you will feel like you're moving much slower. In the long term, it'll pay dividends.

Productivity is a topic too complicated to put into a few sentences but there is one tip I'd like to contribute: paper and pen are underrated.<p>There were awful lot of tasks I tried to achieve via pure coding and rewriting / rewiring blocks here and there. All they actually needed was some analysis on paper.

BIG disclaimer: I have NO formal training.<p>1. Tools. I generally shy away from tools. I just don't like using <i>anything</i> that makes me more productive when I'm programming. I prefer to type out every line of code, occasionally cutting and pasting from the same program or something similar from the past, but not very often. I <i>want</i> the writing of code to be painstakingly slow and deliberate. Why? Because productivity is not the objective. Becoming "one" with my project is. I may not start as fast as others, but that doesn't matter. It's not how fast you start, it's how soon you deliver a quality product. Like memorizing a speech, cranking out the code by hand makes it "firmware" in my brain. It's not unusual for me to crank out 300 lines of code and then be able to reenter them on another machine from memory. So when it comes time to debug, refactor, enhance, or rework, those cycles go <i>very</i> quickly; that code is already in my brain's RAM and it got there the hard way.<p>2. Simple Algorithms. Yes! I love this example:<p><pre><code> * EnterOrders 08/31/10 edw519 * return(); </code></pre> I now have a working programming - Woo hoo! You say you want more features? No problem. Let's start enhancing it.<p>3. Debugging. I don't. I've seen 25 different debuggers and I hate them all. Print() is my friend, especially beyond the right hand margin. Better yet, write code that doesn't need to be debugged (See #1 &#38; #2 above.) (Of course, this is much harder with <i>someone else's</i> code.)<p>4. References. Don't need no stinkin' manual. I have become extremely adept at about 4% of what's available to me, but that 4% accomplishes 98% of what I want to do. (OK, I'll refer to a manual when I need something from the other 96%, but that doesn't happen too often.)<p>Nice post, Gabriel. Got my juices flowing. We could talk about all kinds of other things too, like variable naming, how to iterate and branch, and never typing the same line of code twice, but this was a nice starting subset.

"I also found sleeping on it often magically produces a solution in the morning."<p>I think this is a great reason to take a nap in the middle of the day if your environment is conducive to it. It works for me as long as the code is the top thing on my mind when I fall asleep.

I wouldn't say this is an article on productivity so much as an approach to learning. I find a lot of auto-didact programmers learned this way. The compiler is a great TA after-all.<p>If there was one thing I could add it would be <i>take notes</i>. If you can explain to someone else the "whys" and "hows" of your solution to a problem, you've got it down pat. Sometimes we get something to work by googling a quick solution, but we forget to try and understand that solution. This doesn't serve us well. Taking notes helps me to submlimate what I learn on the job into hard-referenceable tomes of knowledge.

The article mentioned the dangers of clever code and asked for a particular quote he couldn't remember. I couldn't help but be reminded of this one:<p>Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan

A bad habit I can get into is thinking about a feature in terms of all it's parts and getting mentally stuck on starting trying to put the whole thing together from the start. When as the advice in the article gives it is much better to focus on getting the critical path of a feature working. The mental block of thinking about the whole can easily lead to procrastination for me, something I am trying to avoid.

It well depends of the problem domain, sometimes productive programming is about best algorithms, for example if you develop a software playing chess you can't left it for later improvements.<p>I can add some of my experience (since I was 8 years old?), it works in my personal framework:<p>- Hybrid languages/technologies: for some solutions I need to use jython to develop in python + java libraries that you don't found in other languages (i.e: htmlunit).<p>- I have always an interactive console opened to test stuff while using an editor.Sometimes the language doesn't have a good interactive interpreter, my preference is using python (if using .net, then ironpython, if using java, the jython, etc).<p>- Since I do a lot of research for customers, research and proof of concept are first in the list to reduce the real risk in the project.<p>- When I need optimizacion/speed C/C++ is the language, but try to glue with python, ruby, COM, etc (SWIG is your friend).<p>- Sometimes debugging is the best option, sometimes focusing in the code and try to find the bugs in my head.<p>- Then I agree with Gabriel.

I appreciate the call to find the exact line of code that is causing the problem. I've done a fair number of code reviews where there was a bug, and it was "fixed", but no one knew <i>why</i>. The developer had simply kept changing things until the problem seemed to go away. That would mark the bug as closed, but it always seemed to show up again some months later in a new guise. These days I'm a terrible nuisance as I always want to know why the bug was happening. In my experience it's not enough to "fix" the bug you really do need to understand why it was happening in the first place, which is something that not all programmers do.

&#62; I initially try to accomplish X in the simplest way possible by breaking it down into trivial steps. I know there is a famous programming quote that pertains to this process, but I can't find it right now<p>Maybe this is it?<p>A program should be light and agile, its subroutines connected like a strings of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little nor too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity. -- The Tao of Programming

I can't think of a specific quote about breaking down programs into small steps, but you could be thinking of something from <a href="http://paulgraham.com/progbot.html" rel="nofollow">http://paulgraham.com/progbot.html</a>

The quote for #2<p><i>What's the simplest thing that could possibly work?</i> <a href="http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html" rel="nofollow">http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...</a>