I'm still at school, and I know I have problems dealing with other people.

I'm not an angry or shy or different, I just like to work my way and with my opinions while respecting other's, I have a big curiosity and hunger for knowledge, but I lack practice and I guess people don't want to work with me because they might fear I would talk some kind of morale. (For example I started to learn programming using linux instead of windows, even if I use windows a lot. And I have a mac).

What happens to programmers who lack teamwork ? Where does the problems begin ? Does being a good programmer compensate at least a little ? Is it normal for a programmer to have a vision about his work instead of just doing what he is told ?

closed as not constructive by Mark Trapp Nov 23 '11 at 4:57

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

15

There ain't a profession in today's world where communication and teamwork skills aren't valued.
–
Fanatic23Nov 29 '10 at 14:08

1

Being able to admit you have a problem is the first step towards resolving it and this is a good problem to realize you have before its too late!
–
ChrisNov 29 '10 at 17:58

16 Answers
16

The good news is that most of the time, it evolves in the good direction. You will learn how to integrate yourself within a team. You will love it! But I met some people that weren't able to make it and are now stuck is depression.

Depending on the style of management of your company, you will either be rejected by your team or simply fired after a while. So you must be prepared to face some difficulties.

France's most common style of management is based on fear and punishment. This is not a good news for you since it will encourage your individualism. So it will encourage your behavior.

That said, you already know there is a problem with you, so it's a pretty good indication that you have all you need to evolve without external help. The first step is being aware. The second one, the most difficult, is acting on it.

Then it becomes difficult to work on projects that are too large for a single programmer. Difficult for the solo programmer, and difficult for the rest of the team.

Where does the problems begin?

All sorts of places. We currently have a single programmer who is bad at working as part of a team. He tends to make short cuts that have bad effects on the rest of the application because he is too narrowly focused on fixing the bug in front of him. Or writing the new feature in such a way that it isn't compatible with the rest of the application. We have to rearrange things so that every code check-in of his is reviewed by the rest of the team. But in order not to single him out, we also review everyone else's code check ins, so along with the morning status meeting, we get no work done until after lunch. So at our office, this means that 4 people are losing a 1/2 day of work each and every day because one guy is lousy at team work. I can't say it is an improvement over the previous adventures, because we could randomly lose a day to a week (usually chasing new bugs) from his check-ins that break things (we call those "robstacles"). Some of the fixes to his code will end up clearing a half dozen bugs because of how tangled and messy the application is (my recommendation to nuke it from orbit, and start over again because that's the only way to be sure was not accepted).

When we are in a generous mood, we call him a "head down programmer" has he tends to look down at the keyboard and type real fast. He doesn't pay attention to what others are doing.

Does being a good programmer compensate at least a little?

No. Most programmers who are bad team players have a very high opinion of their own skills, and this is called the Dunning-Kruger effect. PDF of paper.

Maybe: the solo programmer would need to be far better than the rest of the team. But this just means that no one else can maintain what he does; and when that happens, it probably means that the solo programmer is not actually far better than the rest of the team - he (and it is almost always a guy) is just better at fooling everyone.

In business software development, the company will be around long after you leave. Programs were most likely written before you started, and will be maintained long after you are gone. If you write things that are so special and amazing that no one else can understand them, then you end up in the situation that Naughty Dog is in - their lead developer quit, no one else understands the proprietary programming language the guy wrote (and wrote things in), so they are now having to switch everything to C++.

Is it normal for a programmer to have a vision about his work instead of just doing what he is told?

It is common - like a traffic jam or diabetes. I would not call it normal. In the corporate world, there are lots of other things to consider; the strong ego that many developers have typically makes the developer think that nothing else matters. This "lack of fit" and lack of consideration for the rest of the business is why so many manager-types come to the conclusion that software developers are hard to work with.

Being a good programmer will compensate a little but only a little. In sixteen years in the industry all the best programmers I've worked with could get on with people - it may not have come naturally to them but they managed it and it was an absolutely key skill. Those who couldn't were tolerated but in honesty not much more.

For me the main area the ability to work with others comes into play is with users and analysts. It doesn't matter how well you can code if you're coding the wrong thing and a good working relationship with the people who are defining the product is key to that.

The first step might be to understand a bit more about yourself. You say you're happy to respect the opinions of others but is this really true? If it is then why do you imply that you're prone to taking moral positions on issues (which tend to be the opposite of respecting the views of others)?

Generally getting on with others tends to be about ignoring who is right and who is wrong (which believe it or not is irrelevant in 80% of situations) and focusing on doing whatever moves the project forward.

Professional software development today is primarily a team effort. The best software is produced through sharing of new ideas and high collaboration and not tinkering by your lonely self. The cowboy coder ideal is a known impediment to teams. In fact, it is by definition the complete opposite of teamwork.

So yes, having poor team skills in a team setting is very bad. But if you are honestly willing to work with it, there is no reason you won't eventually be a great team contributor (with great coding skills to boot)!

Others have already covered most of what I was gonna say, so I'll just add this: just because you have an opinion or a vision doesn't mean you're right or that your approach is the best one. There's a lot you can learn from others if you open your mind to the possibility that they have an opinion and/or vision, too.

Teamwork is about making all those opinions come together into something that builds on the collective experience of the people involved and addresses flaws that a single person might not have considered.

That was one of the first lessons I learned on the job, and I became a better programmer after that.

If you cannot collaborate with others and you are not a naturally born coding stellar genius, you basically block yourself for working on any non-trivial project, because for these you want a team if nothing else than lowering the bus factor.

