What makes someone a good software developer? Or more precisely, what qualities does a software developer exhibit that makes me interested (or even eager) to work with them again? Here are the things I am looking for in a fellow software developer:
Asks questions appropriately. Meaning: don't ask for help on every little stupid thing, and also don't beat your head against a wall for three days before telling me - "okay, I'm stuck".
Asks about priorities, if unsure about them. For example, don't assume that the deadline is the most important thing, unless I've already told you that.
Adheres to the standards on the project. I worked with a guy once who set his tab spacing to 8 characters. Can you imagine what that was like to try to read? Okay, that's a dumb example, but do it the way we have already agreed to, unless you can convince me that you have a compelling reason not to.
Demonstrates reliability. Stop telling me you only need two more weeks, since you told me that 2 months ago, and it doesn't look like it is getting any better. Give me a real number, or don't bother making one up.
Admits it when he/she is wrong. No one is perfect, myself included. But I can't take you seriously if you won't admit your mistakes.
Doesn't constantly reinvent the wheel. If there is code already out there that will do what we need, why are you wasting 2 days on writing something you like better? Just use what already works and MOVE ON! (Okay, I'm guilty of this one too sometimes!)
Takes personal responsibility for the quality of his/her code. I saw a guy once who was supposed to design and code the reports for a project. His design was useless. Everyone signed off on the design, because we were crammed for time, and well, he was writing the code anyway, so people thought he had it all in his head. Not so. The reports were slow and didn't work correctly. Another group of people came in and had to re-code the entire thing! Meanwhile, no one wanted to work with this guy, so he was put on the bench, where he started learning new technology - in other words: playing! Every day, people came in and re-wrote his crappy code, and he was goofing off. If it would have been me, I would have come in every day and offered to get those people coffee, donuts, lunch, whatever, because I would have felt guilty. If this guy felt bad - he didn't show it to the people who suffered.
Communicates with me (and others). Tell me what is going on. Tell me if you think you'll be done early - maybe someone else needs some help. But more importantly, tell me when things are going badly. Please, I really need to know.
Isn't selfish. You know, other people are working on this project, too. We don't appreciate it if you take all the credit, and slap us with the blame when things go wrong. Also, don't keep all the "fun" work for yourself, and dump the crappy work on the rest of the team.
A lot of these items may look as if they only apply to software developers who are working on team, but I think they can apply even if you are programming alone. It is still important to communicate with your manager, or your customer, or the end users. And they will quickly realize if you are selfish or unreliable.
These are the things I look for when putting together an effective programming team.