We have many great tools which helps a lot when programming, such as good programmers text editors, IDEs, debuggers, version control systems etc. Some of the tools are more or less "must have" tools for getting the job done (e.g. compilers).

There are still always tools which do help a lot, but still don't get so much attention, for various reasons, for instance, when they were released, they were ahead of their time and now are more or less forgotten.

What type of programming tool do you think is the most underestimated one? Motivate your answer.

| |
  • 3
    Our brains? - - – Trufa Mar 12 '11 at 1:55
  • Okay, who wants to add the Lisp entry? *grin* – Mark C Mar 12 '11 at 4:10

32 Answers 32


A rubber duck. Yes, really.


Rubber duck debugging, rubber ducking, and the rubber duckie test are informal terms used in software engineering to refer to a method of debugging code. The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

To use this process, a programmer explains code to an inanimate object, such as a rubber duck, with the expectation that upon reaching a piece of incorrect code and trying to explain it, the programmer will notice the error. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent...

  • 6
    I do this all the time with my husband. As a tech support guy with just a smattering of programming ability, he understands about 60% of what I say but forces me to explain the 40% that I don't understand as well. The number of occasions where it works is really quite impressive. – Ethel Evans Mar 11 '11 at 19:32
  • 1
    You laugh. I had a coworker actually have a rubber duck on her desk. – Berin Loritsch Mar 11 '11 at 20:51
  • 57
    I tried it, but my rubber duck couldn't seem to focus on the problem. Where can I find a properly qualified rubber duck with a genuine interest in programming? – Steve314 Mar 11 '11 at 21:25
  • 3
    I use my journal for this. I sometimes have quite lengthy discussions with myself on it. I wish I could make myself understand what I mean, sometimes. Writing this into a journal sometimes helps a lot later on, when I wonder what the idiot who wrote the code I'm working on was thinking. – Lars Wirzenius Mar 12 '11 at 16:59
  • 1
    @Steve: Japanese researchers are working on it, but I don't think they're anywhere close: youtube.com/watch?v=3g-yrjh58ms – Rei Miyasaka Mar 13 '11 at 0:56

Pen and notebook.

  1. Works without electricity.
  2. Portable.
  3. Doodle on/in when bored in meetings
  4. Store useful information.
  5. If it is written down, people attach more importance to it.
  6. Others can read it and learn.
| improve this answer | |
  • In the old days of big corporations, engineers and technicians would be given blank engineering notebooks where they would write all those things we tend to stuff in various files on our hard drives. When the notebooks were filled, they would be sent off to a secure and fire-safe repository. If anyone needed to have access to those notes they could check out the notebooks. – oosterwal Mar 11 '11 at 21:15
  • 3
    The Russians used a pencil. – Job Mar 11 '11 at 22:03
  • @Job Hah, I still use a bottle of ink! (... Well, only for calligraphy, but still. :) ) – Mateen Ulhaq Mar 12 '11 at 0:45
  • What about Tablet PCs? – Mateen Ulhaq Mar 12 '11 at 0:50
  • 1
    @Job: …and vodka! – Spoike May 4 '11 at 10:43

Diff tools seem to be underused when comparing log outputs or data in flat text files. Or maybe that's just a niche? I seem to find it very useful and helpful for debugging to compare huge logs of program executions and pinpoint one or two details that changed.

Performance profiling tools are also very good to have, especially when you hit a critical bottelneck, but it seems very few people are familiar with them (and I admit myself to a degree in this category).

