10 ms·

Productive Programming

139 points by taylorwc 16y ago

jolan 16y ago
> 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 Maybe this is it? 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
- epi0Bauqu 16y ago
  No, this comment on the blog is the closest so far to what I was talking about: rjbond3rd: "I'm mangling the quote but what I've heard is: 'Tackle a difficult problem by redefining it as a series of solved problems.'"
  - auxbuss 16y ago
    That's kind of the way mathematics expands its knowledge base. Not always, of course. But it's a fine approach. It's an application of the KISS principle.
  - garret 16y ago
    One of the most useful mental habits I know I learned from Michael Rabin: that the best way to solve a problem is often to redefine it. http://www.paulgraham.com/ideas.html http://www.paulgraham.com/ideas.html
jonpaul 16y ago
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.
- Lewisham 16y ago
  Yeah, BDD/TDD will also stop the necessity for "running the code all the time" like Gabriel espouses... what is better is to test the code all the time. Hit those green marks. Manual run-throughs of code paths is boring, to say the least. This I guess is less applicable to the web dev/machine learning domains that Gabriel operates in.
tieTYT 16y ago
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: 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
robryan 16y ago
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.
agentultra 16y ago
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. If there was one thing I could add it would be take notes. 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.
- epi0Bauqu 16y ago
  In addition, start a blog for the pieces you can make public. Blogs have so many other benefits that you should be doing one anyway (especially if you are also involved in startups). That said, writing about programming on your public blog is scary because you (usually) know that whatever topic you write on there are people who know more about that topic. You just have to get over that and learn to embrace the benefits of the conversations that ensue. Or write to a private audience.
  - bostonvaulter2 16y ago
    If you just one day decide to start a blog. Chances are it will be mostly private audience for quite a while. Of course that is dis-regarding the spammers.
briancooley 16y ago
"I also found sleeping on it often magically produces a solution in the morning." 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.
- hswolff 16y ago
  This has happened to me on the past two consecutive days (and nights). A problem that I couldn't figure out at 11pm, one that I spent at least 30 minutes pouring through Google Groups, searching through APIs, trial and error, etc...After sleeping on it the solution revealed itself to me in the morning in less than five minutes. Truly phenomenal and hugely rewarding.
  - Tyrannosaurs 16y ago
    My scariest one was dreaming a solution. I woke up about 3am absolutely clear what I'd done wrong, scribbled a note and went back to sleep. Next morning I looked at the note and it was exactly right.
    - jonknee 16y ago
      Well that's one way to increase your billable hours.
    - markkanof 16y ago
      I've done this and actually find it a bit disturbing. It's great when I can't solve a problem in the evening, get a good nights sleep, and then I am able to quickly solve the problem in the morning. Sometimes though I actually have dreams about sitting at my desk writing the code that I couldn't come up with during the day. On the one hand it's great to wake up in the morning with the solution to my coding problem. But on the other hand, I'm not sure it's healthy to have my dreams filled with the same thing that I do all day while awake. Whenever that happens I definitely make some extra time for my hobbies that don't involve computers.
  - 16y ago
xentronium 16y ago
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. 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.
- NickPollard 16y ago
  This is really true, and I think the reason is that it abstracts the problem away from the implementation, and forces you to think in 'problem-space' rather than 'implementation-space'. When I sit at my desk coding, I tend to think in detailed, code (c/c++ for me) specific ways. My thinking is constrained by how I think the code might look. When I turn off the screens and grab a pen and pad, I think in abstract, mathematical ways. Once I have a mathematical solution, it's easy to turn that into a practical implementation.
- kenjackson 16y ago
  For me a white board is a lot better. No idea why. But something about standing up in my office at the white board gets the juices flowing more than a pen and paper.
  - xentronium 16y ago
    I think there's some explanation in biomechanics and different courses of blood flow, but even more than that, whiteboard allows you to share your findings and troubles with the colleagues which is probably why you needed whiteboard in the first place :)
deleted 16y ago
[deleted]
jakevoytko 16y ago
"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 should not take long, and before you ask anyone else about it you should know exactly where the problem lies." 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.
- flatline 16y ago
  Also, for Windows/.NET: mdbg.exe is a .NET command-line debugger that can be helpful when there is a crash on a test or client system as it is portable. Also learn how to take a memory dump and analyze it with Windbg, it has saved me hours particularly when analyzing problems with complex applications like webapps running under IIS. More in terms of tools: if you are tracking down a memory leak, get a memory profiler, don't guess blindly at what is leaking. What can be done in an hour of tracing rooted objects with windbg takes five minutes with a profiler. Likewise with performance profiling.
