Five signs that developer will not survive team work

I have been working in IT for about 10 years and worked with plenty of great developers, architects and designers. Many of those people formed my current skills and way of thinking. They also have shown me the biggest obstacles for developer to grow. Funny enough during the years I started to see, that few colleagues who didn’t fight those issues ran into kind of developer limbo. More successful have made one product/project and do it for years alone. Others wonder from team to team and always end up leaving because conflicts. Despite anyhow character and cultural challenges, there were always some habits that refrained them from breaking that circle of madness:

1. Being negative to changes

It’s often origin of the issues. It’s sometimes hard, when you put your time and effort do something and one day huge change turns your world 180 degrees. Anyhow that happens. New people are joining the team. New technologies are trending. New clients have new requests. People change their minds. You need proper change management, but if you react negatively to change, because it appears – you should leave.

2. Not reading

That is one of most frustrating things for people who are responsible for introducing others to new project, technology, and methodology. It’s not only about ignoring any kind of documentation, but also about reading. It’s insane how many people (including developers) don’t read messages on their screen. Have you seen someone clicking on OK button on popup suddenly after it appeared? How many times have you asked your colleague to read printed out stack trace, before you have an answer to his complain, “it doesn’t work”? How many times you saw someone taking look on code, never running it, debugging and saying, “it’s far too complicated, it’s rubbish”. If that is your attitude too – coding is not work for you.

3. Pushing off

Regards last point: you can find people who find difficult tasks and push them away. It has sense, if you do LEAN development and specification is unclear, or if you do Tomato Clock development for your prototype. But sometimes you face difficult tasks. Sometimes you have to analyse foreign code. Sometimes you have to use Ctrl+F. Nowadays you have your Inteli-whatever tools that allow you to jump from invoke to invoke without thinking… and if still it’s too hard for you to think over that bigger task, should you code?

4. Taking criticism personally

It will happen that you will find other team members bugs. You will also make some. Sometimes your concepts won’t be compatible and you’d have to trash part of your work to align to the system. If sometime will point problems in your code or concept – it’s for your good and for project good. People who seek in such communicates irony, sarcasm, competition will make hell for the team. It’s insane how many teams meet situation, which project collapse because people can’t be simply nice to each other. Clear communication and awareness in a team is golden. Anyone who creates or increase feeling of micro-fights and high-school-like person to person issues has no place in any project.

##5. Not exploring

Being a good developer require balance of inner child and engineer mind. In rapid and wild IT world you need to feel like Indiana Jones in a jungle. Every day you will find new projects, libraries. Community produce billions of great tools each day. When you work in a team, when you take code made by others you need to feel like explorer. Being curious makes you see issues, tips, paths, and patterns. Being good observer makes you good developer and teammate. If you turn each time you don’t know name of method or class, you will be only annoying coder. Sometimes using magical Ctrl+F can be great code driven adventure. Googling answers to your questions (which for 99,99999999% are already answered on StackOverflow) will give you super powers. Spending half hour on reading tech blogs will let you know what other adventures discovered.

Hope my notes will help you fight your habits in teamwork and made you smile at some point.