The Most Important Skills for a Software Developer

First off, this isn't going to be a post about languages, technologies, etc. It would be borderline pointless to write one of those as they come and go so quickly, which brings me to my first important skill:

Adaptability

Or, if you don't change, you die. Sure there are still some COBOL programmers around, and I'm sure they get paid a lot of money to keep what's essentially a dead skill around, but I have a suspicion that field is shrinking. We've been making a pretty heavy push at work to migrate everything up to the cloud lately. In a lot of cases it's a pain in the ass to do so, but in the end, it'll probably be worth it. Now, imagine yourself as being "that guy" (I'm using the male pronoun on purpose here) that won't adapt, won't learn, won't grow with whatever direction the business wants to go in. Imagine yourself out of a job!

Curiosity

Or, I wonder what this does? This is the one place where a lot of more experienced developers lose their way (speaking from my own personal experience, of course). If you react to something new with "ugggh, it's something new that I have to learn" instead of with wonder, it might be time to re-examine some things. In some ways, it's your job to constantly be pushing the boundaries of what can be done in tech. A large part of that job is learning about what others have done and then implementing that to make things better.

Exploration

Or, huh, that sounds interesting, let's go exploring! In essence, this is the flip side of curiosity. Instead of learning someone else's tech, go build something new. A great reminder for this is to have a 'whizbang' project folder on every computer you control. It's a gentle nudge to always be thinking about the really hard problems. This concept came from Jeff Knupp's awesome blog: Whizbang Project Post

Fearlessness

Or, break stuff! Get your hands dirty! Is it a technology you don't understand, can't wrap your brain around? Who cares! Go play with it, get it installed, get a hello world working, and then go nuts. It's one of the best ways to internalize how a given technology can work (or not!) for you. As long as you're not driving your local sysadmin nuts with breaking hardware, you should be good. All of this boils down to having an entrepreneurial mindset as it relates to pushing tech forward into the future. If you're not learning, pushing things forward, making stuff better, then the question you need to be asking is whether you're stagnating. If you're stagnating it makes it very easy to replace you unless you've built walls of code around your position that only you understand. And that, very quickly, turns you into a curmudgeon (or a BOFH).

Don't be a curmudgeon, no one likes 'em and I've never seen one that was actually happy.