5 ms·

Couldn't agree more. In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. Juniors don't have a

by whstl 3y ago

Couldn't agree more. In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. Juniors don't have a lot of experience with complex code, so they just make simple code which I can understand with a glance. Mid-level developers are often into trying new stuff and fall in love with complex solutions, so the code isn't really easy to understand, but damn if it isn't interesting, full of crazy new libraries, patterns and ideas. Seniors have a lot of experience with complex code, so they just make simple code which I can understand with a glance. Similar: https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.htm https://pages.cpsc.ucalgary.ca/~robin/class/449/Evolution.ht...

JohnFen 3y ago
Yes, there's a name for this, but I forget what it is. Being a beginner or a true expert are relatively safe. Beginners are aware of the limits of their knowledge/skills. Likewise, true experts are aware of the limits of their knowledge/skills. In between the two, though, people tend to think they understand more than they actually do. And, of course, being a beginner, intermediate, or expert is topic-specific. You can be an expert in one things and a beginner in another at the same time.
- Benjammer 3y ago
  It's along the same lines as Fred Brooks' "Second system effect," although not quite the same.
- astura 3y ago
  >Yes, there's a name for this, but I forget what it is. Resume Driven Development.
- hhh 3y ago
  Bell curve moment
- 6D794163636F756 3y ago
  This sounds like the Dunning Kruger effect
  - JohnFen 3y ago
    Dunning-Kruger is certainly a closely related effect, yes, but wasn't what I was thinking of.
- lcnPylGDnU4H9OF 3y ago
  > name for this Sounds like "Advanced Beginner" https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... "Expert Beginner" is the one who barely knows shit but convinces themselves they know everything and "Advanced Beginner" is the one who thinks they know just slightly more than they really do until their compiler gives them an error they didn't expect.
- B1FF_PSUVM 3y ago
  > a name for this The canny valley. Aka just learned enough to be dangerous.
- phkahler 3y ago
  >> You can be an expert in one things and a beginner in another at the same time. That's apparent or implied mastery. Psych friend says it happens all the time, executive type comes to therapy. He's a master at his business, has all sorts of industry experience, really knows his stuff, but then has trouble in say... personal relationships because he's absolutely clueless on those types of things. Mastery in one area does not imply it in another. So when you think "this person is really smart, why are they making xxx stupid decision?" just check if the reason you think they are smart is in any way related to the area of the stupid decision ;-)
- jchanimal 3y ago
  A complication is the skills curves overlap so while I was a dangerous intermediate at database design 15 years ago, now I am a dangerous intermediate at organization design.
- cratermoon 3y ago
  Richard Dreyfus came up with a Five-Stage Model of Adult Skills Acquisition. 1 Novice. Follows simple rules. Performance is poor. 2 Advanced beginner. Rules modified by context & situation. 3 Competence. Able to recognize more contextual elements than can be used. Ability to chose a perspective for analysis and prioritize features of the context. However, does poorly at choosing the right perspective. 4 Proficient. If detached rule-following is replaced by intentional learning, learns to use judgment and emotion in choosing perspectives. However, that judgement and emotion informs a decision still based on rules and maxims. 5 Expertise. Applies refined discriminatory perceptions to determine what must be done and what must happen to get there. Analysis and calculation are not necessary. It's stage 3, "does poorly at choosing the right perspective" and 4, "decision still based on rules and maxims" where problems arise. In Dreyfus' original paper, he considered learning in the context with feedback. BTW the paper is worth reading for Dreyfus' comments on feedforward simulated neural networks.
- memefrog 3y ago
  Sounds like the 'bell curve'/'midwit' meme, which shows an IQ bell curve and three people: one on the left, one in the middle and one on the right. The left and right have the same view, and the middle has a (clearly worse, usually overcomplicated) view. Example: The dimwit just uses a simple notes app. The midwit uses an overengineered and elaborate note-taking system using flash cards, Anki, spaced repetition, etc. The midwit spends more time on his note-taking system than he does actually taking notes on anything. The expert realises that all of that bloat is unnecessary and that he is more effective just using a simple notes app. You can communicate all of this in one image: https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedshare-shrink_2048_1536/0/1674685713129?e=1689811200&v=beta&t=Ss4hqAzMuowSU3tNDt_oD3QYoI58YNMKKil1XmbXm1Q https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh... https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedshare-shrink_2048_1536/0/1674685713129?e=1689811200&v=beta&t=Ss4hqAzMuowSU3tNDt_oD3QYoI58YNMKKil1XmbXm1Q https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh...
