It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I think the single best thing you can do for the bus factor is to use a pull request review model. If nothing makes it into the codebase without at least x other people signing their name to "I understand this change well enough to know that it does what it says it does" then that's x other people who at bare minimum have a head start on picking up the slack on bus day.
The trick is solving for x. On smaller teams, you might have to have everyone review each change. If there are more people, then it's possible to share the load around by requiring maybe two or three approvals. This also lets you play to people's strengths and specializations -- if you have a couple of frontend experts, they'll be able to clear UI pull requests faster than the team average. And if someone is interested in breaking into the frontend, getting on the review list (even if their approval isn't strictly required) is a solid learning opportunity.
Senior Fullstack JavaScript Developer with a passion for creating testable, maintainable, scalable codebases.
Specialising in Vue.JS, React, Node.JS, TypeScript, and Vanilla JavaScript.
Location
London, UK
Work
Senior Fullstack JavaScript Developer @ Studio Rotate
Code reviews are something I never really considered as helping increase bus factor as I've always seen them as primarily a code quality improvement tool but you make a pretty good point, no reason why it can't do both.
I guess it would be best to have as you say, front end or back end devs reviewing their respective specialities on each project that way you get maximum number of eyes on each project without having a labour intensive review process.
Our team has talked about only approving a pull request when you are sure you understand the implications of the PR. We just started testing this out so we're still seeing how it goes. It's a balancing act between getting things done quickly and making sure everyone understands what changes are happening and why.
As a matter of lowering the bus factor on items that can't be so cleanly reflected in the code, we have a few "heads up" and "minutes" channels to send out signals about certain relevant activities/discussions that only one or two people took part in. We've found this super valuable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the single best thing you can do for the bus factor is to use a pull request review model. If nothing makes it into the codebase without at least x other people signing their name to "I understand this change well enough to know that it does what it says it does" then that's x other people who at bare minimum have a head start on picking up the slack on bus day.
The trick is solving for x. On smaller teams, you might have to have everyone review each change. If there are more people, then it's possible to share the load around by requiring maybe two or three approvals. This also lets you play to people's strengths and specializations -- if you have a couple of frontend experts, they'll be able to clear UI pull requests faster than the team average. And if someone is interested in breaking into the frontend, getting on the review list (even if their approval isn't strictly required) is a solid learning opportunity.
Code reviews are something I never really considered as helping increase bus factor as I've always seen them as primarily a code quality improvement tool but you make a pretty good point, no reason why it can't do both.
I guess it would be best to have as you say, front end or back end devs reviewing their respective specialities on each project that way you get maximum number of eyes on each project without having a labour intensive review process.
Thanks!
Our team has talked about only approving a pull request when you are sure you understand the implications of the PR. We just started testing this out so we're still seeing how it goes. It's a balancing act between getting things done quickly and making sure everyone understands what changes are happening and why.
As a matter of lowering the bus factor on items that can't be so cleanly reflected in the code, we have a few "heads up" and "minutes" channels to send out signals about certain relevant activities/discussions that only one or two people took part in. We've found this super valuable.