35

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.

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

32 Answers 32

Reset to default
1
2
69

A rubber duck. Yes, really.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

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

Improve this answer
8
  • 7
    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
    Commented Mar 11, 2011 at 19:32
  • 1
    You laugh. I had a coworker actually have a rubber duck on her desk.
    – Berin Loritsch
    Commented Mar 11, 2011 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?
    – user8709
    Commented Mar 11, 2011 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
    Commented Mar 12, 2011 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
    Commented Mar 13, 2011 at 0:56
41

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
9
  • 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
    Commented Mar 11, 2011 at 21:15
  • 3
    The Russians used a pencil.
    – Job
    Commented Mar 11, 2011 at 22:03
  • @Job Hah, I still use a bottle of ink! (... Well, only for calligraphy, but still. :) )
    – Mateen Ulhaq
    Commented Mar 12, 2011 at 0:45
  • What about Tablet PCs?
    – Mateen Ulhaq
    Commented Mar 12, 2011 at 0:50
  • 1
    @Job: …and vodka!
    – Spoike
    Commented May 4, 2011 at 10:43
39

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.

Improve this answer
8
  • 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
    Commented Mar 11, 2011 at 19:02
  • Yeah, I have thought about actually learning a profiling tool, but never got to that
    – Anto
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 at 19:06
  • 2
    @Mason: Cute XML.
    – Mike Dunlavey
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 at 19:41
37

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
5
  • 8
    Remember that Regular Expressions aren't a Swiss army knife even if they are great when applied correctly.
    – Anto
    Commented Mar 11, 2011 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.
    – user8709
    Commented Mar 11, 2011 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
    Commented Mar 12, 2011 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
    Commented Mar 12, 2011 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
    Commented Mar 13, 2011 at 7:53
24

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.

Improve this answer
1
  • Good team mates can never be over valued. Most software and hardware can.
    – Anonymous Type
    Commented Mar 12, 2011 at 4:38
19

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
6
  • 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
    Commented Mar 11, 2011 at 18:52
  • 12
    I'm sorry, but Google underestimated? At the very least Google is overestimated :)
    – eestein
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 at 19:06
  • 3
    @Adam Crossland: 75% is being kind. I think it's higher than that.
    – S.Lott
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 at 19:56
16

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.

Improve this answer
3
  • 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
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 at 20:43
14

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.

Improve this answer
6
  • 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.
    Commented Mar 11, 2011 at 19:23
  • @Matthieu M That's also a good point. Many people forget the easy ways for it to help you out.
    – kemiller2002
    Commented Mar 11, 2011 at 19:44
  • 3
    Every compiler warning is a precious gift. Don't ignore them! Ask for more! -Werror should be mandatory.
    – Kristof Provost
    Commented Mar 11, 2011 at 20:18
  • @Kristof: -pedantic -Wall -Wextra -Werror... though it can get difficult to build anything then :p
    – Matthieu M.
    Commented Mar 13, 2011 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
    Commented Apr 15, 2011 at 13:03
10

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

Improve this answer
10
  • 4
    I have rendered mine mostly unserviceable on occasion.
    – David Thornley
    Commented Mar 11, 2011 at 18:43
  • 3
    "more or less forgotten" :-S
    – user1249
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 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
    Commented Mar 11, 2011 at 19:19
  • 1
    Some comments got me to change my opinion, +1 :)
    – Anto
    Commented Mar 11, 2011 at 19:25
9

Good old:

print

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
1
  • 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
    Commented Mar 13, 2011 at 6:08
8

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.

Improve this answer
3
  • 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
    Commented Mar 12, 2011 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
    Commented Mar 13, 2011 at 2:55
  • @Billy Use python. Spaghetti problem solved :)
    – Evan Plaice
    Commented Mar 18, 2011 at 17:27
7

Pen and whiteboard.

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

Improve this answer
3
  • 3
    Duplicate answer - programmers.stackexchange.com/questions/57148/…
    – ChrisF ♦
    Commented Mar 11, 2011 at 22:06
  • May be a duplicate answer, but it earns my separate up vote for whiteboard.
    – Carson Myers
    Commented Mar 12, 2011 at 4:21
  • Hmm, pretty sure it wasn't a duplicate when I created it, very strange. I'll change it to Pen and Whiteboard.
    – Andy Lowry
    Commented Mar 12, 2011 at 14:55
6

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

Improve this answer
0
5

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

Improve this answer
4
  • 1
    I'm not sure they are underestimated...
    – Anto
    Commented Mar 11, 2011 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
    Commented Mar 12, 2011 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
    Commented Mar 12, 2011 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
    Commented Mar 12, 2011 at 17:34
4

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
4

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
4

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.

Improve this answer
1
  • I like writing code generators, not the easiest thing to get right, but oh so useful.
    – Zachary K
    Commented Mar 13, 2011 at 16:35
3

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
3

Formal Methods.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

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
1
  • 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
    Commented Mar 11, 2011 at 20:39
3

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
3

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
0
3

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

Improve this answer
2
  • +1, but not really underestimated anymore
    – MAK
    Commented Mar 12, 2011 at 18:44
  • 4
    maybe even overestimated, or at least overused
    – Anto
    Commented Mar 12, 2011 at 21:19
3

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.

Improve this answer
0
2

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.

Improve this answer
1
  • Agreed. But unfortunately simple, yet efficient, tools like this are often underappreciated.
    – Peter Mortensen
    Commented Jun 3, 2014 at 19:50
2

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
  • 2
    Both underestimated and also underimplemented.
    – Anonymous Type
    Commented Mar 12, 2011 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
    Commented Mar 12, 2011 at 14:08
2

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
2

Curiosity

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
2 
Ctrl + C    
Ctrl + V

Saved countless hours worldwide!

Improve this answer
1

Tail

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
1
  • Mac OS X is a UNIX system. No need to mention it seperately.
    – user4595
    Commented Sep 12, 2011 at 20:03
0

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
1
2

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