If you just do not like physical contact, but work well with telecommuting or on open source mailing lists, then you will have to specialize in those skills allowing for working like that.

Unfortunately this can be a bit of an issue as it is rare to work on large projects and not have to work on a team. Even if you work on project interdependently you are generally going to be finding that you have to work closer with the end users which all comes back to teamwork, so it is something that is very important.

That said though, as others have pointed out, this is a learn-able skill (to an extent) and if you put the effort into it. There are generally some courses that you can take here in the United States in larger cities to develop leadership skills; however, part of being a good leader is also being a good follower so those skills are developed as well. Likewise, being able to communicate effectively in public is sometimes a skill that people need practice with and is related to teamwork skills but is sometimes glossed over - someone that is unable to communicate effectively might be cited as not being a "team player" even though just need to work on their communication skills a bit.

However, a large part of working with a team is knowing yourself to an extent and being comfortable with yourself as well as with others so sometimes it doesn't hurt to talk to a psychologist or counselor to see if if there is anything you can improve in regards to working with others.

In regards to your career as a whole, here in the United States, having a reputation of "being hard to work with" or "not being a team player" can be extremely detrimental to your long term career prospects and I would hazard a guess that it would be the same in most other countries. This is also a difficult reputation to shake once it has been established without making a move to another company or possibly even another industry depending upon what field you work in.

Since you're a good learner, there's one more thing you should learn, that some people already know.

Everyone is different, and they are all valuable.

There are times for being independent, and there are times for pulling together. They are both important.

Since you are in school, you can exercise your curiosity and look for new and different ways to do things. That is a good thing.

When you work with a software team, you can contribute your good ideas. Some will be accepted. Some will not. Then you all "put your shoulder to the wheel" and get the job done. That is also a good thing.

My experience on projects is there's a group morale that is low at first, when people are still trying to get the big picture in focus. Then the morale steadily rises as progress is made toward the goal. Toward the end it is very high as your "baby" comes to be "born". That's something you don't want to miss.

In this industry, I think that a fair amount of us expect and assume that competency and the ability to articulate our competency is critical. After all, we go to work to accomplish some tasks in order to earn money, making friends is secondary.

At some point in your life, you will realize one of two things:

You are in a position to be as snide, withdrawn, antisocial, cynical or rude as you like because despite your behavior, your skills (and ability to articulate your knowledge) ends all arguments.

You are just like everyone else and need to be able to work in a team setting, while putting up with (and brain picking) snide, withdrawn, antisocial, cynical and rude behavior from others whose skills and proficiency at articulating knowledge ends most arguments.

If you are questioning this, I think you see some value in participating agreeably in a team setting, and perhaps 'doing it for the sake of doing it' is a good enough excuse to explore the possibility.

I'm also a lot like you. I hate disruptions, It took me the better part of five years just to learn how not to interrupt and dismiss people. I've also worked on teams where I learned more in a month than I could have in a year on my own. Isn't it odd that you only want people around you when you have something interesting to show or discuss?

If you have not yet seen it, take in a viewing of the movie "Real Genius". Pay special attention to Lazlo Hollyfeld. Jump into a team with an open mind, and feel free to borrow my pyjamas.

There is nothing wrong with having strong opinions on how things should be. Any great programmer has plenty of them. However, you need to ask yourself: why am I writing this code?

If it's for your own entertainment, and you can do all the work yourself, then do whatever you please. However, if you're doing it for other people to use, or if you need help, or if you expect that other programmers will maintain it after you grow bored, you'll need to start taking other people's needs and notions into account.

Having a vision is fine. But it really only makes a difference if you can persuade other people to share your vision. Gates, Jobs, and Torvalds all managed to bring their visions to life by making products that served a lot of people, and getting them to buy into their visions. Working purely your way is more pure and satisfying, but it comes at a cost. You may, as Voltaire said, be letting the perfect be the enemy of the good ("Le mieux est l'ennemi du bien").

Team work is a important part of Software Engineering. If you are working alone, you might not be bothered about how others are and what people expect from you. But if you are working with another person, working together really counts. When it comes to software, what you mean by team-work is a really 'communicating well'. Just give respect to your colleague and be tolerant of all ideas. It should be fine.

If you believe something, say it and mean it, but once proven wrong or outranked, accept it and learn from it. Teamwork isn't about agreeing all the time, but having a way to get to the best possible solutions in the given situation and time-frame.

You will end up working alone.
Benefits of working in a team:
1- Interactive Help: you will not stuck in a problem for hours/days.
2- You will learn things that you will not find in books/online tutorials,forums.
3- Competition: will fuel your motivation to overcome teamates.
4- Discussions: which is better than hours reading books and blogs.

Since you are just getting ready to go into the work force, I'm going to point out something else.

Entry level programmers are never superstars. You can't go into a job thinking you are better than everyone else because demonstrably, you are not. You have been competing with other people at your level, so you can think, I'm better than these people, I must be a great programmer.

But someone fresh out of school does not know what the person who has ten years of professional experience knows. You just don't know it yet. Now I admit not everyone with lots of experience is a superstar either and just being entry level doen't mean you can't be a decent programmer. It doesn't even mean you can't become a superstar with less seasoning than some other people (Well some will never be superstars, but thats OK too).

But you won't have the credibilty to get your ideas implemented until you are something other than the most junior person on the team. To get that credibility, you need to be a team player. You need to learn about the business domain and how businesses operate. You need to understand that your personal needs and wants are irrelevant in the workplace most places. You are going to be hired to do a specific job and produce results. Until you have produced some of them, people will be skeptical of whatever you suggest even if you are correct. You have to walk the walk before you can talk the talk.