Difficult lessons for new programmers?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

RTFM

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

Don't over-engineer

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

Answer 8

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.

Answer 9

Learn the most common design patterns

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

Answer 10

Closures

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

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

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

Don't Copy and Paste your way through.

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

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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

Bonus: It reduces maintenance and future headaches

Answer 25

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

Answer 26

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.

Answer 27

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.

Answer 28

avoid

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.

Answer 29

Don't create interfaces that look like this

That suck and confuse the hell out of end users!

Answer 30

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.

Answer 31

Select isn't Broken.

Answer 32

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.

Answer 33

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!

Answer 34

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.