Please, stay on technical issues, avoid behavior, cultural, career or political issues.

locked by yannis Mar 13 '12 at 20:52

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

  • 7
    See this also… – pramodc84 Sep 9 '10 at 14:14
  • This sort of question really annoys me. It can only spring from the mind of someone who sees the world in terms of black & white. Not every programmer has the same job and if it is the smallest common denominator that you are looking for, the answers below show that you just end up with a list of pet peeves. – Diego Deberdt Jun 24 '11 at 18:22

90 Answers 90

  1. The bug is in your code, not the compiler or the runtime libraries.

  2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

  3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

  4. Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.


Yes, my point #1 is overstated. Even the best engineered application platforms do have their share of bugs, and some of the less well engineered ones are rife with them. But even so, you should always suspect your code first, and only start blaming compiler / library bugs when you have clear evidence that your code is not at fault.

Back in the days when I did C / C++ development, I remember cases where supposed optimizer "bugs" turned out to be a due to me / some other programmer having done things that the language spec says have undefined results. This applies even for supposedly safe languages like Java; e.g. take a long hard look at the Java memory model (JLS chapter 17).

  • 17
    I prefer to say "The bug is probably in your code", since I've come across bugs in runtime libraries a few times. I've yet to run into a compiler bug though. +1 anyway. – Chinmay Kanchi Sep 9 '10 at 16:24
  • 29
    If you've never found a bona fide bug in the compiler, you're not nearly adventurous enough with your coding. ;) – Mason Wheeler Sep 9 '10 at 22:57
  • 8
    @Chinmay, @spudd86, @Mason - yes ... and I've also found my share of compiler and library bugs in my 30+ years of programming. But in my experience, 99+% of bugs turn out to be (at least in part) the fault of my code. My answer deliberately overstates this to get across the point that you should always suspect your code first. – Stephen C Sep 9 '10 at 23:06
  • 5
    I don't get the irrational fear that people have with multi-threaded programming. I suspect the people who perpetuate this view, don't program much multi-threaded code. It's just not that hard. +1 for everything else though. – Steven Evers Sep 13 '10 at 17:19
  • 4
    If you're working on the compiler, then the bug is probably in both your code and the compiler ;) – Legooolas Sep 16 '10 at 12:19
  • How to read other people's code.
  • Code doesn't exist if it is not checked in Version Control System.
  • 8
    +10000 if I could for the version control comment. History and change logging are absolutely indispensable and are the reason you should put everything in version control right from the start. – Legooolas Sep 16 '10 at 12:20
  • 2
    ...and the repository has been synchronized to at least one other location. Important with DVCS, but also with centralized VCS. – Roger Pate Sep 27 '10 at 11:37
  • For that matter, code doesn't exist unless a work item exists which authorizes the developer to write it. – Jesse C. Slicer Dec 13 '10 at 21:46
  • 2
    I will plus one for learning how to read other people's code. It's more difficult that most of us realize, but an essential part of successful programming. – bogeymin Dec 24 '10 at 13:10
  • plus one for learning how to read other people's code. – itsaboutcode Jul 6 '11 at 5:09

Floating point computations are not precise.

  • 22
  • If anyone doesn't know what I'm talking about, read @Adam's link. It's an excellent summary of the pitfalls of floating point computation. – Chinmay Kanchi Sep 9 '10 at 16:53
  • 1
    And if they don't know they can be amongst the set of people who ask on stackoverflow daily. – Brian R. Bondy Sep 9 '10 at 23:20
  • 1
    @Brian: So true. I wish there was a way to identify questions explained by floating point arithmetic. You could create a Stack App that displays a different floating point question every day! – Adam Paynter Sep 17 '10 at 16:50

Don't stop learning.

  • 1
    Related: Don't stop believing. – Fishtoaster Sep 21 '10 at 21:18
  • 3
    Related: Don't stop thinking about tomorrow. – ocodo Dec 13 '10 at 21:21
  • 7
    Related: Don't stop the music. – adamk Dec 24 '10 at 15:47
  • 1
    Related: Don't stop movin'! It's your life, keep on movin', get it right, you gotta get it right! – ocodo Jan 16 '11 at 3:19

That the #1 thing you can do to increase the quality and maintainability of your code is REDUCE DUPLICATION.

  • 4
    DRY, yes! How I can forget? ;-) – Maniero Sep 10 '10 at 13:50
  • This is so important I answered with it again. – Roger Pate Sep 27 '10 at 11:51
  • I would rather say: REDUCE CONDITIONALS. Each while/if/for is a potential bug. – zvrba Nov 20 '10 at 7:35
  • 1
    You know, the funny thing about DRY is that it's repeated everywhere. :) +1 – Billy ONeal Jan 16 '11 at 9:11

