Ultimately, it's the people that elevate a project to its success or send it to its doom. When I think about the most successful software developers I've met and the least successful programmers that I've had the fortune to avoid, I have found two attributes that distinguish the best from the rest.
1. Passion
One of the most disturbing experiences I've had (to date; stay tuned for my TSA post) was when I hired a cleaning service. Every few weeks, two or three people would barge into my house with the mission to clean every square inch of surface in my house. Given that mission, they were quite successful. The problem was, they didn't clean quite the way I'd do it. They didn't care! You may argue that my cleaning techniques are less effective, but if I do it myself, I can pay more attention to my personal preferences, e.g. I prefer to leave my shower doors on their tracks and not leaning against the frame; I prefer to leave permanent wall fixtures attached to the wall; I prefer to keep the fridge door closed; I prefer to keep the stove gas off (stay tuned for my Customer Disservice post).
I look for similar passion when I evaluate software developers, and I have since the days when I was a TA for CS 201. I was in the Computer Science program right when the .COM trend hit; many students told me they were choosing Computer Science because "it's the thing to do" and not because they like it (heck, some of them hated it). I find it disturbing when I work with people whose goal is to make it to closing time; I find it fulfilling when I work with people who love doing great work. Although it has many creative elements, software is a tangible work product. You can tell the difference between a product built by someone because they have to and a product built by someone who loves to do it.
2. Fundamental Software Skills
2a. Know Your Tools (or Learn Them)
(Ha! You see what I did there? Stay tuned for my Math post.)
You have to walk before you can run... Blocking, tackling, passing, catching... Pick your quote.
You must master the fundamentals of your craft before you can expect to succeed. I kick myself every time I hire a contractor that doesn't know how to use a bubble level. I've had to redo too many home projects that weren't level. The same should apply to software. I've seen a few well-run test-driven development shops; these instances are great arguments for implementing TDD yourself. But before you do that, shouldn't you learn how to write a unit test? Or use source control? Should we hire programmers that can't figure out where the Start button is?
2b. Communication
Communication doesn't apply if you work by yourself in isolation. Unfortunately, I have yet to find a suitable financial arrangement where I can work in a cave and no one uses my software (stay tuned for my Mega Millions post).
Communication is the ability to take your thoughts and stick them in someone else's head, and vice versa. I don't care how you do it, as long as you do it efficiently and non-invasively. I believe that strong verbal communication is important in a collaborative environment. I believe that strong written communication leads to well-written code. I believe that strong user interface communication leads to happy users. There are many ways to accomplish communication, and a successful software developer must master all methods pertinent to the project.
2c. Attention to Detail
I have difficulty reading resumés past the first typo. If it's a really bad typo (like you misspelled the technology that you work with), I can't continue reading.
This is my tie-in to Passion. If you care about your work product, you'll pay attention to detail. I know, I know, sometimes we're in a hurry and we'll check in a typo. Sometimes we'll check in a new file with a typo in the file name -- those can be more difficult to fix... but you should. On one project, I recall encountering a somewhat humorous typo in a filename, but when we saw that the file had been created years in the past, modified many times since then, and still no one thought to fix it, it wasn't so funny anymore. This even ties back into Communication: our file names, class names, identifiers, code, and comments are all ways that we communicate with other people on the team!
I submitted an application to give a talk on improving code quality. My greatest fear is that my application will be selected and I'll have to pare hundreds of things I can say from my soap box down to the few that can fit into an hour.
Agile software development, particularly Scrum, has been receiving a lot of attention lately. In its best-case scenario, I've seen it amplify the talents of individual team members and produce some spectacular results. In its worst case, I've seen it amplify technical shortcomings and crush entire projects. Technical talks are focused on the latest and greatest processes and technologies, but it's rare that I see a return to the fundamentals -- the basic software development principles for which I penalized many a CS 201 student.