What should every programmer know about programming?

1. The bug is in your code, not the compiler or the runtime libraries.

2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

4. Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.

EDIT

Yes, my point #1 is overstated. Even the best engineered application platforms do have their share of bugs, and some of the less well engineered ones are rife with them. But even so, you should always suspect your code first, and only start blaming compiler / library bugs when you have clear evidence that your code is not at fault.

Back in the days when I did C / C++ development, I remember cases where supposed optimizer "bugs" turned out to be a due to me / some other programmer having done things that the language spec says have undefined results. This applies even for supposedly safe languages like Java; e.g. take a long hard look at the Java memory model (JLS chapter 17).

• How to read other people's code.
• Code doesn't exist if it is not checked in Version Control System.

Floating point computations are not precise.

Don't stop learning.

That the #1 thing you can do to increase the quality and maintainability of your code is REDUCE DUPLICATION.

Troubleshooting and Debugging Skills

They hardly spend any time on this topic in any of the programming courses I took, and in my experience it is one of the biggest determinants of how productive a programmer is. Like it or not, you spend a lot more time in the maintenance phase of your app than the new development phase.

I've worked with soooooo many programmers who debug by randomly changing things with no strategy for finding the problem whatsoever. I've had this conversation dozens of times.

Other Programmer: I think we should try to see if it fixes it.
Me: Okay, assuming that does fix it. What does that tell you about where the source of the problem is?
Other Programmer: I don't know, but we have to try something.

1. Don't be clever; be clear.
2. Use before reuse.
3. Names matter.
4. A function does 1 thing and does it well.
5. Small is better than big.

The basics. Currently programmers learn technologies not concepts. It's wrong.

Every programmer should know that he's putting assumptions in code all the time, e.g. "this number will be positive and finite", "this code will be able to connect to the server all the time within a blink of an eye".

And he should know that he should prepare for when those assumptions break.

Every programmer should know about testing.

Learn concepts. You can Google the syntax.

Critical and logical thinking. you can't do anything good without it.

Unit Testing. This is a great way to codify your assumptions on how the code is to be used.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

That's it's harder than you think.

While it's easy(ish) to put something together that works when used normally, coping with erroneous input, all the edge and corner cases, possible failure modes etc. is time consuming and will probably be the hardest part of the job.

Then you've got to make the application look good too.

Domain knowledge. The spec is never 100%; knowing the actual domain with which you are developing for will ALWAYS increase the quality of the product.

Big O notation and its implications.

Some useful references

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Pointers, obviously. :)

Code Complete 2 - cover to cover

Data is more important than code.

If your data is smart, the code can be dumb.

Dumb code is easy to understand. So is smart data.

Almost every algorithmic grief I've ever had has been due to data being in the wrong place or abused of its true meaning. If your data has meaning put that meaning into the type system.

Which language and environment is most suitable for the job. And it's isn't always your favourite.

Divide and Conquer. It's usually the best way to solve any type of practical problem from scheduling to debugging.

True skill is reflected in the ability to execute a simple design well, not in the ability to make a complicated design work at all.

This skill comes from greater mastery of the fundamentals, not in mastery of the arcane. A high-caliber programmer isn't defined by their ability to code what others cannot (using higher level functions, advanced functional programming, what-have-you) but rather in their ability to refine perfectly mundane coding. Choosing the appropriate decomposition of functionality between classes; building in robustness; using defensive programming techniques; and using patterns and names that lead to greater self-documentation, these are the bread and butter of high-caliber programming.

Writing good code that you, or someone else, can come back to in a week a month or a year and understand how to use, modify, enhance, or extend that code is crucial. It saves you time and mental effort. It greases the wheels of productivity by removing roadblocks that you would have stumbled over before (perhaps interrupting your train of thought, or perhaps taking hours or days of effort away from other work, etc.) It makes it easier to concentrate on the hard problems, and sometimes it makes the hard problems go away.

In a word: elegance. Every class, every method, every condition, every block, every variable name: strive for elegance.

Never blame on the user what could be fixed with a cleaner user experience or better documentation. Often, programmers automatically assume the user is an idiot who can't do anything right, when the problem is a poor overall experience or lack of communication. Programs are meant to be used, and to treat the user with contempt is to miss the point of programming in the first place.

Every programmer should know how to use the debugger, and know how to use it well.

Data structures

How to use Google

Short-circuit evaluation, althought it's one of the first thing they teach you about boolean operators.

How to accurately estimate how much time a feature is going to take to implement. More importantly, how to convey you're not bullshitting when you submit that estimate.

Coding style matters:

• consistent indentation matters,
• consistent use of white space (e.g. around operators) matters,
• consistent placement of { } s matters,
• well chosen identifiers matter,
• etc.

... and good design matters.

Ideally, the programmer learns these things before (or during) his/her first code review. In the worst case, the programmer learns them when the boss tells him/her to make some non-trivial changes to some horrible code in a hurry.