In fact, I might say that pretty much every engineer will be guilty of this if they have been in the industry long enough.
It doesn't mean you're evil! It just means you're the one who created a bunch of stuff and naturally you can work with your own stuff more efficiently than others can.
In fact I actually was "this guy" with one section of the code at my old company; the one where we had the "faux 10x" architect-dictator. I did manage to achieve a fairly clean transition once my involvement in that bit of the code ended.
Ask for the mediocre engineers to be
removed from the team
It sounds like this codebase is significantly complicated that even above-average engineers might find it an uphill battle. Is this true? If so, perhaps the answers are the largely the same whether or not the mediocre engineers are replaced.
"asking the mediocre engineer to do something
means it will take a full Sprint instead of
the two hours it'll take me"
"[Transitioning from coder to mgmt/mentor]
would probably slow us down 3-4x"
How many hours of useful coding do you do per day? There are a lot of studies that suggest even great engineers don't code for more than a few hours per day. I don't think I'm great, but this definitely applies to me.
Maybe you could divide your time in a way that's not too painful. Perhaps you could spend a fixed 1-2 hours per day on knowledge transfer (pair programming, etc) and not impact your productivity.
Here's what I would say.
0. Get buy-in from the rest of the management/leadership team. They should fully support your efforts to get others up to speed. Tell them you are concerned about being the only one who can maintain the product effectively. They should NOT want you, personally, to remain an indispensible single point of failure. What if you leave? What if you are hit by a bus?
1. As I said above, if you can devote perhaps 25% of your week to full-time knowledge transfer, you might find that you accomplish a lot without sacrificing your other productivity unduly.
2. Pair programming is, I think, the fastest form of knowledge transfer. An hour or two of pairing with the newbie engineers at the outset of a task goes a LONG way and may save dozens of hours later in the sprint. It sounds like these engies should never, ever begin a task without this guidance from you. They will learn the code, they will learn the thought process that went into the code, and they will learn your problem-solving process.
3. Is your test suite awesome? Writing or improving tests can be an excellent way for folks to get up to speed on the code in a low risk way. And a strong test suite has long-lasting benefits. If you don't have a test suite at all, even a very rudimentary one will reap large rewards down the road.
4. I document my code (via inline code comments) more than most. My opinion is that if a bit of code represents a non-obvious technical kludge, or a bit of business logic, it should have an explanatory note. Theoretically this could be accomplished via diligent commit messages, but sifting through hundreds of commit messages is awfully tough.
5. YOUR ENGINEERS ARE PEOPLE. Working on your legacy hairball of code is... frustrating. Recognize their pain. Be sure to get them some "wins" on a regular basis so they can feel good. Praise their efforts in private, and in front of others in meetings.
Good luck to you! My email is john edmund rose "at" gmail if you want to correspond. I'd like that!
“Average” engineers manage to be productive with React, Spring, WPF[1]... These are not simple technologies. Why can’t “average” engineers be productive with my stuff?
Quite often it’s because these bigger, more complex, projects have far more comprehensive docs.
It sounds like this codebase has a fair few abstract concepts in it. Those things can be hard to understand without comments and docs explaining core concepts.
Sequence diagrams are also great. I like generating sequence diagrams from logs during automated testing so they never go out of date.
I also find it useful to have docs at the top of each class (or file) explaining 1. what its responsibilities are, and 2. what it collaborates with. Like the old CRC cards.
Obviously this stuff can drift out of date, but it’s less of a problem with the core bits of the system once they’ve settled a bit.
If they don’t exist already, it’s nice to write docs by pairing with new devs.
It is of course possible your engineers really aren’t up to the job, in which case the effort you put in to explaining things now will still make things easier for their eventual replacements.
I had all this wrong for so many years.
[1] whether these are “good” technologies is beside the point here
The telephone game taught me why there should be a “how the system works” runbook in writing. At 3 AM, I don’t want to try to remember the lecture I got from someone who was trying to remember the lecture they had gotten from Saint Paul or whomever.
In fact, I might say that pretty much every engineer will be guilty of this if they have been in the industry long enough.
It doesn't mean you're evil! It just means you're the one who created a bunch of stuff and naturally you can work with your own stuff more efficiently than others can.
In fact I actually was "this guy" with one section of the code at my old company; the one where we had the "faux 10x" architect-dictator. I did manage to achieve a fairly clean transition once my involvement in that bit of the code ended.
It sounds like this codebase is significantly complicated that even above-average engineers might find it an uphill battle. Is this true? If so, perhaps the answers are the largely the same whether or not the mediocre engineers are replaced. How many hours of useful coding do you do per day? There are a lot of studies that suggest even great engineers don't code for more than a few hours per day. I don't think I'm great, but this definitely applies to me.Maybe you could divide your time in a way that's not too painful. Perhaps you could spend a fixed 1-2 hours per day on knowledge transfer (pair programming, etc) and not impact your productivity.
Here's what I would say.
0. Get buy-in from the rest of the management/leadership team. They should fully support your efforts to get others up to speed. Tell them you are concerned about being the only one who can maintain the product effectively. They should NOT want you, personally, to remain an indispensible single point of failure. What if you leave? What if you are hit by a bus?
1. As I said above, if you can devote perhaps 25% of your week to full-time knowledge transfer, you might find that you accomplish a lot without sacrificing your other productivity unduly.
2. Pair programming is, I think, the fastest form of knowledge transfer. An hour or two of pairing with the newbie engineers at the outset of a task goes a LONG way and may save dozens of hours later in the sprint. It sounds like these engies should never, ever begin a task without this guidance from you. They will learn the code, they will learn the thought process that went into the code, and they will learn your problem-solving process.
3. Is your test suite awesome? Writing or improving tests can be an excellent way for folks to get up to speed on the code in a low risk way. And a strong test suite has long-lasting benefits. If you don't have a test suite at all, even a very rudimentary one will reap large rewards down the road.
4. I document my code (via inline code comments) more than most. My opinion is that if a bit of code represents a non-obvious technical kludge, or a bit of business logic, it should have an explanatory note. Theoretically this could be accomplished via diligent commit messages, but sifting through hundreds of commit messages is awfully tough.
5. YOUR ENGINEERS ARE PEOPLE. Working on your legacy hairball of code is... frustrating. Recognize their pain. Be sure to get them some "wins" on a regular basis so they can feel good. Praise their efforts in private, and in front of others in meetings.
Good luck to you! My email is john edmund rose "at" gmail if you want to correspond. I'd like that!