MichaelRo 3y ago
One big problem if not "the problem" in software development is that it's just too easy to forgo responsibility for the code one writes. With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This means most people will collect their checks with zero liability for a long time and leave the minute they face the slightest accountability for their actions (code, architecture etc). I'm not condoning it but it's a useful parable. Story goes that during World War 2, the engineers responsible for designing armor for Soviet tanks were required by direct Stalin orders to test it themselves in the final stage: they'd be crammed in a tank equipped with the armor they built and the tank would be fired at with live ammunition. This sort of "your life depends upon it" test should be introduced as standard requirement for software engineers, there'd be a lot fewer remaining but at least we'd have some quality :)
- JohnFen 3y ago
  > With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This is one of the things I dislike about agile methodologies. A big part of why I choose the jobs that I do is because I'll learn something new in them that I want to learn. Agile methodologies don't leave much room for that sort of analysis and learning. They are very focused on production, and only production.
  - nradov 3y ago
    The Scaled Agile Framework (SAFe) places a major emphasis on learning. https://scaledagileframework.com/continuous-learning-culture/ https://scaledagileframework.com/continuous-learning-culture... https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/innovation-and-planning-iteration/ https://scaledagileframework.com/innovation-and-planning-ite... Of course some organizations fail to implement the methodology correctly and skip the learning part. But you can't blame the methodology for that.
    - JohnFen 3y ago
aledalgrande 3y ago
> In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. mid-level develeopers promoted to architects/managers because the startup grows fast, in a startup that mostly hires juniors, and then sitting there without ever updating their knowledge
mkaic 3y ago
This is that one meme with the normal distribution from total novice to jedi master: https://i.kym-cdn.com/entries/icons/original/000/035/645/cover4.jpg https://i.kym-cdn.com/entries/icons/original/000/035/645/cov...
BlargMcLarg 3y ago
Hasn't been my experience. People who overthink will always overthink. People who play safe and love to discuss things until the sun comes up, will do just that. People who want to be hands on, break things first and then try it again with new information will do exactly that. Whenever I see people overcomplicate things, the idea usually comes from a senior and then passed down to the chain of loyal followers. We can have a debate on whether that is a 'true senior', but the books sold, praised by the majority of the dev crowd and then recommended by said seniors don't lie. 5+ years or 40+ years, there have been those going for 'crazy new libraries, patterns and ideas', even bold enough to claim things that no study has been able to back up so far. And god forbid sometimes a mid-level does figure out something can be done in a better way and the seniors ignore it while stuck in their old ways.
- cratermoon 3y ago
  OK, I'll bite. > even bold enough to claim things that no study has been able to back up so far. What claims? Who and where do those claims come from?
- whstl 3y ago
  That's fair and fine. You can call the three levels "beginner - expert beginner - experienced", if you don't want to use the ranks. Doesn't matter. This still happens in the middle of the career and way more often than it should.
jcadam 3y ago
...and yet, mid-level developers seem to be the most in-demand.
- whstl 3y ago
  Because they're the ones who know enough to get the job done, and are not as expensive or difficult to hire as senior developers. Doesn't mean they aren't the most challenging group to manage.
- Spooky23 3y ago
  Nobody wants to pay for senior people with a clue, and nobody wants to train cheap juniors.
jt2190 3y ago
> … they just make simple code which I can understand with a glance. That locks the team into “as smart as me, but no smarter” and doesn’t really scale beyond very small teams and very rote work. One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. It’s more important IMHO to require devs to communicate what they’re doing at a design level, to help them set clear goals and define (and enforce) boundaries. Far too often I’ve seen seniors go nuts “fixing” a system that in some theoretical sense was broken but for all practical purposes worked just fine, while neglecting things that were truly issues for the organization. Note that this is primarily a management issue, mainly a lack of oversight and control.
- thebigwinning 3y ago
  Agreed. It's much harder to be a manager of people smarter than you doing stuff you don't understand, but also absolutely necessary.
- whstl 3y ago
  > That locks the team into “as smart as me, but no smarter” No it doesn't. People aren't really "smarter" just because they write incomprehensible code. The "smarter" way is being able to get things done without making a mess for yourself, the other people working with you, and after you. Over-engineering is not a positive quality. And "not easy to understand" doesn't mean "impossible". Maybe for Juniors! In fact, it's the people writing the difficult code that are forcing teams to be "as smart or smarter than me". It's time to stop rationalizing architecture astronautics. There is nothing "smarter", it's just annoying and expensive. - > One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. And this is exactly why we need code to be comprehensible to everyone.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]