- bjg 16y ago
  With some prior setup you can actually get automatic stack traces in C/C++ for some common crashes ( SIGSEGV, or any other signal for that matter ). http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trac...
- ecaradec 16y ago
  Under windows you can also get minidump which are a mini core dump with the current state of variables
- dgallagher 16y ago
  In Objective-C/Cocoa, I'm a big fan of using the "assert" macro's to throw exceptions if something happened in programming land which is the fault of the programmer. If the assertion is not true, an exception is thrown, and the Class/Method/Line-Number is printed to the console with the exception details. This makes certain programmer errors extremely easy to track down. For example, say you have a method that prints a string, and you "require" that all callers of the method to actually provide a string, and that it's not 0 length: - (void)printAString:(NSString *)aString { NSParameterAssert(aString || [aString length]); NSLog(@"Printing a string: %@", aString); } If |aString| was passed as nil, or 0 length, an exception would have been thrown, showing up on the console. Class, method name, and line number, along with the exception are all printed. Super easy to find! Asserts are also great to affirm that a method returns only "kosher" results: - (NSData *)loadDataFromDatabase:(NSString *)databasePath { NSData *someData = [aDataBaseClassInstance loadData:databasePath]; NSAssert1(someData, @"The |databasePath| is invalid: %@", databasePath); return someData; } If |someData| came back from 'aDataBaseClassInstance' as nil, an exception is thrown; the programmer provided a bad |databasePath| to the database file. The caller of -loadDataFromDatabase: never has to worry about being returned a nil NSData either. You can crash the app, do @try/@catch/@finally, or whatever you choose. While you have to be careful where you use NSAssert()/NSParameterAssert() (Obj-C methods) and NSCAssert()/NSCParameterAssert() (C functions), it can make it easier to stay out of debugger land.
edw519 16y ago
BIG disclaimer: I have NO formal training. 1. Tools. I generally shy away from tools. I just don't like using anything 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 want 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 very quickly; that code is already in my brain's RAM and it got there the hard way. 2. Simple Algorithms. Yes! I love this example: * EnterOrders 08/31/10 edw519 * return(); I now have a working programming - Woo hoo! You say you want more features? No problem. Let's start enhancing it. 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 & #2 above.) (Of course, this is much harder with someone else's code.) 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.) 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.
- johnrob 16y ago
  I share your aversion to debuggers. Everyone is different, and plenty of people like them - but I've always thought that they consume brain cycles that otherwise could be engaging with the code. That's why I like print(); it keeps my head in the code.
  - barrkel 16y ago
    When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy. Personally, I'm fond of configurable logging, but I'm not under any illusions; logs are like freeze-dried debug sessions with less features. Logs verbose enough to contain the relevant information can also get borderline unwieldy and time-consuming to generate and process. The compiler I work with, when hosted in the IDE, could easily produce over 100GB of log output on a complex project test case, so I usually try and keep it down to 1..2GB or so, but that often leaves out the incriminating evidence, so it takes some back and forth... And the reason I'm using log files at all is often because debugging itself gets unwieldy on large test cases.
jackowayed 16y ago
I can't think of a specific quote about breaking down programs into small steps, but you could be thinking of something from http://paulgraham.com/progbot.html http://paulgraham.com/progbot.html
- aheilbut 16y ago
  I don't know if this counts as a quote, but the term of art is "divide and conquer"
  - epi0Bauqu 16y ago
    No, neither of those are it. I saw it on HN within the last two weeks, but I couldn't find it in a reasonable amount of time.
smithbits 16y ago
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 why. 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.
wslh 16y ago
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. I can add some of my experience (since I was 8 years old?), it works in my personal framework: - 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). - 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). - 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. - When I need optimizacion/speed C/C++ is the language, but try to glue with python, ruby, COM, etc (SWIG is your friend). - Sometimes debugging is the best option, sometimes focusing in the code and try to find the bugs in my head. - Then I agree with Gabriel.
10ren 16y ago
The quote for #2 What's the simplest thing that could possibly work? http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...
deleted 16y ago
[deleted]

