I always ask myself this question — What is a good developer?

As my first 3 years as a web developer, I would say that to finish your sprint assignments, do not miss the deadline, learn new stuff in my spare time, that’s it.

But now, it is my 4th year of a web developer, I think the above criteria are still valid. However, I realize that team performance is more important than individual achievements. I can say that individual success does not exist when the teamwork is broken. 

A good developer should be a good team-worker which should be above all other criteria.

Good teamwork comes with great efficiency and individual growth, which also impacts personal achievements, salaries, and happiness. I have observed that team efficiency does need every team members’ contributions. Bad teamwork usually just because of very few developers.

Good Teamwork!? How?

Talking about good teamwork is actually talking about teamwork cultures. I am going to explain my views about good teamwork cultures.

Pair programming and its extensions

I feel that the pair programming represents a working attitude of collaboration. Pair programming is recognized as more efficient than 2 solo developers programming separately. The one who drives the session needs to express his design to the other person, and the other person needs to give instant feedback to the driver. The whole process includes phrasing the problem, proposing a solution, implementing the solution.

The idea of pair programming is very useful in other scenarios and it is not necessary to be coding together. I often use pair programming to get unstuck when I happen to have a tough problem. In other cases, when you have a design idea, you can schedule a pair programming session to have someone else review your idea.

After I started doing pair programming daily(sometimes there is no coding, just talking), my coding efficiency was improved at least 40%(sorry, no data support).

The downside of soliciting my team to have more pair programming is that too many pair programming to help out others may slow sprint work. But on the other hand, it is not a real downside. After having a lot of pair programming sessions, I started to hear different opinions, learn more stuff related to my sprint works. It helped me to make better decisions and it eventually boosts my progress. I become more efficient.

Do not be a hero who thinks he can fight the war by himself

I don’t want to be looking bad so I do not need others to unstuck me. I do not need others’ help because I am capable to finish jobs by myself. I used to have this mindset.

Problem-solving is an important skill but it does not mean that you have to train yourself by spending hours on a problem alone without any progress.

If you feel you are smart enough to finish jobs without any assistance, you are walking away from the route of teamwork.

My ideas are awesome, I do not agree with any objections. Is that good? Remember, teamwork does need good collaborators instead of heroes.

Do not treat a good idea as your own precious

Guru dies because of his precious

When you think you may get a solution for a long-running problem of the team or a good idea that can improve the team’s efficiency, you may want to hide your ideas because you do not want others to be ahead of you.

If there is a shortcut in front of you that can help you grow fast, I would like to say it is Share. Share your ideas with the team and get some feedback regarding the feasibility. Get some additional hands to make your idea real.

Ask for other people’s input, always! Do this when you come with a new design, a strategic plan, your personal career goals because you never know whether other people have started working on the similar stuff ahead of you, or whether your career goals are realistic. Having another pair of eyes on your plan as early as possible is always better than having people reviewing something you have done.

Do not turn around when other people are looking for your help

“Sorry, I have an urgent task, please ask other people to help you”.

Sometimes you may say this to your team members when they are looking for your help. It is a polite answer and it is true that you are in a crunch project, you may think. But what I’ve learned is that it happens for someone to look for help for days because everyone gives the same response as you do.

Why not just schedule a 15 min meeting with that person to learn what he is frustrated even the question seems would take more than an hour to figure out. Some times, he can get what he wants during that 15 min because of your help. If that does not work, you can either schedule another 30 min with him or refer him to a proper person.

Most likely both of you will get clear directions toward the final solution when the first 15 min meeting ends. Furthermore, people will feel you are always with them. Every team member will feel safe because their team members, including your, will back him/her up. Everyone loves a happy working environment, don’t you?

Always think yourself as a service provider

Here “Service” refers to your code, it also could be a new feature or a new tool you built. Who is the service receiver? Your coworkers whom you are going to share your code with.

My point is that you should treat your code as a service to your team in terms of readability, reusability, and maintainability. Fill proper documents, use clear function names, all these will help your team members love you more.

Do not try to be a blocker

Most likely you were the blocker who blocked other people’s pull requests because of some valid reasons. Have you ever helped those people to get unblocked with patience and compassion after you blocking them?

If you happen to be a doorkeeper at some level of your team and you have the responsibility to block other people when they do not follow the team-consented flow, of course, you need to say no to them. It is also your responsibility to guide those people to do things right and try to understand their pains.

One more important point here, do not try to set new rules to regulate other team members when the new rules set additional obstacles to your folks who just want to get things done. If there are other options, please do not create rules to solve problems.

Last and most important — Servant leadership

The perfect picture expresses my idea

As a servant leader, you're a "servant first" – you focus on the needs of others, especially team members, before you consider your own.

Final Thoughts

I really love the idea of servant leadership. This is one of the most important characters to be a qualified leader. Teamwork is not about competing with each other, it is about helping each other.

You must be the person who lifts others up first before expecting others to lift you up.