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

+9  A: 

By asking good questions.

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

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 ...
Out of all forums kn in the Internet where else would you ask this question and get such great responses from top programmers in the field. Although the paraphrase is hilarious.
upvoted for liberal use of boldface :D
+23  A: 

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.

The "we" is very important. Analyse the emails you send. In most cases you'll want to replace any "I" and "You" or "Your" with "We" and "Our". It makes a lot of difference to the general philosophy of the development team.
Nearly all of this can equate to "reduce the unpleasantness for others". :)
@Mayo: That's a good general rule for life, programming or not.
"Don't blame" - good point. Too many times people are more worried about who broke it than how to fix it...
Philip Wallace
+4  A: 

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.

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.

I've got to admit I would love to do this more if time permitted.
The part about building something using a design pattern you've just read about is the path to a Bad and Scary place IMO. Better to design applications in your spare time and research the best solutions to real world problems when you encounter them, rather than try to apply the seemingly most appropriate academic solution you know (particularly if it's from one of the legion of experts who have suspiciously published vastly more advice on programming in books they make money from than they have reviewable real-world code). </cynic>
Iain Collins
I think he meant that you should build something that you'll probably just throw away afterward. The point being to remember what you read, not to use what you read.
You've put it better. Essentially that's the distinction I was trying to make.
Iain Collins
Apologies for not being clear - If I build throwaway stuff utilising techniques I read about, they're much more likely to become concrete to me and stick around in my mind...
+8  A: 

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

David Moles
Most of the Time easier said then done.
If it was easy they wouldn't pay you the big bucks. :)
David Moles
+7  A: 

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

+7  A: 

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.

Greg Andora
+65  A: 

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")

There is so much truth to this. Readability is a critical code quality metric.
Mike Burton
comments commments comments :) and helpful ones!
Comments can be misleading, better the code be expressive in itself.
+8  A: 

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

Mat Nadrofsky
If you can read it the second edition is printed in Gray and I cannot read it without massive headaches, The first edition is in normal black and white and can be read and it is well worth reading.
+2  A: 

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

+4  A: 

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

Boris Modylevsky
Seems more like a life answer.
Should be rephrased as: Remember that we were born with two ears and one mouth, so we could listen twice we speak.
Chris Shouts
+3  A: 

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

+1  A: 

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.

Cylon Cat
+5  A: 

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)

Matt Joslin
+6  A: 

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.

+3  A: 

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.

Anthony Forloney
+3  A: 

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.

+3  A: 

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

JB King
+3  A: 

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.

+4  A: 

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.

+3  A: 

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.

+4  A: 

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.

Michael Zanussi

The answer is 42.

+3  A: 

"Good coders code, great reuse."

... and awesome coders stackoverflows :)
+1  A: 

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.

David Block
+3  A: 
  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.
Samuel Holloway