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.

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.

share

migrated from stackoverflow.com Jul 10 '11 at 10:20

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

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.

comments disabled on deleted / locked posts

174 Answers

up vote 636 down vote accepted

How to swallow pride and admit mistakes without taking them personally.

share
60  
That is something that every human being should do regardless of their job (...sex, religion, culture, social status...), don't you think? ;) –  Manrico Corazzi Sep 25 '08 at 12:00
3  
Oh yes. But we programmers (at least I do) have a tendency to have more overt pride than most :-) –  Gilligan Sep 25 '08 at 12:02
17  
I wish i could vote you up twice. –  JoshReedSchramm Sep 25 '08 at 15:27
4  
I think this is one thing I learned at university. In highschool I was always one of the smart kids. If I hadn't gone to uni, I would have thought I was pretty smart and had a big ego. Going to uni, and interacting with people who were truly more skilled then I was helped me see just how dumb I was –  Kibbee Sep 27 '08 at 1:45
4  
While this is very true, the issue isn't always denial or a big ego, but the potential consequences of openly admitting to making mistakes, at least not without some sort of self defense/damage control first. Sometimes it's a cultural thing. :) –  Emrah Dec 1 '09 at 14:00
show 7 more comments

When to ask for help, and when NOT to ask for help.

share
2  
So true. Lately, the answer has popped into my head as I was asking someone. :( –  daub815 Dec 25 '08 at 1:45
28  
Ask your rubber duckie first. If he can't help you, then ask someone else... –  Dean Rather Feb 11 '10 at 5:59
3  
upvoted because when I first started I didn't realize how much I was annoying other developers by continuously asking them simple stuff I should figure out myself until I had some n00b do it to me. –  eviljack May 13 '10 at 12:12
1  
I always ask myself a question along the lines of "What would my colleague say if I was to ask them". Usually that helps me get a bit further down the problem before I then have to actually ask. –  Fogmeister Sep 16 '10 at 20:11
show 1 more comment

Familiarity with version control systems. It doesn't have to be every one, but the basic concepts that can be applied to all of them should be known.

share
4  
I would add that there's a significant enough difference between centralized SCMs (eg subversion, CVS) and distributed SCMs (eg git, mercurial, bazaar) that it's important to learn one of each. –  intuited Apr 15 '10 at 21:19
show 2 more comments

Basic data type & algorithm theory. Things like Big O notation, arrays, queues, etc.

share
3  
Well, nowadays standard algorithms are implemented in the libraries/frameworks but I agree that some hard-algorithm-like thinking is useful, but not very often –  Łukasz Sowa Sep 26 '08 at 0:14
7  
Just because they are implemented already doesn't mean you don't have to understand what to use when, complexity guarantees, etc. This is the important stuff behind algorithms. –  Greg Rogers Sep 26 '08 at 20:54
3  
Agreed with Greg Rogers. You might need to implement the algorithms but you better understand their complexities and tradeoffs. Eg. Some algorithms take more memory but are faster. –  grom Nov 17 '08 at 4:26
6  
You won't know which one to use if you don't understand them. Algorithms are very important. –  Bernard Jan 2 '09 at 16:52
show 4 more comments

Requirements change, your code will have to adapt, and it may or may not be you who has to adapt it.

There have been several questions here related to topics that are affected by this.

share
add comment

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

share
add comment

Reading other peoples' code is not going to spoil your brain, but rather figure out why you would not have done it that way (if better or not is another question).

This gives you programming gedankenexperiment, and occasionally you do find someone implementing something way better! Like in way better.

This answer naturally expands to reading your own code, thus it expands to use version control and DIFF, and thus to 42.

share
add comment

How to read other people's code.

share
102  
Addendum: How to write code other people can read –  Mike Robinson Jan 15 '09 at 19:02
42  
Addendum #2: How to read your own code 6 months later –  Nathan Koop Sep 4 '09 at 16:33
10  
@Nathan Koop: It should be better "How to write code so that you can read it by yourself 6 months later". –  Doc Brown Dec 18 '09 at 13:13
4  
When it's been 6 months, it's already become someone else's code. In the sense that you have since evolved, gotten better, and it might as well be someone else who wrote it in the first place, so treat it as such. –  MPelletier Jan 26 '10 at 14:05
7  
Addendum #3: How to read your code 6 minutes later. –  Mark Apr 22 '10 at 4:54
show 4 more comments

How to think like a user, and not like a techie geek programmer.

share
2  
I always find it ironic that the thing it seems most of us in the industry lack may be one of the most important skills to have: communication skills. –  Gilligan Sep 25 '08 at 12:11
23  
I actually disagree. That's what you hire people for. You'll never be able to think like a user, but you can certainly have people tell you what users think and act on that advice. Just don't ask the users how they think! That's the worst option of all. –  Asmor Sep 25 '08 at 20:29
1  
You may hire other people to do that, but if your development team can comprehend how a user thinks, then you will have a lot fewer arguments and iterations before things are right. Plus, if a developer can think like a user, who knows what new features they will come up with –  Jon Galloway Sep 26 '08 at 12:24
3  
The user may very well be a techie geek programmer, but less likely a techie geek programmer who also implemented the code. If the application has very subtle and complex semantics/behavior, the person who wrote the code might be the only person who can understand how to use the application... –  Reuben Dec 25 '08 at 7:21
show 5 more comments

That the programmer doesn't know everything and should always try to learn new languages/technologies, etc.

share
add comment

How to observe a big complicated object and decompose it in small simple objects that still accomplish the same task when put together again.

share
add comment

How to choose the right tool for the right task, and not taking part in silly flaming wars about his favourite programming tools.

share
show 1 more comment

While helpful at times, you should not be fully relying on your compiler or your debugger to help you make your code better.

share
add comment

You can't test quality into a product.

share
2  
Thus "Quality Assurance" professionals have the wrong name. –  ZeroBugBounce Sep 26 '08 at 1:47
1  
Technically speaking QA and Test is not the same thing, although to your point I'm not sure most organizations actually practice the difference. –  Tall Jeff Sep 26 '08 at 12:02
5  
Recently encountered - and stuck: "The result of testing is not quality, but knowledge". –  peterchen Apr 13 '10 at 11:07
show 1 more comment

Where to find the information the programmer needs :)

