|
|
|
|
|
|
by neilv
1662 days ago
|
|
|
Those aren't the only two options. You can try to get a team to develop systems that any other capable software engineer can pick up reasonably (such as via effective documentation, and reasonably maintainable nature of the code). One of the biggest barriers to that (besides teams needing guidance on how to do it) is conflict of interest, which is a factor in the why. I started saying it upfront with founders at my last company, when speaking of who we wanted to hire, and how engineering should be done: "One of the jobs of an engineer is to 'document themselves out of a job'." Then I add something like "And the company has to realize that engineers who can and will do that are generally the best engineers, and extremely valuable to the company." Though, if the engineers didn't trust management (e.g., not exhibiting analogous professionalism and duty, such only looking at near-term selfish impact), then I can't argue that engineers should go out of their way to be easier for a stereotypical anti-leader to treat poorly. I'd have to appeal to the engineer's sense of professionalism, or of some degree of duty to other team members. I'd also know it's probably only a stopgap, and to give them whatever support I can if/when they look elsewhere for a home for an unusually great engineer. |
|
|
That sounds nice in theory, but I've only ever seen it be a disaster in practice. It's like that mirror thing from Harry Potter. As soon as you actually try and make a maintainable code base, it starts going the other way.
The only way to truly optimise for onboarding is by writing the simplest, cleanest code possible. Everyone is already trying to do that by hiring the best devs they can. Any further efforts just look like more dependencies, more patterns, and more incidental complexity to act as guard rails in the pursuit of a newb-friendly codebase.
The end result is that new devs are productive at small and simple tasks, but big things take longer. Also, you're never going to find a manager that understands this trade off, so your new dev is going to be left in a terrible position trying to explain how they got so much work done in the first month when they knocked off all the small cards, but now the new feature that the business desperately needs has taken 3 months all by itself.