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.
I directly disputed the central thesis that OP (the person I was responding to, not the article) was putting forth, that senior developers shouldn't be coding:
> 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
Your reading comprehension suffers under your fragile ego.
Nobody said 'senior developers shouldn't be coding'.
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?
> Your reading comprehension suffers under your fragile ego. Nobody said 'senior developers shouldn't be coding'.
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.
For what it’s worth I agree with the person you’re replying to. The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.
I’m surprised you mentor, given all the hubris you have displyed on this thread.
> The OP is saying: given two senior applicants with the same coding skill level, the one most suited to the job is the person who can communicate to juniors and delegate effectively.
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.
No. Read it again. What I was saying is two things:
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)
And I'm saying that your arguments are wrong. I don't care how good the junior dev is, I can out code them every time.
> 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).
Look. Aren't you spending time thinking? Do you imagine you think faster than everybody aged 23?
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.
> Aren't you spending time thinking? Do you imagine you think faster than everybody aged 23?
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).
Actually, the context that you're ignoring is important:
> 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.
Education is a good point. New algorithms are often found in academia that aren't exactly on Hacker News all of the time. It doesn't matter which field either - micro architecture, high performance computing, UX, databases, PL, computational linguistics, you name it. Or hell, math has been around for a long time and you might not know planar graph algorithms off-hand unless you were really smart or had taken the course two months ago.
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.
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.