Good XML tools are vital - if you're working with XML files more than a dozen lines or multiples schemas. Sometimes you need more than just basic syntax highlighting other editors provide. Also when working with XML, learning XSL can be very useful. Many times I see what could be done in a simple XSL transform done in many lines in the application's code. Though to clarify: I am not suggesting that XML itself is an "underestimated programming tool"; I am suggesting that the value of good XML editors is underestimated, from what I've seen.

  • 1
    ++ Absolutely diff is underappreciated. On the subject of profiling, you're not alone in thinking they must be useful, but you yourself don't know how. Check this. – Mike Dunlavey Mar 11 '11 at 19:02
  • Yeah, I have thought about actually learning a profiling tool, but never got to that – Anto Mar 11 '11 at 19:05
  • 23
    +1 for profiling, +1 for diff tools, -1 for XML tools. Some people, when presented with a problem, think "I know, I'll use XML." <Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening> – Mason Wheeler Mar 11 '11 at 19:06
  • 2
    @Mason: Cute XML. – Mike Dunlavey Mar 11 '11 at 19:35
  • 10
    @Mason Wheeler: I didn't suggest XML as a tool to solve problems, I suggested Good XML Tools - when you have to work with XML, make sure you have an editor/tool that is very good at it. Something that can execute Xpath queries, schema validation, transformation, value vs. structure comparison (a special kind of diff tool I guess) etc... Simple editors with highlighting just can't cut it when things get messy - they often make things worse (btw I like your XML code ;) ). – FrustratedWithFormsDesigner Mar 11 '11 at 19:41

Regular Expressions

They are just so useful. They help when searching through log files, parsing text etc.. They are just extremely useful.

I find it strange how many people I know that don't ever use them because there is a bit of a learning curve associated with them. A lot of times I see people do things the hard way (Note: before regex I did things the hard way) when a simple regex could get it down quickly.

| improve this answer | |
  • 8
    Remember that Regular Expressions aren't a Swiss army knife even if they are great when applied correctly. – Anto Mar 11 '11 at 19:22
  • 10
    Extremely useful - but often abused, leading to cryptic unmaintainable code. The old "now you have two problems" saying does have some basis in reality. – Steve314 Mar 11 '11 at 21:32
  • 4
    RegExes are a Swiss army knife: An adequate tool for lots of quick jobs, though probably not the right tool for building an entire house. – JasonTrue Mar 12 '11 at 5:07
  • 4
    Hmm, for some reason I always got the impression regex was far from being underestimated. Too often I see people reaching for a regex where a simple split/for-loop would suffice or when regexes are simply not the answer (e.g. parsing xml/html). – MAK Mar 12 '11 at 18:41
  • I've seen both phenomena: Regex? That stuff is unreadable/slow/insert pejorative here and "What's the best way to parse (insert completely non-regular grammar) with one regex?" – JasonTrue Mar 13 '11 at 7:53

Your teammates. When you are off on some hot-shot idea and forget to incorporate your team, you'll never hear their concerns or ideas for why it won't work or for why it could be even better.

I say this, because it's easy to think that programming is some antisocial thing people do off in corners with their brilliant ideas. People who think this underestimate the value of teams and their teammates in helping make ideas/projects sink/swim.

  • Good team mates can never be over valued. Most software and hardware can. – Anonymous Type Mar 12 '11 at 4:38

Google. There is are very few problems that haven't already been solved and documented. A well-tuned Google query can save everyone a lot of time.

