Stack OverflowWhat should every programmer know?
[+222] [176] Matt Lacey
[2008-09-25 11:50:18]
[ language-agnostic career-development ]

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.

Every programmer should know how to have fun in life instead of trying to become the best. - Hamish Grubijan
(1) What do you mean, "instead"? - Jeanne Pindar
(5) this should be moved to - Junior Mayhé
[+579] [2008-09-25 11:51:16] Gilligan [ACCEPTED]

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

(54) That is something that every human being should do regardless of their job (, religion, culture, social status...), don't you think? ;) - Manrico Corazzi
(1) Oh yes. But we programmers (at least I do) have a tendency to have more overt pride than most :-) - Gilligan
(15) I wish i could vote you up twice. - JoshReedSchramm
While hubris continually extolled by many in our community... - Even Mien
nice response. this is both the most obvious, and also hardest to achieve .. "no way. that bug is in YOUR code, not mine. oh sh!t who checked that in. damn, it was me" - Chris Ballard
(2) 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
This so true, especially for non-social creatures such as programmers ;). - David The Man
Oh boy is this true. - Andy Webb
I think most programmers are quite humble inside. They're just pretending to be proud cause they're so insecure about their code. - Cyril Gupta
Amen! Praise the lord, for such an answer! - Aaron
+1. So it so true. - Guru
(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
[+274] [2008-09-25 11:56:57] community_owned

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

(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
Couldn't agree with this more. This should be #1. - Charles Roper
(21) 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
(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 - community_owned
Why do you assume that the user is not a techie geek programmer? If you're writing desktop or web apps, then fine. If you're writing an API or implementing a protocol, that's quite another. - slim
(1) 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
Eric Evans calls it "ubiquitous language", the benefits of sharing models with users, avoiding translations between "designer language" and "user language". (Domain-Driven Design: Tackling Complexity in the Heart of Software) - mjn
How can you not think like a user? All you have to do is put yourself in their situation, think about the things they want to accomplish, then use your program in a way they might. Being able to see things from different perspectives is an invaluable skill, and everyone should work on it. - Codygman
This may be better worded, how to not-think like a user. - harpo
[+220] [2008-09-25 11:53:04] Brian Knoblauch

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

(1) So true. Lately, the answer has popped into my head as I was asking someone. :( - daub815
so, what`s the answer?) - chester89
(20) Ask your rubber duckie first. If he can't help you, then ask someone else... - Dean
(2) 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
(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
[+166] [2008-09-25 11:56:43] Bill the Lizard

How to read other people's code.

(88) Addendum: How to write code other people can read - Mike Robinson
@Mike: Yes indeed. I would almost say that's more important than specifically being able to read others' code (which should typically be fairly straightforward). - Noldorin
If you think other's code is typically straightforward, you've been very lucky in your career thus far. Being able to read other people's code is a pre-condition to writing your own legible code. Reading LOTS of code helps you recognize the good from the bad, while understanding everything you read. - J Wynia
(35) Addendum #2: How to read your own code 6 months later - Nathan Koop
(10) @Nathan Koop: It should be better "How to write code so that you can read it by yourself 6 months later". - Doc Brown
(3) 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
(6) Addendum #3: How to read your code 6 minutes later. - Mark
[+138] [2008-09-25 11:53:10] Thomas Owens

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.

and that revision control isn't software - jrhicks
+1 Enjoy your gold badge :P - Ólafur Waage
(2) 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
[+117] [2008-09-25 12:30:02] Rob Cooper

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.

(27) This must be an octal post. - Even Mien
(9) Regarding the first bit.... "Don't be so humble, you're not that great". - Magnus Johansson
@TheOtherScott, nice catch lol, but I was actually saying 2 bits :D ;) - Rob Cooper
"Understand that people ultimately use software and want to make those people happy." -- not always! - slim
@Rob, it so happens that you listed 8 bullet points. That happens to be 10 in octal. I suppose it was unintentional :) - Tryke
(2) Regarding point 3: - Jasper Bekkers
@Jasper Bekkers: I find wikipedia generally better for stuff that's not completely obscure, as it sorts things into groups and gives a synopsis. - intuited
@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
[+100] [2008-09-25 13:09:23] catfood

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.

(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
I should put a link to your answer as my former teamleader's homepage. you're so right. - Amir Arad
(3) I love that you said "a lot of programmers (and normal people)" :-) - fingerprint211b
[+87] [2008-09-25 14:40:07] Brian MacKay

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.

(1) What do you mean by contraction? - Egg
@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
@Egg, he means contraction of unused muscles. - harpo
(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
[+76] [2008-09-25 11:53:23] Glenn Slaven

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

Doesn't help you at all if all you do is crafting templates for web content management systems. - xmjx
I would say if you're doing that you're not programming, you're doing web design. - tloach
(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
(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
(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
(6) You won't know which one to use if you don't understand them. Algorithms are very important. - Bernard
Also, Big 0 notation is useful for estimating performance. If you write a chunk of code, it's useful to be able to look at it and think 'thats not gonna scale'. - workmad3
It's like changing a car tire, even if you don't use that knowledge very often, it is still something you really should know. - Bob The Janitor
[+58] [2008-09-25 12:00:07] Terminus

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

+1 so that this one does not stay at 42 :) - CharlesB
[+53] [2008-09-25 13:13:02] Sandman

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.

Is that your .02 dollars or .02 cents? LOL! :-D - Fogmeister
"Write your code as if the person that's going to maintain it is a psychotic serial killer who knows where you live." +1 - Pietro
[+47] [2008-09-25 12:03:20] Tall Jeff

You can't test quality into a product.

(1) Thus "Quality Assurance" professionals have the wrong name. - ZeroBugBounce
(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
(4) Recently encountered - and stuck: "The result of testing is not quality, but knowledge". - peterchen
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
[+43] [2008-09-26 04:21:55] KevDog

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.

(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
(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
@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
(2) Agreee.. hmm... minus the "native tongue" part, some of us [unfortunately?] communicate better/clearer in our non-native tongues. - sjobe
[+42] [2008-09-25 11:55:33] eugensk00

Where his towel is.

42 – no more, no less, folks :)

(1) and make sure you celebrate towel day: - Chris Ballard
(52) This must stay at 42 votes! - Chris Blackwell
(38) This has been at 42 for two months now. I think we're officially the nerdiest community on the internet. :) - Bill the Lizard
(2) "for two months now." You were counting? 0_0 - Bernard
+1 for 41 blargh 10 - Mike Robinson
(12) I almost voted up ... phew :) - disc0dancer
(1) I'm sorry. -1 to push this back to 42. (I originally upvoted, but then I saw that I had to.) - Chris Lutz
(2) oh man, I almost ruined it - Carson Myers
(1) Is there any other literary reference techies know? - Paul
(13) I wish I could vote this up :( - György Andrasek
(9) I hereby vote this up without marking it. - Rui Pacheco
i voted down to keep at 42 but mentally vote it up .. - Gaby aka G. Petrioli
+74 / -32 must be really controversial ;-) - peterchen
Darn... I was just about to vote it up !!! - Newtopian
I was going to upvote just to screw w/you :-) - eviljack
(3) Voted back down to 42. - notJim
Is that the question? - Evan Plaice
@Bill the Lizard♦, you've been monitoring this question for 2 months just to see if it stays at 42 votes. I think you're officially the nerdiest guy on the internet. :) - Fluffy
Not enough rep to downvote this back to 42 :( - Sam
Must. Get. 125. Rep. To. Downvote. This. Back. To. 42. - JavaAndCSharp
[+37] [2008-09-25 19:05:45] J Healy

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

Excellent!!!!!! - Andrei Rinea
[+31] [2008-09-26 00:28:24] alexp206

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


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
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
(9) Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems. --"Jamie Zawinski", in comp.lang.emacs - Bjorn Reppen
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
Addendum - know when to use RegEx, and when not to. But know RegEx. - Kimball Robinson
Addendum 2 - know how to write readable Regular Expressions. See… - Kimball Robinson
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
[+29] [2008-09-26 00:42:04] Nick Sergeant

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

If I had one wish, it would be that Santa was my father. - Pete Karl II
Because Santa ...? - Robert Venables
The day you stop learning should be the day you die. :) +1 anyway - ShdNx
So to live forever you must always keep learning? Now there's an idea I can endorse! - canadiancreed
[+29] [2008-09-25 13:14:35] Jon

Unit testing and debugging.

The first removes the need for the second. ;-) - phjr
(2) No, when the unit test fails, that needs debugging. The two go together. - Zan Lynx
Cannot stress this enough. - fastcodejava
[+29] [2008-09-25 12:17:15] fluffels

Every programmer should understand design patterns [1].


(11) I would add that they also need an understanding that not everything can be shoe-horned into a given design pattern. - tloach
Could you elaborate? - user9282
(8) 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
(2) design patterns are for desingers not "programmers" - a programmer will need to know that when he/she becomes a "designer" - Autobyte
(8) 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
@Autobyte & Reppen: I can't say that I agree with this notion. I prefer to work in agile settings. In these cases there's not really a design team. All team members code, design, document and market the project. In that case (and for general knowledge) they're a must for coders. - fluffels
@mamama: I think the link to Wikipedia provides enough elaboration. - fluffels
@tloach: I completely agree. However, that point was made a little further down in the answers, so I won't make it here again. - fluffels
(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
@tomjen I couldn't agree more :) - fluffels
[+26] [2008-09-25 13:08:48] David Basarab

How to program in C.

Haha. Where's Jeff when you need him? ;) - Kevin Fairchild
(10) Not to mention assembly language. - Ferruccio
(9) Not to mention X. - Ali
(6) Screw it...Binary - Egg
Jeff!!!! People are talking shit on your site :P - Andrei Rinea
[+26] [2008-09-25 20:12:38] Andrew

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

(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
I like to believe that one could write software people find a pleasure to use. - Nikolai Ruhe
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
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
[+21] [2008-09-25 13:01:25] Rulas

Coffee and IntelliSense [1] are your best friends ever.


I wish I could give this more than 1 upvote! - Dinah
I hope to have more coffee!!!! ñ_ñ - Rulas
I think I agree with this more then any other thing on SO. - Unkwntech
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
Coffee doesn't give you any energy. It just squeeze some from your internal reserves. That's bad/unhealthy. - Andrei Rinea
[+18] [2008-09-25 11:57:00] Dror Helper

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

[+18] [2008-09-25 11:58:07] Manrico Corazzi

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

[+17] [2008-09-25 12:58:47] Robinb

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) This is too generalized. Some pragmatism is good as well. - mafutrct
[+15] [2008-09-25 15:26:06] Charles Roper

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 [1] by Robin Williams

Here's what Joel Spolsky says of it [2]:

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) I'll second that with an additional nod to 'the design of everyday things'. - Stimul8d
[+14] [2008-09-25 13:22:10] Ryan Thames

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.

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
[+14] [2008-09-25 12:08:33] MattW.

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

[+10] [2008-09-25 11:54:42] Adam Bellaire

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 [1] questions [2] here [3] related to topics that are affected by this.


[+9] [2008-09-25 11:56:03] Martin

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 [1], 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.


[+8] [2008-09-25 16:51:58] Jekke

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.

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
[+8] [2010-04-22 14:52:37] bethlakshmi
  • Look for the bad in the buzz - it's nice to think that because something is new, it's better - but every technology has a downside and a limitation. Just because your first real-world corporate team isn't using the latest technology, it doesn't mean their heads are stuck in the sand - look for the reasons why and realize that serious redesign and techology rev won't happen at certain phases.
  • it's not about being the star, it's about being on the team - sort of a twist on the elite developer bullet - I'll take a team of 10 people who can cover each other's faults with strengths as a team over the 1 hot shot any day.
  • Asking good questions makes you look smart - conversely, handing in something way off the mark because you didn't ask a single question makes you look dumb. Check in early and often with others on your team, especially your designated lead. Restate the goals, even if you have no doubts you understand them, to confirm that you have the right idea. This isn't stupid, it's good communication. The more you can do this, the bigger and harder work you'll be given.

"Asking good questions makes you look smart " <-- This is a really good one! This applies really well to interviewing, too. - Brad Heller
"Look for the bad in the buzz" Boy do I see people who need to learn this one. Preferably before your whole system is based on something that works fine with 12 test records but which never perform well with the 20,000,000 records you wil have in year two. - HLGEM
@bethlakshmi: I liked reading some of your answers, nicely said. - VoodooChild
[+7] [2010-04-22 14:57:01] ZombieSheep
  • The most important thing you bring from college is NOT technological - The most important thing you learned is how to learn. The fact is that a large chunk of any specific technology you learned in college will be out of date in a few years, so your ability to learn and absorb new things is paramount.

[+6] [2010-04-22 15:21:54] Dour High Arch

The fastest way to learn is the slowest. The slowest way to learn is the fastest.

In universtiy I was one of those guys who always asked the prof. for the formulas, for tricks and mnemonics to memorize the right answer, for the fastest way to solve the question, and this is my greatest regret.

Learning things by formulas and memorization means you start every problem at step one; you can't apply any of your previous solutions to new problems. I was no better at solving problems at graduation than I was as a freshman.

The guys who did best were the ones who learned how to do things from first principles; they derived the formulas instead of memorizing them, and would solve the same question multiple times to try different approaches and check their answers.

Yeah, at first those guys took forever to solve the simplest problems, but from then on they never had to solve them again, they knew it cold. By the final year they could solve many problems at a glance, and could estimate the right answer without working it out first.

[+5] [2010-07-07 23:59:04] Comptrol

THIS [1]:

alt text


[+5] [2010-04-21 19:30:54] Jim Kiley
  • Source control, unit testing, and continuous integration are far more important than any clever algorithm.

My god, how did I miss that? This is a big one! - Brad Heller
[+5] [2008-09-25 20:00:19] Joeri Sebrechts

If you want to be the best possible programmer, you need to understand how the "magic" works. Others have suggested learning about compilers, and that's a good start. I would even say every serious programmer has to build their own compiler at least once. But there are other "magics" you need to understand:

  • How floating point maths work on the bit level
  • How an operating system manages processes and memory
  • How a CPU handles instructions internally (microcode, pipelining, branch prediction, ...)
  • How everything is built out of transistors, and how transistors work on the level of basic physics

I would also suggest studying "magical software techniques":

  • How game AI works, how a chess game plans its next move
  • Different sorting algorithms
  • Different techniques for laying out connected node graphs and finding paths in them

You should end up with a knowledge good enough to feel that you could look up everything you need to know to work on any part of the entire system. What this then will give you is a grounding that lets you tackle any issue, regardless of how many disciplines it traverses.

Ofcourse, this isn't all required to be a good programmer, but your question wasn't about being good, it was about being the best you can.

[+5] [2008-09-25 12:03:56] MADMap

Where to find the information the programmer needs :)

[+4] [2008-09-25 12:10:07] Prakash

The fact that, No one is indispensable!

[+4] [2008-09-25 13:26:15] Rob

Your code will inevitably have some little thing you never thought of go wrong. Don't worry, it's ok, just fix it and learn from the experience.

[+4] [2008-09-25 13:43:22] J.J.
  • Writing code (with good practices is mind) makes you a better coder.
  • Constant study and debate.
  • Viewing problems from multiple angles.
  • Humility.
  • Knowing where to look if you don't know the right answer.

[+4] [2008-09-25 12:49:27] Arc the daft

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

[+4] [2008-09-25 12:16:51] devinmoore

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

[+4] [2008-09-26 11:39:57] David Plumpton

All problems are people problems

[+4] [2008-09-28 21:38:53] Christopher

Every programmer should know that:

a) maintainability should not be sacrificed for insignificant performance gains.

b) maintainability is better in the long run, even if it costs a little more up front.

c) maintainability generally does not cost more up front if you know what you're doing in the first place.

[+4] [2008-11-30 06:31:45] J.T. Hurley

How to talk to non-programmers about programming concepts. It's tricky to get the hang of, but it will increase your value and the ease of your life greatly.

[+4] [2009-12-03 20:53:42] Dr. Xray

Do not be a complainer, solve the problem.

[+3] [2009-12-03 20:56:42] JasCav

The web address: [1]


[+3] [2008-12-07 21:29:05] Andreas Grech

I think that a lot of people are reluctant to help or teach others what they know, and for me, this is, simply put, wrong on many levels.

First of all, one of the best ways to really learn something is to teach it to someone else...and it that someone else doesn't understand your explaining, then it means that you don't know it enough to explain it in simple terms.

If you really are passionate about your craft, why restrict what you know to yourself? I personally think that there is a social side to programming as well. Of course, we all like our late night coding sessions with a mug and an ashtray by our sides, but believe it or not, some time or another, you will find yourself working in a team. And when you are, why not mentor the ones that are less knowledgeable than you (about the respective subject), and teach them what you know so that they become better programmers?

After all, in the final product, better developers will develop a better solution.

...and besides, wouldn't you want other fellow developers giving you a few tips here and there, or even teaching you what they know? I suppose you would...I mean, if you wouldn't, then it just means that you don't love your craft and you are just doing it because there is nothing better to do

So anyways, my point is: Do not keep what you know to yourself...

[+3] [2008-10-04 05:34:08] community_owned

You can't bolt 'security' onto a product.

[+3] [2008-09-27 23:03:07] user20282

That writing code is only a small part of being a programmer.

[+3] [2008-09-26 04:59:35] Dan

My 2¢ as an aspiring hardware design guy:

you should know how a computer physically works, so that you understand where the power of software bumps up against the limits of hardware, and how to prepare for them, code around them, and come out ahead.

[+3] [2008-09-26 05:15:19] burkestar

How to learn.

[+3] [2008-09-25 13:39:34] torial

Short and sweet -- no person will be an excellent coder / programmer / developer (pick your favorite word) unless he is a continuous learner.

[+3] [2008-09-25 12:02:32] Tall Jeff

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

[+3] [2008-09-25 19:25:49] Jeff
  1. Debugging someone else's code
  2. How to test your own code
  3. Design with security in mind
  4. How/when to comment

Recommended reading list:

[+3] [2008-09-25 21:28:07] Caleb Huitt - cjhuitt

One of the things that I try to recall whenever I'm writing code is that someone else will have to change it someday. Now, in certain instances, this may not be true, but I write as if it is. I try to code so that they can enjoy the process, or at least not give it a second thought.

[+3] [2008-09-25 21:32:57] community_owned

Be language/platform agnostic. Java is not the right tool for all applications. Neither is C#, or C, or Lisp, or [insert your own language here]

Without users, there is no use for programmers

And one of my favorite quotes... Always write your code as if the next person to come along and support it is a raving lunatic who knows where you live.

[+3] [2008-09-25 14:37:21] databyss

How to establish good communication with management so that requirements and time frames are achievable and realistic.

Sadly, I've never seen anyone with good enough communication to get a realistic time frame on any project, ever. - Sean McMillan
[+3] [2008-09-25 15:05:40] Jim C

How to learn new things and adapt. I've watch us go from assembler to BASIC to FORTAN, to C, to C++ to Java to C# and so on. I've watched computers go from mainframe to desktops to embedded in just about everything.

I've seen computers go from being large calculator only a few people ever used to controlling almost everything in our daily lives. How many computers, microprocessors, and other programmable device did you interact with today? It may be hundreds!

I know a person with a CS degree they earned about 20 years ago. She has to ask her kids to help them send a e-mail or look up a web site. They could not adapt to the changes.

Your most important skill is learning.

[+2] [2008-09-25 16:35:15] Martin Probst

Try to understand the complete stack of software that will turn your ascii characters into an executable program. I.e., understand how a compiler turns your code into bytecode or assembly, understand how a CPU executes your assembly code, understand what a JIT does, understand processes, operating system calls and threads, understand how polymorphism works through vtables and method dispatch.

Of course, not to a level that you could write all that code, but at least having a pretty good idea how software works on all these levels will make you a better programmer, and also give you insight into solutions you might not have thought of before.

[+2] [2008-09-25 17:03:58] Adam Porad

I've found Jeff Atwood's "Recommended Reading for Developers" post to be a good list of reading material.

Suggesting Jeff's reading list isn't a shameless attempt to get brownie points. I had the same question myself and came across the list, so decided that it would be a good place to start. Whether it's the best or most comprehensive list, I don't know. I was just browsing the technical books section at Barnes and Noble, so having a thought out list of recommended reading was a huge step forward in my effort to get better educated.

[+2] [2008-09-25 17:43:10] community_owned

Oh, and also, don't forget to stand up for yourself, and stand your ground when you know something is not true, and someone is trying to "sell you down the river".

[+2] [2008-09-25 12:07:26] MattW.


[+2] [2008-09-26 04:51:10] surajs

Power of searching.

Even the tiniest issue might have answers in the net, if only one is willing to spend some time searching.

[+2] [2008-09-27 01:13:01] Sean Sexton

Nobody has said this yet, but--fundamentals of computer architecture. I'm talking about things like: registers, memory access, and assembly language. Clearly you don't need to know any of this to program effectively. But if you truly want to be a professional developer, you should know the real fundamentals of the machine that you're working on. And this stuff really isn't that hard.

[+2] [2008-09-26 12:24:50] Martin Spamer

Nature gave you two ears and one mouth, so use them in that proportion.

aka; if you have a tendency to talk to much try Listening; if you have a tendency to keep quiet then speak up.

[+2] [2008-09-26 14:32:28] Marcin

Functional programming. It'll teach you to think about how elements of your programme fit together. Terribly useful in object oriented programming.

Learn the difference between a type and a tag assigned by your compiler's type system. This will allow you to write better generic code.

[+2] [2008-09-26 19:11:37] community_owned

Understand that (mostly) the only people who will value your code, will be another programmer. Users will only say "Hey, that's pretty, but can it be with another color?" I just had to live with that. ;)

[+2] [2008-09-28 10:36:30] xardias

I think there are two things every programmer should learn:

  1. Choose the right tools/languages for the right problem
  2. You are programming to solve problems

Seems obvious but I think developers tend forget these two simple things.

Choose the right tools/languages for the right problem

I know many programmer who learned one language (mostly C++) and stick with it. Regardless of the Problem they are trying to solve they do it in C++, because C++ is the ultimate language from their point of view. Even if it could be solved in with a fractional amount of effort and code in other languages.

You are programming to solve problems

I know many programmer (me too sometimes) who start implementing one feature after another because its cool to have them. But in the end many of these features are pretty useless because no one needs them. You are programming to solve a problems for people. So don't let that target get out of your sight.

[+2] [2008-12-16 17:57:00] Scott Vercuski

I've always believed that every programmer should know as much as they can about databases. Every company worth its salt has a database ... no matter what programming language you go for ... C#, VB.NET, Perl, PHP, Python, ASP, Shell Scripts .... you're almost always going to interact with a database of some sort.

I've seen companies run on MS Access, Oracle, MySQL, MS-SQL, Pervasive ... you name it ... any big company (or company who is going to pay you to do work) is going to have a database of some sort.

Knowing how to get info out of that database in a fast and reliable manner will make you look like a hero. Being able to spot an absolutely atrocious query and re-work it can make you look pretty impressive. Just think of some of the apps you've run across with horrid response times ... if it's due to a database query and you can re-write it quickly ... you've just pleased hundreds if not thousands of people in a heartbeat.

So my advice is ... learn about databases ... queries, stored procedures, indices, tables, cardinality etc. ... because in the end it's all about the data.

[+2] [2009-07-29 18:45:14] Larry Watanabe
  1. Algorithms and data structures - independent of language or platform (which always change)
  2. Google :)
  3. Top-down programming
  4. Bottom-up programming
  5. Concurrency and distributed computing
  6. Relational database theory and practical understanding of queries and database design, normalization.
  7. Human interface design principles and human factors.
  8. How to write clearly and simply to communicate information vs. sounding elegant.
  9. Testing principles and theory.

[+2] [2010-11-19 06:52:33] Zain Shaikh

I would like to quote the following only,

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan

[+1] [2010-10-24 20:27:28] Comptrol

The Mother of All Demos [1]

from Wikipedia [2]

The Mother of All Demos is a name given retrospectively to Douglas Engelbart's December 9, 1968, demonstration at the Fall Joint Computer Conference (FJCC) at the Convention Center in San Francisco, in which a number of experimental technologies that have since become commonplace were presented. The demo featured the first computer mouse the public had ever seen, as well as introducing interactive text, video conferencing, teleconferencing, email, hypertext and a collaborative real-time editor.


[+1] [2010-04-13 10:55:54] gath
  1. Drop your ego

  2. Criticism is not evil

  3. Embrace failure

  4. Recover from failure quickly

  5. Practice, practice, practice ....

  6. Be eager to learn from others

  7. Be willing to change

[+1] [2010-04-22 03:59:46] SHiNKiROU

How to understand a program written in a programming language that you did not learn.

(for example, a Java programmer reading C# code without learning C#)

[+1] [2010-04-22 04:49:42] Mark Tomlin

That you must eat your own dog food if you really want to make robust code.

[+1] [2010-06-05 07:15:01] Nikita Rybak

Funny, but I find the single most important skill in my work is googling. Sometimes I google problem even before I think about it :)
Or, if generalize, I'd call it 'information processing': ability to 'scan' lots of data quickly and find the information you need.

[+1] [2010-04-22 15:31:05] Ken

Learn Lisp.

ESR nailed this one [1]:

"languages of particular importance to hackers include Perl and LISP" ... "LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot."

I've never seen a Lisp programmer who couldn't very easily pick up any new language, though I've seen many, many programmers who specialized in every other imaginable language who had trouble learning new languages. There's something about Lisp that stretches one's brain. (I think it has to do with the circularity of defining something in itself.) Like a contortionist, nothing else seems like much of a stretch any more.

My college required all students to take courses in foreign languages and cultures, including non-western cultures. I'm amazed that we allowed people to graduate from the computer science school having only learned C++ and Java.

Yes, when hiring I rank this way above many of the other things here. Any Lisp programmer can learn "Source control, unit testing, and continuous integration" in almost no time, but a Java-only programmer who knows those 3 things may well struggle with closures, or parsers, or something that I actually need. If you know computer science and programming, we can teach you the processes, but not the other way around -- or at least, not on a timescale I'm willing to subsidize with payroll.


[+1] [2010-04-23 00:06:30] Grant Palin

Speaking as a college grad, there are soooo many things I did not learn in school, which I had to pick up on my own. I could go on about the various things I had to learn on my own, but that might take a while :) Instead, I suggest that the following trumps any specific tool or technology:

Continue learning new things. You must have the drive for continuous improvement in order to remain sharp and competitive.

[+1] [2009-09-04 16:27:16] phaedrus
[+1] [2009-09-20 23:14:44] Rachel

As a programmer we should take proper care of our eyes and fingers. Also should take small breaks often to keep mind fresh and avoid silly coding mistakes. Also take proper care of back and be sure to do daily routine of exercise as in programming profession they are high risks of putting some unwanted body weight which might be very hard to reduce down the line.

[+1] [2009-11-21 14:41:08] Chocol8

The existance of

[+1] [2008-12-25 00:09:57] Bill


  • How to learn (things are always going to change)
  • How to communicate with non-technical people
  • How to communicate with technical people
  • How to work in a group
  • How to manage their time
  • How to break projects down, estimate, and plan
  • How to object or criticize without being a dick


  • Basic data structures (lists, hashs, heaps, etc.) Even if your language of choice implements these for you, they still shouldn't be black boxes.
  • A few different algorithms & how to analyze run times. Not everyone needs to know sorting, but to be honest, so many people do, you're in a small minority if you don't.

Most things from there are hard to generalize. E.g., someone working on embedded controllers probably doesn't need to know SQL, likewise a DBA probably doesn't need to know the STL.

[+1] [2009-05-16 18:29:11] kcwu
  • SQL
  • matlab
  • one OO language
  • one functional language
  • one scripting language
  • lex/yacc or similar parsing tools
  • and maybe tex, prolog, vhdl, postscript

Just few hours or few days of exploring is enough. No need to be very familiar to these things.

The main point is to broaden the view of programmer: there are many kind of programming which is so different. Don't let the language you used limit your thinking.

[+1] [2009-06-13 18:01:53] community_owned

My .02 cents worth......

Not knowing how you are going to design/code/accomplish a task while the client is asking for it is NOT reason enough to reject the client request. Sometimes we have to agree to do something BECUASE the client needs it ...and THEN find out HOW to do it.

As Patton once said: 'We are in business to do the impossible"....any slob can accomplish what's possible. That last part I added in ;))

[+1] [2009-07-29 18:39:07] pbailey19

Lots of great answers here, but I'll toss out one more: Do NOT rely on your job to improve your skills. Many programmers figure that five years' worth of following orders and bug-fixing work at a typical IT shop, doing CRUD programming, automatically makes them a "senior programmer". Not necessarily so: I like Jared Richardson's line, "Some programmers have gotten five years' experience. And some programmers have gotten one year's experience, five times."

Accept that is ultimately YOUR responsibility (NOT your boss's) to improve your skill set, learn new languages, and produce higher quality, well-designed code. This could mean writing your own tools at work, it could mean a side project done in your spare time, it could mean a new tech book a month, or it could mean contributing to an open source project. If you can find a project related to something you're passionate about, so much the better.

Whether you're salaried, or a contractor ... ultimately, we're ALL freelancers.

[+1] [2008-12-16 17:39:19] tunnuz

How software uses memory and the processor. How to design good software. How to comment. A bunch of programming languages / technologies, to get the best from each of them and to gain point of view on the whole. How to estimate deadlines.

[+1] [2008-09-29 13:10:51] unochild

To put themselves in the shoes of the developer potentially taking on the project after them - commenting well and naming sensibly.

[+1] [2008-10-30 00:04:27] dongilmore

Recently, I've read credible blogs from technical managers complaining that almost all job applicants for programming positions can't actually code, including those with CS degrees. If this is true, then the answer to your question is clear: what every programmer needs to know is whether they can actually program. Without warning, you should be able to listen to a simple problem, then sit at a computer and code a correct solution in a few minutes.


[+1] [2008-09-28 18:29:19] sammyo

If P == NP

And Assembly, on some platform. Probably will never want to use it but an awareness that it's not turtles (or objects) all the way down, the byte stops here.

I am of course joking about NP, but an understanding of what problems are actually difficult to solve problematically can be quite helpful.

Understand the difference between idealism and pragmatism, and why both are important when designing software.

[+1] [2008-09-28 21:29:10] Jeff Yates

These are things I've learned myself from trial and error over the course of my education and career. I'd say these lessons have served me well although it's sometimes a struggle to overcome my own shortfalls.

  1. How to conceptualise a problem before trying to code it. Designing up front is important and having the ability to properly conceptualise the problem helps to get a good design.

  2. Humility. We never stop learning and we should never assume we know it all. There's always something to learn, and we're always going to have times when we're wrong. It's important to recognise and accept that.

  3. How to break code. Many I have worked with (including me) have coded to meet requirements and didn't spend enough time checking that the code was robust to bad data and bad control flows.

  4. How to understand code. Borrowing from others is not a bad thing, but borrowing without understanding what is being borrowed is a bad habit to get into. Just because it looks like a duck and quacks like a duck doesn't mean that it won't eat like a lion, or BM like a flying elephant.

[+1] [2008-09-27 20:18:04] jakobengblom2

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.

[+1] [2008-09-27 20:55:54] JesperE

Surround yourself with people who are smarter than you are.

[+1] [2008-10-13 08:25:54] ravicini

Every programmer should at least once see his customer/user. You'll get a better view of the user and why he has sometimes such 'odd' requirements.

If you get a bug report, do not search a person to blame and rethink. Maybe it is your fault.

[+1] [2009-01-07 10:58:59] user28954

Every programmer should know the basic of the underlying hardware they work on. What is the difference between languages before choosing one. Know every inch of the language he works on. Know almost 10 different containers. Generic programming. basic Boolean logic, some basic mathematical principles. the 100 basic algorithms. And good goggling techniques.

BUT the top ability of a good programmer is the problem solving and out of the box thinking and believe me you can't learn this you are born with it.

[+1] [2009-01-07 23:18:22] Demian Garcia

Besides the obviuos:

Communication skills

Graphical, Spoken and Written.

(1) Communication Skills seems pretty obvious to me...(still +1'd you, though) - JasCav
[+1] [2009-01-15 18:47:58] Tanmoy

Never Assume Anything. As in Stephen King's Cell ..Assume makes an ass out of U and Me

[+1] [2009-01-15 19:03:24] Mike Robinson

Beware the complicator!

[+1] [2009-03-08 19:01:26] chillfire

a good developer must be able to;

  • step back from the codeonce and awhile to look at the big picture
  • explain what (and why) they are doing to a fellow developer and the office PA and the director and the marketing manager....
  • understand that if the spec hasn't been changed by the time they are about to launch, something is inevitably/inherently wrong
  • take developer crticism as a way of learning
  • NEVER stop learning
  • still get a buzz out of developing good software/code

[+1] [2009-03-11 06:22:20] teriz

Know when to stop.

Don't spoil a good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while.

-- From "The Pragmatic Programmer"

Although sometimes, I just can't help it and my hands are simply itching to optimize it a "little bit more". =)

[+1] [2009-03-11 06:36:10] Patrick Peters

Instead of pointing fingers, point to possible solutions. It's the positive outcome that counts.

(from: "Practices of an Agile Developer")

[+1] [2008-09-26 19:25:34] Karl

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

[+1] [2008-09-27 00:19:45] Omeoe

What this strange little gizmo called recursion [1] is.


[+1] [2008-09-26 18:07:15] Anthony Potts

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.

[+1] [2008-09-26 12:51:28] community_owned

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.

[+1] [2008-09-26 13:05:12] user21110

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

[+1] [2008-09-26 12:19:33] Nrj

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 !

[+1] [2008-09-27 01:37:45] Ferruccio

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

[+1] [2008-09-27 06:32:49] Heat Miser

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.

[+1] [2008-09-27 06:55:39] rasx

To dominate through powerful, verifiable generalities. Making your code as generic as possible is a priority.

Would that not be determined by what language one uses? - WolfmanDragon
[+1] [2008-09-27 08:29:35] Andreas Holstenson

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

[+1] [2008-09-27 23:11:27] Matthew Winder

The problem domain they're working in.

[+1] [2008-09-28 08:10:49] antonio

Every developer out there should read this post [1]:

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


[+1] [2008-09-28 08:45:44] SchizoDuckie

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 [1]), 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
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
@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
[+1] [2008-09-28 09:14:41] stephanea

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 [1].


[+1] [2008-09-28 09:31:10] Firas Assaad

Humility. You're a human being, not an extension of the machine you're working on. You don't and will never know everything and you will always make mistakes.

[+1] [2008-09-28 10:25:18] Goran

Knowing how not to reinvent everything. The vast majority of problems a developer faces has been faced and successfully solved by smarter developers a long time ago. Not using this knowledge is the biggest mistake a developer can make. In the worst case one will not be able to solve the problem. In the best case one will waste time coming up with a solution that already exists.


[+1] [2008-09-25 21:17:05] Kevin Pang

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

[+1] [2008-09-26 11:29:40] Antonio Louro

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

[+1] [2008-09-26 02:35:05] Pat
  • How to read an income statement
  • How to think like a user
  • How to discard features because they confuse users

[+1] [2008-09-26 03:04:08] jericho

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.

[+1] [2008-09-26 05:42:51] community_owned
  • 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.

[+1] [2008-09-26 07:55:13] community_owned

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
[+1] [2008-09-26 08:34:09] pointernil

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

Don't swallow pride!

[+1] [2008-09-26 09:46:55] ksuralta

How to be a Programmer: A Short, Comprehensive, and Personal Summary [1]


[+1] [2008-09-26 10:42:09] SeasonedCoder

Stop worrying and start doing.

[+1] [2008-09-25 12:54:01] HenryR

What you don't know.

[+1] [2008-09-25 14:05:37] community_owned

I no particular order...

Learn all you can about; Algorithms, Design Patterns and Data Structures

Remember programming elegance should be striven for, but not over productivity.

Remember to use Google, heck and now

[+1] [2008-09-25 12:05:34] Slace

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

[+1] [2008-09-25 11:55:25] Lars Westergren

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

[+1] [2008-09-25 19:10:32] Clue Less

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

[+1] [2008-09-25 19:11:33] Barry Brown

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
[+1] [2008-09-25 20:25:57] Geek

Always be willing to learn from your mistakes.

[+1] [2008-09-25 21:56:27] Gary

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.

[+1] [2008-09-25 23:36:53] chocolate_jesus

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
[+1] [2008-09-25 21:05:01] JB King

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.

[+1] [2008-09-25 16:58:02] Nicolas Dorier

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

[+1] [2008-09-25 16:44:53] Will Sargent

The number one thing that you should know as a programmmer: how to take responsibility.

There are going to be bugs. Some of them are going to be yours. You are going to make mistakes and cost the company money. This is guaranteed and known.

When you find a bug, start from the premise that it's not someone else's code that screwed up; it's yours. Be willing to admit that out loud, and learn from it. Keep track of where you make mistakes, and learn how to cover from them; if you have lots of null pointer bugs, then start checking for them in every method. If you have bugs against the database, then start writing functional tests and verify that the queries you're running are correct. Do you have a tendency to go off and write something cool, even if it's not what the customer asked for or wanted? Then start writing out the user stories and use cases beforehand with the customer and hold yourself to them.

There are all sorts of things that you should know, but the most important thing is to know who you are.

[+1] [2008-09-25 16:54:51] Daniel Auger

It is OK to abandon a design or solution once it becomes clear that it is not working or is very suboptimal. This is not the same as saying all your code has to be perfect. I've seen many people spin their wheels for long periods of time on something that clearly won't work in the long run. I think learning to recognize that and change tracks is an important skill.

[+1] [2008-09-25 15:29:54] Jamie Eisenhart

I'm not opposed to generating a list like this, but what you get is probably going to be pretty random and unstructured in comparison to the many books that cover the same topic. I suggest the following as the best places to start: The Pragmatic Programmer [1] and Code Complete [2].

More specific topics like language mastery, design patterns, refactoring, etc. are also super important.


Code Complete (actually in it second version Code Complete 2) is required reading. - AnthonyWJones
[+1] [2008-09-25 16:20:12] Matt Pascoe

I would say the biggest thing to keep in mind is that you are programming the system for the user and not yourself. It doesn't matter how you program the actual system, but rather it meets the needs and requirements of the user because if it meets the needs and requirements of the user they will continue to return to you for business. The opposite being a programmer who programs a system very elegantly, but does not meet the needs and requirements of the users. This is one of the primary reasons people choose Windows and Mac over Linux. Linux is fantastically programmed, but does not meet the ease of use requirement most users are looking for from an operating system.

Other things I can suggest are:

Know when to ask for help.

Know where to ask questions and how to find answers?

Learn how to logically design your code, it will save you so much time and hassle when you are coding. Look into UML designs.

Learn how to properly comment and document your code. I can suggest this for good tips on documenting and commenting your code.

Those are a few suggestions I can provide, but really remember that the user is who you are making the system for.

Some people think that others choose Windows or MacOS often because they came with their computer. - sanmai
[+1] [2008-09-25 16:23:39] HLGEM

Every business application programmer needs to understand data. They need to understand not only the database structure and how to efficienty get data out of it or put data into it, but they also need to understand the meaning behind the data. How is it used for decision making? What is the impact of a mistake in a report? Why do the users want the things you think are silly? What are the legal ramifications of your coding processes? If it is a finanial system, then you need to think if the way you are accessing data creates an easy path for the person who wants to commit fraud. (Never use dynamic SQL of any kind in a financial system because you have to have the rights at the table level. This makes it very very easy for someone to commit fraud.) What data needs to be protected and how should you protect it?

Or better yet, if not on application sever, no DB access for you. - Joshua
@joshua, assuming that you can only or should only access from the application server is big mistake, there are many other processes that hit databases that should not be going through the application server. That is one of the worst of the SQL antipatterns and generally results in poor data integrity. - HLGEM
There are such additional processes, and every one I've seen has and needs sufficient power as to override access settings anyway. - Joshua
[+1] [2008-09-25 16:25:22] Derek

People and communication skills. Seems like those who excel in the IT industry have the skills to "make friends and influence people". It seems trite, but communication and people skills are something you need to work at - just like learning programming skills...

[0] [2008-09-25 16:26:15] stephbu

Along the swallow your pride lines - learn how to divorce your ideas in heartbeat if a better idea is proposed.

[0] [2008-09-25 15:35:02] Silvercode

Every programmer is a programmer. Then there are designers and analysts, too. If analysis phase has been skipped, no one should blame the programmer if he programs wrong things...

Of course small projects might have only one developer, but you get the point.

Sounds like you too still live in the wonderful world of waterfall? ;) - Bjorn Reppen
[0] [2008-09-25 16:56:18] amadamala
  • Be humble to learn new things.
  • Participate in language community.

[0] [2008-09-25 17:42:05] community_owned

Besides knowing how to do the cool, the boiler plate, the borning, and the redundant. Know and learn one thing, you are replacable. Once you get over that, you'll job will be easier. Know that even though there is "internet time", somethings which are worth doing also take time, and cannot be accomplished in five minutes, no matter what your boss thinks.

[0] [2008-09-25 21:10:09] andy.gurin

Know and understand the theory and the algorithms. Anyone could learn to code, but only few becomes those who can teach to code.

[0] [2008-09-25 20:54:56] Adam Gibbins
  • Too learn from your mistakes.
  • Regex - Which I still don't know :-(
  • Version Control.
  • Where to stop with performance optimisations.

[0] [2008-09-25 20:58:56] Simon West

A good level of Math!

[0] [2008-09-25 12:11:25] Marcos Bento

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

[0] [2008-09-25 12:13:52] TomY

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.

[0] [2008-09-25 13:33:42] Bob Minteer

Every programmer should know how to accompany code with good documentation.

I find that code that is well documented (liberal use of embedded comments) is easier to maintain and upgrade.

When a programmer embeds their rationale for an implementation (inline to the code), I can spend less time on figuring it out and more time on the task at hand whether it is adding features or debugging other related issues.

[0] [2008-09-26 10:49:09] Jonathan Swift

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?"

[0] [2008-09-26 00:50:03] MrDatabase

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
[0] [2008-09-27 09:46:45] Priit

How to format code:

  • Decide whether to use spaces or tabs while stepping. If you use spaces, set tab stop width.
  • Almost each language has it's own formatting conventions. Pay attention to these when learning new language. Later on, keep conventions always easily reachable.
  • Don't invent your own formatting rules.
  • Know how to split single, long lines into multiple. Better yet, don't write long lines.

[0] [2009-03-11 06:50:15] Shyam

My list:

  1. Attach importance to and know well the Science and Logic of programming more than the technology that you are working on!
  2. Empathise with the end user and do not give him something just to show that you are proficient in some technique or technology. i.e. do not force a rocket to him when what he needs is actually a bicycle.

[0] [2009-03-24 00:25:53] Rayne


Or at least /some/ LISP. I vote Clojure!!!


[0] [2008-10-13 17:02:05] Kyle Walsh

Figure things out on your own. Or, at least, make a real, honest attempt to do figure the problem out on your own. You'll learn more than you ever will getting the answer from someone else, and it'll be a lot more rewarding.

[0] [2008-09-29 01:59:32] user23313
[0] [2009-12-18 12:10:44] Ahmad Dwaik
to understand
to think
to write well
to optemize
..and to cheer up :D

[0] [2009-12-18 12:15:45] ruibm

Just be a good team player - always accept feedback as a suggestion for improvement and not destructive criticism.

[0] [2009-12-18 13:00:05] Sean McMillan

How to deal with frustrating people without losing your temper.

When the manager drops a list of items on your desk and says he expects them to be done by friday; When the DBA runs a data load script twice; When the sysadmin deploys the wrong version of your code; When the user asks you to explain how it works, again -- That's when you need the be able to handle it with grace. Because you're going to have to work with all these people, and it will go much better if they don't think you're a nasty jerk, no matter how wrong [1] they are.


[0] [2009-12-18 13:18:02] Hagai L

How to use google

[0] [2010-04-22 15:46:37] Uri

The skills needed to get a development job and the skills needed to be successful at a development job are often typically two very different things. In making career choices, prefer places where they are the same.

Conversely, in most jobs 95% of your data structure / algorithm needs are served by library classes. 95% of your time will be wasted by dealing with unmaintainable code written by people who are ninjas at CS but have the engineering skills of a lobotomized beaver.

I rather like the phrase " engineering skills of a lobotomized beaver" - HLGEM
[0] [2009-01-02 16:24:59] arshad

every programmer has to be resource-hungry - has to constantly learn and adapt .

[0] [2010-09-16 20:07:25] user171523

Today I came across this book. It is a very nice book and a good recap of all the best practices.

97 Things Every Programmer Should Know [1]


[0] [2010-04-22 15:08:32] JB King

The real world may not run the same as things did when you were in school. Accept that how a company runs its software development isn't going to match exactly what the theory was that you were taught.

Take some time to understand how things run in a new organization. This applies to everyone but grads may hopefully find it more sobering than others.

[0] [2010-04-21 19:18:25] MJB
  • You will never know as much as you think you do. Even after a few years in the business, you will continue to encounter people who know more than you do about your personal area of expertise. Don't worry about it and keep studying and learning.

  • You will never have learned enough languages or architectures or paradigms or buzzwords. Because once you think you know it all, someone will invent a new (insert favorite technology here) and you will be out of touch again.

  • You will be that old fuddy duddy soon enough. Cut him/her some slack and assume that once upon a time, he/she was in your shoes.

"Don't worry about it?" I don't think that's very good advice. "Do something about it, don't worry about it" might be more to the point. - Yar
OK, I can buy that. I should have written it better. - MJB
I once heard that if someone used the word 'paradigm,' they didn't actually know what they were talking about. - dclowd9901
I can't tell if I have been insulted or not. - MJB
[0] [2010-04-22 03:54:01] fastcodejava

Think outside the box!

[0] [2011-05-25 09:04:29] cma

The Three Great Virtues of a Programmer [1]


[-1] [2008-09-25 17:01:23] directrixx

Mathematics. Programming is just an frighteningly tiny subset of the language of mathematics.

(3) NO! Programming is a subset of Logic! Mathematics is a language, a highly useful language that allows us to communicate values, but still just a language. - WolfmanDragon
[-2] [2009-09-04 16:37:33] Daniel Melo

User's satisfaction matters, code quality not that much

(4) I, respectfully, disagree. User's satisfaction definitely matters. However, code quality matters as well. Heck, if I can't keep my code in order, I may not be able to satisfy my users. - JasCav
I understand your point. What I really meant (and perhaps I should have elaborated more) is that even smelly code can satisfy users if the application solves their problems. Every developer should aim to build good code, but user satisfaction must come in first place. A beautifully coded application that doesn't solve user's problem on time is not that useful, is it? - Daniel Melo
(2) @Daniel Melo: No but it's much more fun to work on :) - the_drow
[-2] [2008-12-27 11:41:32] fsniper

Programming is making computers

  1) Get input  
  2) Process input data  
  3) Generate output

Computers are dumb but real fast..

And without electricty 'or a relevant energy source' there is no spoon..

[-2] [2010-04-29 10:34:47] V S Suryanarayana

How a veterinary doctor does his job!

(1) While funny, very unrelated. - the_drow