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

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

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

How to read other people's code.

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.

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.

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.

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.

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

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

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.

You can't test quality into a product.

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.

Where his towel is.

42 – no more, no less, folks :)

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

• Regular Expressions
  • What they're good for
  • When not ^[1] to ^[2] use ^[3] them ^[4]
  • How to write readable regexes ^[5]
  • How to debug them ^[6]

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

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

Unit testing and debugging.

Every programmer should understand design patterns ^[1].

How to program in C.

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

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

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

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

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.

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.

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.

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

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.

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.

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.

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

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

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.

THIS ^[1]:

http://media.smashingmagazine.com/cdn_smash/wp-content/uploads/2010/06/aboutprogramming04.jpg

• Source control, unit testing, and continuous integration are far more important than any clever algorithm.

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.

Where to find the information the programmer needs :)

The fact that, No one is indispensable!

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.

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

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

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

All problems are people problems

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.

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.

Do not be a complainer, solve the problem.

The web address: http://stackoverflow.com ^[1]

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

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

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

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.

How to learn.

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

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

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: http://www.codinghorror.com/blog/archives/000020.html

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.

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.

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

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.

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.

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

http://www.codinghorror.com/blog/archives/000020.html

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.

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

Model-View-Controller

Power of searching.

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

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.

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.

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.

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

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.

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.

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.

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

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

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#)

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

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.

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.

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.

97 Things Every Programmer Should know: http://programmer.97things.oreilly.com/wiki/index.php/Edited%5FContributions

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.

The existance of http://stackoverflow.com

General:

• 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

Technical:

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

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

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 ;))

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.

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.

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

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.

See http://steve.yegge.googlepages.com/five-essential-phone-screen-questions

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.

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.

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.

Surround yourself with people who are smarter than you are.

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.

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.

Besides the obviuos:

Communication skills

Graphical, Spoken and Written.

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

Beware the complicator!

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

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

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

(from: "Practices of an Agile Developer")

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

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

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.

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.

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

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 !

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

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.

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

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

The problem domain they're working in.

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

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

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.

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

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.

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.

Goran

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

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

• How to read an income statement
• How to think like a user
• How to discard features because they confuse users

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.

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

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.

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

Don't swallow pride!

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

Stop worrying and start doing.

What you don't know.

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

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

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

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

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.

Always be willing to learn from your mistakes.

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.

Boolean Logic and Basic algorithmic notions

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.

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

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.

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.

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.

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 http://www.gamedev.net/reference/articles/article1218.asp 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.

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?

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

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

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.

• Be humble to learn new things.
• Participate in language community.

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.

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

• Too learn from your mistakes.
• Regex - Which I still don't know :-(
• Version Control.
• Where to stop with performance optimisations.

A good level of Math!

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

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.

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.

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

Binary search. It's useful in a lot of places: search through sorted collection, certain debugging scenarios, programming interview questions.

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.

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.

Clojure!

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

CLABANGO!

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.

Step 1. Read http://www.pragprog.com/the-pragmatic-programmer.

Step 2. Win.

to understand
to think
to write well
to optemize
..and to cheer up :D

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

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.

How to use google

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.

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

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]

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.

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

Think outside the box!

The Three Great Virtues of a Programmer ^[1]

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

User's satisfaction matters, code quality not that much

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

How a veterinary doctor does his job!