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.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

32 Answers
32

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

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 EvansMar 11 '11 at 19:32

1

You laugh. I had a coworker actually have a rubber duck on her desk.
–
Berin LoritschMar 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?
–
Steve314Mar 11 '11 at 21:25

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 WirzeniusMar 12 '11 at 16:59

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.

@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 ;) ).
–
FrustratedWithFormsDesignerMar 11 '11 at 19:41

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.

Remember that Regular Expressions aren't a Swiss army knife even if they are great when applied correctly.
–
AntoMar 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.
–
Steve314Mar 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.
–
JasonTrueMar 12 '11 at 5:07

3

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).
–
MAKMar 12 '11 at 18:41

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.

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).
–
FrustratedWithFormsDesignerMar 11 '11 at 18:52

12

I'm sorry, but Google underestimated? At the very least Google is overestimated :)
–
eesteinMar 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 CrosslandMar 11 '11 at 19:06

@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.
–
eesteinMar 11 '11 at 19:56

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.

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.

@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

I have rendered mine mostly unserviceable on occasion.
–
David ThornleyMar 11 '11 at 18:43

3

"more or less forgotten" :-S
–
user1249Mar 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.
–
jnevelsonMar 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.
–
asoundmoveMar 11 '11 at 19:19

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.

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 ONealMar 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 SehgalMar 13 '11 at 2:55

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.
–
RookMar 12 '11 at 3:08

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.

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.

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.

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.

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

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.

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.

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.

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.