Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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.

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 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
    
Couldn't agree with this more. This should be #1. – Charles Roper Sep 25 '08 at 15:16
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
    
so, what`s the answer?) – chester89 Apr 11 '09 at 14:39
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. – mpen 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
    
and that revision control isn't software – jrhicks Oct 31 '09 at 19:57
    
+1 Enjoy your gold badge :P – Ólafur Waage Nov 21 '09 at 14:45
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
    
@TheOtherScott, nice catch lol, but I was actually saying 2 bits :D ;) – Rob Cooper Sep 25 '08 at 17:21
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! – mpen 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
    
I should put a link to your answer as my former teamleader's homepage. you're so right. – Amir Arad Oct 14 '08 at 12:16
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
    
@Egg, he means contraction of unused muscles. – harpo Sep 16 '10 at 20:12
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
    
Doesn't help you at all if all you do is crafting templates for web content management systems. – xmjx Sep 25 '08 at 12:07
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
    
+1 so that this one does not stay at 42 :) – CharlesB Jun 5 '10 at 8:08

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
    
Is that your .02 dollars or .02 cents? LOL! :-D – Fogmeister Sep 16 '10 at 20:15
    
"Write your code as if the person that's going to maintain it is a psychotic serial killer who knows where you live." +1 – Ben Dec 21 '10 at 7:56

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
    
richdiet: SQA expert James Bach believes that the "A" in SQA/QA should stand for "Assistance". I strongly agree with his opinion and your statement. – Kimball Robinson Apr 27 '10 at 21:43

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
    
@Inshallah: unless you do some thing like if (BlowUpTheSystem = 1). Granted, given proper unit testing, you're likely to be saving only time. But then time is pretty important. – intuited Apr 15 '10 at 21:30
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
    
Excellent!!!!!! – Andrei Rinea Oct 15 '10 at 11:21

How to program in C.

share
    
Haha. Where's Jeff when you need him? ;) – Kevin Fairchild Sep 26 '08 at 13:40
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
    
Jeff!!!! People are talking shit on your site :P – Andrei Rinea Oct 15 '10 at 11:22

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

share
    
If I had one wish, it would be that Santa was my father. – Pete Karl II Oct 13 '08 at 16:46
    
Because Santa ...? – Robert Venables Jan 11 '09 at 16:34
1  
The day you stop learning should be the day you die. :) +1 anyway – ShdNx Jul 29 '09 at 18:58
    
So to live forever you must always keep learning? Now there's an idea I can endorse! – canadiancreed Dec 23 '09 at 22:02

Unit testing and debugging.

share
    
The first removes the need for the second. ;-) – phjr Sep 25 '08 at 16:28
4  
No, when the unit test fails, that needs debugging. The two go together. – Zan Lynx Sep 25 '08 at 19:15
    
Cannot stress this enough. – fastcodejava Apr 22 '10 at 3:53

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

share
    
I run into uses for it more and more, and I pick up pieces here and there, but I'm still not even an amateur. – alexp206 Sep 26 '08 at 0:29
    
I completely agree. It looks strange and difficult when you don't understand it, but when you do understand it, it's so much easier than a tonne of substring/indexof function calls that would be necessary to do the same thing otherwise. I would just ensure that your patterns are well commented. – Kibbee Sep 27 '08 at 1:41
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
    
Using an editor basically built around them is a good way to learn the nasty nitty gritty. My experience is with vim —which uses a mostly-comparable equivalent to the de facto standard PCREs— but I get the impression that the same rules apply in the emacs world. – intuited Apr 15 '10 at 21:27
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
    
I like to believe that one could write software people find a pleasure to use. – Nikolai Ruhe Dec 3 '09 at 21:15
    
Couldn't agree more. This however also applies to APIs. Noone wants to learn new APIs because it's so damn funny. We want the functionality of the API, not the code it represents. – Blub Jul 28 '10 at 10:44
    
Kevin, I wish our "implementation programmer" (posh word for testing guy) would read and understand that. I too sit behind my desk hoping the world would swallow him up as he starts talking about loops and if statements to end users. – Fogmeister Sep 16 '10 at 20:21

Coffee and IntelliSense are your best friends ever.

share
    
I wish I could give this more than 1 upvote! – Dinah Dec 7 '08 at 21:48
    
I hope to have more coffee!!!! ñ_ñ – Rulas Dec 11 '08 at 15:48
    
I think I agree with this more then any other thing on SO. – Unkwntech Jun 8 '09 at 1:49
    
I practically never drink coffee unless I absolutely need to finish a project in X hours, when: Number of used up hours + X > 8 for a day. – Blub Jul 28 '10 at 10:40
    
Coffee doesn't give you any energy. It just squeeze some from your internal reserves. That's bad/unhealthy. – Andrei Rinea Oct 15 '10 at 11:23

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. – mafu 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
    
I started my first ever programming job and within a week was writing code that would eventually go live. Luckily I'm a quick learner and had past programming experience. Within 6 months I had restructured the client-server connection to improve performance three-fold. This was in a language I had never used before. – Fogmeister Sep 16 '10 at 20:24

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
    
Number 10 made me laugh. So many times I'll be working on a problem at work but it's only in bed at 10pm that I eventually come up with the answer! – Fogmeister Sep 16 '10 at 20:27

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.