Communication and Programming

Programming is all about communicating – communicating with the computer, and with other people. So it follows that to be a good programmer, you need to be a good communicator, too.

Programming is all about communicating.

Let’s face it – when you really break it down, programming is just a very specialized and highly technical form of communication. It’s communication between the programmer and the computer (or compiler) of course, but it’s also communication with other programmers and with end-users of the software.

So it naturally follows that to be a good programmer, you need to be a good communicator. You might even argue that a good programmer is by definition a good communicator.

Now, we know that the only way to become a better programmer is to program – that is, you get better at programming by programming more. Experience, in other words, counts for an awful lot, and is a wonderful teacher – better than any book or school.

But how do you become a better communicator?

One way to improve your communications skills is to start a blog (which I’ve written about before), and that’s all well and good, but blogging can only take you so far – it is, by its very nature, rather one-sided; you write, other people read (and sometimes comment).

Another way to improve your communications skills – which I have found to work very well myself, and which might be very beneficial in these troubled economic times is, ironically, to work from home.

It sounds crazy – how can isolating yourself at home improve your communications skills? Won’t you be communicating less? How can this possibly work?

I’m not entirely sure of the answers myself, but my theory is that it’s a bit like learning to swim by being thrown into a pool – you are forced to learn. And when you work from home (or work remotely), you sort of are forced to become a better communicator.

Think about it: suddenly, you can’t just walk over to someone and ask them a question – you’ll have to use email, IM, or the phone. And since you don’t have all the wonderful subtleties of facial expressions and hand gestures, you’re going to have to learn how to communicate all of that clearly and conciselyprobably in written form, although over the phone works too (at least then you get the benefit of being able to use “tone of voice”). And for a programmer, there is no greater skill than that of being clear and concise – after all, the best code is that which is clear in its intent and concise with regards to its form. (If code isn’t clear and concise, it’s no better than “spaghetti code.”) 

In a way, it’s like being deaf or blind – you learn to use your other senses even more to compensate. So to make up for the lack of direct, person-to-person communications, you develop your writing (and phone) skills to an even higher level to compensate. You learn to:

  • Eliminate ambiguity and write (or speak) clearly and to-the-point
  • Get to the point quickly so as not to waste people’s time
  • Structure your writing (or speaking) for maximum effect with minimum effort

All of these things help make you a better communicator – and by being a good communicator, you’ll be a better programmer.

Unfortunately, working from home has an awful stigma attached to it – people look down on working from home – which is truly unfortunate, as there are so many benefits. Of course, it’s true that working from home isn’t for everyone – there certainly are types of jobs where it’s simply not an option. But those reasons should be integral to the job itself, not artificially imposed from the outside – for example, a cashier can’t work from home, for obvious reasons. But most office workers – and especially “knowledge” workers, like programmers – could work from home without any trouble. The only limiting factor is really the organization’s willingness to allow it.

On the other side of the coin, there are of course some people who just can’t handle working from home – people who lack the self-discipline to focus on their work while at home, or who don’t have a “space” in their home to work from in the first place. While there’s not much that can be done for the latter problem, the former should be easy enough for any good programmer to overcome. After all, ours is a job that requires focus – if you can’t focus, you have no business being a programmer in the first place.

It’ll be interesting to see if more companies begin to embrace the idea of working from home in the coming years. The economic benefits from it can be great – the company can spend less on office space and the employees can save on gas and commuting costs. The incidental costs of good Internet connections and maybe some IT infrastructure to support remote workers is miniscule in comparison. And as for the stigma associated with working from home – well, I can only hope that it will erode with time.

To Delete, or Not to Delete

To delete or not to delete? That is the (programming) question I’m trying to answer.

Lately I’ve been doing some work on a desktop application that uses a database to store things, and I’ve run up against an age-old question:

To Delete, or Not to Delete?

There is a school of thought that says if you’re going to store things in a database, don’t ever delete them – just flag them as “deleted” or “hidden” and don’t show them unless you do something special. After all, disk space is cheap and that way you can save yourself from embarrassing accidents where you accidentally delete something you didn’t mean to (even the recycle bin can’t save you from every accidental deletion, after all).

Then there is a different school of thought that says if you’re going to delete something – really delete it! Don’t lie to the user and “hide” it and make the user pay the penalty of the disk space/performance overhead/etc. for things they think they’ve gotten rid of permanently. (There’s also an issue of data privacy to consider here as well – if you don’t delete things, and those things contain sensitive information – say, passwords, social security numbers, etc. – is that “right?”)

I’m mostly in the 2nd camp – if I want things to stick around after I’ve deleted them, I’ll explicitly allow for it, though either a backup system (Mozy) or version control (Subversion). Otherwise, when I delete something, I expect it to be really deleted!

Of course, in keeping with the idea of “strong opinions, weakly held,” I do have to consider the possibility of going the other way. And honestly, it’s a hard decision to make. There is no “right” answer – there are trade-offs on both ends.

Which camp are you in – the “keep everything” camp or the “deleted means deleted” camp?

The Desktop App is still King

Although all the “cool kids” these days seem to be writing web apps, and the word “cloud” has taken on a new meaning that is sure to confuse meteorologists and normal people alike, I still think that desktop apps are very important. Maybe even important enough to deserve a little more attention than they’ve been getting lately (living, as they do, in the shadow of the buzzword friendly “web app”).

Although all the “cool kids” these days seem to be writing web apps, and the word “cloud” has taken on a new meaning that is sure to confuse meteorologists and normal people alike, I still think that desktop apps are very important. Maybe even important enough to deserve a little more attention than they’ve been getting lately (living, as they do, in the shadow of the buzzword friendly “web app”).

Now, I’m not deriding web apps here – I use them, too! But let’s face it – the web was not designed to be an application. Look up the history of what hypertext means and you’ll see how far we’ve had to stretch it to get to where we are today.

Even the very best web apps tend to spend a lot of effort to look just like a desktop app. When the lazy programmer in me sees this sort thing, it causes me to develop an unhealthy twitch (in minor cases) or curl up into a ball in the corner (in extreme cases), muttering something about “code reuse.”

Of course, this is just a generalization – there are web apps that have absolutely nothing in common with desktop apps – take Google and Twitter, for example.

But even truly unique web apps still end up tied to the desktop in one way or another. I use Google all the time; but most of my searches happen through the “search” box in Firefox. I use Google Notebook, but I get to it through a Firefox add-in. I use Twitter, but I do so through a client (I’m currently using Witty Twitter, but there are literally dozens and dozens of clients out there).

Sometimes I worry that we focus too much on web app design, to the detriment of desktop app design (UI design in particular). Web apps are cool, sure, but the desktop app is still “king,” and it’s not wise to ignore the king!

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.


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’sChillout – Ambient PsySHOUTcast 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?