6 ms·
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. A
by 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 agoYour 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 agoThis 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 agoI 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.