What you get when my brain crashes…

10 Tips for New Programmers

It occurred to me the other day that I’ve been doing this stuff (programming) for more than a few years now - most of them in a very much “professional” manner. So I guess that makes me qualified to come up with lists like this!

1. Learn the machine. Build yourself a computer. Understand how the CPU, memory, and IO work. Even if you forget it all tomorrow, you’ll have at least a rough understanding - trust me, it’s important.
2. Everything you know is wrong. Well, not really, but you need to act like it is. Always go back and look at your code with a critical eye - as if it was written by someone else, if that helps - and imagine that you just know there’s something wrong with it, something terribly, terribly wrong, and it’s your mission to find it. Your code will be better because of this sort of attitude.
3. Communication is key. Coding is basically communicating with a very dumb machine (the computer). You have to give it very, very precise instructions, being very careful to tell it exactly, precisely what you want it to do. The mark of a good programmer is someone who can commune with the computer on an almost instinctual level. But it’s equally important to be able to talk to real, live people in just as effective a manner. So don’t neglect that “speech” class that they make you take in college!
4. Everything you’ve done is junk (a corollary to “everything you know is wrong”). Be humble. Learn from your mistakes. Because you will make them.
5. Doublethink can be your friend. Being a really god programmer means walking a fine mental line between being totally confident in what you’re doing - you think that Bill Gates will show up at any given moment to kiss the ground you’re walking on, that’s how good you are - and simultaneously thinking of your work as the worst possible junk that looks like it was hammed out by a bunch of monkeys banging randomly on keyboards.
6. 99% of the time, it’s been done before. Otherwise known as “be a lazy programmer.” Take advantage of work that’s been done before - unless you really want to learn how it’s done, in which case you should re-write it on your own, get it to work, and then throw it out and use the pre-made code instead. Humility AND experience, all in one deft stroke!
7. Be multi-lingual. You don’t need to be able to write an OS from scratch in x86 assembly or anything, but being able to at least read other languages is a great asset - especially since so much of the 99% of code that’s already been written (see #6 above) has probably been written in a different language from the one you’re using right now.
8. Always think of yourself as a student. Programming languages grow and there is always something more to learn, so always think of yourself as a student, and never let go of that feeling.
9. Know your tools - but don’t be held hostage by them. Experiment with different IDEs. Try a different code editor. Yes, we all love auto-complete and Intellisense, but you should at least not be completely helpless without it.
10. Learn and use source control. Hey, you knew I had to squeeze this in here. There’s just no excuse for not using some form of source control, no matter how small your project is - even if it’s just a little side project you’re doing for nobody but yourself. Subversion is free, and so is the great client TortoiseSVN. They’re both available for Windows and Linux, so you have no excuse for not using them.

Well, there you have it. If you’re a new programmer, hopefully these tips will be helpful to you - goodness knows I wish I had known them all when I started out.

Enjoy!

Music to Code By

I read a post over at Coding Horror today about “Music to (Not) Code By,” and it got me thinking about the music I code by - which, let me just say, is not anything like the music mentioned in Jeff’s article!

There’s always been a sort of unspoken rule with me that the best music to write code by is some sort of techno-electronica type music - preferrably without lyrics. I wrote one of my earliest commercial programs almost entirely to the sounds of Digitally Imported’s “Chillout - Ambient Psy” SHOUTcast station.

Lately I’ve changed over to game music, thanks to the fine folks at Radio GOSU (The Gamers of Oklahoma State University). Of course, some people will argue there is little distinction between “game music” and “chillout techno.” But that’s neither here nor there.

The fact is, there’s just something… “right” about having that sort of music on in the background while pooring over thousands of lines of code, or while designing a totally new User Interface for your program. It’s not quite white noise, and it’s generally up-beat enough to keep you “in the groove.” And staying “in the groove” is, of course, very important for programmers - and any other sort of knowledge worker, in fact.

Maybe it’s the upbeat nature of the music, or the tempo, but I just find it much easier to program when listening to that kind of music.

So I guess the question now is… what sort of music do YOU listen to while you work?

Keithius, the Barefoot Programmer

Call me “the barefoot programmer.”

Actually, that’s not 100% accurate - I only go barefoot during the summertime. It’s just more comfortable - and it helps you stay cool.

Of course, since I work from home, this is not a problem. (It’s nice when the buns come by and say hi - they rub against my feet!)

A lot has been written already about keeping programmers comfortable while they work - volumes have been written about selecting a good chair, a good desk, an ergonomic keyboard, etc. And it goes without saying that programmers - who are more often than not “geeks” - hate formal clothing. So it should be no surprise that being barefoot while programming seems like a logical progression to me.

I also have a tendency to sit cross-legged in my chair from time to time, instead of in the “normal” way. I know it’s terribly bad posture, but sometimes I just need to change my position. And it’s much easier to sit cross-legged when you have bare feet.

Oh - and lest anyone get any funny ideas, my feet are the only part of me that’s “bare” while I work. Jeans/shorts and t-shirts are the order of the day.

So how do you sit while you’re working?

The Greatest Bug of All

Call Me Fishmeal.: Pimp My Code, Part 15: The Greatest Bug of All

This is great story… if you’re a programmer. If you’re not, you won’t get it, so sorry about that.

Some of MY Programming Book Recommendations

Well, I shouldn’t say “recommendations,” since I’m just recommending one book: Testing Computer Software (Second Edition) by Cem Kaner, Jack Falk, and Hung Quoc Nguyen. This is an utterly invaluable book for anyone who ever aspires to be more than just a code monkey.

Technically speaking, this book was written more for “testers” and people who manage testing teams rather than “programmers” but as long as you keep that in mind it shouldn’t be a problem.

This book goes over everything that a good software testing team should do - from bug reports (including how a bug reporting system should be designed) all the way up to how to hire and manage a team of testers. There’s also a lot of stuff in there in regards to dealing with being a tester - because too often in a corporate environment, testers are really looked down upon, especially when finding bugs near the end of a deadline.

All in all, just a really great book.