Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share
7  
See this also stackoverflow.com/questions/132798/… –  pramodc84 Sep 9 '10 at 14:14
show 1 more comment

locked by Yannis Rizos 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.

90 Answers

  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.

EDIT

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

share
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. –  Steve 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
show 13 more comments
  • How to read other people's code.
  • Code doesn't exist if it is not checked in Version Control System.
share
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
1  
+1 one for version control comment. –  Tyler Egeto Oct 20 '10 at 2:08
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
show 2 more comments

Floating point computations are not precise.

share
22  
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
show 1 more comment

Don't stop learning.

share
1  
Related: Don't stop believing. –  Fishtoaster Sep 21 '10 at 21:18
3  
Related: Don't stop thinking about tomorrow. –  Slomojo 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! –  Slomojo Jan 16 '11 at 3:19
add comment

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

share
4  
DRY, yes! How I can forget? ;-) –  bigown Sep 10 '10 at 13:50
1  
You know, the funny thing about DRY is that it's repeated everywhere. :) +1 –  Billy ONeal Jan 16 '11 at 9:11
show 2 more comments

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.

share
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
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
show 2 more comments
  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.
share
5  
+1 for "don't be clever" –  Tyler Egeto Oct 20 '10 at 2:11
2  
Can you clarify "Use before reuse". I haven't heard that one before. –  Tjaart May 12 '11 at 14:32
add comment

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

share
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
show 3 more comments

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.

share
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
1  
...unless compiled with NDEBUG. –  Roger Pate Sep 27 '10 at 11:51
show 1 more comment

Every programmer should know about testing.

share
6  
It doesn't work unless you've tested it. –  J8D Sep 9 '10 at 16:13
add comment

Learn concepts. You can Google the syntax.

share
show 1 more comment

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

share
add comment

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

share
add comment

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.

share
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
show 2 more comments

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.

share
add comment

Pointers, obviously. :)

share
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
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
show 2 more comments

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.

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

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

share
add comment

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

share
add comment

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.

share
add comment

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.

share
add comment

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

share
add comment

Data structures

share
add comment

How to use Google

share
add comment

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

share
add comment

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.

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

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.

share
add comment

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