245
votes

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.

0

174 Answers 174

Reset to default
1
2 3 4 5 6
636
votes

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

11
  • 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
    Commented Sep 25, 2008 at 12:00
  • 3
    Oh yes. But we programmers (at least I do) have a tendency to have more overt pride than most :-)
    – Gilligan
    Commented Sep 25, 2008 at 12:02
  • 17
    I wish i could vote you up twice.
    – JoshReedSchramm
    Commented Sep 25, 2008 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
    Commented Sep 27, 2008 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
    Commented Dec 1, 2009 at 14:00
309
votes

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

9
  • 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
    Commented Sep 25, 2008 at 12:11
  • Couldn't agree with this more. This should be #1.
    – Charles Roper
    Commented Sep 25, 2008 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
    Commented Sep 25, 2008 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
    Commented Sep 26, 2008 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
    Commented Dec 25, 2008 at 7:21
244
votes

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

5
  • 2
    So true. Lately, the answer has popped into my head as I was asking someone. :(
    – kevindaub
    Commented Dec 25, 2008 at 1:45
  • so, what`s the answer?)
    – chester89
    Commented Apr 11, 2009 at 14:39
  • 28
    Ask your rubber duckie first. If he can't help you, then ask someone else...
    – Dean Rather
    Commented Feb 11, 2010 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
    Commented May 13, 2010 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
    Commented Sep 16, 2010 at 20:11
184
votes

How to read other people's code.

9
  • 102
    Addendum: How to write code other people can read
    – Mike Robinson
    Commented Jan 15, 2009 at 19:02
  • 42
    Addendum #2: How to read your own code 6 months later
    – Nathan Koop
    Commented Sep 4, 2009 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
    Commented Dec 18, 2009 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
    Commented Jan 26, 2010 at 14:05
  • 7
    Addendum #3: How to read your code 6 minutes later.
    – mpen
    Commented Apr 22, 2010 at 4:54
152
votes

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.

2
  • and that revision control isn't software
    – jrhicks
    Commented Oct 31, 2009 at 19:57
  • 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
    Commented Apr 15, 2010 at 21:19
128
votes

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.
8
  • 38
    This must be an octal post.
    – Even Mien
    Commented Sep 25, 2008 at 16:26
  • 10
    Regarding the first bit.... "Don't be so humble, you're not that great".
    – Magnus
    Commented Sep 25, 2008 at 16:36
  • @TheOtherScott, nice catch lol, but I was actually saying 2 bits :D ;)
    – Rob Cooper
    Commented Sep 25, 2008 at 17:21
  • 3
    Regarding point 3: www.acronymfinder.com
    – Jasper Bekkers
    Commented Dec 16, 2008 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
    Commented Apr 22, 2010 at 4:57
104
votes

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.

3
  • 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
    Commented Sep 27, 2008 at 1:40
  • I should put a link to your answer as my former teamleader's homepage. you're so right.
    – Amir Arad
    Commented Oct 14, 2008 at 12:16
  • 4
    I love that you said "a lot of programmers (and normal people)" :-)
    – fingerprint211b
    Commented Apr 27, 2010 at 22:06
95
votes

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.

4
  • 1
    What do you mean by contraction?
    – Egg
    Commented Jul 21, 2009 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
    Commented Apr 20, 2010 at 11:46
  • @Egg, he means contraction of unused muscles.
    – harpo
    Commented Sep 16, 2010 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
    Commented Jan 19, 2011 at 10:48
83
votes

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

8
  • Doesn't help you at all if all you do is crafting templates for web content management systems.
    – xmjx
    Commented Sep 25, 2008 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
    Commented Sep 26, 2008 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
    Commented Sep 26, 2008 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
    Commented Nov 17, 2008 at 4:26
  • 6
    You won't know which one to use if you don't understand them. Algorithms are very important.
    – Bernard
    Commented Jan 2, 2009 at 16:52
60
votes

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

1
  • +1 so that this one does not stay at 42 :)
    – CharlesB
    Commented Jun 5, 2010 at 8:08
54
votes

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.
2
  • Is that your .02 dollars or .02 cents? LOL! :-D
    – Fogmeister
    Commented Sep 16, 2010 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
    Commented Dec 21, 2010 at 7:56
50
votes

You can't test quality into a product.

4
  • 2
    Thus "Quality Assurance" professionals have the wrong name.
    – ZeroBugBounce
    Commented Sep 26, 2008 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
    Commented Sep 26, 2008 at 12:02
  • 5
    Recently encountered - and stuck: "The result of testing is not quality, but knowledge".
    – peterchen
    Commented Apr 13, 2010 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
    Commented Apr 27, 2010 at 21:43
44
votes

Every programmer should understand design patterns.

10
  • 13
    I would add that they also need an understanding that not everything can be shoe-horned into a given design pattern.
    – tloach
    Commented Sep 25, 2008 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
    Commented Sep 25, 2008 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
    Commented Sep 26, 2008 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
    Commented Sep 28, 2008 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
    Commented May 16, 2009 at 19:28
44
votes

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.

4
  • 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
    Commented Jun 23, 2009 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
    Commented Nov 5, 2009 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
    Commented Apr 15, 2010 at 21:30
  • 2
    Agreee.. hmm... minus the "native tongue" part, some of us [unfortunately?] communicate better/clearer in our non-native tongues.
    – sjobe
    Commented Apr 27, 2010 at 22:03
39
votes

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

0
35
votes

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

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

How to program in C.

4
  • Haha. Where's Jeff when you need him? ;)
    – Kevin Fairchild
    Commented Sep 26, 2008 at 13:40
  • 12
    Not to mention assembly language.
    – Ferruccio
    Commented Sep 27, 2008 at 1:35
  • 12
    Not to mention X.
    – Ali
    Commented Sep 28, 2008 at 16:20
  • 7
    Screw it...Binary
    – Egg
    Commented Jul 21, 2009 at 15:28
34
votes

Unit testing and debugging.

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

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

8
  • 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
    Commented Sep 26, 2008 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
    Commented Sep 27, 2008 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
    Commented Sep 28, 2008 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
    Commented Apr 15, 2010 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
    Commented Oct 24, 2010 at 20:38
29
votes

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

4
  • 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
    Commented Sep 26, 2008 at 13:43
  • I like to believe that one could write software people find a pleasure to use.
    – Nikolai Ruhe
    Commented Dec 3, 2009 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
    Commented Jul 28, 2010 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
    Commented Sep 16, 2010 at 20:21
27
votes

Coffee and IntelliSense are your best friends ever.

5
  • I wish I could give this more than 1 upvote!
    – Dinah
    Commented Dec 7, 2008 at 21:48
  • I hope to have more coffee!!!! ñ_ñ
    – Rulas
    Commented Dec 11, 2008 at 15:48
  • I think I agree with this more then any other thing on SO.
    – Unkwntech
    Commented Jun 8, 2009 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
    Commented Jul 28, 2010 at 10:40
  • Coffee doesn't give you any energy. It just squeeze some from your internal reserves. That's bad/unhealthy.
    – Andrei Rînea
    Commented Oct 15, 2010 at 11:23
18
votes

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

18
votes

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.

1
  • 1
    This is too generalized. Some pragmatism is good as well.
    – mafu
    Commented Apr 13, 2010 at 11:09
18
votes

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

16
votes

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.

1
14
votes

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.

1
  • 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
    Commented Sep 16, 2010 at 20:24
14
votes

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

0
10
votes

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.

10
votes

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.

1
  • 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
    Commented Sep 16, 2010 at 20:27
9
votes

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.

1
2 3 4 5 6

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