by whstl 3y ago

JohnFen 3y ago

Yes, there's a name for this, but I forget what it is. Being a beginner or a true expert are relatively safe. Beginners are aware of the limits of their knowledge/skills. Likewise, true experts are aware of the limits of their knowledge/skills. In between the two, though, people tend to think they understand more than they actually do. And, of course, being a beginner, intermediate, or expert is topic-specific. You can be an expert in one things and a beginner in another at the same time.

Benjammer 3y ago
It's along the same lines as Fred Brooks' "Second system effect," although not quite the same.
astura 3y ago
>Yes, there's a name for this, but I forget what it is. Resume Driven Development.
hhh 3y ago
Bell curve moment
6D794163636F756 3y ago
This sounds like the Dunning Kruger effect
- JohnFen 3y ago
  Dunning-Kruger is certainly a closely related effect, yes, but wasn't what I was thinking of.
lcnPylGDnU4H9OF 3y ago
> name for this Sounds like "Advanced Beginner" https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... "Expert Beginner" is the one who barely knows shit but convinces themselves they know everything and "Advanced Beginner" is the one who thinks they know just slightly more than they really do until their compiler gives them an error they didn't expect.
B1FF_PSUVM 3y ago
> a name for this The canny valley. Aka just learned enough to be dangerous.
phkahler 3y ago
>> You can be an expert in one things and a beginner in another at the same time. That's apparent or implied mastery. Psych friend says it happens all the time, executive type comes to therapy. He's a master at his business, has all sorts of industry experience, really knows his stuff, but then has trouble in say... personal relationships because he's absolutely clueless on those types of things. Mastery in one area does not imply it in another. So when you think "this person is really smart, why are they making xxx stupid decision?" just check if the reason you think they are smart is in any way related to the area of the stupid decision ;-)
jchanimal 3y ago
A complication is the skills curves overlap so while I was a dangerous intermediate at database design 15 years ago, now I am a dangerous intermediate at organization design.
cratermoon 3y ago
Richard Dreyfus came up with a Five-Stage Model of Adult Skills Acquisition. 1 Novice. Follows simple rules. Performance is poor. 2 Advanced beginner. Rules modified by context & situation. 3 Competence. Able to recognize more contextual elements than can be used. Ability to chose a perspective for analysis and prioritize features of the context. However, does poorly at choosing the right perspective. 4 Proficient. If detached rule-following is replaced by intentional learning, learns to use judgment and emotion in choosing perspectives. However, that judgement and emotion informs a decision still based on rules and maxims. 5 Expertise. Applies refined discriminatory perceptions to determine what must be done and what must happen to get there. Analysis and calculation are not necessary. It's stage 3, "does poorly at choosing the right perspective" and 4, "decision still based on rules and maxims" where problems arise. In Dreyfus' original paper, he considered learning in the context with feedback. BTW the paper is worth reading for Dreyfus' comments on feedforward simulated neural networks.
memefrog 3y ago
Sounds like the 'bell curve'/'midwit' meme, which shows an IQ bell curve and three people: one on the left, one in the middle and one on the right. The left and right have the same view, and the middle has a (clearly worse, usually overcomplicated) view. Example: The dimwit just uses a simple notes app. The midwit uses an overengineered and elaborate note-taking system using flash cards, Anki, spaced repetition, etc. The midwit spends more time on his note-taking system than he does actually taking notes on anything. The expert realises that all of that bloat is unnecessary and that he is more effective just using a simple notes app. You can communicate all of this in one image: https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedshare-shrink_2048_1536/0/1674685713129?e=1689811200&v=beta&t=Ss4hqAzMuowSU3tNDt_oD3QYoI58YNMKKil1XmbXm1Q https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh... https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedshare-shrink_2048_1536/0/1674685713129?e=1689811200&v=beta&t=Ss4hqAzMuowSU3tNDt_oD3QYoI58YNMKKil1XmbXm1Q https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh...

MichaelRo 3y ago

One big problem if not "the problem" in software development is that it's just too easy to forgo responsibility for the code one writes. With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This means most people will collect their checks with zero liability for a long time and leave the minute they face the slightest accountability for their actions (code, architecture etc). I'm not condoning it but it's a useful parable. Story goes that during World War 2, the engineers responsible for designing armor for Soviet tanks were required by direct Stalin orders to test it themselves in the final stage: they'd be crammed in a tank equipped with the armor they built and the tank would be fired at with live ammunition. This sort of "your life depends upon it" test should be introduced as standard requirement for software engineers, there'd be a lot fewer remaining but at least we'd have some quality :)