| improve this answer | |
  • 13
    A good tool but I'm not sure I'd call it underestimated, at least not anymore (maybe I would have agreed 9 or 10 years ago). – FrustratedWithFormsDesigner Mar 11 '11 at 18:52
  • 12
    I'm sorry, but Google underestimated? At the very least Google is overestimated :) – eestein Mar 11 '11 at 18:58
  • 2
    I know, I know! But my rationale for saying that it is underestimated is one that I suspect you will agree with: at least 75% of the questions that are asked on StackOverflow are easily answerable with Google, yes? Clearly, it is to some degree underestimated if that many people are not using it. If my rationale is flawed, I will delete my answer. – Adam Crossland Mar 11 '11 at 19:06
  • 3
    @Adam Crossland: 75% is being kind. I think it's higher than that. – S.Lott Mar 11 '11 at 19:26
  • 1
    @adam @s.lott so I guess the point is that Google is not used properly. With that I agree. So many questions could be answered (wouldn't need to be asked) if people knew how to Google properly. Regards. – eestein Mar 11 '11 at 19:56

Far and away the most underappreciated tool for finding "bottlenecks" is Ctrl + C or the "Pause" button, in a debugger.

Check the last paragraph of this post, and this post, and this post, for starters.

So many times I see/hear of people saying "The program's too slow! What can I do about it? I tried a profiler (if they did), but I don't understand what it says. Anybody got any guesses? Help!" Well, guesses are just that. What I've always done, and others have too, is get it going, interrupt it, and examine the call stack. If the problem is really bad, bingo, it's right in front of you. If the problem is only mild, you do it several times. Anything that shows up on more than one sample, that you can avoid, is a bottleneck you can fix.

Yeah, this is downvote-bait, but it works.

  • One shouldn't underestimate blunt instruments. Clearly this isn't always the right answer, but it can be. Call it a first order approximation, to be refined by a real profiler if needed. – Kristof Provost Mar 11 '11 at 20:17
  • @Kristof: It's tempting to think so, and there are problems it can't handle, and there are cases where the samples are not easy to get, but profilers can't handle those cases either, except for a certain kind, like Zoom, and even then they're not actually better in the sense of leading you right to the problem. – Mike Dunlavey Mar 11 '11 at 20:36
  • @Kristof: Here's the kind of problem random-pausing is not good at - where if you take a snapshot in time and study it, you can't tell the reason for what it's doing. Example: message-driven processing, where you can't tell where the message was sent from or why or how often. Another example: asynchronous protocols, where messages are being exchanged, and it seems like we're always waiting for the other guy. For synchronous processing, profilers may measure better, but random-pausing is better at finding. – Mike Dunlavey Mar 11 '11 at 20:43

What type of programming tool do you think is the most underestimated one? Motivate your answer.

The compiler.

Most people don't take time to understand what their compiler of choice does. They just feel that it makes the code into a runnable program and that is as far as they go. On most modern ones, there are several configurations that you can feed into it make it do what you need it to. Here's an example, I bet half the devs in your office have no idea how to set the warning as errors level (assuming it actually has one). What options to do you have to output debug symbols? Which optimizations (or what level of) do you want it to make. The list goes on.

  • 3
    @Kevin: and I would add ways to write code to actually have the compiler perform checks for you (for statically typed languages). Most devs use off the shelf types (such as string) to represent any kind of info, where they could define simple but incompatible types for unrelated data... and have the compiler they didn't mess up when passing arguments. – Matthieu M. Mar 11 '11 at 19:23
  • @Matthieu M That's also a good point. Many people forget the easy ways for it to help you out. – kemiller2002 Mar 11 '11 at 19:44
  • 3
    Every compiler warning is a precious gift. Don't ignore them! Ask for more! -Werror should be mandatory. – Kristof Provost Mar 11 '11 at 20:18
  • @Kristof: -pedantic -Wall -Wextra -Werror... though it can get difficult to build anything then :p – Matthieu M. Mar 13 '11 at 12:42
  • Maybe it's just me, but if "half of the devs" don't know what about debug symbols" is not an exaggeration, it's quite daunting. – kizzx2 Apr 15 '11 at 13:03

Your brain. Other tools wouldn't have much meaning without it.

| improve this answer | |
  • 4
    I have rendered mine mostly unserviceable on occasion. – David Thornley Mar 11 '11 at 18:43
  • 3
    "more or less forgotten" :-S – user1249 Mar 11 '11 at 18:44
  • 5
    I would say it's underestimated. Too many people are always looking for shortcuts so that they don't need to think. There is no replacement for common sense and logic, and tools just cannot replace that. – jnevelson Mar 11 '11 at 18:52
  • 2
    I agree with Jonathan, the brain is often underestimated. In fact too many programmers rely on the few tricks they know instead of stepping outside the box and occasionally writing a bespoke (cheap and dirty, throw away class) test case and test tool to investigate the problem at hand. I have on many occasions given developpers the means to go beyond their state of thinking and solve their problems with not much more than a few questions. – asoundmove Mar 11 '11 at 19:19
  • 1
    Some comments got me to change my opinion, +1 :) – Anto Mar 11 '11 at 19:25

Good old:


