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

  1. Debugging someone else's code
  2. How to test your own code
  3. Design with security in mind
  4. How/when to comment

Recommended reading list:


Well... there are about a ten thousand things a programmer should know before they start getting productive, so this question is too generic and subjective. But a willingness to listen and learn new stuff, and a basic ability to Google is always a plus...


Try to understand the complete stack of software that will turn your ascii characters into an executable program. I.e., understand how a compiler turns your code into bytecode or assembly, understand how a CPU executes your assembly code, understand what a JIT does, understand processes, operating system calls and threads, understand how polymorphism works through vtables and method dispatch.

Of course, not to a level that you could write all that code, but at least having a pretty good idea how software works on all these levels will make you a better programmer, and also give you insight into solutions you might not have thought of before.


I've found Jeff Atwood's "Recommended Reading for Developers" post to be a good list of reading material.

Suggesting Jeff's reading list isn't a shameless attempt to get brownie points. I had the same question myself and came across the list, so decided that it would be a good place to start. Whether it's the best or most comprehensive list, I don't know. I was just browsing the technical books section at Barnes and Noble, so having a thought out list of recommended reading was a huge step forward in my effort to get better educated.


Oh, and also, don't forget to stand up for yourself, and stand your ground when you know something is not true, and someone is trying to "sell you down the river".


A good level of Math!

  • How to read an income statement
  • How to think like a user
  • How to discard features because they confuse users

Power of searching.

Even the tiniest issue might have answers in the net, if only one is willing to spend some time searching.


How to learn.


Nature gave you two ears and one mouth, so use them in that proportion.

aka; if you have a tendency to talk to much try Listening; if you have a tendency to keep quiet then speak up.


Functional programming. It'll teach you to think about how elements of your programme fit together. Terribly useful in object oriented programming.

Learn the difference between a type and a tag assigned by your compiler's type system. This will allow you to write better generic code.


Understand that (mostly) the only people who will value your code, will be another programmer. Users will only say "Hey, that's pretty, but can it be with another color?" I just had to live with that. ;)


What this strange little gizmo called recursion is.


Nobody has said this yet, but--fundamentals of computer architecture. I'm talking about things like: registers, memory access, and assembly language. Clearly you don't need to know any of this to program effectively. But if you truly want to be a professional developer, you should know the real fundamentals of the machine that you're working on. And this stuff really isn't that hard.


To dominate through powerful, verifiable generalities. Making your code as generic as possible is a priority.

Would that not be determined by what language one uses? – WolfmanDragon Dec 17 '08 at 21:30

How to format code:

  • Decide whether to use spaces or tabs while stepping. If you use spaces, set tab stop width.
  • Almost each language has it's own formatting conventions. Pay attention to these when learning new language. Later on, keep conventions always easily reachable.
  • Don't invent your own formatting rules.
  • Know how to split single, long lines into multiple. Better yet, don't write long lines.

I think there are two things every programmer should learn:

  1. Choose the right tools/languages for the right problem
  2. You are programming to solve problems

Seems obvious but I think developers tend forget these two simple things.

Choose the right tools/languages for the right problem

I know many programmer who learned one language (mostly C++) and stick with it. Regardless of the Problem they are trying to solve they do it in C++, because C++ is the ultimate language from their point of view. Even if it could be solved in with a fractional amount of effort and code in other languages.

You are programming to solve problems

I know many programmer (me too sometimes) who start implementing one feature after another because its cool to have them. But in the end many of these features are pretty useless because no one needs them. You are programming to solve a problems for people. So don't let that target get out of your sight.


How software uses memory and the processor. How to design good software. How to comment. A bunch of programming languages / technologies, to get the best from each of them and to gain point of view on the whole. How to estimate deadlines.


I've always believed that every programmer should know as much as they can about databases. Every company worth its salt has a database ... no matter what programming language you go for ... C#, VB.NET, Perl, PHP, Python, ASP, Shell Scripts .... you're almost always going to interact with a database of some sort.

I've seen companies run on MS Access, Oracle, MySQL, MS-SQL, Pervasive ... you name it ... any big company (or company who is going to pay you to do work) is going to have a database of some sort.

Knowing how to get info out of that database in a fast and reliable manner will make you look like a hero. Being able to spot an absolutely atrocious query and re-work it can make you look pretty impressive. Just think of some of the apps you've run across with horrid response times ... if it's due to a database query and you can re-write it quickly ... you've just pleased hundreds if not thousands of people in a heartbeat.