JohnFen 3y ago
> With all agile sprints and shit, real feedback for one's actions still comes very very late in the life of a project. This is one of the things I dislike about agile methodologies. A big part of why I choose the jobs that I do is because I'll learn something new in them that I want to learn. Agile methodologies don't leave much room for that sort of analysis and learning. They are very focused on production, and only production.
- nradov 3y ago
  The Scaled Agile Framework (SAFe) places a major emphasis on learning. https://scaledagileframework.com/continuous-learning-culture/ https://scaledagileframework.com/continuous-learning-culture... https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/iteration-retrospective/ https://scaledagileframework.com/innovation-and-planning-iteration/ https://scaledagileframework.com/innovation-and-planning-ite... Of course some organizations fail to implement the methodology correctly and skip the learning part. But you can't blame the methodology for that.
  - JohnFen 3y ago

aledalgrande 3y ago

> In almost 20 years I've learned that, at least to me, the most challenging group to manage are mid-level developers. mid-level develeopers promoted to architects/managers because the startup grows fast, in a startup that mostly hires juniors, and then sitting there without ever updating their knowledge

mkaic 3y ago

This is that one meme with the normal distribution from total novice to jedi master: https://i.kym-cdn.com/entries/icons/original/000/035/645/cover4.jpg https://i.kym-cdn.com/entries/icons/original/000/035/645/cov...

BlargMcLarg 3y ago

Hasn't been my experience. People who overthink will always overthink. People who play safe and love to discuss things until the sun comes up, will do just that. People who want to be hands on, break things first and then try it again with new information will do exactly that. Whenever I see people overcomplicate things, the idea usually comes from a senior and then passed down to the chain of loyal followers. We can have a debate on whether that is a 'true senior', but the books sold, praised by the majority of the dev crowd and then recommended by said seniors don't lie. 5+ years or 40+ years, there have been those going for 'crazy new libraries, patterns and ideas', even bold enough to claim things that no study has been able to back up so far. And god forbid sometimes a mid-level does figure out something can be done in a better way and the seniors ignore it while stuck in their old ways.

cratermoon 3y ago
OK, I'll bite. > even bold enough to claim things that no study has been able to back up so far. What claims? Who and where do those claims come from?
whstl 3y ago
That's fair and fine. You can call the three levels "beginner - expert beginner - experienced", if you don't want to use the ranks. Doesn't matter. This still happens in the middle of the career and way more often than it should.

jcadam 3y ago

...and yet, mid-level developers seem to be the most in-demand.

whstl 3y ago
Because they're the ones who know enough to get the job done, and are not as expensive or difficult to hire as senior developers. Doesn't mean they aren't the most challenging group to manage.
Spooky23 3y ago
Nobody wants to pay for senior people with a clue, and nobody wants to train cheap juniors.

jt2190 3y ago

> … they just make simple code which I can understand with a glance. That locks the team into “as smart as me, but no smarter” and doesn’t really scale beyond very small teams and very rote work. One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. It’s more important IMHO to require devs to communicate what they’re doing at a design level, to help them set clear goals and define (and enforce) boundaries. Far too often I’ve seen seniors go nuts “fixing” a system that in some theoretical sense was broken but for all practical purposes worked just fine, while neglecting things that were truly issues for the organization. Note that this is primarily a management issue, mainly a lack of oversight and control.

thebigwinning 3y ago
Agreed. It's much harder to be a manager of people smarter than you doing stuff you don't understand, but also absolutely necessary.
whstl 3y ago
> That locks the team into “as smart as me, but no smarter” No it doesn't. People aren't really "smarter" just because they write incomprehensible code. The "smarter" way is being able to get things done without making a mess for yourself, the other people working with you, and after you. Over-engineering is not a positive quality. And "not easy to understand" doesn't mean "impossible". Maybe for Juniors! In fact, it's the people writing the difficult code that are forcing teams to be "as smart or smarter than me". It's time to stop rationalizing architecture astronautics. There is nothing "smarter", it's just annoying and expensive. - > One person rarely has all the ability plus all of the “on the ground” context that’s necessary to do great work across a larger system. And this is exactly why we need code to be comprehensible to everyone.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]