5 ms·

I find it amazing how many people in a team don't share their insights, assets or experiences with the team. Why is that? Is it fear?

nedwin 14y ago
A saw a post on Twitter a couple of weeks ago from a guy who was in his last week of his job. He claimed his employer was trying to "milk him" by asking for a handover guide for the next person taking over the role. I think that people hold onto information for power, to protect their position and to give them leverage over their situation.
- digitalengineer 14y ago
  I think you're right. Like Klaas said in the presentation, such behavior usually is a reaction to the working ethics of the company. Screwing your colleagues (and the company) is rewarded by (lousy) management or management with a hidden agenda.
pcrh 14y ago
Most frequently it is because they are in a competitive environment and fear that they won't be given credit for their contribution.
lazyjones 14y ago
It's probably the "I don't get paid for that" attitude ...
- pc86 14y ago
  Which is a cop out anyway. Programmers don't get paid to "write code," they get paid to solve problems. Part of that is discussing options and strategies with teammates and making sure everyone is on the same page (or as close to the same page as possible when you have teammates with vastly disparate specialties and expertise).
- ExcitedByNoise 14y ago
  That is the worst. The "That's not my job" attitude is from people who are not team players and believe that they are above doing certain work, regardless if the work needs to be done. If you work in a problem solving profession, then you just can't have this attitude, because eventually someone is going to ask you to solve a problem outside your domain, and if you can't figure it out, then it doesn't get done or they get someone who will figure it out. Although people bringing their stapler to the IT help desk is one of those times I might not be mad if the response was "That's not my job"
martswite 14y ago
In my experience, which, granted is limited (3.5 years programming), one or two team members I work with very rarely share their insights. In the case of these team members I think one comes down to fear of maybe looking daft in front of the rest of the team by saying something that they think might be wrong. The other can just be a sanctimonious prick and will ask people questions that they simply wont know the answer to, to show them up in front of the rest of the office. So in my experience fear is certainly a factor holding a person back. However on the flip side a person lording his knowledge over other people but not sharing it in a useful way conducive to improving the general programming knowledge of the team. They both harm the team but in different ways. I don't know how these two problems can be solved though. Maybe encouraging opinion from the people who fear sharing their points of view and being supportive of them would help. I'm at a loss though with regards to the power-bitches that like to make people look small with their own knowledge.
- alinajaf 14y ago
  As a sanctimonious prick who asks a lot of leading questions, I find it's very difficult to communicate technical insights with other members of my team by just giving them the answers to the hard questions. What I'm guessing you'd like sanctimonious pricks like me to say: "That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use." This categorically does not work! Don't do it! It allows for zero shared credit, puts everyone on the defensive and leads to bickering and bike-shedding. In the best case, the person you're arguing with will disagree vehemently, go away for a few weeks, then come up with a new idea all by themselves that is exactly the same as what you were arguing for. This achieves the same result but isn't a very pleasant way to get there. Questions work marginally better. In general my lines of questioning follow one of the following formats: 1. Is there a reason we're not using <a := some no-brainer technology choice> instead of going to all the effort of rolling our own <a>? 2. Have you thought about how that's going to work when <one or more use cases that are almost definitely going to happen that you clearly haven't thought about>? 3. Is <b> something we're just doing now to get it working and then planning on refactoring later? <where b := a horrible mess they just merged into master> 4. It looks like the script is running when I enter <script>alert('bazinga!');</script> as my username. Seeing as it's your commit that caused it would you mind taking a look at that? In terms of sharing insight without offending people, that's about as polite as I can get I'm afraid.
alinajaf 14y ago
As hinted at in a comment a few threads down, sometimes the sheer effort of trying to impart some knowledge or technique when other developers clearly don't want to hear it takes its toll. In those situations, it is a lot less effort to allow developer B to commit whatever the hell they want into the codebase, wait until they lose interest and then go in later and clean up the mess.

nedwin 14y ago

