I started off programming with no formal education in it all. I suspect this was (and still is) pretty normal, especially with the culture around programming. However, this inevitably means that you're missing a lot of useful knowledge that you end up picking up the "hard way" ... by making mistakes and slogging through it. So, what mistakes did you make early on that you think might be useful to people starting out now?

For me it was: Do not store money in floating point variables

One of my first applications was an office management suite that had to deal with money. I had never heard of fixed point numbers, I didn't know anything about internal representation yet. And I paid for it with weeks of tracking down missing pennies from round-off errors. The lesson was to never, ever use floating point numbers for something that has to have an exact decimal representation. This seems obvious now, but a decade ago it really wasn't.

Work arounds:

  1. Fixed point numbers. Databases have them. Most frameworks have them now. Use them.
  2. Failing that, store / do math on everything as in integer, scaled to store correct precision. (ie, multiply everything by 100 if you care about 2 decimal places), divide by the scaling factor for display, but do all math on the int.
+59  A: 

Version control is an absolute necessity. It's something that goes without saying when working with experienced devs in a team environment, but is easily overlooked when you're just developing on your own without any guidance or perceived need for rollbacks/auditing.

Kevin Pang
TortoiseSVN is a wonderful tool to show to a novice.
Ben S
+1 Code is not code unless it's in a version control.
Something every new programmer learns by suddenly realizing he lost a few days work and has no backup.
Backup of the source control is also important.. :)
John Christman
I wish I had a +10 upvote. Sad that it still has to be said at all.
+26  A: 

Comment your code!

...or you'll be kicking yourself a month later when you're trying to fix something and have no idea how it works.

I agree 100%. I inherited an embedded software project, some year ago. there was an undocumented, concept in it that at first seemed like a huge waste of memory and time, to us all. It wasn't until, we ran into a situation that this code was necessary, that the true genius of it was discovered.2 lines of comments would have (and currently do) tell the tail of this genius code.
John Christman
And write docs in the correct way:
+27  A: 


When learning a new language, or trying to get something to work in a known language, there is almost always documentation showing you how to go about doing it.

Reading the "Getting Started"-type of manuals, or even spending an afternoon reading over the interesting parts of "Programming Guide"-type, in-depth manuals really pays off.

Ben S
I wish I could upvote this multiple times.
Alternatively, ask a noob question on Stack Overflow.
Hamish Grubijan
+22  A: 

The most successful programmers aren't always the best programmers. Being great at writing algorithms means nothing if people hate how you present ideas and how you intereact with other members on the team.

"It's not enough to be right."
+3  A: 

Document / comment your code. You may think it's unnecessary now, but the first time you come to a chunk of code and say "What idiot wrote this? Oh, apparently I did..." you'll recognize the value.

XML Documentation in C# is what really encouraged me to start documenting my functions. Giving structure and reason (Intellisense) to documentation is what was always needed.
Will Eddins
+1, theres plenty of times you write your code and think "this is pretty straight forward" then later after you've forgotten it and need to revisit, you think "this isn't as straight forward as I thought it was" – Neil N 0 secs ago
Neil N
@WillEddins: yeah, I agree; I prefer the unified style of JavaDoc, but I agree that the C# documentation process is good too.
StyleCop is a life saver in C#.
Hamish Grubijan
+11  A: 

It's not about the code - It's about solving a business problem. You get a pass/fail grade in the real world. Your users can solve the business problem or they can't. Period.

No Refunds No Returns
I gotta say there are shades of gray; if your user interface makes it remarkably difficult to do something, but you *can* do it, another company with a better interface will eat your lunch.
Dean J
+17  A: 

Don't over-engineer

Or you won't meet your deadlines nor your cost target.

Unfortunately it can be hard for new programmers to recognize when they're overengineering. Then again, that's sometimes true of very experienced programmers as well.
Dan Olson
"abstraction astronauts"
Neil N
Just give it a "DRY KISS, SR!":
+4  A: 

When you find yourself staring at a bug without making progress for more than a certain amount of time (my guideline is 1-2 hours), it is absolutely time to run it by someone else. In the rare case where that is an impossibility, it's time at least to get up and walk around.

