Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

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

Regardless of programming language(s) or operating system(s) used or the environment they develop for, what should every programmer know?

Some background:

I'm interested in becoming the best programmer I can. As part of this process I'm trying to understand what I don't know and would benefit me a lot if I did. While there are loads of lists around along the lines of "n things every [insert programming language] developer should know", I have yet to find anything similar which isn't limited to a specific language.

I also expect this information to be of interest and benefit to others.


migrated from Jul 10 '11 at 10:20

This question came from our site for professional and enthusiast programmers.

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.

174 Answers 174

Every programmer should know how to accompany code with good documentation.

I find that code that is well documented (liberal use of embedded comments) is easier to maintain and upgrade.

When a programmer embeds their rationale for an implementation (inline to the code), I can spend less time on figuring it out and more time on the task at hand whether it is adding features or debugging other related issues.


Every programmer is a programmer. Then there are designers and analysts, too. If analysis phase has been skipped, no one should blame the programmer if he programs wrong things...

Of course small projects might have only one developer, but you get the point.

Sounds like you too still live in the wonderful world of waterfall? ;) – Bjorn Reppen Sep 28 '08 at 21:16

Along the swallow your pride lines - learn how to divorce your ideas in heartbeat if a better idea is proposed.

  • Be humble to learn new things.
  • Participate in language community.

Mathematics. Programming is just an frighteningly tiny subset of the language of mathematics.

NO! Programming is a subset of Logic! Mathematics is a language, a highly useful language that allows us to communicate values, but still just a language. – WolfmanDragon Dec 17 '08 at 21:34

Besides knowing how to do the cool, the boiler plate, the borning, and the redundant. Know and learn one thing, you are replacable. Once you get over that, you'll job will be easier. Know that even though there is "internet time", somethings which are worth doing also take time, and cannot be accomplished in five minutes, no matter what your boss thinks.

  • Too learn from your mistakes.
  • Regex - Which I still don't know :-(
  • Version Control.
  • Where to stop with performance optimisations.

Know and understand the theory and the algorithms. Anyone could learn to code, but only few becomes those who can teach to code.


Figure things out on your own. Or, at least, make a real, honest attempt to do figure the problem out on your own. You'll learn more than you ever will getting the answer from someone else, and it'll be a lot more rewarding.


Programming is making computers

  1) Get input  
  2) Process input data  
  3) Generate output

Computers are dumb but real fast..

And without electricty 'or a relevant energy source' there is no spoon..


every programmer has to be resource-hungry - has to constantly learn and adapt .


My list:

  1. Attach importance to and know well the Science and Logic of programming more than the technology that you are working on!
  2. Empathise with the end user and do not give him something just to show that you are proficient in some technique or technology. i.e. do not force a rocket to him when what he needs is actually a bicycle.

User's satisfaction matters, code quality not that much

I, respectfully, disagree. User's satisfaction definitely matters. However, code quality matters as well. Heck, if I can't keep my code in order, I may not be able to satisfy my users. – JasCav Dec 3 '09 at 20:58
I understand your point. What I really meant (and perhaps I should have elaborated more) is that even smelly code can satisfy users if the application solves their problems. Every developer should aim to build good code, but user satisfaction must come in first place. A beautifully coded application that doesn't solve user's problem on time is not that useful, is it? – Daniel Melo Feb 23 '10 at 2:59
No but it's much more fun to work on :) – the_drow Jul 8 '10 at 8:25
to understand
to think
to write well
to optemize
..and to cheer up :D

Just be a good team player - always accept feedback as a suggestion for improvement and not destructive criticism.


How to deal with frustrating people without losing your temper.

When the manager drops a list of items on your desk and says he expects them to be done by friday; When the DBA runs a data load script twice; When the sysadmin deploys the wrong version of your code; When the user asks you to explain how it works, again -- That's when you need the be able to handle it with grace. Because you're going to have to work with all these people, and it will go much better if they don't think you're a nasty jerk, no matter how wrong they are.

  • You will never know as much as you think you do. Even after a few years in the business, you will continue to encounter people who know more than you do about your personal area of expertise. Don't worry about it and keep studying and learning.

  • You will never have learned enough languages or architectures or paradigms or buzzwords. Because once you think you know it all, someone will invent a new (insert favorite technology here) and you will be out of touch again.

  • You will be that old fuddy duddy soon enough. Cut him/her some slack and assume that once upon a time, he/she was in your shoes.

"Don't worry about it?" I don't think that's very good advice. "Do something about it, don't worry about it" might be more to the point. – Dan Rosenstark Apr 21 '10 at 19:32
OK, I can buy that. I should have written it better. – MJB Apr 21 '10 at 19:34
I once heard that if someone used the word 'paradigm,' they didn't actually know what they were talking about. – dclowd9901 Apr 22 '10 at 15:39
I can't tell if I have been insulted or not. – MJB Apr 23 '10 at 12:25

Think outside the box!


The real world may not run the same as things did when you were in school. Accept that how a company runs its software development isn't going to match exactly what the theory was that you were taught.

Take some time to understand how things run in a new organization. This applies to everyone but grads may hopefully find it more sobering than others.


The skills needed to get a development job and the skills needed to be successful at a development job are often typically two very different things. In making career choices, prefer places where they are the same.

Conversely, in most jobs 95% of your data structure / algorithm needs are served by library classes. 95% of your time will be wasted by dealing with unmaintainable code written by people who are ninjas at CS but have the engineering skills of a lobotomized beaver.

I rather like the phrase " engineering skills of a lobotomized beaver" – HLGEM Apr 22 '10 at 20:24

How a veterinary doctor does his job!

While funny, very unrelated. – the_drow Jul 8 '10 at 8:24

Today I came across this book. It is a very nice book and a good recap of all the best practices.

97 Things Every Programmer Should Know


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