| Teamwork | One of the things emphasized most in software development is the ability to work in a team. I tend to prefer working alone, but always within the context of contributing to the team. My style of teamwork emphasizes cooperative productivity. I focus on how my work contributes to the overall project, and I expect others to do likewise. I'm not much into "cheerleading", which some people seem to emphasize, but I think there's a more important issue: I have no qualms about changing or deleting any code I've written if that's the best way to move the project forward. A project shouldn't use bad code just to make the person who wrote it feel good. That's a recipe for disaster. |
|---|---|
| Communication |
Communication is one of the most important issues in group software development.
It's the unifying theme of agile development methods.
XP is communication with the customer.
Pair programming is communication between programmers.
Scrum is communication between management and technical staff.
Good communication involves both parties, both speaker|writer and listener|reader, going more than halfway to the other person's viewpoint. 50-50 is not enough. Most people think they're being more generous than they really are, so if two people in a discussion each think they're meeting the other person half way, each person may really be going only 40% of the way, in which case there may still be miscommunication and misunderstandings. In order to avoid this, each person should go even farther, more like 60% of the way to the other person's perspective. If you're dealing with someone who doesn't communicate very well, then you may have to go even farther than that. At the same time, it's important that each party make an effort to understand the other person, so the overlap doesn't have to be excessive, to the point where the other person feels they're being talked down to. Understanding what the other person does and doesn't understand helps you get past the boundary of misunderstandings with only a few extra percent effort instead of explaining things the other person already knows. Good communication means being able to describe things in both technical and nontechnical terms. I place a high value on good communication in all areas of work and life. |
| Egoless programming |
Some programmers don't like to change code once it's written,
whether it's theirs or someone else's,
even if it clearly doesn't work right.
Instead, they'll write more bad code to undo the original code's mistakes.
They may not be sure what the code really does,
or they may want to avoid hurting the feelings of the programmer who wrote the code.
I have a strong sense of contributing to the team, no matter what that means for code that I've written. If a piece of code doesn't work right, it should be rewritten. |
| Competent programming | I get the feeling a lot of development teams lose track of the main goal in their focus on being emotionally supportive of each other. The real source of ego in a programmer should be how well he or she contributed to the success of the project they work on. A programmer should define their value by their contribution, not by gratuitous displays of technical prowess or by adherence to the group's favorite programming language or development method. |