139 points by taylorwc 16y ago

jolan 16y ago

> 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 Maybe this is it? 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

epi0Bauqu 16y ago
No, this comment on the blog is the closest so far to what I was talking about: rjbond3rd: "I'm mangling the quote but what I've heard is: 'Tackle a difficult problem by redefining it as a series of solved problems.'"
- auxbuss 16y ago
  That's kind of the way mathematics expands its knowledge base. Not always, of course. But it's a fine approach. It's an application of the KISS principle.
- garret 16y ago
  One of the most useful mental habits I know I learned from Michael Rabin: that the best way to solve a problem is often to redefine it. http://www.paulgraham.com/ideas.html http://www.paulgraham.com/ideas.html

jonpaul 16y ago

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.

Lewisham 16y ago
Yeah, BDD/TDD will also stop the necessity for "running the code all the time" like Gabriel espouses... what is better is to test the code all the time. Hit those green marks. Manual run-throughs of code paths is boring, to say the least. This I guess is less applicable to the web dev/machine learning domains that Gabriel operates in.

tieTYT 16y ago

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: 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

robryan 16y ago

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.

agentultra 16y ago

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. If there was one thing I could add it would be take notes. 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.

epi0Bauqu 16y ago
In addition, start a blog for the pieces you can make public. Blogs have so many other benefits that you should be doing one anyway (especially if you are also involved in startups). That said, writing about programming on your public blog is scary because you (usually) know that whatever topic you write on there are people who know more about that topic. You just have to get over that and learn to embrace the benefits of the conversations that ensue. Or write to a private audience.
- bostonvaulter2 16y ago
  If you just one day decide to start a blog. Chances are it will be mostly private audience for quite a while. Of course that is dis-regarding the spammers.

briancooley 16y ago

"I also found sleeping on it often magically produces a solution in the morning." 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.

hswolff 16y ago
This has happened to me on the past two consecutive days (and nights). A problem that I couldn't figure out at 11pm, one that I spent at least 30 minutes pouring through Google Groups, searching through APIs, trial and error, etc...After sleeping on it the solution revealed itself to me in the morning in less than five minutes. Truly phenomenal and hugely rewarding.
- Tyrannosaurs 16y ago
  My scariest one was dreaming a solution. I woke up about 3am absolutely clear what I'd done wrong, scribbled a note and went back to sleep. Next morning I looked at the note and it was exactly right.
  - jonknee 16y ago
    Well that's one way to increase your billable hours.
  - markkanof 16y ago
    I've done this and actually find it a bit disturbing. It's great when I can't solve a problem in the evening, get a good nights sleep, and then I am able to quickly solve the problem in the morning. Sometimes though I actually have dreams about sitting at my desk writing the code that I couldn't come up with during the day. On the one hand it's great to wake up in the morning with the solution to my coding problem. But on the other hand, I'm not sure it's healthy to have my dreams filled with the same thing that I do all day while awake. Whenever that happens I definitely make some extra time for my hobbies that don't involve computers.
- 16y ago

xentronium 16y ago

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. 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.

NickPollard 16y ago
This is really true, and I think the reason is that it abstracts the problem away from the implementation, and forces you to think in 'problem-space' rather than 'implementation-space'. When I sit at my desk coding, I tend to think in detailed, code (c/c++ for me) specific ways. My thinking is constrained by how I think the code might look. When I turn off the screens and grab a pen and pad, I think in abstract, mathematical ways. Once I have a mathematical solution, it's easy to turn that into a practical implementation.
kenjackson 16y ago
For me a white board is a lot better. No idea why. But something about standing up in my office at the white board gets the juices flowing more than a pen and paper.
- xentronium 16y ago
  I think there's some explanation in biomechanics and different courses of blood flow, but even more than that, whiteboard allows you to share your findings and troubles with the colleagues which is probably why you needed whiteboard in the first place :)

deleted 16y ago

[deleted]

jakevoytko 16y ago

"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 should not take long, and before you ask anyone else about it you should know exactly where the problem lies." 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.

