Work Ethic? Teamwork? Communication?
These are some of the most cited skills on résumés, and traits all employers look for when hiring. This is true, whether they're looking for a Database Administrator or a cashier.
So what skills are more specific to software development?
What distinguishes a good software developer from a great one?
It all begins with one's Standard of Quality.
Truth be told, as long as they put the time and effort into it, most anyone can learn to code. However, not everyone will be able to give something back to each team they're a part of.
To be a truly great software developer, you must hold yourself to the highest standards—even if no one else does.
All of those practices that your computer science professors (if you had a formal education) attempted to drill into your head are far more important than you may think.
Clean Code, Comments, Meaningful Names, DRY
Consistent indentation and spacing isn't all that important when your programs and applications are never more than a few hundred lines.
In the real world, though, you are much more likely to be working with hundreds of files, containing thousands of lines each.
If you, your teammates, or anyone else who looks at your code, can't easily distinguish where one block of code ends and another begins, you're unnecessarily costing someone valuable time—and money.
Comments & Documentation
Commenting your code is another practice that seemed oh-so-unnecessary when writing a program that does nothing more than prompt the user for his name and prints it out to the page.
When dealing with large, complex applications, however, it is a practice that is indispensable to efficiency and usability.
When you comment your code, not only are you making it easier for other developers to both understand and continue your work, but you also lay the groundwork for writing in-depth documentation for your application.
So unless you're one of those people that absolutely delights in writing documentation (do those people exist?), regularly commenting your work can save you a great deal of time—and tears.
If you have to add comments to explain what a variable or function itself is for...chances are that you aren't naming them well.
Meaningful naming is another invaluable practice that might prevent your teammates from hating you.
Don't Repeat Yourself (DRY)
This is a practice that may cost more time than it saves when doing simple, one hundred line projects, but it is crucial to professional software development.
This simple concept leads into possibly the most important characteristic that distinguishes good code from bad - High Cohesion & Low Coupling.
High Cohesion is when small pieces of code or functionality are strongly related to one another within some code boundary—such as a function or class declaration.
The opposite of this is Low Cohesion, where you may have many snippets of code in a block that are weakly related, or not related at all.
Maintaining High Cohesion both necessitates and results in modular code. Keep the individual blocks and pieces of your code as small and simple as possible.
Loose Coupling is the term used to describe having the least possible dependency of one component on another component, meaning that if you change one component, you do not have to change the other.
Loose Coupling is the other half of modular code. Write the methods and blocks of your code to be functional parts, independent of the algorithms used outside of them.
Besides making both your team and your applications more efficient, High Cohesion and Loose Coupling provides yet another benefit:
Keeping your code modular, where small code boundaries perform only one function, allows you reuse this code in other applications, preventing you from repeating yourself in the future. (Yay!)
A great resource on writing great code is Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. You can find it on Amazon here.
Just Good Enough is Never Good Enough
The average person believes that fulfilling the basic requirements of his job is sufficient and satisfactory. He believes that so long as the end goal is met, it doesn't matter how it was accomplished.
The average person doesn't think, or perhaps even care, about whether or not the process, the service, or the product could be improved.
The Software Development Life Cycle is a never-ending process. There is always room for improvement. Technology changes far more quickly today than it ever has in the past, and moving too slowly—or not moving at all—could be the downfall of your company.
Consumers today have an endless array of options. If your photo editing application loads just one second too slow, or if your Kakuro game has an annoying and disruptive ad, users can find a replacement within minutes.
Great Software Developers aren't in this line of work just for the money (although it's a great perk). Great Software Developers love what they do.
They constantly strive to write better code, to make their applications more efficient, to increase user satisfaction.
Great Software Developers don't do this because their bosses, or anyone else, expect them to, but because they expect it of themselves.
No one wants to hire someone they have to nag, coerce, threaten, bribe, or beg to uphold the company philosophy.