So my advice is ... learn about databases ... queries, stored procedures, indices, tables, cardinality etc. ... because in the end it's all about the data.


As a programmer we should take proper care of our eyes and fingers. Also should take small breaks often to keep mind fresh and avoid silly coding mistakes. Also take proper care of back and be sure to do daily routine of exercise as in programming profession they are high risks of putting some unwanted body weight which might be very hard to reduce down the line.


I would like to quote the following only,

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan


The negatives of their prefered language, no better way to defend your choice of language and know how to use it to its full potential better than knowing what is down sides are


I no particular order...

Learn all you can about; Algorithms, Design Patterns and Data Structures

Remember programming elegance should be striven for, but not over productivity.

Remember to use Google, heck and now


I'm not opposed to generating a list like this, but what you get is probably going to be pretty random and unstructured in comparison to the many books that cover the same topic. I suggest the following as the best places to start: The Pragmatic Programmer and Code Complete.

More specific topics like language mastery, design patterns, refactoring, etc. are also super important.

Code Complete (actually in it second version Code Complete 2) is required reading. – AnthonyWJones Sep 25 '08 at 21:39

I would say the biggest thing to keep in mind is that you are programming the system for the user and not yourself. It doesn't matter how you program the actual system, but rather it meets the needs and requirements of the user because if it meets the needs and requirements of the user they will continue to return to you for business. The opposite being a programmer who programs a system very elegantly, but does not meet the needs and requirements of the users. This is one of the primary reasons people choose Windows and Mac over Linux. Linux is fantastically programmed, but does not meet the ease of use requirement most users are looking for from an operating system.

Other things I can suggest are:

Know when to ask for help.

Know where to ask questions and how to find answers?

Learn how to logically design your code, it will save you so much time and hassle when you are coding. Look into UML designs.

Learn how to properly comment and document your code. I can suggest this for good tips on documenting and commenting your code.

Those are a few suggestions I can provide, but really remember that the user is who you are making the system for.

Some people think that others choose Windows or MacOS often because they came with their computer. – sanmai Apr 22 '10 at 23:52

Every business application programmer needs to understand data. They need to understand not only the database structure and how to efficienty get data out of it or put data into it, but they also need to understand the meaning behind the data. How is it used for decision making? What is the impact of a mistake in a report? Why do the users want the things you think are silly? What are the legal ramifications of your coding processes? If it is a finanial system, then you need to think if the way you are accessing data creates an easy path for the person who wants to commit fraud. (Never use dynamic SQL of any kind in a financial system because you have to have the rights at the table level. This makes it very very easy for someone to commit fraud.) What data needs to be protected and how should you protect it?

Or better yet, if not on application sever, no DB access for you. – Joshua Sep 16 '10 at 21:05
@joshua, assuming that you can only or should only access from the application server is big mistake, there are many other processes that hit databases that should not be going through the application server. That is one of the worst of the SQL antipatterns and generally results in poor data integrity. – HLGEM Sep 17 '10 at 13:24
There are such additional processes, and every one I've seen has and needs sufficient power as to override access settings anyway. – Joshua Sep 17 '10 at 15:25

People and communication skills. Seems like those who excel in the IT industry have the skills to "make friends and influence people". It seems trite, but communication and people skills are something you need to work at - just like learning programming skills...


The number one thing that you should know as a programmmer: how to take responsibility.

There are going to be bugs. Some of them are going to be yours. You are going to make mistakes and cost the company money. This is guaranteed and known.

When you find a bug, start from the premise that it's not someone else's code that screwed up; it's yours. Be willing to admit that out loud, and learn from it. Keep track of where you make mistakes, and learn how to cover from them; if you have lots of null pointer bugs, then start checking for them in every method. If you have bugs against the database, then start writing functional tests and verify that the queries you're running are correct. Do you have a tendency to go off and write something cool, even if it's not what the customer asked for or wanted? Then start writing out the user stories and use cases beforehand with the customer and hold yourself to them.

There are all sorts of things that you should know, but the most important thing is to know who you are.


It is OK to abandon a design or solution once it becomes clear that it is not working or is very suboptimal. This is not the same as saying all your code has to be perfect. I've seen many people spin their wheels for long periods of time on something that clearly won't work in the long run. I think learning to recognize that and change tracks is an important skill.


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