Joe Mabel
I find just the act of explaining it to the other engineer, makes me realize the problem, more often than not. Sometimes while the other engineer is still confused as to what is wrong.
John Christman
Yep. That happens to me all the time. Sometimes I'm tempted to just start talking to myself like a crazy person because just trying to explain the problem out loud seems to help.
Sounds like rubber duck debugging:
Jason Baker
Ha, never heard that term before, but a former coworker had received a stuffed bear from a vendor that he kept on hand for debugging help.
+5  A: 

Learn the most common design patterns

Learn the most common algorithms for datastructures (and more importantly their Big-O values)

I would actually suggest to a novice to forgo learning design patterns until they have a little bit of experience. I've had too many novice programmers on my team who thought that *everything* needed to use design patterns...
Ben S
Yeah.. That's true. I guess that's an anti-pattern. Aaah, the paradox :)
Just don't mix your patterns and anti-patterns: complete conversion of pattern to energy! huge explosion, people killed.
Patrick Karcher
+2  A: 


+29  A: 

Don't re-invent the wheel.

Almost certainly someone, somewhere has done something either similar or identical to what you want to accomplish. Use it. Learn from it.

While I agree, I also think that reinventing is good for learning to do things yourself. When on schedule, reuse. When just "doing it for fun" or such, reinvent. (Not a strict rule =) )
Jani Hartikainen
A corollary to re-inventing the whell: Do not use regular expressions to parse XML, there are XML parsing frameworks for this.
And regexps aren't the proper tool for parsing XML^h^h^h anything at all really, anyway.
My favorite quote (don't know the author): "The thing about reinventing the wheel get a round wheel". The opposite is *much* worse: bloating with 3rd party libs for every little thing.
+1  A: 

Things that shouldn't happen, may actually happen. A common example is asking for a number and getting something outside of base 10 values.

JB King
+6  A: 

Technically: Recursion.

Overall: the job is to ship code, not to perfect it.

"The Pragmatic Programmer" is what I give to all of our new developers here.

Dean J
I wouldn't have said The Pragmatic Programmer was really about that type of pragmatism... Unless I totally mis-read it :P
It's not about that type of pragmatism, but it really helps folks avoid common errors by giving them some informal training as a developer that colleges seem to miss.
Dean J
And then there's the joy of writing code just for yourself, just for fun, and code you can actually perfect. (Or try to, anyway...) ;-P
Producing something - anything - for pay is always a lot different than doing it for fun. When you're doing it to pay the bills, the priorities change quite a bit. For the vast majority of developers, shipped code is better than perfect code, because shipped code pays the bills.
Dean J
+5  A: 

Learn the general principles of programming before you become wedded to one particular language. It will help you later as you move from your first programming language to your second, and so on.

Get a good book on the principles of programming, it will serve as your foundation.

Ivan Nevostruev
+2  A: 

Just because it shouldn't happen doesn't mean it won't. Find and fix those edge cases before they bite you!

Matthew Jones
+12  A: 

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan

Brilliant. I've always *felt* this, but never could put it into words with this kind of beautiful precision. Thank you!
+2  A: 

If you think it's got to be a hardware problem, or an operating system problem, or a bug in the language/compiler, or a bug in the API, it's probably not. 99% it's a simple bug you overlooked, and the quicker you realize that, the quicker you can find and solve it.

+2  A: 

There's a difference between programming and computer science. I learned to program doing projects in college - the only programming course I ever took, I hated. Teachers have a way of telling you the "right way" to do things (which makes grading easier). I much preferred learning from other programmers and discovering for myself what worked and what didn't.

At the same time, formal computer science and discrete mathematics are beautiful material, and if you can learn them in a coursework setting from a good teacher, it's incredibly valuable, not just intellectually, but practically.

Mike Dunlavey
so true. so true.
+23  A: 

Odds are the popular API you're connecting to isn't what's broken.

A hard pill for all programmers to swallow can be that there is a problem in their "perfect" code. I've known so many tech people in general who, when something goes wrong, immediately blame someone else without even considering the possibility that it could be their mistake.

Everyone makes mistakes, and usually they are only a big deal if they are ignored.

It is also very interesting when you do prove the API is wrong though.
And it can be hell if you're (like me) the kind of person who tends to blame himself before others (thanks, I got better). I once found a bug in the Modula-2 compiler I was using (waaaay back in my Amiga days), *after* I had exhaustively tried to find *my* mistake.
Though sometimes the framework **is** what's broken (Entity Framework and WinForms come to mind...)
BlueRaja - Danny Pflughoeft
+6  A: 

Don't Copy and Paste your way through.

Actually take the time to learn to write an interface/program/library properly.


Yes, the problem could be in 'your' code and not a fault of the system admin / other developers

Too many times the finger gets pointed outward instead of inward, especially if you are a new developer. Swallow your pride and admit: It might just be my fault.

+1  A: 

Don't believe that the programs you are working with are actually written well. Be skeptic and question it. In time, well written sources will be obvious, because you will regard them as 'a joy to work with'.

It's hard to be subjective if you don't know what to look for... sometimes the programs and libraries are not written as well as they should be and should not be considered good sources to learn from.

+7  A: 

Make your code fault tolerant

Do not assume input is formatted correctly. Do not assume variables have valid values. Specify and enforce the pre- and post-conditions for the routines you write.


Use assertions (and plenty of them) to verify the runtime of your programs.

Bonus: It reduces maintenance and future headaches

+3  A: 

Code readability is really, really, really, really important.

For example, if your language lets you use "unless", then use it! It'll read so much faster and easier the next time you look at it than if you used "if !(whatever)"

I think the unless point is debatable. I personally am of the camp that "there should be one and only one obvious way to do it".
Jason Baker
You missed out the "preferably". Intentionally? ;-)
Code haiku for the win:
+6  A: 

