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

"Learn a new language every year, and read at least 3 or 4 books a year" Steve McConnel.

More your learn, faster you'll learn.


How to use paper and pen (or something equivalent) to write and explain code...


Use or license someone else's code when it makes financial sense to do so. In other words, be aware of the tradeoff between time and money. If it's cheaper to license a library rather than spend time rolling your own, do so.

or even trolling your own :)))) – Andrei Rinea Oct 18 '10 at 15:38

Always be willing to learn from your mistakes.


I'll add my own bits:

  • Basic understanding of Software Development Life Cycle, generally the phases of requirements gathering, analysis and design, implementation, testing and maintenance.

  • Know how you learn - Do you prefer visual, oral, or some other method of learning new material? Also, what kind of reference look ups do you usually do to learn something?

  • Knowledge of where they want to go or at least what to try. Architect, business analyst, systems analyst, program manager, or some other next step after being a developer for a few years is something to ponder and explore, not necessarily commit to forever. Alternatively, what kind of specialization do you want to have: Web, Windows applications, web services, databases, etc.

  • Be able to communicate at various levels of detail depending on your audience. The exception here are the top 1% of programming geniuses that will cater to someone with such ability.

  • Be good at solving problems and designing solutions. In most places this may be part of your work that you didn't think as this isn't necessarily specific to what software you'll be writing.

  • Be humble when things go wrong, expect things to go in odd or unusual directions.


That there is a time to discuss system architecture and a time to just get things done.


Correct naming conventions for variables - There are several out there, pick one, stick to it religiously... every time.

Third normal form - If you're having to design a database, this is like, the most important thing ever.

Good commenting - Anyone with basic knowledge of the language, should be able to decipher your code.

Where to get help - No-one knows everything... knowing which forums, communities, manuals, references etc. to go to when you get stuck can literally save days of man-hours.


Boolean Logic and Basic algorithmic notions

+1. Some of these answers are setting the bar really high. Let's start by understanding the difference between AND and OR. I've worked with people who seemed to have trouble! – slim Sep 26 '08 at 9:44

Binary search. It's useful in a lot of places: search through sorted collection, certain debugging scenarios, programming interview questions.

why would anyone vote this down? If the programmer will write any original code, he had best know this or be in a world of hurt. I'll vote you up to 0. +1 – WolfmanDragon Dec 17 '08 at 21:27

IMHO, a career programmer should have the passion and drive to create things. One should also be very keen on learning new stuff as well as master the language you are currently using. I also agree that good programmers should accept their mistakes and admit to have had mistakes in the past and use these mistakes to improve one's skills. And always keep in mind that someone is always better than you in something else but don't make this deter you from being the best programmer you can be.

  • Work in small teams (2-10) where you're one of the weakest programmers. You'll learn much more from working with experienced folks than you will by contracting/freelancing and reading books.
  • Ugly, complete and working beats elegant, incomplete and broken.
  • Learn about every trendy concept, whether it be good, bad or the-jury-is-still-out (e.g. MVC, Ruby on Rails, test-driven development, respectively) so you can ignore it or embrace it with good reason.
  • How to write comments and name your variables/methods/objects/functions correctly. Read the latest edition of Code Complete for suggestions.

This is probably already posted but I'm not about to search and read through all that. But a programmer must know when to give up on their idea if a better way of doing it comes along.

And learn from others experience ;) – Aaron Sep 26 '08 at 8:04

How to remain proud of your work and be able to admit mistakes at the same time.

Don't swallow pride!


I live by these mottoes:

"Success is 10 percent inspiration and 90 percent perspiration."

"How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?"


When I get to work, my ego stays in the car. Nothing matters more than the work and its quality. Never take criticism personally and listen to everyone, no matter how stupid they may sound. But don't ever compromise the quality just because it's faster or easier.

And of course, learn,learn, learn. :)


Should know what to code and how to code. if don't know, then should at least have the apt and enthusiasm to learn it !


Know that a good (the best) program is not necessarily the one that runs fast(er). A good program is one that: - Is easy to understand and change. - Is easy to use - it has a simple/clear/easy to learn interface.

I like to say that the best programmers are the one who can write programs that even the worst programmers can understand and even the most casual users can use.


Great thread! I'll add that I learned a great deal from the Programming Pearls books.


I'm pretty keen on mathematics, but I think one that comes over time that programmers should know is what rabbits to chase and which to let go. When searching for an answer to a question and you can't find the answer anywhere, it's not giving up to try a different tack. We get paid to solve problems, we don't get paid on the method by which we solve the problem.

You can and will make mistakes too. This helps in two ways. First, you don't get down on yourself. Secondly, you don't look down on your coworkers. This second one will help you as you go trough your career.


to discipline yourself to write software that's good enough even if it's not perfect


How to write clearly and concisely. I'm not talking about code, although that would be good too.


Every programmer should know how to solve problems. It is important to approach every task with an open mind as to what tools and methodologies to use. Sometimes frameworks or patterns will be the answer, but sometimes they will not.


Play the game, learn that most of your daily work is going to be about work-place politics and not programming.


Version control, obviously. But more importantly, the mechanics of a computer.

Compiler theory: how do you transform one language to another? Without some idea for how this works and what it can do, code is bound to be full of bad decisions. Compilers tend to look magical to the non-initiated, and they tend to write horrific code.

Computer architecture: you need to understand the machine deep down below to some extent to really write good code. Even on top of multiple layers of middleware, the fundamental machine will shine through. You need to understand caches, multiprocessing, how IO works, at some level, to have a decent chance at writing decent code. Writing code obliviously to the issues of memory size, caching, etc. might work well to some point -- but when it breaks due to lacking synchronization or hits a performance wall, you need to understand what is going inside the bowels of the machine.


Surround yourself with people who are smarter than you are.


The problem domain they're working in.


Every developer out there should read this post:

"It is harder to read code than to write it"


The one thing i can give up for advice:

  1. Programming isn't just work, it's art form
  2. Programming is the only art-form where it pays to be lazy.

Now not the form of lazy where you grab some code off some open source project, think it's good enough and cut-n-paste it in your own app, i mean preparing to be lazy in the future.

I always try to break everything down into basic, standard objects that do dedicated tasks. An SSH object that does SSH connection handling and SCP'ing, a dbconnection object that handels all the db communication, you name it.

Just drop it in, make it work and you're done. The longer you are a good programmer, the easier it gets to get something done.

Also If you're not being lazy enough (for instance, check TheDailyWTF), get yourself an other job. There should be something inside you that makes you not want to re-implement the programming language in the language itself, or do any of the other stupid stuff that you see on TheDailyWtf.

I hate the word lazy, because I always see it implemented as avoid standards, overlook security concerns, and forget about errors and exceptions. I prefer "coding to reduce maintenance cost." Even business folks can appreciate that one. :) – Bernard Feb 4 '09 at 15:54
Programming is an art for those who consider project management an art and this as art and that as art. Art is the word that suffers a lot. Programming is a science. While in (true) art, you let your imagination free and decide your own constraints, in programming as in science, constraints are already provided and you have to argue what is right and what is not. – phaedrus Sep 4 '09 at 16:39
@Amit: A Sculptor must work within the limits of his medium; So must a painter. No canvas is infinitely flexible. That programming has constraints doesn't stop it from being art, any more than the constraints of stone prevent sculpting from being art. – Sean McMillan Dec 18 '09 at 12:47

Know that there is more than one way to do it. This is Perl motto, but it is very general. You can also learn the free software song.


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