# bus factor

Published articles for bus factor.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Reducing Single-Person Dependency Through Documentation and Onboarding

DevFeed: [Reducing Single-Person Dependency Through Documentation and Onboarding](<https://devfeed.tech/articles/the-bus-factor-of-zero-29354.md>)

Original publisher: [Read original article](<https://arturdryomov.dev/posts/bus-factor-of-zero/>)

Author: Artur Dryomov

Published: 2026-01-30T00:00:00Z

Content type: opinion

Language: en

Sources: [Artur Dryomov](<https://devfeed.tech/sources/artur-dryomov.md>)

Topics: [Documentation](<https://devfeed.tech/topics/documentation.md>), [Requirements](<https://devfeed.tech/topics/requirements.md>), [Code review](<https://devfeed.tech/topics/code-review.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [GitLab](<https://devfeed.tech/topics/gitlab.md>)

Tags: [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [collaboration](<https://devfeed.tech/tags/collaboration.md>), [docs](<https://devfeed.tech/tags/docs.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [github](<https://devfeed.tech/tags/github.md>), [gitlab](<https://devfeed.tech/tags/gitlab.md>), [onboarding](<https://devfeed.tech/tags/onboarding.md>), [requirements](<https://devfeed.tech/tags/requirements.md>), [review](<https://devfeed.tech/tags/review.md>), [source-of-truth](<https://devfeed.tech/tags/source-of-truth.md>)

### AI overview

The article reflects on onboarding a new developer and argues that accessible documentation, product requirements documents, and architectural records can reduce reliance on tribal knowledge and make project history easier to understand.

### Source excerpt

Onboarding new developers to a team is an opportunity for introspection. It's one thing to share tribal knowledge, and another to realize that the mere existence of such knowledge can be counterproductive. Recently, I had an opportunity to onboard a new developer to one of our projects. Fortunately, almost everything went right. In a couple of days, the developer was able to contribute minor changes to the project, within a couple of weeks, major ones. Of course, a good portion of this rapid involvement can be attributed to the developer, but I believe the approaches described below helped a lot.

## Why Software Engineers Should Emphasize the Impact of Their Work

DevFeed: [Why Software Engineers Should Emphasize the Impact of Their Work](<https://devfeed.tech/articles/your-work-doesn-t-matter-40008.md>)

Original publisher: [Read original article](<https://www.saiyangrowthletter.com/p/your-work-doesnt-matter>)

Author: Tiger Abrodi

Published: 2024-06-09T12:46:03Z

Content type: opinion

Language: en

Sources: [Saiyan Growth Letter](<https://devfeed.tech/sources/saiyan-growth-letter.md>)

Topics: [Software](<https://devfeed.tech/topics/software.md>), [bus factor](<https://devfeed.tech/topics/bus-factor.md>), [lead time](<https://devfeed.tech/topics/lead-time.md>), [Learning](<https://devfeed.tech/topics/learning.md>)

Tags: [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [lead-time](<https://devfeed.tech/tags/lead-time.md>), [learning](<https://devfeed.tech/tags/learning.md>), [promotion](<https://devfeed.tech/tags/promotion.md>), [results](<https://devfeed.tech/tags/results.md>), [software-engineer](<https://devfeed.tech/tags/software-engineer.md>), [team](<https://devfeed.tech/tags/team.md>)

### AI overview

The article argues that software engineers should track and communicate the impact of their work, not only the tasks they completed. It uses organizing a weekly learning session as an example, linking that activity to a larger bus factor, shorter lead time, faster delivery, and happier customers.

### Source excerpt

Input never matters. Outcome does.

## How to lead weekly sessions for your team

DevFeed: [How to lead weekly sessions for your team](<https://devfeed.tech/articles/how-to-lead-weekly-sessions-for-your-team-39995.md>)

Original publisher: [Read original article](<https://www.saiyangrowthletter.com/p/how-to-lead-weekly-sessions-for-your>)

Author: Tiger Abrodi

Published: 2024-02-21T15:03:33Z

Content type: tutorial

Language: en

Sources: [Saiyan Growth Letter](<https://devfeed.tech/sources/saiyan-growth-letter.md>)

Topics: [sessions](<https://devfeed.tech/topics/sessions.md>), [bus factor](<https://devfeed.tech/topics/bus-factor.md>), [Learning](<https://devfeed.tech/topics/learning.md>), [context](<https://devfeed.tech/topics/context.md>)

Tags: [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [learning](<https://devfeed.tech/tags/learning.md>), [minutes](<https://devfeed.tech/tags/minutes.md>), [remote](<https://devfeed.tech/tags/remote.md>)

### AI overview

A practical guide to leading weekly learning sessions for a remote team. It covers common organizational mistakes and recommends using an agenda, communicating presenters, recording sessions, sharing materials, and preparing at least a week in advance to respect teammates' time and energy.

### Source excerpt

Care about your teammates' time and energy.

## Does extensive documentation do more harm than good?

DevFeed: [Does extensive documentation do more harm than good?](<https://devfeed.tech/articles/does-extensive-documentation-do-more-harm-than-good-38866.md>)

Original publisher: [Read original article](<https://dev.to/vestrel00/does-extensive-documentation-do-more-harm-than-good-4kef>)

Author: Vandolf Estrellado

Published: 2022-01-03T00:01:33Z

Content type: opinion

Language: en

Sources: [Vandolf Estrellado](<https://devfeed.tech/sources/vandolf-estrellado.md>)

Topics: [Documentation](<https://devfeed.tech/topics/documentation.md>), [Code](<https://devfeed.tech/topics/code.md>), [GitHub](<https://devfeed.tech/topics/github.md>), [jira](<https://devfeed.tech/topics/jira.md>)

Tags: [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [code](<https://devfeed.tech/tags/code.md>), [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [development](<https://devfeed.tech/tags/development.md>), [discuss](<https://devfeed.tech/tags/discuss.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [github](<https://devfeed.tech/tags/github.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [opensource](<https://devfeed.tech/tags/opensource.md>), [showdev](<https://devfeed.tech/tags/showdev.md>), [software](<https://devfeed.tech/tags/software.md>), [want](<https://devfeed.tech/tags/want.md>)

### AI overview

The author reflects on writing extensive documentation across code, pull requests, issue trackers, open-source discussions, and workplace communications. They question whether the time spent documenting is excessive, while noting that it reduces dependency on their personal knowledge and helps them disconnect from work.

### Source excerpt

I feel like I tend to write too much documentation in code, PR descriptions, PR comments, JIRA tickets, markdown files, etc. If I can write documentation on it, then you bet that I am doing it 😆 There are few exceptions where I don't write documentation such as self-explanatory, 1-liner code... I think I do it because I don't like people asking questions. Really anti-social behavior 😊 Some may say that I have obsessive-compulsive disorder. Warning! The following GIFs may cause siezures as they have been sped up to meet maximum file size limits. I'm writing documentation in code, extensively... Useful? Not useful? Who cares? No one? Readable? Beautiful? I'm writing howto pages for all APIs, functions, and entities in the library... Cool? Or insane? Or cool but a waste of time? It looks like this in the mobile GitHub app... Tell me it's not pretty... Tell me! (Please don't tell me). I'm using GitHub Pages as a free website for my hard work on my documentation... Can't really turn down a free domain and 1-click theme changes 😄 I'm writing really long responses in my open source discussion pages, issues, and PRs... Because I want to make my collaborators feel heard and appreciated. These insane tendencies carry over to my professional life. I write really thorough, detailed JIRA tickets, Slack messages, architectural docs, engineering notes, to a point of insanity. Typically, when I post my response to people at work, they usually don't have any follow up questions. They expect that if they ask Vandolf a question, he will answer that question and give every bit of context related to it with links to supporting documents and visual aid (GIFs and videos with callouts) when needed. It is probably starting to annoy some people at work despite them publicly giving me praise for it. I don't have a GIF for this part because I don't want to get fired 🔥 It also carries over to my personal life, which I will not discuss here... So... Lately, I've been wondering if I'm wasting tim

## A component-based approach to managing team responsibility in Badoo and Bumble

DevFeed: [A component-based approach to managing team responsibility in Badoo and Bumble](<https://devfeed.tech/articles/article-23641.md>)

Original publisher: [Read original article](<https://habr.com/ru/companies/badoo/articles/562000/>)

Author: Unclead (Badoo)

Published: 2021-06-09T15:08:15Z

Content type: article

Language: ru

Sources: [Badoo EN](<https://devfeed.tech/sources/badoo-en.md>), [Badoo RU](<https://devfeed.tech/sources/badoo-ru.md>)

Topics: [PHP](<https://devfeed.tech/topics/php.md>), [phpstorm](<https://devfeed.tech/topics/phpstorm.md>), [Git](<https://devfeed.tech/topics/git.md>)

Tags: [badoo](<https://devfeed.tech/tags/badoo.md>), [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [git-hook](<https://devfeed.tech/tags/git-hook.md>), [php](<https://devfeed.tech/tags/php.md>), [phpstorm](<https://devfeed.tech/tags/phpstorm.md>), [tag-622612a5798e](<https://devfeed.tech/tags/tag-622612a5798e.md>), [tag-a3f08f91b7c9](<https://devfeed.tech/tags/tag-a3f08f91b7c9.md>), [tag-b3a84f87fd83](<https://devfeed.tech/tags/tag-b3a84f87fd83.md>), [tag-c51cc4bf76e5](<https://devfeed.tech/tags/tag-c51cc4bf76e5.md>), [team](<https://devfeed.tech/tags/team.md>)

### AI overview

The article describes how Badoo and Bumble addressed the challenge of identifying teams and maintainers responsible for parts of a growing PHP codebase. It explains the limitations of DocBlock tags, PhpStorm templates, and a Git hook, and introduces a component-based approach intended to centralize responsibility information and let other systems consume updates automatically.

### Source excerpt

Меня зовут Евгений Тупиков, я ведущий PHP-разработчик в Badoo и Bumble. У нас в команде более 200 бэкенд-разработчиков, которые работают над сотнями модулей и отдельных сервисов в наших приложениях. Но поначалу всё было не так масштабно. В 2006 году это был один проект, над которым работала небольшая команда. Каждый разработчик хорошо понимал, как всё устроено: легко ориентировался в коде, знал, какие есть сервисы и как они взаимодействуют между собой. Однако по мере роста проекта всё больше времени занимал поиск "хранителей знаний" -- тех, кто отвечает за ту или иную функциональность и к кому можно обратиться с вопросом или предложением. В этой статье я расскажу, как мы решили проблему разделения зон ответственности и сделали процесс актуализации информации быстрым и удобным с помощью компонентного подхода. Читать далее

## Covid and Your Personal Bus Factor

DevFeed: [Covid and Your Personal Bus Factor](<https://devfeed.tech/articles/covid-and-your-personal-bus-factor-28144.md>)

Original publisher: [Read original article](<http://fuzzyblog.io/blog/covid/2020/04/22/covid-and-your-personal-bus-factor.html>)

Author: Fuzzygroup

Published: 2020-04-22T00:00:00Z

Content type: opinion

Language: en

Sources: [Scott Johnson](<https://devfeed.tech/sources/scott-johnson.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [passwords](<https://devfeed.tech/topics/passwords.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Documentation](<https://devfeed.tech/topics/documentation.md>)

Tags: [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [covid](<https://devfeed.tech/tags/covid.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [password](<https://devfeed.tech/tags/password.md>), [passwords](<https://devfeed.tech/tags/passwords.md>), [personal](<https://devfeed.tech/tags/personal.md>), [process](<https://devfeed.tech/tags/process.md>), [side-projects](<https://devfeed.tech/tags/side-projects.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [startup](<https://devfeed.tech/tags/startup.md>)

### AI overview

The article applies the software-engineering concept of bus factor to personal, professional, and side-project responsibilities during the COVID-19 pandemic. It emphasizes documenting processes and securely sharing essential passwords and PIN codes so responsibilities can continue if someone becomes ill or unavailable.

### Source excerpt

In the world of software engineering, the term Bus Factor refers to the number of people on your team that have to get hit by a bus for your project to collapse: The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus." It is also known as the bread truck scenario, lottery factor, truck factor, bus/truck number, or lorry factor. Wikipedia I am currently a part of a number of projects with a bus factor of 1. This means that if I get hit by a bus things simply fall apart. Normally I don't worry about things like this because I'm in excellent health and I'm a careful person (and that is not to say that I'm invulnerable but at least professionally my clients accept that we have a bus factor of 1 because they must understand this issue). But the world has changed around me and like everyone else I am struggling to catch up hence this bit of writing. Someone close to me, last night, had both a fever and an upset stomach (both of these are diagnostic factors of COVID-19) and I woke up in a panic thinking about bus factors in three contexts: Personal Professional Side Projects If you're not a tech nerd then you can only read the personal section; if you are a tech nerd then I advise that you read all sections. Your Personal Bus Factors Your personal bus factors tend to be centered around matters of identity: Passwords Pin Codes Process Medication Documentation Here's an example - I don't know the password / pin code to my wife's phone or laptop. If she gets sick then I have to still pay bills and deal with accounts. And without access to that information, well, I'm fscked (and thus so is the family hence my view of this as a bus factor). Now, given the sensitivity of the information on our phones and devices, having access to someone's phone password can be terrifying so I don't normally have an issue with not having access - but these aren't normal ti

## How Code Reviews Support Chromium's Code Quality and Team Resilience

DevFeed: [How Code Reviews Support Chromium's Code Quality and Team Resilience](<https://devfeed.tech/articles/code-reviews-for-fun-and-profit-35513.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/code-reviews/>)

Author: Monica Dinculescu

Published: 2014-03-31T00:00:00Z

Content type: opinion

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Chromium](<https://devfeed.tech/topics/chromium.md>), [code style](<https://devfeed.tech/topics/code-style.md>), [bus factor](<https://devfeed.tech/topics/bus-factor.md>)

Tags: [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [code](<https://devfeed.tech/tags/code.md>), [code-reviews](<https://devfeed.tech/tags/code-reviews.md>), [code-style](<https://devfeed.tech/tags/code-style.md>)

### AI overview

The article explains how Chromium uses code reviews and style guides to manage a large, actively changing codebase. It argues that review helps catch broken or poor-quality code, maintain consistency, and reduce reliance on a small number of contributors.

### Source excerpt

Stats: a preamble I've been reading too much about March Madness brackets, so I thought I had to run some numbers around here like the cool kids do. Get your umbrella out, it's about to rain cold facts. In the history of time, Chromium has had 205,095 commits made by 1,943 contributors representing 7,431,088 lines of code. In the last 30 days, there have been 5021 commits, by 637 contributors, including 53 new hoomans. I did some advanced Nate Silver analysis here for you, and that's at least 167 commits and 1+ new committers a day. On average, that's at least 7 commits an hour. Every hour. All of the hours. That's an imperial ton of new code being added, by what it seems like new people. Imagine if everyone could commit code willy-nilly. Are you imagining a minefield? You should. Code reviews ftw Good news for our browser using audience! Chromium isn't a minefield, and on top of it, has pretty awesome looking code. This comes from the fact that any code changes need to be reviewed and blessed before they can land on the master branch. More eyes means less bugs means you're less likely to commit broken code and break the internet. And you really don't want to break the internet. Even if you have tests, and everything is going your way, you can write correct, but genuinely shitty code. 7 million lines of kinda-shitty code is not something anyone wants to work with, and are worth investing a little time in fixing. Code reviews also bring up the bus factor, which is my favourite sinister nerd metaphor. You know, the buuuuuus factor. The number of people that can get run over by a bus on a team before that team is royally and epically screwed. If all the code that you write has been closely read by a different person, then you're probably ok getting run over by a bus every once in a while. But still, you probably shouldn't. Who would feed your cat? Consistent code is the best code Code style guides are sooper neat, and are a huge part of code reviews, because ain't nobo

## HRT - Humility, Respect and Trust

DevFeed: [HRT - Humility, Respect and Trust](<https://devfeed.tech/articles/hrt-humility-respect-and-trust-21168.md>)

Original publisher: [Read original article](<https://juri.dev/blog/2012/10/hrt-humility-respect-and-trust/>)

Published: 2012-10-14T00:00:00Z

Content type: opinion

Language: en

Sources: [Juri Strumpflohner](<https://devfeed.tech/sources/juri-strumpflohner.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Development](<https://devfeed.tech/topics/development.md>), [code productivity](<https://devfeed.tech/topics/code-productivity.md>)

Tags: [book](<https://devfeed.tech/tags/book.md>), [bus-factor](<https://devfeed.tech/tags/bus-factor.md>), [communication](<https://devfeed.tech/tags/communication.md>), [culture](<https://devfeed.tech/tags/culture.md>), [developer](<https://devfeed.tech/tags/developer.md>), [software](<https://devfeed.tech/tags/software.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [team](<https://devfeed.tech/tags/team.md>)

### AI overview

The article discusses why effective software development teams require humility, respect, trust, shared purpose, distinct responsibilities, and collaboration. It reviews Team Geek, a book about interpersonal relationships, team culture, communication, and the risks of isolated work.

### Source excerpt

Lorem ipsum dolor sit amet