1. Break it down. A whole project - even an ostensibly simple one - is overwhelming to contemplate and leads to defensive procrastination. Always take the time at the beginning to break the project into manageable components. Then work through the steps until complete. Be sure to review and revise the list of steps as your requirements change.

2. Your requirements will change. Accept it. Embrace it. Understand that the final product will be better if you're willing to change your mind when the facts change.

3. Obey Gall's Law. When coding a project, take the shortest path to a simple application that works, even if it's only a fractional subset of the total project requirements. Then incrementally add functionality, testing as you go, until the project is completed.

4. Document as you go. This includes both code comments and external documentation for application and/or API users. Every time you add or change a feature, update the documentation to reflect the change. Just make it a core part of your workflow. If you wait until you've finished coding to start documenting, it will end up looking forced, rushed, and incomplete. Ideally, include your documentation right in your version control.

5. Use version control. Disk space is cheap and abundant, so commit early and commit often. Make sure your commit comments reflect what you're capturing in each snapshot.

6. Backup and restore. This should be a no-brainer. You need a proper, reliable, redundancy-tested offsite backup, and you need to test regularly that you can restore from your backups. No, a RAID array is not a backup solution.

7. Leave your code in a working state at the end of every day. Don't walk out on code that won't run. It's surprisingly demoralizing to come to work the next day knowing that a broken build is waiting for you. If you have to roll back or comment out a half-finished code block, do it.

8. If you can't figure out a problem, walk away. For small to medium-sized problems, I find a good brisk walk is enough to break the logjam in my mind and see through to a solution. For big problems, I may have to pull out the big guns: a good night's sleep.

9. Fix bugs first. Don't introduce any new features while any identified bugs are still outstanding.

there will be bad days. Some days just aren't meant for programming. Do something else those days or you'll cause more harm than good.

The best way is always to stop when you are going good and when you know what will happen next. If you do that every day … you will never be stuck. Always stop while you are going good and don’t think about it or worry about it until you start to write the next day. That way your subconscious will work on it all the time. But if you think about it consciously or worry about it you will kill it and your brain will be tired before you start.

(more detail: http://www.secondactive.com/2009/08/boost-your-productivity-...)

I would also add 9a. Understand what was causing the bug once it's fixed. I'd say a key hallmark of a bad engineer is if they are happy with a fix even though they don't understand what the underlying problem was.

http://quandyfactory.com/blog/41/top_10_programming_lessons_...

http://quandyfactory.com/blog/41/top_10_programming_lessons_...

Thanks Hacker News! You're my smart way of receiving my technology news :-) My own knowledge is fairly narrow (at least relatively speaking), C#/.NET and Python/Django for the most part, but reading about all of the stuff going on elsewhere in the tech world at least helps me to know what I don't know.

A language is a language is a language

Perhaps I am simply not yet experienced enough, but I find which language I am working with makes a great deal of difference.

I know that some of it is personal preference and knowledge of the languages, but at the same time some of it seems to be that some languages are better suited for some tasks than others, and yes it at least looks like some languages are all around better than others.

Personally, I generally choose Python as my general purpose programming language and prefer it for most projects, and I get a lot more done in than I do in Java. I use C# for many types of projects on Windows, but I use VB.Net only if forced. If I ever decided to write an OS as an exercise I would probably start with C and if I needed to do something heavily statistical I would seriously look at learning R.

More (and I've found this to be true) that once you learn most basic programming concepts in one language, moving to another becomes easier. The more you learn the easier it is to switch to another language.

This I agree with fully.

But at least on initial reading that was not how I took. He seemed to be saying that language choice does not matter, and at least at my current point of development it matters a great deal.

Therefore, having concern of anyone being 'best' is simply a waste of time. Besides, 'best' is purely subjective, anyway. So, a pursuit of finding the 'best' is absurd, and wanting to consider one's self as 'best' is ego (or simply narcissism). It's also a sign of youth, and is to be expected.

But seriously, I would continue to improve out of dedication to the art, science, or craft (whichever you consider programming to truly be).

  1. Start with the answer, then work back.
  2. Name your variables so that anyone will know what they are.
  3. Name your functions so that anyone will know what they do.
  4. Never write the same line of code twice.  Use functions.
  5. Assume the user doesn't know what they want.
  6. Even if the user knows what they want, assume they can't verbalize it.
  7. The user always knows what they don't like.  Prototype often.
  8. Be prepared to dig down as many levels of detail as needed to understand.
  9. When you're stuck, turn off your computer.
  10. Don't turn your computer on until you have a specific task.
  11. Beauty is important, but delivery is more important.
  12. No variable should be fully contained within another variable.
  13. All variables should be at least 3 characters long.
  14. Use the right tool for the right job.
  15. Almost any tool can do the job.  Some are better than others.
  16. Benchmark often in order to learn what happens under the hood.
  17. Try something that's never been done.  It may be easier than you thought.
  18. Remember the patterns you've used before. You'll use them again.
  19. Keep it extremely simple at first.  Complexify as you go.
  20. Code every day.

If you have the variables TodayYYYY, TodayMM, and TodayDD in your program, then you cannot also have a variable named Today, because it's fully self-contained in another variable. Why? Because it screws up global find and/or replace in a simple text editor.

Lots of people have told me that this is unnecessary with a good IDE, and lots have given me lots of common examples of violations of this rule, but I still like the rule (guideline). I like my source code to be portable, easily reviewed by even the simplest tools, and I like the common tasks (reviewing every instance of a variable in a program) to be easy.

One of the hardest things I ever have to do when reviewing someone else's code is to identify every use of a variable to find a bug or understand something. Violation of this guideline is the biggest culprit. (And violent, painful death to anyone who writes a 1200 line function wrapped with "for(a=b;a<c;a++){...")

This is also why all variables must be 3 characters or more, or it would be very difficult to adhere to #12.

(FWIW, my list comes more from many iterations than from any theory or philosophy. We can debate these forever. I just like to do what works for me. Use what you like, ignore the rest.)

I think the divergence in opinions may simply come from working in different domains. In business software, I imagine the types of data may be a lot more varied than in DSP software and such, so a longer variable name may help keep track of things.

Sure, that makes sense.

Don't know if it makes a top 20 though. ;) Seems like it could be a bit hard to manage beyond a local module scope.

Also it is a good idea to avoid too much software architecting from the top down. I made this mistake early on, because "divide and conquer" was how the books said it should be done. Often a more bottom up approach works better, and is more adaptable to mid-project changes in requirements.

1. It may be our own fault -- A lot of things have known solutions, and if they aren't simple we haven't created good enough tools/abstractions. This doesn't apply to truely new stuff, but I could argue that a lot of stuff isn't that new.

2. Absolutely, but so often its like the old kung fu movies jokes. The chinese being spoken is 3 words, and the translation is 3 lines, and the inverse. It makes a naive sort of sense that it should be a simple to do if it can be described simply. (of course karma can be built by letting hte user over describe some things and having them done realtime, some are then more likely to beleive you if you say "its harder than it sounds")

It took me 6 months and a couple days, working 40 hour weeks.

It wasn't. It's not even complete, and it took me several weeks of free time (much of which was spent simplifying my code).

[1]: http://www.loup-vaillant.fr/projects/ussm

I've seen lots of people, even experienced coders get overwhelmed when they make a change, screw up the syntax and see screens and screens full of errors show up.