Plan it out before you start coding

If you can write out what you're trying to accomplish in paper and pencil first, coding it will be much easier.

I think this is specific to the programmer. It is good to have a plan but someone once told me, "There are two types of programmers. Those that plan extensively and write it correctly the first time, and those that think about it start writing, erase and write again. They both do the same thing and get it done in the same amount of time"
John V.
+1  A: 

There is no relevant performance boost from floats over doubles.

Likely a premature optimization, but I figured "Less data = Faster". Why shouldn't 4 bytes be processed twice as fast as 8? I now use doubles in any cases where memory size is irrelevant.

Will Eddins
This is, if I'm not completely mistaken, due to current FPUs doing all calculations in double anyway (or even higher precision, internally). Back in the old days, *or* when you work on a non-FPU platform (embedded, anyone?), it really should and *will* make a difference.


DELETE from Table;

In SQL, whenever you write DELETE make sure there is a WHERE clause. I would often type the WHERE before typing the query.

That brings back bad memories...
Spent entirely too long recovering a backup because of this. Thankfully I was working late so no one except me was on the DB at the time.
+1  A: 

Don't create interfaces that look like this

alt text

That suck and confuse the hell out of end users!


Not a major one, but I just recently learned how to do threads in Java and used QuickSort for practice. The lession I learned the hard way is that you need to limit the number of Threads executing at once. My quicksort spawned a new thread for each sort (so it was basically: find pivote, spawn thread to sort left right, spawn thread to sort right side). It worked fine for sorting 100 items. It completely locked up my computer with 100,000 items. Lesson learned: Don't use 100,000 threads to sort a list of 100,000 items.

Brendan Long
+1  A: 

Select isn't Broken.

Nick Presta
Except when it is, see my comment above (note also that the referenced site say that it's *rare*. And not "it's impossible").
+1  A: 

Keep your ego in check. Sometimes your colleagues will give great insight, even if it differs from your current direction. Step back and see if it makes sense, with your pride aside, before you write them off.

John Christman

I think having the basics covered from a data structures perspective is very important. It's easy to fall into a "won't happen to me" attitude when writing code, just to get a solution going, only to find further down the line you've used some horrendous data container that doesn't fit the mode of the problem. I've had that nasty feeling of a previous manager saying "let's see how it runs with 100k records", followed by a long pause... ugh. I went back to the books after that little exercise I can tell you!


Learn from other programmers Don't try to figure everything out yourself. Seek out those more knowledgeably than yourself and learn from them.

I got everywhere in my career by doing this. When I wanted to learn a new skill I befriended those coworkers who were fluent in that area and asked for advice and guidance. If you approach people with respect and admiration for their skills and abilities, you will be shocked at the lengths they will be willing go in order to help you.

You can also join local technical user groups. I found the folks at these organizations to be some of the top developers in their area.