A saw a post on Twitter a couple of weeks ago from a guy who was in his last week of his job. He claimed his employer was trying to "milk him" by asking for a handover guide for the next person taking over the role. I think that people hold onto information for power, to protect their position and to give them leverage over their situation.

digitalengineer 14y ago
I think you're right. Like Klaas said in the presentation, such behavior usually is a reaction to the working ethics of the company. Screwing your colleagues (and the company) is rewarded by (lousy) management or management with a hidden agenda.

pcrh 14y ago

Most frequently it is because they are in a competitive environment and fear that they won't be given credit for their contribution.

lazyjones 14y ago

It's probably the "I don't get paid for that" attitude ...

pc86 14y ago
Which is a cop out anyway. Programmers don't get paid to "write code," they get paid to solve problems. Part of that is discussing options and strategies with teammates and making sure everyone is on the same page (or as close to the same page as possible when you have teammates with vastly disparate specialties and expertise).
ExcitedByNoise 14y ago
That is the worst. The "That's not my job" attitude is from people who are not team players and believe that they are above doing certain work, regardless if the work needs to be done. If you work in a problem solving profession, then you just can't have this attitude, because eventually someone is going to ask you to solve a problem outside your domain, and if you can't figure it out, then it doesn't get done or they get someone who will figure it out. Although people bringing their stapler to the IT help desk is one of those times I might not be mad if the response was "That's not my job"

martswite 14y ago

In my experience, which, granted is limited (3.5 years programming), one or two team members I work with very rarely share their insights. In the case of these team members I think one comes down to fear of maybe looking daft in front of the rest of the team by saying something that they think might be wrong. The other can just be a sanctimonious prick and will ask people questions that they simply wont know the answer to, to show them up in front of the rest of the office. So in my experience fear is certainly a factor holding a person back. However on the flip side a person lording his knowledge over other people but not sharing it in a useful way conducive to improving the general programming knowledge of the team. They both harm the team but in different ways. I don't know how these two problems can be solved though. Maybe encouraging opinion from the people who fear sharing their points of view and being supportive of them would help. I'm at a loss though with regards to the power-bitches that like to make people look small with their own knowledge.

alinajaf 14y ago
As a sanctimonious prick who asks a lot of leading questions, I find it's very difficult to communicate technical insights with other members of my team by just giving them the answers to the hard questions. What I'm guessing you'd like sanctimonious pricks like me to say: "That particular (algorithm|technology decision|doohickey) is bad for the following three reasons, this alternative is better because it's !(those three reasons), is less work, easier to maintain and also offers us the following three affordances. I've used this in a number of other installations and can vouch for its reliability and ease-of-use." This categorically does not work! Don't do it! It allows for zero shared credit, puts everyone on the defensive and leads to bickering and bike-shedding. In the best case, the person you're arguing with will disagree vehemently, go away for a few weeks, then come up with a new idea all by themselves that is exactly the same as what you were arguing for. This achieves the same result but isn't a very pleasant way to get there. Questions work marginally better. In general my lines of questioning follow one of the following formats: 1. Is there a reason we're not using <a := some no-brainer technology choice> instead of going to all the effort of rolling our own <a>? 2. Have you thought about how that's going to work when <one or more use cases that are almost definitely going to happen that you clearly haven't thought about>? 3. Is <b> something we're just doing now to get it working and then planning on refactoring later? <where b := a horrible mess they just merged into master> 4. It looks like the script is running when I enter <script>alert('bazinga!');</script> as my username. Seeing as it's your commit that caused it would you mind taking a look at that? In terms of sharing insight without offending people, that's about as polite as I can get I'm afraid.

alinajaf 14y ago

As hinted at in a comment a few threads down, sometimes the sheer effort of trying to impart some knowledge or technique when other developers clearly don't want to hear it takes its toll. In those situations, it is a lot less effort to allow developer B to commit whatever the hell they want into the codebase, wait until they lose interest and then go in later and clean up the mess.