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.

174 Answers 174

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

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

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

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

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

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

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

How to relax. It's the secret to productivity.

Eventually, willpower and caffeine are not enough. This constant contraction we do is very damaging.

This is a big deal.

share
1  
What do you mean by contraction? –  Egg Jul 21 '09 at 14:56
4  
@Egg: Sometimes when I work, I'm able to be completely relaxed and very productive. On my bad days, I run on adrenaline and caffeine, and I feel tremendous tension in my body. If I pay close attention I'm actually contracting some muscles. I notice this tension in others all the time. Unfortunately it can lead to all kinds of problems such as burnout and heart disease, and it probably also leads to a net loss of productivity since it's only possible to sprint for a finite amount of time. That's the contraction I'm talking about. –  Brian MacKay Apr 20 '10 at 11:46
2  
speaking of coffee and contraction, did you know that coffee shrinks the artery suppling blood to the brain. That causes the brain to wake up. Coffee is not such a good thing after all. tl;dr drink water –  Reno Jan 19 '11 at 10:48

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

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

share

Well, here's my .02$ :

  • The learning never stops. No matter how good you think you are, there is always someone better than you, and there is always something you can improve about yourself. If you stop learning, you'll inevitably degrade as a programmer. Read books. Read blogs. Talk to other programmers.
  • Try to learn several languages. At least one of them object-oriented. Also, you should know something about various technologies related to the language you learn (e.g. If you learn Java, it would be nice if you knew something about Spring, and so on..).
  • Refactoring. Sooner or later you're going to need that knowledge.
  • Learn how to deal with legacy code.
  • Write unit tests. Learn about TDD.
  • Learn to work in a team.
  • Write elegant and readable code. As the old saying goes:"Write your code as if the person that's going to maintain it is a psychotic serial killer who knows where you live."
  • Learn how to be lazy and disciplined at the same time. Good programmers posess both of these qualities. Weird as it seems, they're not contradictory to one another, but complementary.
share

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

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

I'm a little late to this one, but I'll go with the knowledge laid down by Edsger Dijkstra:

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

If you can't write a good paragraph, chances are you can't write good code either.

share
8  
Yet I'm amazed at the terrible spelling, grammar, and punctuation used in natural-language writing by some programmers. You would think that working every day with systems that have zero tolerance for spelling errors and invalid syntax would have a beneficial effect... –  cheduardo Jun 23 '09 at 13:07
1  
@cheduardo, that's because once you compile or run a program, in most languages, you will be told about any spelling, grammar or punctuation errors, which can then be easily corrected. Not so for logical errors. –  Inshallah Nov 5 '09 at 20:41
2  
Agreee.. hmm... minus the "native tongue" part, some of us [unfortunately?] communicate better/clearer in our non-native tongues. –  sjobe Apr 27 '10 at 22:03

Don't get too emotionally vested in, attached to, or religious about any given technology, OS, or language - none are perfect - in the long run you're likely to end up wishing you could create your own ala carte from what you like about each different one.

Think of it like cars - you may not have driven a particular car before, but they all have keys, steering wheels, accelerators, and brakes - you should be able to get in one and quickly drive off once you sort out what's where. Treat OSes and languages similarly and focus on learning the essential concepts underlying them even if you're in the throes of the specifics of any given instance.

And over time try to understand and appreciate the ancestry, heritage, and commonalities of the various technologies which will help you keep perspective. Realize for example that, while the evolutionary tree is actively branching and full of dead-ends, over time technology tends to repeatedly converge around 'best practices' and 'economies of scale' (e.g. notice a Mac isn't all that different than a PC under the hood these days...).

Last, remember no matter how much fun you're having with it all, technology essentially represents an imperfect lens between what your mind can envision and what you actually produce. Do your best, learn to learn, and remain adaptable...

share

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

That the day you stop learning should be the day you're no longer a programmer.

share
1  
The day you stop learning should be the day you die. :) +1 anyway –  ShdNx Jul 29 '09 at 18:58

Unit testing and debugging.

share
4  
No, when the unit test fails, that needs debugging. The two go together. –  Zan Lynx Sep 25 '08 at 19:15

It was mentioned before but I think it deserves it's own answer.

share
9  
Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems. --"Jamie Zawinski":jwz.livejournal.com, in comp.lang.emacs –  Bjorn Reppen Sep 28 '08 at 21:11
1  
Some people, when confronted with a regular expression, think “I know, I'll quote Jamie Zawinski.” Now they have two problems (one of which is that they probably don't know what they're doing in the first place). –  Donal Fellows Oct 24 '10 at 20:38

No-one wants to use software. They want problems solved.

share
7  
Exactly. When I hear developers attempting to explain the database to an end user as an answer to their question of why something can't be done, I cringe. They don't need to know how we do stuff. They just want it to work. And that's the way it should be. –  Kevin Fairchild Sep 26 '08 at 13:43

Coffee and IntelliSense are your best friends ever.

share

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

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

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

share

The basics of good UI design and communication (aka graphic) design.

I see so many apps and projects ruined by bad design or poor usability. Just learning the basics can make a world of difference. Plus the visual problem solving techniques (i.e., how to communicate a concept visually) are a stimulating challenge that should open your eyes to new ways of seeing, which should in turn have an impact on your code.

A recommended book is The Non-Designer's Design Book by Robin Williams

Here's what Joel Spolsky says of it:

Wow! Everybody has to do some graphic design, and not every software team has the luxury of professional designers. This excellent, thin book will give you a grasp of the principles behind page layout, fonts, etc. The good news is, you can read it in the bath before the water gets cold, and the next day, your dialog boxes and powerpoints and web pages will start looking better.

share
1  
I'll second that with an additional nod to 'the design of everyday things'. amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746 –  Stimul8d Nov 26 '09 at 17:19

Every programmer should know how to learn quickly. A lot of times you come into a job and will be asked to develop in a technology you've never used. They might give you a week or so to get on your feet (if you're lucky) before you're asked to write production-quality code.

share

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

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

Off the top of my head:

  1. Very few programming problems require math beyond addition, subtraction, multiplication, and division. If you're thinking of using calculus to solve a problem, research the alternatives exhaustively before doing so.

  2. Any time you find yourself guessing about how something should work, you're doing it wrong. It's not your job to be telepathic.

  3. The person giving you the spec rarely knows everything he wants until you've hashed it out.

  4. More than half of being a great programmer comes from dealing with human beings. Interacting with your team, managing your manager, and finessing the end user are half of the job.

  5. Good code is written to be read by people as much as it is to be read by your compiler.

  6. Best practice and practical reality will be in conflict more than the programmer thinks, but less than the manager does. When they appear to be in conflict, it's up to you to delineate and understand the conflict and then give in to the practical. The subtle and clever solution is only better than the ugly, brutish one if it's more cost effective in the long run.

  7. Great tools can't make great programmers, but bad tools make us equally awful.

  8. Never look down on a technology, but always look for the best alternative.

  9. The more languages you know, the better you'll be in the one you're using.

  10. Don't be disturbed by the slow creep of programming-oriented thoughts into your daily life. Even when we're not at a computer, we all suffer from bandwidth limitations, have performance penalties from task switching, and need to load things from backup storage. Computers are supposed to mimic human thought and the analogues are everywhere.

share

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

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