share
add comment

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

share
add comment

Model-View-Controller

share
add comment

Version control. And to quote my girl friend: "I don't just want you to do the dishes, I want you to like it!"

share
add comment

The fact that, No one is indispensable!

share
add comment

Thinking out-of-the-box is usually a good thing! Most of the development is not just straightforward.

share
add comment

How to leverage their network of contacts both internally within their current organisation and externally, as you never know when you will need someone to mull over an issue with you or where the next interesting project might come from.

share
add comment

Every programmer should understand that generally the best solution for the business and the most technically elegant programming solution are not the same thing.

share
add comment

Every programmer should understand design patterns.

share
13  
I would add that they also need an understanding that not everything can be shoe-horned into a given design pattern. –  tloach Sep 25 '08 at 12:48
10  
I would also add that not every programmer should understand design patterns. There are languages out there in faraway lands which have other features so powerful that thought flows directly out of the programmer and into working programs. In those languages, deliberate patterns are a misdirection. –  Ali Sep 25 '08 at 20:20
2  
design patterns are for desingers not "programmers" - a programmer will need to know that when he/she becomes a "designer" –  Autobyte Sep 26 '08 at 19:58
10  
There are two types of people.. people who enjoys coding and people who prefers talking about coding. Design patterns is a must for the second group.. –  Bjorn Reppen Sep 28 '08 at 21:13
1  
Such patterns is a way to overcome limitations of languages. A programmer should understand them only because he should understand and be able to overcome the weaknesses of his languages. –  tomjen May 16 '09 at 19:28
show 5 more comments

Here's my 10 bits:

  • How to be humble. We are all here to learn. You may be smarter than others, but there are a lot of people smarter than you.
  • How to study/consume information. I don't know about you, but I am forever studying! Books, the Internet, whatever!
  • What a dictionary is and how to use one, and how to find out acronyms quickly.
  • What the basic tools of the trade are and what they do (IDE, CVS et al).
  • Know common terminolgy and what they mean: design patterns, usability, testing (ha!), stack, etc.
  • Have an understanding of OOP.
  • Be "capable" in at least one language, nothing amazing, just know how to identify variables and methods, etc. From here you can learn FAST.
  • Understand that people ultimately use software and want to make those people happy.
share
38  
This must be an octal post. –  Even Mien Sep 25 '08 at 16:26
10  
Regarding the first bit.... "Don't be so humble, you're not that great". –  Magnus Sep 25 '08 at 16:36
3  
Regarding point 3: www.acronymfinder.com –  Jasper Bekkers Dec 16 '08 at 17:42
1  
@jasper/intuited: just type the acronym into google and it will pull up one or the other... the answer is usually in one of the first 10 results anyway. more info can be obtained by clicking! –  Mark Apr 22 '10 at 4:57
show 4 more comments

Managing expectations of your clients, your manager, your coworkers.

share
add comment

What you don't know.

share
add comment

Never trust a user (especially if the app is public!), they will often do everything in their power to break your app one way or another.

Make it future proof & expandable – you never know when you want to expand it in a few years time and realise how much effort it would take to re-code badly created code.

share
1  
This is too generalized. Some pragmatism is good as well. –  mafutrct Apr 13 '10 at 11:09
add comment

Coffee and IntelliSense are your best friends ever.

share
show 5 more comments

How to program in C.

share
12  
Not to mention assembly language. –  Ferruccio Sep 27 '08 at 1:35
12  
Not to mention X. –  Ali Sep 28 '08 at 16:20
7  
Screw it...Binary –  Egg Jul 21 '09 at 15:28
show 2 more comments

Maybe it's too subtle, but I think of it as "knowing which problem to solve." A lot of programmers (and normal people) waste tremendous effort solving things that simply aren't very important; or they create a solution, with a great deal of extra work, that isn't quite what is needed.

share
4  
Agreed, worrying about fringe use-case scenarios that only a handful of users will ever encounter instead of more core functionality is an all too common trap! I still learn this one the hard way... –  Ian Robinson Sep 27 '08 at 1:40
4  
I love that you said "a lot of programmers (and normal people)" :-) –  fingerprint211b Apr 27 '10 at 22:06
show 1 more comment

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