6 ms·

I'm going to go out on a limb and say it's inversely proportional to skill. That is, skilled developers will want a better product/process and they will want t

I'm going to go out on a limb and say it's inversely proportional to skill. That is, skilled developers will want a better product/process and they will want to work with other skilled devs. Putting them in less-than-ideal situations causes frustration. OTOH, a poorly skilled dev will want to push the environment in the other direction, for no other reason than to obfuscate the lack of skill. Putting them in an ideal situation for the skilled dev causes fear. Their aim is job security.

watwut 10y ago
I do not think it is that simple. Skilled developer can still be pretty fine with bad process, as long as worst consequences of the process don't fall on him personally. So when juniors have more mistakes as a result of not knowing requirements or code changes (process does not help to broadcast information), the skilled developer is fine - he is doing most code reviews so he personally knows enough and has control. Skilled developer in that situation will resist changes, because he is fine - it is just that juniors are less capable which strokes his ego. Or when junior are increasingly demotivated due to excessive micromanagement (bad process), skilled developer is perfectly fine - he is the one doing micromanagement. The fact that juniors could learn faster and achieve more will escape such developer. Moreover, more skilled developers are oftentimes better able to offset the bad process. The less skilled developer pays more price for bad process - it turns him from able to do work into unable to perform the work. Technical skill and ability to organize or see through process are not the same thing. You wont be able to organize if you do not have enough of technical skill, but technical skill in itself wont make you able to create good process.
- brandall10 10y ago
  I mean much more than technical skill... communication, delegation, mentorship, humility, culpability, etc. The hallmarks of being a good teammate in addition to someone who can sling code. Character is important. If someone like this is in a situation where they need to micromanage or mitigate that is going to be a source of frustration. If someone has dysfunctional or antisocial tendencies and that's the reason why they're technically excellent, yes, they will gravitate toward chaos, just like they would probably gravitate toward a co-dependent relationship in their personal life. Also to be clear, when I say skilled I'm talking about relative to the expectation of the position. A skilled jr. dev will be one who possesses the potential for greatness and who does good work at that level. As a sr. dev may enjoy mentoring others, a good jr. dev will seek out mentorship. And an ideal environment will be conducive to and support these types of relationships.
JamesBarney 10y ago
Bad devs are devs who just haven't spent as much time thinking about software, they probably don't consider themselves bad developers, and they sure as hell aren't sabotaging projects.
- brandall10 10y ago
  "Bad devs are devs who just haven't spent as much time thinking about software" I would say they lack the character to overcome their flaws... lack of intellectual curiosity and humility. I've worked with quite a few people with 10+ years of experience at large enterprise companies who were flat out dangerous to a project and had to be managed as to what they worked on. People with senior titles who were functioning at a junior level, who simply got the title due to the number of years of "experience". At one place I worked I literally saw a team form from the outcasts of other teams. All they did was copy translated strings into string tables and crystal reports and resize elements on screens in cases of overflow. It was literally data entry. All 5 were highly paid sr. developers. When layoffs started happening at that company they were one of the first groups to get axed... one of them I keep in touch with took two years to get a job, and another recently reached out to me asking for any leads. He hasn't worked in nearly 4 years. I gave him some tips for career development and self improvement, he didn't care, he just needed a job. "they probably don't consider themselves bad developers," That's a problem. Knowing your limits/flaws is pretty crucial, a bad developer tends to have an outsized view of their abilities. Conversely, good developers tend to battle imposter syndrome during periods of growth. "they sure as hell aren't sabotaging projects" Maybe not intentionally (or at least they view it that way), but incompetence has a funny way of dragging down a team. Not putting in the effort to properly understand the domain of the problem or the business model, architecting confusing/overwrought solutions which lack conceptual integrity, not communicating clearly on progress, trying to confuse instead of admitting they don't know, etc.
taeric 10y ago
How do you think you could test this hypothesis?
- deleted 10y ago
  [deleted]

watwut 10y ago

I do not think it is that simple. Skilled developer can still be pretty fine with bad process, as long as worst consequences of the process don't fall on him personally. So when juniors have more mistakes as a result of not knowing requirements or code changes (process does not help to broadcast information), the skilled developer is fine - he is doing most code reviews so he personally knows enough and has control. Skilled developer in that situation will resist changes, because he is fine - it is just that juniors are less capable which strokes his ego. Or when junior are increasingly demotivated due to excessive micromanagement (bad process), skilled developer is perfectly fine - he is the one doing micromanagement. The fact that juniors could learn faster and achieve more will escape such developer. Moreover, more skilled developers are oftentimes better able to offset the bad process. The less skilled developer pays more price for bad process - it turns him from able to do work into unable to perform the work. Technical skill and ability to organize or see through process are not the same thing. You wont be able to organize if you do not have enough of technical skill, but technical skill in itself wont make you able to create good process.

brandall10 10y ago
I mean much more than technical skill... communication, delegation, mentorship, humility, culpability, etc. The hallmarks of being a good teammate in addition to someone who can sling code. Character is important. If someone like this is in a situation where they need to micromanage or mitigate that is going to be a source of frustration. If someone has dysfunctional or antisocial tendencies and that's the reason why they're technically excellent, yes, they will gravitate toward chaos, just like they would probably gravitate toward a co-dependent relationship in their personal life. Also to be clear, when I say skilled I'm talking about relative to the expectation of the position. A skilled jr. dev will be one who possesses the potential for greatness and who does good work at that level. As a sr. dev may enjoy mentoring others, a good jr. dev will seek out mentorship. And an ideal environment will be conducive to and support these types of relationships.

JamesBarney 10y ago

Bad devs are devs who just haven't spent as much time thinking about software, they probably don't consider themselves bad developers, and they sure as hell aren't sabotaging projects.

brandall10 10y ago
"Bad devs are devs who just haven't spent as much time thinking about software" I would say they lack the character to overcome their flaws... lack of intellectual curiosity and humility. I've worked with quite a few people with 10+ years of experience at large enterprise companies who were flat out dangerous to a project and had to be managed as to what they worked on. People with senior titles who were functioning at a junior level, who simply got the title due to the number of years of "experience". At one place I worked I literally saw a team form from the outcasts of other teams. All they did was copy translated strings into string tables and crystal reports and resize elements on screens in cases of overflow. It was literally data entry. All 5 were highly paid sr. developers. When layoffs started happening at that company they were one of the first groups to get axed... one of them I keep in touch with took two years to get a job, and another recently reached out to me asking for any leads. He hasn't worked in nearly 4 years. I gave him some tips for career development and self improvement, he didn't care, he just needed a job. "they probably don't consider themselves bad developers," That's a problem. Knowing your limits/flaws is pretty crucial, a bad developer tends to have an outsized view of their abilities. Conversely, good developers tend to battle imposter syndrome during periods of growth. "they sure as hell aren't sabotaging projects" Maybe not intentionally (or at least they view it that way), but incompetence has a funny way of dragging down a team. Not putting in the effort to properly understand the domain of the problem or the business model, architecting confusing/overwrought solutions which lack conceptual integrity, not communicating clearly on progress, trying to confuse instead of admitting they don't know, etc.

taeric 10y ago

How do you think you could test this hypothesis?

deleted 10y ago
[deleted]