Troubleshooting and Debugging Skills

They hardly spend any time on this topic in any of the programming courses I took, and in my experience it is one of the biggest determinants of how productive a programmer is. Like it or not, you spend a lot more time in the maintenance phase of your app than the new development phase.

I've worked with soooooo many programmers who debug by randomly changing things with no strategy for finding the problem whatsoever. I've had this conversation dozens of times.

Other Programmer: I think we should try to see if it fixes it.
Me: Okay, assuming that does fix it. What does that tell you about where the source of the problem is?
Other Programmer: I don't know, but we have to try something.

  • 2
    I was about to post this. So much of a programmer's job is fixing bugs, and a lot of people tend to be incapable of doing so (especially in others' code). – Dov Sep 9 '10 at 18:30
  • +1 I went from javascript/php to C# and fell in love with stepping through code. I wish that dynamically typed languages could do a much better job of this. – Evan Plaice Sep 15 '10 at 11:54
  • Another weird behaviour is the programmer insisting that every part of his program is correct while the result if faulty. "-You don't need to print the array on the console to check if it's sorted because the line above is array.sort()." "-Well... you know, it's not working. There must be something wrong somewhere. You can't just defend your code at this point!" – gawi Sep 27 '10 at 18:59
  • 2
    I think the point of debugging to validate your assumptions across your program. Sometimes, you need to go fishing for some clues. This has to be done systematically. It it perfectly valid to try something that might tell you something new. I do it often. – gawi Sep 27 '10 at 19:04
  1. Don't be clever; be clear.
  2. Use before reuse.
  3. Names matter.
  4. A function does 1 thing and does it well.
  5. Small is better than big.
  • 2
    Can you clarify "Use before reuse". I haven't heard that one before. – Tjaart May 12 '11 at 14:32

The basics. Currently programmers learn technologies not concepts. It's wrong.

  • Yes and no. You sound like every prof I ever had in university... all of whom never made a lick of software in their entire life. Knowledge, without skills is useless in our profession. – Steven Evers Sep 13 '10 at 17:25
  • 4
    +1, so true. Yes, this is something ivory tower types like to say, but it doesn't make it any less true for the rest of us in the trenches. – MAK Sep 16 '10 at 11:23
  • 2
    Basics like spelling? Its wrong should be it's wrong, for example. – Konerak Sep 16 '10 at 11:46
  • 2
    No, basics like doesn't care about a typo but care about programming issues. – clrod Sep 18 '10 at 0:27
  • 5
    It's easy to learn the steps to do something and often hard to find out when you should use it and more importantly when you could use it but shouldn't. Textbooks are particularly bad at showing the how but not the why (and why not). – HLGEM Sep 24 '10 at 18:35

Every programmer should know that he's putting assumptions in code all the time, e.g. "this number will be positive and finite", "this code will be able to connect to the server all the time within a blink of an eye".

And he should know that he should prepare for when those assumptions break.

  • 6
    specifically state those with assert() -- everywhere. assert() will help you document your assumptions and save you when you are wrong. – Dustin Sep 15 '10 at 18:42
  • @Dustin +1 There's no way you can just remember all your assumptions - document them programmatically and you'll be told exactly when they turn out to be wrong assumptions. – Skilldrick Sep 23 '10 at 11:05
  • 1
    ...unless compiled with NDEBUG. – Roger Pate Sep 27 '10 at 11:51

Every programmer should know about testing.

  • 6
    It doesn't work unless you've tested it. – JD Frias Sep 9 '10 at 16:13

Learn concepts. You can Google the syntax.

  • Good in theory, except Google is terrible for finding specific syntax: Searching for terms like "object reference" or "this" given a gazillion results, and searching for idioms like "$?" give no results at all. – l0b0 Jan 17 '11 at 10:06

Critical and logical thinking. you can't do anything good without it.

Unit Testing. This is a great way to codify your assumptions on how the code is to be used.

That's it's harder than you think.

While it's easy(ish) to put something together that works when used normally, coping with erroneous input, all the edge and corner cases, possible failure modes etc. is time consuming and will probably be the hardest part of the job.

Then you've got to make the application look good too.

  • 3
    i think this is the source of the old saying '90% of the work takes 90% of the time. the last 10% takes the other 90% of the time' – GSto Sep 9 '10 at 14:41
  • I think a lot of people tend to consistently under-estimate the complexity. "How hard can X be?" - famous last words :/ – Roman Starkov Sep 21 '10 at 23:20
  • @GSto I don't want to work 180% of the time, 100% is just fine by me! – adamk Dec 24 '10 at 15:53

