Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

See this also… – pramodc84 Sep 9 '10 at 14:14

90 Answers 90

User mistakes are not; they are usability mistakes:

  • Dangerous functionality should be undoable, not just warned about. Here's looking at rm, which still doesn't work with the trash can.
  • Do the least harmful thing if the user breaks (ESC, Ctrl-C). Ideally, the system should be in the same state as before running the command. rm, again.
  • Harmful options should be far away from harmless ones. Right-clicking a file in the GNOME Trash can shows "Delete Permanently" directly adjacent to "Restore" :(

Not to pick specifically on GNU Tools or GNOME, but these were the easiest examples to come up with.


That knowing the answer to this question doesn't make you a programmer


Speaking of commercial software dev here... Obviously might not apply to a DOD security system or a hedge fund quant.

  • Focus on what works, not on what's clever, KISS.
  • Keep the 80/20 rule in mind, and don't spend all your time trying to please/sell the minority.
  • Take a course in data structures / algorithms.
  • Test, test, test.
  • Don't go mucking about in code that is in production, and currently working. Unless you have excessive cash flow and no new ideas. Then it's fine.
  • The vast majority of your time will be spent sorting through the cruft, and not solving interesting programming problems. Unless you're interviewing, in which case people only want to see how you solve interesting programming problems.

Every programmer should bind FindNextSelected and FindPreviousSelected actions (visual studio) to keyboard keys (preferrably F4 and F2). You get two things from that:

  1. Faster way to navigate between different points of variable/function/substring usage (faster than with "Find all references")
  2. Possibility to diff things inside one document. By jumping back and forward while searching some substring you can see the differences between different locations. No need to use Winmerge when need to compare parts of the same document.

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.


Be Master of Something, but Be Aware of Everything !!!!


Don't stop learning.

Related: Don't stop believing. – Fishtoaster Sep 21 '10 at 21:18
Related: Don't stop thinking about tomorrow. – Slomojo Dec 13 '10 at 21:21
Related: Don't stop the music. – adamk Dec 24 '10 at 15:47
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

Know your OS/Platform before you start coding.

If you code Windows/Linux/Android/iOS etc. start by learning the OS. If you target something else such as Web the same goes there.


Documentation is very important. More so if you are building something from scratch. It helps to document your ideas before writing any code.

I learned this the hard way.


When you have to distribute an application or put a website into production outside the confines of your company, everything that you thought didn't matter, does.


Can't believe this hasn't been mentioned

Every programmer worth is salt needs to be able to produce world ready software.

By this I mean following basic internationalization principles such as externalizing all strings etc.

I can't believe how many times I've seen hard-coded English strings or dialogs with truncated strings etc. when the product has been translated.


That whatever programs do, more than telling a machine how to do a work, they are a most unambiguous way of showing fellow human beings how to do a work.


When someone asks you to build something, remember: they are also asking you to maintain it. Possibly, forever.


Software Licensing Basics

  • The difference between a "viral" copyleft license (GPL) when compared to closed-source-friendly Apache, and non-viral MS-PL/MS-RL.

  • When you should use LGPL, and when not to.

  • License compatibility. For example, you may link a modern Apache license'd library to a GPLv3 code, but not GPL 1 or 2.

  • If you own the source code in it's entirety, you may publish it under as many (or few) licenses as you wish.

Note to S.O. community:
Please feel free to edit this answer as you see fit... mainly for information not suited for the comments section below.



A programmer ought to know how the statements they write are evaluated. a(line.of(code) is aSequenceOf(evaluations)) and if you don't understand what that line looks like after each step of its evaluation, you are going to be extremely restricted as a programmer in your ability to take advantage of language features.

I'm not just talking about the basic

if (bool == false):
    return true
    return false

which of course can just be replaced by return !bool.

I'm also referring to the ability to understand your language to the point where you can come up with something like this:

string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));    

When I first saw a statement like that it blew my mind a little bit; it hadn't occurred to me I could leverage the for loop in such a way. The person who wrote that statement more fully understood the possibilities available to them - they saw more open doors than I, which gave them more freedom and power in their ability to design code.

Now, whether it's good code is an issue - whether any of those doors should be opened - that's up to debate. It remains that with great power comes great responsibility.


It stands in a few letters, really:

Ok, I'm over-simplifying, but basically if you are pretty autodidact, never stop to learn, and are a bit of a perfectionist, you should have the basis to become a good programmer.

Anything beyond that would be more specific to particular roles and technologies.


every programmer should have a firm grounding in software engineering, and also system analysis/design and information systems concepts. this way if they are called upon to contribute substantially to systems analysis/design and/or information architecture, they will be in a position of knowledge + opionion..whereas normally it seems to be just personal opinion that usually simply stems from personal preferences instead of best problem solution. software engineering is a bit harder to measure, but the pre-requisite knowledge is available out there, and at suitable university degree courses where they teach more than just how to cobble a bit of code together. anyway this is not meant to be negative because the main spirit is but improvement, but then i've worked with some people who have no IT knowledge whatsoever or there's the single minded "script kiddies" that code and re-code (and only in their language of choice) and only see every problem as a repeat of previously applied solutions (by that coder.) so i would much prefer if programmers concentrated more on the larger picture in terms of software engineering (SSADM) and looked at problems as opportunities to do better for the client.


Some of these have been posted already, but here is my list:

  • Build to the requirements, don't add things you don't need, especially if you "think" you will. If you need it later, add it then.
  • How to use Google search. Don't bother your co-worker, until you've looked.
  • Don't be clever.
  • It's not done till it's meets ALL the requirements, tested, documented, and checked into SVN.
  • Proper coding standards, eg: naming conventions

"Hello world" is not a complete application, as there is no demonstrated / programmatic assertion that the output is in fact "Hello world". Code is not complete until it has been unit tested.


There are some very good suggestions here, but I'm surprised no one has mentioned the excellent series of articles by Ulrich Drepper: What every programmer should know about memory.


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.

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

Program with maintainability in mind.


Order of execution.

You'd be amazed, when talking to programmers vs the people who've never seen or touched code or the pretend programmers*, the thing they don't get is the order of execution. If you meet someone who can't pick up on the control structures, get this idea in their head first. You'll find that they learn faster after that.

*yes, those people who are able to get jobs as programmers, but when you ask them the simplest technical question they go brain fart.. I think we've all met one of those.


Hexadecimal notation. Also bit fields -- ANDing, ORing (inclusive and exclusive), complementing (1's and 2's), bit shifting.


They need to know about the power of closures and start using them.


If the system works and you change it and it stops working, the change you made is what broke it, even if that cannot possibly be the case.


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


If something can go wrong , then it will . Assume the worst case


write code for people!

no more magic number!

don't write all code in one line!


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