5 ms·

Most of the skills that you listed only start to really matter if you try to move into a management position. No company or project wants rank and file program

Most of the skills that you listed only start to really matter if you try to move into a management position. No company or project wants rank and file programmers (which is the vast majority of any project) who think there also managers and act as such. Even if you have those skill your job is to focus on your tasks and solve your very specific problems, not the big picture and what everyone else is doing.

michaelchisari 9y ago
I emphatically disagree. All of those skills are necessary to be a strong team member, and thinking that only management requires them is to move into territory where programming as a trade is in need of micro-management and social babysitting by a managerial class. I've been in plenty of teams that were extremely flat exactly because the programmers in those teams were all highly skilled in those areas.
- pink_duck 9y ago
  I have just joined the workforce after uni, and it has never been more clear to me that what you're saying about communication and "people skills" is correct. Almost all of the issues that the company that I work for have are based on lack of communication skills, lack of empathy, too much ego etc. It reminds me of what a coed wrote to me once about the difference between a good developer, and two ok ones. "2 < 1+1" Basically, even if you're higher ranked intellectually speaking and do more work than the average worker alone, two people that can perform adequately and that work together will outperform you. Cooperation is key, and people need to be trained to do better handle that part of the job. Not just produce code. </end-rant>
  - michaelchisari 9y ago
    Your observations are correct, and the more you can nurture those skills in yourself and others right alongside the ability to optimize algorithms and learn new frameworks, the faster you will leave the programmers who don't think these "soft" skills are useful very quickly behind.
  - deleted 9y ago
    [deleted]
  - nd7287z 9y ago
    This claim is entirely unsubstantiated. In fact it is pretty much the opposite of the theses in Fred Brooks' "Mythical man month". I'm not saying Brooks is 100% correct, but his observations are close to what I am seeing in the field.
    - pink_duck 9y ago
      I wouldn't consider my claim any more unsubstantiated than other observations made by a developer, for instance you. I haven't read the book that you refer to, but it seems like Brooks's law (which according to Wikipedia is the central theme of the book) is talking about already late projects. For those, or any already ongoing project, I agree that adding more people will require ramp up time, but I am not talking about late projects alone. I think that for development in general, using something like pair programming instead of the lone, rock star developer, will lead to better code in the end (https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia....). Further, his second point about communication issues is to some extent proving my, and michaelchisari's point. Communication is a skill that is essential, but not stressed enough. If people were better at "communicate complex ideas in accessible ways", as michaelchisari originally put it, then I think it's likely that Brooks' wouldn't have the second argument to support his law (https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law). Essentially, I think it comes down to where we work, what we assume about a project, and how the issues in these projects are best tackled. At my work, better communication would have lead to less work in the long run. This because team leads couldn't clearly state their requirements, the different parties thought they agreed, and work was made that wasn't originally intended by team leads. Moreover, no one that holds a senior position is willing to acknowledge that these communication issues often are two way streets and that they are equally responsible for the miscommunications that happen. They also talk badly about others and have a serious case of hubris, which means that other peoples opinions are looked down upon or sometimes not even listened to. Basically lacking a lot of the skills that michaelchisari originally listed. I hope that this clears out any "unsubstantiated" parts of my original rant for you.
- generic_user 9y ago
  Its a question of degree. Yes you have to have 'some' people skills to be a programmer in a team but its a small amount of skill. In a group of people that probably has more in common with you than any other group you have to interact with in life. But its much less people skills then a manager, in meetings most of the day resolving issues that are much higher level that involve different departments etc. So your average programming job is well within the social skills of the vast majority of Men. When your evaluating a pool of potential hires its going to be 95% finding the best programmer and then the last 5% is making sure there not crazy or a drug addict etc. Its never going to be the case that you start out with a pool of resumes from people with really nice personal bios and try and find out which ones can program a computer.

michaelchisari 9y ago

I emphatically disagree. All of those skills are necessary to be a strong team member, and thinking that only management requires them is to move into territory where programming as a trade is in need of micro-management and social babysitting by a managerial class. I've been in plenty of teams that were extremely flat exactly because the programmers in those teams were all highly skilled in those areas.

pink_duck 9y ago
I have just joined the workforce after uni, and it has never been more clear to me that what you're saying about communication and "people skills" is correct. Almost all of the issues that the company that I work for have are based on lack of communication skills, lack of empathy, too much ego etc. It reminds me of what a coed wrote to me once about the difference between a good developer, and two ok ones. "2 < 1+1" Basically, even if you're higher ranked intellectually speaking and do more work than the average worker alone, two people that can perform adequately and that work together will outperform you. Cooperation is key, and people need to be trained to do better handle that part of the job. Not just produce code. </end-rant>
- michaelchisari 9y ago
  Your observations are correct, and the more you can nurture those skills in yourself and others right alongside the ability to optimize algorithms and learn new frameworks, the faster you will leave the programmers who don't think these "soft" skills are useful very quickly behind.
- deleted 9y ago
  [deleted]
- nd7287z 9y ago
  This claim is entirely unsubstantiated. In fact it is pretty much the opposite of the theses in Fred Brooks' "Mythical man month". I'm not saying Brooks is 100% correct, but his observations are close to what I am seeing in the field.
  - pink_duck 9y ago
    I wouldn't consider my claim any more unsubstantiated than other observations made by a developer, for instance you. I haven't read the book that you refer to, but it seems like Brooks's law (which according to Wikipedia is the central theme of the book) is talking about already late projects. For those, or any already ongoing project, I agree that adding more people will require ramp up time, but I am not talking about late projects alone. I think that for development in general, using something like pair programming instead of the lone, rock star developer, will lead to better code in the end (https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia....). Further, his second point about communication issues is to some extent proving my, and michaelchisari's point. Communication is a skill that is essential, but not stressed enough. If people were better at "communicate complex ideas in accessible ways", as michaelchisari originally put it, then I think it's likely that Brooks' wouldn't have the second argument to support his law (https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law). Essentially, I think it comes down to where we work, what we assume about a project, and how the issues in these projects are best tackled. At my work, better communication would have lead to less work in the long run. This because team leads couldn't clearly state their requirements, the different parties thought they agreed, and work was made that wasn't originally intended by team leads. Moreover, no one that holds a senior position is willing to acknowledge that these communication issues often are two way streets and that they are equally responsible for the miscommunications that happen. They also talk badly about others and have a serious case of hubris, which means that other peoples opinions are looked down upon or sometimes not even listened to. Basically lacking a lot of the skills that michaelchisari originally listed. I hope that this clears out any "unsubstantiated" parts of my original rant for you.
generic_user 9y ago
Its a question of degree. Yes you have to have 'some' people skills to be a programmer in a team but its a small amount of skill. In a group of people that probably has more in common with you than any other group you have to interact with in life. But its much less people skills then a manager, in meetings most of the day resolving issues that are much higher level that involve different departments etc. So your average programming job is well within the social skills of the vast majority of Men. When your evaluating a pool of potential hires its going to be 95% finding the best programmer and then the last 5% is making sure there not crazy or a drug addict etc. Its never going to be the case that you start out with a pool of resumes from people with really nice personal bios and try and find out which ones can program a computer.