Sometimes a debugger or profiler or a UML flow diagram is useful. And sometimes they make you crazy. I always find myself falling back on using print statements (or trace or NSLog or what-have-you) just to make sure my code is doing what I think it's doing when I think it's doing it.

| improve this answer | |
  • I think this depends on the language and debugger. The kinds of debuggers offered by most decent IDEs nowadays for popular languages let you do things a hell a lot easier than print statements. – Billy ONeal Mar 13 '11 at 6:08

Plain old scripts... no matter how many next generation languages we develop we still heavily rely on scripts also most of the day to day tasks can be achieved by writing a few line of scripts.

  • 1
    See.. I would disagree with this one. Yes, scripts can automate some tasks. But often they're taken far beyond the point of sense to the point where they just become a big pike of spaghetti. – Billy ONeal Mar 12 '11 at 16:49
  • 1
    True , big scripts are gruesome to look at and one might use perl or python for it. Though they are still great at getting small jobs done. – Gaurav Sehgal Mar 13 '11 at 2:55
  • @Billy Use python. Spaghetti problem solved :) – Evan Plaice Mar 18 '11 at 17:27

Pen and whiteboard.

You can't beat low tech when trying to explain something.


ack. It's like grep -r, but it's designed for seaching through your source code.


Perl and other scripting languages. Great for tasks that are just a bit too complicated for GUI tools like Agent Ransack.

| improve this answer | |
  • 1
    I'm not sure they are underestimated... – Anto Mar 11 '11 at 21:33
  • 3
    Definitely underestimated ... expecially Perl. It is a lang. very well designed with the keep things simple motto ... as such, it's priceless for quick tasks which just need to get done. – Rook Mar 12 '11 at 3:08
  • @Rook: I'm not sure how a language with more than 100 operators can be considered "simple". Useful, possibly. But not "simple". – Billy ONeal Mar 12 '11 at 16:50
  • @Billy - Simple does not exclude powerful. I find calculators simple. I don't know what half of the 300 functions on mine does, but that doesn't reduce its simplicity. – Rook Mar 12 '11 at 17:34

Keyboard shortcuts that allow quick, frequent and safe refactoring. Learning how to extract (or inline etc) variables, methods, constants, or classes at the press of some keys fundamentally changed how I code. You will only refactor frequently (i.e. enough) when the cost is minimal, so making these shortcuts second nature is essential to writing and maintaining good code as far as I'm concerned.

So generally, use good tools (IDE/editor) and learn how to get the most of the features they provide.

Unit testing and TDD comes next, to keep your code testable and prevent fear of refactoring.

Use these and you'll easily move towards writing correct maintainable code that conforms to the DRY principle and is self documenting.

| improve this answer | |

Unit testing offers the following benefits:

  • Developers become the first clients of the code. The quicker a bug is caught, the less expensive it is to fix. Bugs may be caught before a build, install, or deployment.
  • Testing changes your perspective on the code. Is the design clear? Does it handle corner cases?
  • The Hawthorne Effect will improve quality, simply by announcing that a team is publishing quality/testing metrics.
  • Even if tests aren't checked into source control, they can be a great way to explore and learn new terrain.
  • A high probability of fewer bugs!
| improve this answer | |

Code generators

Code generators can create a large amount of efficient and bug-free code from a simple definition. ORM type uses are the most obvious for creating data access classes, but there's many more potential uses.

Code generating support seems to still be in its infancy both from a programmer and framework point of view, but I believe it's something we'll see more and more of. In .NET you can start dabbling with the CodeDOM stuff.

  • I like writing code generators, not the easiest thing to get right, but oh so useful. – Zachary K Mar 13 '11 at 16:35

I use AgentRansack heavily. It is a tremendous help searching through thousands of files very quickly. It has saved me so much time, but I don't know of a lot of programmers that know about or use it.

| improve this answer | |

Formal Methods.



It's hard to overstate their importance. Every loop and every if statement starts out as an idea that requires some kind of "proof". Most programmers do this proof most of the time in their heads. You ask what the if statement does and they can articulate -- soundly and logically -- what the choices are and why the choices are complete, consistent, and exclusive.