flatline 16y ago
Also, for Windows/.NET: mdbg.exe is a .NET command-line debugger that can be helpful when there is a crash on a test or client system as it is portable. Also learn how to take a memory dump and analyze it with Windbg, it has saved me hours particularly when analyzing problems with complex applications like webapps running under IIS. More in terms of tools: if you are tracking down a memory leak, get a memory profiler, don't guess blindly at what is leaking. What can be done in an hour of tracing rooted objects with windbg takes five minutes with a profiler. Likewise with performance profiling.
bjg 16y ago
With some prior setup you can actually get automatic stack traces in C/C++ for some common crashes ( SIGSEGV, or any other signal for that matter ). http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV http://www.tlug.org.za/wiki/index.php/Obtaining_a_stack_trac...
ecaradec 16y ago
Under windows you can also get minidump which are a mini core dump with the current state of variables
dgallagher 16y ago
In Objective-C/Cocoa, I'm a big fan of using the "assert" macro's to throw exceptions if something happened in programming land which is the fault of the programmer. If the assertion is not true, an exception is thrown, and the Class/Method/Line-Number is printed to the console with the exception details. This makes certain programmer errors extremely easy to track down. For example, say you have a method that prints a string, and you "require" that all callers of the method to actually provide a string, and that it's not 0 length: - (void)printAString:(NSString *)aString { NSParameterAssert(aString || [aString length]); NSLog(@"Printing a string: %@", aString); } If |aString| was passed as nil, or 0 length, an exception would have been thrown, showing up on the console. Class, method name, and line number, along with the exception are all printed. Super easy to find! Asserts are also great to affirm that a method returns only "kosher" results: - (NSData *)loadDataFromDatabase:(NSString *)databasePath { NSData *someData = [aDataBaseClassInstance loadData:databasePath]; NSAssert1(someData, @"The |databasePath| is invalid: %@", databasePath); return someData; } If |someData| came back from 'aDataBaseClassInstance' as nil, an exception is thrown; the programmer provided a bad |databasePath| to the database file. The caller of -loadDataFromDatabase: never has to worry about being returned a nil NSData either. You can crash the app, do @try/@catch/@finally, or whatever you choose. While you have to be careful where you use NSAssert()/NSParameterAssert() (Obj-C methods) and NSCAssert()/NSCParameterAssert() (C functions), it can make it easier to stay out of debugger land.

edw519 16y ago

BIG disclaimer: I have NO formal training. 1. Tools. I generally shy away from tools. I just don't like using anything 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 want 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 very quickly; that code is already in my brain's RAM and it got there the hard way. 2. Simple Algorithms. Yes! I love this example: * EnterOrders 08/31/10 edw519 * return(); I now have a working programming - Woo hoo! You say you want more features? No problem. Let's start enhancing it. 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 & #2 above.) (Of course, this is much harder with someone else's code.) 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.) 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.

johnrob 16y ago
I share your aversion to debuggers. Everyone is different, and plenty of people like them - but I've always thought that they consume brain cycles that otherwise could be engaging with the code. That's why I like print(); it keeps my head in the code.
- barrkel 16y ago
  When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy. Personally, I'm fond of configurable logging, but I'm not under any illusions; logs are like freeze-dried debug sessions with less features. Logs verbose enough to contain the relevant information can also get borderline unwieldy and time-consuming to generate and process. The compiler I work with, when hosted in the IDE, could easily produce over 100GB of log output on a complex project test case, so I usually try and keep it down to 1..2GB or so, but that often leaves out the incriminating evidence, so it takes some back and forth... And the reason I'm using log files at all is often because debugging itself gets unwieldy on large test cases.

jackowayed 16y ago

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

aheilbut 16y ago
I don't know if this counts as a quote, but the term of art is "divide and conquer"
- epi0Bauqu 16y ago
  No, neither of those are it. I saw it on HN within the last two weeks, but I couldn't find it in a reasonable amount of time.

smithbits 16y ago

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 why. 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.

wslh 16y ago

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. I can add some of my experience (since I was 8 years old?), it works in my personal framework: - 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). - 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). - 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. - When I need optimizacion/speed C/C++ is the language, but try to glue with python, ruby, COM, etc (SWIG is your friend). - Sometimes debugging is the best option, sometimes focusing in the code and try to find the bugs in my head. - Then I agree with Gabriel.

10ren 16y ago

The quote for #2 What's the simplest thing that could possibly work? http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...

deleted 16y ago

[deleted]