A few minor things they might not cover in whatever book or class you’re using (and way more important than ancient maxims like Keep It Simple Stupid)…
Writing Comments in your Code
Documenting intent in code comments is important. Some programmers believe that the source code is the documentation – they’ve never had to maintain someone else’s code.
Documenting what each line of code does, however, isn’t desirable, unless it’s not obvious. So comments like “This implements a piecewise-linear approximation of a sin() function” – awesome.
Comments like “This adds 1 to the count” – terrible, unless it’s some ungodly mess of functions to do that thing – in which case, there’s probably something horribly wrong with the code, and the reason for that mess is worth documenting, not what it does.
Write Readable Code
Write readable code. Readable is more important than optimal – because code always has bugs. (And you in 6 months time will thank you).
Don’t Repeat Yourself
Keep it D.R.Y. – and that means Don’t Repeat Yourself.
If you find yourself writing the same code over and over, stick it in a function. Occasionally go back through your code and do this elsewhere. Don’t get hung up on it though.
Generally, you want it to be code that you use a ton, or that other people might want to use that you do this with. If the language you’re using doesn’t let you do this (unlikely, but it happens), or the code you’re trying to “hoist out” is really tiny, just roll with the punches and don’t worry too much about it.
Build Your Own Code Library
Keep a library of code snippets. If you find a useful way to do something, stash it away for later. You can store it as code files, or as libraries, or just stick it in OneNote or EverNote. All of these work – you just need to be able to find them in a hurry. It saves you a ton of time.
Every expert programmer I’ve ever met keeps their own library of stuffs, by some method or another.
Cheat, But Cheat Wisely
Use the intertubes to figure stuff out. It’s not cheating. But understand what and why the code does what it does before you use it – that puts you ahead of the people who blindly copy & paste, especially because you can modify it later if the code isn’t right
While we’re at it, if you’re looking at other peoples’ code, make sure that the license is compatible with your workplace. People will figure out if you’re copying and pasting GPL-licensed code into your commercial software against the terms of the license. So don’t do it.
Bugs Come in Two Flavors (for the most part)
Most bugs in code written by any programmer can be boiled down into two categories – simple typos and omissions.
Simple-typos can be most quickly found by getting someone else to look at your code – you’ll be blind to them.
Most omissions can be found by talking through the code, statement by statement, explaining what it does to yourself, or to a rubber ducky, mannekin, balloon with a face drawn on it, stuffed toy, or another human – there’s something about the process of serializing it into words to explain it which makes you go “Oh crap!” and notice the bug nearly every time.
Compiler Bugs Do Happen, So Do OS and Library Bugs
Everyone will tell you “no, there’s never a compiler bug” or “no, there’s never a bug in the OS” – they’re wrong. They’re rare, and you have to be off the beaten path a bit, but they do come up (about once a year for most people – more if the compiler/OS is undergoing lots of churn and changes).
How to tell if there’s a compiler bug: check the output of the compiler vs. what you expect to see. Most compilers have diagnostic output you can flip on, usually adding the original source code as comments alongside the output to make it easier to follow.
That said, start by assuming that the bug is in your code. That’s more likely.
Debugging With Style
Use the debugger! If the debugger doesn’t work, use whatever equivalent of console-output functionality you have at your disposal. Litter your code with printf’s, telling you what it’s doing. Just make sure you have a way to compile it all away to nothing when you’re running in Release mode rather than Debug mode.
Log debug output so you can look at what’s going on when you’re running the code, and that it matches what you expect.
Use breakpoints to figure out where things go wrong, and the state before and after.
Use telemetry and crash dumps to figure out problems when the code is out in the wild, rather than just on your machine.
Worst case? Use a binary-search – narrow down where the problem occurs by splitting the search space in two each time (using a logging function on either side that you bring in closer and closer, and one near the source of the problem), using breakpoints/print statements until you find out where the problem lies.
This technique also applies to bad source code changes – you just go back and forward with the checkins between the last-known-good one and the current one until you find the bad one.
Additional Tips from Friends
George Broussard (3D Realms)
Program. A lot. Repeat. Re-read stuff every 6 months as when you read it the first time you weren’t at sufficient level to really understand it.
In fact this is advice for anyone learning any skill ever
Mark Shoemaker (Hidden Path):
I can’t stress this enough. Skills atrophy.
Brandon Mann (Z2/King):
Every now and then, your compiled code can get into a bad state causing seemingly random behavior. Completely clean and rebuild your project. Your IDE can have bugs too.
James Curry (BlackBaud / New Iron Group):
If you’re using git, git bisect is great for finding the bad check-in using binary-searches.
John Cuyle (nVidia):
Addendum to the compiler/OS bug thing: Library bugs are more common than either and happen with depressing frequency. This applies to language standard libraries. Variations in behavior between compilers and library implementations are also common, particularly where behavior is undefined. Never take a dependency on undefined behavior. Know what behavior is undefined.
Nate Waddoups (Microsoft):
Related Quora post: Bootstrapping a career in software.