But some just seem to guess randomly. They need more help and formal methods could be the kind of help they need.

It's just algebra (and calculus) for code. Nothing too complex or sophisticated.

| improve this answer | |
  • I've found them frequently useful to get the simple stuff right so I can rely on it while debugging the more complicated stuff. My experience is that formal methods pretty well eliminate subtle bugs, leaving only the glaring obvious ones that are easily caught with testing. – David Thornley Mar 11 '11 at 20:39

Physical design patterns like leaving the chair for a quick jog in the sunlight and fresh air keep our brains running at peak awesomeness.

| improve this answer | |

Well it's Half Life 2 (insert your favourite game here). If i got a problem I can't solve I just quit and start playing with my favourite game and suddenly the solution pops in my mind. So to be honest it is not a game or something like that but doing something else. I often see people sitting on a problem for hours without solving it and all they should do is putting their brain offline for a short period.

| improve this answer | |

Stack Overflow - quick expert help when you are stuck

question and answer site for professional and enthusiast programmers. It's built and run by you as part of the Stack Exchange network of Q&A sites. With your help, we're working together to build a library of detailed answers to every question about programming...

  • +1, but not really underestimated anymore – MAK Mar 12 '11 at 18:44
  • 4
    maybe even overestimated, or at least overused – Anto Mar 12 '11 at 21:19

I think it is Notepad/TextPad/simple text edit programs. Everyone has a time when they need a quick fix that does not require opening an IDE and need just a quick edit. And all computers have some kind of simple text editing program.


Asserts and a good alwaysAssert() function. IMHO these are more important than unit tests, because unit tests can only find bugs in the specific cases you thought to test. If the same programmer writes the code and the tests, he/she will probably miss the same edge cases in both. Furthermore, sometimes unit testing is impractical because the environment in which the component functions and/or the data it operates on is too complicated to come up with a contrived test case for.

The beauty of asserts lies in their ability to document assumptions and test them on non-contrived inputs. If any of these assumptions are wrong, your code fails loudly instead of "working" but producing subtly incorrect results. It also fails closer to the root of the problem than it would without the asserts. In practice, if you explicitly state enough assumptions about a piece of code and all of these assumptions are correct then the code is usually correct.

One common gripe about asserts is that they can be turned off. IMHO every language or standard library should have an alwaysAssert() function or rough equivalent that does the same thing as assert but can't be turned off. This can be used for checking assumptions in non-performance critical areas of code, where the benefits of turning off asserts are negligible.

  • Agreed. But unfortunately simple, yet efficient, tools like this are often underappreciated. – Peter Mortensen Jun 3 '14 at 19:50

The F1 key. - Useful for programs you don't know and for programs you are working on. (Assuming that it's a large application.)

Powerful to filter out issues were a users report bugs based on their interpretation of how the software should work. Of course, it could be that the design itself was flawed. But that's another story.

| improve this answer | |
  • 2
    Both underestimated and also underimplemented. – Anonymous Type Mar 12 '11 at 4:45
  • Very underestimated by developers of the application you are using right now; as such the help contains little to no useful information. – poke Mar 12 '11 at 14:08

Various UNIX core utilities, but primarily find and occasionally grep or ed. The ability to find things in deep nests of files is invaluable, particularly when you suddenly inherit a codebase and have to fix it. Even if said code is well-documented, you will probably have to hunt, and a strong understanding of find kills it.

| improve this answer | |


Call it the "Riddle of programming." What is a tool compared to the person that wields it? The desire to know how and why something does or does not work expands one's knowledge more than any specific tool and that is true beyond programming.

| improve this answer | |
Ctrl + C    
Ctrl + V

Saved countless hours worldwide!

| improve this answer | |


Tail can be used to monitor program log output file in realtime. It has been of great help when developing for systems that doesn't provide others means of reading the log.

Example programs are;

| improve this answer | |
  • Mac OS X is a UNIX system. No need to mention it seperately. – rightfold Sep 12 '11 at 20:03

I kludged together a Perl call graph generator once. It was extremely useful, but fell over hard on non-procedural code or out-of-file routines.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.