How can you be a quality programmer in a programming team?

Question

How can you be a quality programmer in a programming team? Despite office politics and social indifferences and unrealistic timeframes.

Answer 1

Just follow this great advice:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler, "Refactoring: Improving the Design of Existing Code")

Answer 2

Work a lot.

Stick to specs. Don't encourage scope creep.

Write maintainable code.

Interface with your co-workers in a positive way. Don't blame.

Ask "How can we do this?" instead of complaining about why it won't work.

Answer 3

By asking good questions.

(And I don't mean on SO, although on SO it helps too).

Edit
The responses to this post illustrated my point, about bad questions...
Their main drawback is that they foster lousy responses!
Bare with me, responders (and readers at large), while there are a few worthless responses, most of them convey information which is somewhat relevant to the broad topic(s) hinted in the question; the problem is that [fairly enough] little of this information can lead to practical, actionable ideas.

And BTW, this response is relevant to the question, it is not merely a rant about bad questions. Effective team work implies quality communication, and good questions are both a vector for such communication and a marker of thoughtful, analytical and kind actors.

An informal analysis of the responses shows two main trends:

• they address very different "dimensions" of the issue
• they are generic, and fail to address the "why" and "how"

These characteristics of the responses are rooted in the question. For example what is meant by "quality programmer"? What is the context of the "unrealistic timeframes"?
A good question needn't be long, but it should attempt to frame the meaning of the keywords used. Also [and with a particular caution to not be overly specific and hence narrow too much the field of the potential responses], it should provide statements/examples which show that the question author's is interested in the "why" and "how".

And now for fun I'll illustrate this by asking a similar question and showing similar responses. (Now... this is a rant ;-) pardon my humor)

Question: How can I be a great gardener at the community plot? In spite
     of poor soil conditions, a short growing season and co-op politics?

A1: Be one with the land. Confucius said...
A2: Prevent others to add crops in mid-season.
    Make sure your rows are straight.
    Smile to others.
A3: Reading this [400 pages] book should help.
A4: Systematically measure the watering quantity.
A5: Only use organic techniques
A6: Argue about the early closing of the plot in July and August.
A7: Put pesticide, everywhere.  Also be a good gardener.
A8: Be positive.  Also "There is no 'i' in 'Team'" and "A trip of thousand miles
    starts by a single step".
A9: Vladimir Lenin said ...

Answer 4

Fight for realistic timeframes and social engagement and against office politics.

Answer 5

Learn to say no if you truly don't believe something is feasible. Also do as much research in your spare time as possible.

Answer 6

Lots of good advice so far. Reading the latest edition of Code Complete isn't a bad idea either.

Answer 7

Write maintainable code, listen, ask questions to flush out requirements, don't assume requirements, don't be afraid to take advice and learn, don't be afraid to give advice and teach. Don't waste your time, don't waste other peoples' time.

Answer 8

Version Control!!

the importance of version control, and using it will, gets exponentially higher the more people there are on the test.

Also, always keep the lines of communications open, and make sure everyone is very aware of what other people on the team are working on. This prevents people stepping on each other's toes, our writing code that is going to have trouble working together.

Answer 9

work like hell to keep your skills fresh and up to date.

Spend some time looking at new technologies and see how they can benefit you.

Dont slag off anyone you work with. If you spot problems jump in and sort them. Be a proactive developer. Most of my experience tells me that you only need to be slightly above average to shine (which is a massive shame)

Answer 10

write code which is as simple as possible -- but no simpler. put your code under test to be able to refactor continuously. focus on removing complexity (most often in the form of premature optimization) wherever possible.

Answer 11

Write unit tests and keep them up to date. Don't just think about it - Do it.

Also, read. Keep reading. In particular read Domain Driven Design by Evans.

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

amazing book.

When you read about design patterns, ideas or concepts, build something using them. Even if it is only a little noddy app. I find I will remember and use ideas or patterns I have read about if I built something using them at the time I learned about them.

Answer 12

Remember that G-d created us with two ears and one mouth, so we could listen twice we speak

Answer 13

Learn how to write well.

Not talking code here, but rather sentences and paragraphs, etc. You know, spelling and grammar, proofreading and editing. As programmers we're not always writing code, there is also documentation and proposals, specs and memos, and at the very least, email. Good writing = good communication.

Answer 14

Great answers here already. Apply yourself by becoming one with the Tao.

Answer 15

don't be discouraged by unpleasant code reviews (which I have been exposed to) and be open to suggestions about improving quality of your code, in the long run that will make you a more efficient programmer and shows that your a team-player.

Answer 16

Always be polite, but be ready to fight for the resources you need to be able to do good work. For example, writing tests costs a lot of time - an investment that will repay thousandfold, but those who pay for your work often don't know it. They just see a double-digit drop in productivity at first.

If you are in the position to do so, try to explain why taking time for {insert good practice like code review or unit testing her} pays off on the long run.

If you are constantly denied these resources, and there is no change to be expected, don't be afraid to consider changing jobs.

Answer 17

How to Win Friends & Influence People - Basic Summary has some ideas from Dale Carnegie's book that may also be useful.

Answer 18

Remember that it is our code, not your code, so when everything goes wrong take responsibility, do not look for the responcible.

Think of your coworkers when writing code, emphasis should be made on easy to read, not quick to write

Communicate, ask if you don't know, tell if you have opinions.

Read the books - learn - keep updated. Know the whys as well as the hows.

Do not frown upon everything unknown, investigate. The technology/metodology emerged for a reason, be sure to know why before you discard/embrace it.

Answer 19

Take responsibility for the big picture. Eg. don't focus on writing code - Focus on solving a need/problem, where code is a means to achieve that goal. Don't stop till the problem is solved, regardless of if you've done your part.

Answer 20

"Good coders code, great reuse."

Answer 21

1. Be humble.
2. Remember that you're not you're code.
3. Always remember that someone in the room is probably smarter than you.
4. Don't re-write code without consulting with the team.
5. Remember that when it comes to requirements, the only constant is change.
6. Don't isolate yourself.
7. Critique the code rather than the coder.

Answer 22

"This above all: to thine own self be true, and it must follow, as the night the day, thou canst not then be false to any man."

Answer 23

Besides all the technical stuff mentioned before, It's important to understand that usually a programming team is a team of smart people that are more severe with dumb questions and have a tendency to be selfish, so it's important that even you are good enough don't be so arrogant and try to emphitize the more you can. Your office days the will be more comfortable

Answer 24

This gets deeply into issues of teamwork, which is a huge topic all by itself. As a starting point, I highly recommend reading Teamwork: What Must Go Right/What Can Go Wrong by Carl Larson and Frank LaFasto. short, highly readable, superb book.

Answer 25

Besides most things already said, I would add: Focus, focus...focus. Too often I have seen really good developers get bogged down with unimportant stuff around them - and even important stuff. Even though there are needs elsewhere, it's important to focus on the task at hand and get it done. It's sometimes hard with all the distractions around (and I'm not talking facebook, etc. I mean work related distractions) to focus on what need to be done.

Obviously this can also be applied to life in general.