Hacker News Reader

Comment by whstl | Hacker News Reader

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.

View on HN

> … 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.

> 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.

> People aren't really "smarter" just because they write incomprehensible code.

Go reread what I wrote: I never made that assertion.

Then we might have a misunderstanding. If so, I'm gonna need more context for the phrase “as smart as me, but no smarter”.

In the original comment I never claimed there were different "smartness" levels across the ranks, and stated that Juniors can write code that is understandable. It's not about experience or smartness, it's simply about the importance of not overcomplicating the codebase to the best of your ability, no matter if you're a Junior or Senior. To me, that's being "smarter", and it's definitely possible to have this kind of "smarter" in any team.

> … 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.

Complexity is the enemy.

Code that is easy to understand - for others, and for yourself in six months - pays huge dividends.

Agreed. It's much harder to be a manager of people smarter than you doing stuff you don't understand, but also absolutely necessary.

> 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

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.

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.

> name for this

Sounds like "Advanced 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.

>> 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 ;-)

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/feedsh...

https://media.licdn.com/dms/image/C5622AQFrWvMGA7E7bA/feedsh...

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.

>Yes, there's a name for this, but I forget what it is.

Resume Driven Development.

> a name for this

The canny valley.

Aka just learned enough to be dangerous.

It's along the same lines as Fred Brooks' "Second system effect," although not quite the same.

Bell curve moment

This sounds like the Dunning Kruger effect

Dunning-Kruger is certainly a closely related effect, yes, but wasn't what I was thinking of.

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/cov...

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.

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?

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.

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 :)

That's very capital-A Agile. As per the original agile manifesto, getting feedback as soon as possible is the primary goal of agile, and all the rest is just potential ways of making that happen.

> 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.

The Scaled Agile Framework (SAFe) places a major emphasis on learning.

https://scaledagileframework.com/continuous-learning-culture...

https://scaledagileframework.com/iteration-retrospective/

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.

> But you can't blame the methodology for that.

Well, this comes around to a perennial debate about agile methodologies in general. Yes, an argument can be made that the fault isn't the methodology, but the poor implementation of the methodology.

However, the case can also be made that if a methodology is rarely implemented correctly, that's because there's something wrong with the methodology.

Most companies (every single company I've worked for, anyway) implement an agile methodology purely to crank up production speed. No other consideration enters into it.

The problem, unfortunately, isn't any particular development methodology, it's the perverse incentives of capitalism.

I have worked for quite a few consultancies and feedback is just not there, either the code works or it doesnt, there is no feedback just additional features/bugs to discover.

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

Nobody wants to pay for senior people with a clue, and nobody wants to train cheap juniors.

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.

Reply on news.ycombinator.com