Pfft. I'm about as "senior" as it gets and I'm generally the fastest developer in any team I'm on. I've never met a junior dev that could hold a candle to me, and most senior devs I know are the same...we're coding monsters.
- Better (usually simpler) designs.
- Breaking the problem and choosing the order in which things are implemented.
- Setting up usefull feedback loops.
- etc, etc.
It is a lot about judgment.
that’s the worst kind of data - gives a meaningless feeling of objectivity.
PS: Most people have never worked closely with someone with 25+ years of experience, but the difference is staggering.
Good junior devs are... well, by definition, good. They're just younger, and less experienced - but every bit as smart as you are, and pretty skilled in the art of coding. If anything, they have more time than I do and are a lot more eager to "prove themselves".
I don't view the value I add as "can code features faster"...
I do, at least partly. I can code so much faster that my cost per feature is lower than a junior dev.
It was staggering how they had managed to survive for 25+ years. Every person is different.
Having not worked with the same person for 25 years I can only speak of the average case.
I pointed out how you decided to pick out a totally irrelevant, rhetorical sentence out of all points that OP made, and then decided to refute that, by claiming how much experience you have, and setting up yourself center stage, instead of adding value to the actual discussion topic at hand, which is the coaching gap.
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
What other "points" did OP make?
The topic is about a lack of mentoring for junior devs. You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.
What would scale is if you were to start coaching junior devs, because if you don't, all the juniors will keep reinventing 'left-pad' in this week's ES201x iteration, while your retirement keeps getting closer.
Instead of adding to the discussion on how to solve the coaching gap, you decided to defend your coding efficiency and how you deliver features faster than a Junior Dev. You missed the point completely. You're part of the problem the article addresses, don't you realize?
That is exactly what the post I was responding to said, and I've quoted it several times. Here it is a gain, since you keep glossing over it:
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
So, yes, the person I responded to said "senior developers shouldn't be coding'".
> You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.
How so? I'm a mentor as well as a developer. In addition to doing my part to train the next wave of devs, I also code my ass off. What part of that doesn't scale?
> You missed the point completely.
No. That's what you did though. And are increasingly insulting about it as well.
> You're part of the problem the article addresses, don't you realize?
Who's talking about the article? I was talking about the bogus "point" in the post I responded to.
I’m surprised you mentor, given all the hubris you have displyed on this thread.
If that's what he was saying, I'd be much more in agreement. Instead he said, effectively, that senior devs shouldn't be coding because they can't do it any better than junior devs.
A. GOOD junior devs can (and often do) outperform good senior devs at the metric of "quantity of code produced" (I later added that IMO in fact they should, not just can)
B. (the central point of my argument, really) If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs. It's not just cost-ineffective (you're paying a senior do to a junior's work), but you also run into other risks as well (juniors that ask questions force seniors to explain stuff, which in turn forces them to think clearly about it; you may have experienced the phenomenon where you understand something much better after explaining it to somebody else)
> If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs.
Actually, no argument there. Mentoring is indeed a critical function of senior devs.
> It's not just cost-ineffective (you're paying a senior do to a junior's work)
And you lost me there. I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).
Could you do an MSc at a top-level US university (in your primary domain of expertise) in a week? Because plenty of people (juniors by definition, almost all of them) can do it in 2 years, so if you're "100x" in the sense that you say you are, you should be able to do all that work in 1 week. At least that much should be plainly obvious to you, that you can't possibly be "100x" in the sense that you claim to be. Or well, if you are... you're rather unique, I definitely haven't seen anybody that can even come close to you, and I know some top-notch engineers. So you're definitely the exception, not the rule.
No, but I probably think better...i.e. how to approach a problem, sift out the relevant details, formulate a plan, execute it, understand the trade-offs, etc. As a result, I can deliver more correct code faster than a junior dev.
> you can't possibly be "100x" in the sense that you claim to be.
I never claimed to be 100x. I was just mentioning the reason why I'm cheaper than a junior dev (that I'm not paid in line with my "effectiveness multiplier"). You were the one that mentioned a 100x engineer thing in a link, so I included the number.
You actually did - look 2 posts up, "i.e. I'm a 10x (100x) dev". But I suspect you didn't actually read that link, just the URL - not fair to chide me for mentioning the number if you didn't read what that meant.
> how to approach a problem, sift out the relevant details, formulate a plan, understand the trade-offs
That's exactly my claim, that you add more value with this sort of activity than the "execute it" part; doing that plus teaching others to do it, you add exponentially more value to the company, than just coding stuff in a corner .
You cling on the fact that a junior dev can't possibly code faster than you - even though it's a completely irrelevant detail. And yes they can, if you remove qualifications like "correct code" or "maintainable" or whatever (I never claimed junior devs will do the right thing all by themselves, that'd make them seniors, right? But - I participated in coding competitions in high-school, got a silver medal at IOI - I know very well that my younger self could code circles around my older self when it comes to raw speed. And I've seen other people like that later; experience can't fight youth when it comes to speed and enthusiasm... it just can't. It's more likely that you just never worked with a good junior dev before, than it is that you can always code everything faster).
> I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).
The numbers were merely to indicate that my multiplier is sufficient that I'm cheaper than a dev.
> I suspect you didn't actually read that link, just the URL - not fair to chide me for mentioning the number if you didn't read what that meant.
No need to suspect, I confirm I didn't read it. I saw the number in the URL and just dismissed it as puffery.
> That's exactly my claim, that you add more value with this sort of activity than the "execute it" part; doing that plus teaching others to do it, you add exponentially more value to the company, than just coding stuff in a corner .
That was in no way you're claim, at least, not the claim I disputed. Your claim(s) were:
> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!
> "Mentoring" is basically the job you hire a senior dev to do
No way. Maybe mentoring is a part of the job, but it's by no means the main job in many organizations.
> if you remove qualifications like "correct code" or "maintainable" or whatever
??? This is a pretty ludicrous statement. Why would you ever count incorrect code? And yes, I probably can code incorrectly faster than a junior dev, too. After decades of experience, I'm a faster typist than most junior devs.
> I know very well that my younger self could code circles around my older self when it comes to raw speed. And I've seen other people like that later; experience can't fight youth when it comes to speed and enthusiasm... it just can't.
Rose colored glasses, to say the least. You seem to be switching back and forth on whether raw LOC throughput is meaningful...first you were "flabbergasted" that it might be a measure of productivity, now you're bragging about raw speed, and even suggesting that creating "correct code" or "maintainable" code is irrelevant, which is insane.
> It's more likely that you just never worked with a good junior dev before, than it is that you can always code everything faster).
I've worked with (and mentored) some really great junior devs, who grew into great senior devs. But they didn't walk into the building as my equals in coding.
This whole debate is nutty. I personally would welcome as much strategic and intellectual diversity as possible onto teams I'm running. I wouldn't put all my eggs in one basket, either.
Me too. I just think the blanket assertion that a junior dev is the coding equal to a senior dev is what's nutty.
> can code not only "just as fast", but probably faster too!
is pure BS.
Good junior devs will be more skilled in some areas than you are. Maybe it's stuff you're not interested in; or just stuff they're really interested in. The only way a good junior dev doesn't "out-code" you, ever - is if you're only skilled in a very narrow niche (bonus points if only few people are interested in it, at all).
Junior devs absolutely can, and often do, build "wrong things" faster than senior devs. The measure of seniority is in my mind about knowing what to NOT build, in the first place.
Who uses LOC? I'm talking about completed, tested, accepted features, as defined by our project teams.
> Good junior devs will be more skilled in some areas than you are.
Well, yeah...of course. I'm not comparing myself to someone who works in an entirely different field. A junior front-end dev will be better than me at front-end stuff. I'm talking about a junior in my area, who I'd be in a team with or would mentor.
> The measure of seniority is in my mind about knowing what to NOT build, in the first place.
I agree with that statement.
Still rather strange metrics for productivity in a senior engineer. This is more what I'm taking about: https://zef.me/the-100x-engineer-6d50a690a866
If you're really senior, you shouldn't be working on the kind of features that get delivered at a rate of "5 per sprint". More like on stuff that gets delivered once every year. The junior SHOULD outperform you in "code produced" - they just shouldn't outperform you in dollars produced (or saved).
When I look at code written by junior devs I often think 'dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look'.
Makes me wonder if there are parallels in writing. My understanding is that the most prolific authors can only write 8 publishable pages a day. I'd bet that amateur writers can produce more pages than that, but no page could be published without at least as much time spent by an editor.
This, 100 times over! It is simply incredible how much code and how complex systems a junior dev (junior by knowledge, not by years of coding) can produce in a short time while you were looking the other way... :-D
Senior developers make sure to question their assumptions on a regular basis, FYI
I'm sure you're a quick learner but at least in scenarios I've worked in there are often many, many possible solutions and no specific "right answer."
After all, it's hard for anyone to be right all of the time.
A better point is that this drought of new talent is just the other side of the pendulum. In the odd years, the problem is layoffs and difficulty finding work without being a new-grad or knowing the latest tech fad. You've seen some of those summers, too?
If we both had to read the manual? Yeah, I'd still be faster. It's just as easy to cherry-pick for one side or another.