Domain knowledge. The spec is never 100%; knowing the actual domain with which you are developing for will ALWAYS increase the quality of the product.

Big O notation and its implications.

Some useful references

  • I find Big O notation is one of the main things most computer scientists have a problem with (myself included) – Richard Dec 13 '10 at 19:42

Pointers, obviously. :)

  • 3
    Pointers are only really necessary in a subset of languages for a small subset of tasks. For most tasks, you can (and should be able to) program as if the concept of a pointer didn't exist. – Chinmay Kanchi Sep 9 '10 at 16:29
  • 14
    @Chinay Kanchi No. Pointers should be understood by everyone. – alternative Sep 9 '10 at 20:04
  • 5
    That really depends on what you mean by pointer. If you mean C-style pointers that you can manipulate (which is what I assumed), I would argue that a Java/C#/Python programmer doesn't need to know anything about them. If you mean pointer as in Java's "references", i.e., a pointer that can't be fiddled with, then yes, some knowledge of them is necessary, if only to prevent you from slipping up. – Chinmay Kanchi Sep 9 '10 at 23:25
  • @mathepic You'll be shaken to your very core if you were to learn how many CS students graduate each year that don't understand the first thing about pointers. If I hadn't gone out of my way to take placements each summer I wouldn't have even been taught about pointers in C or references in Java... – Mike B Sep 13 '10 at 14:54
  • 5
    @Chinmay: A Python/Java/C# programmer that doesn't understand the concept of pointers is lost. L = [[]] * 2; L[0].append(42) Different languages use different names, but indirection is essential everywhere. – Roger Pate Sep 27 '10 at 11:55

Code Complete 2 - cover to cover

  • you really should know this before you accept money to program. If you find thing you did not know in it, consider either a career change or an intense period of self directed study to get you across it all. And then apologize to your co-workers. And it only covers the programming basics. – Tim Williscroft Oct 7 '10 at 0:58

Data is more important than code.

If your data is smart, the code can be dumb.

Dumb code is easy to understand. So is smart data.

Almost every algorithmic grief I've ever had has been due to data being in the wrong place or abused of its true meaning. If your data has meaning put that meaning into the type system.

  • 2
    You had me all the way until you said "type system." – Roger Pate Sep 27 '10 at 11:54

Which language and environment is most suitable for the job. And it's isn't always your favourite.

Divide and Conquer. It's usually the best way to solve any type of practical problem from scheduling to debugging.

True skill is reflected in the ability to execute a simple design well, not in the ability to make a complicated design work at all.

This skill comes from greater mastery of the fundamentals, not in mastery of the arcane. A high-caliber programmer isn't defined by their ability to code what others cannot (using higher level functions, advanced functional programming, what-have-you) but rather in their ability to refine perfectly mundane coding. Choosing the appropriate decomposition of functionality between classes; building in robustness; using defensive programming techniques; and using patterns and names that lead to greater self-documentation, these are the bread and butter of high-caliber programming.

Writing good code that you, or someone else, can come back to in a week a month or a year and understand how to use, modify, enhance, or extend that code is crucial. It saves you time and mental effort. It greases the wheels of productivity by removing roadblocks that you would have stumbled over before (perhaps interrupting your train of thought, or perhaps taking hours or days of effort away from other work, etc.) It makes it easier to concentrate on the hard problems, and sometimes it makes the hard problems go away.

In a word: elegance. Every class, every method, every condition, every block, every variable name: strive for elegance.

Never blame on the user what could be fixed with a cleaner user experience or better documentation. Often, programmers automatically assume the user is an idiot who can't do anything right, when the problem is a poor overall experience or lack of communication. Programs are meant to be used, and to treat the user with contempt is to miss the point of programming in the first place.

Every programmer should know how to use the debugger, and know how to use it well.

Data structures

How to use Google

Short-circuit evaluation, althought it's one of the first thing they teach you about boolean operators.

How to accurately estimate how much time a feature is going to take to implement. More importantly, how to convey you're not bullshitting when you submit that estimate.

  • 2
    or learn how to guestimate well and convey you're not guestimating... ;) – Billy Coover Sep 16 '10 at 6:27

Coding style matters:

  • consistent indentation matters,
  • consistent use of white space (e.g. around operators) matters,
  • consistent placement of { } s matters,
  • well chosen identifiers matter,
  • etc.

... and good design matters.

Ideally, the programmer learns these things before (or during) his/her first code review. In the worst case, the programmer learns them when the boss tells him/her to make some non-trivial changes to some horrible code in a hurry.

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