We look at a doorman and might naively think their function is to open doors so if we can replace their function, we can replace the person. Then we build an automation, fire the doorman and subsequently discover the doorman was responsible for a multitude of social tasks, like taking in the mail, co-ordinating services, providing small tasks for the residents etc. and that physically opening and closing doors was actually the least important part of their job.
Similarly, we think the purpose of code review must obviously be for reviewing code until we look deeper and understand the sociological purposes of code review.
Technologists have a bad habit of entering into a field they don't know, observing but not talking to any of the people they're trying to automate and assuming only the most legible parts of anyone's job are important to grok. It's important to understand that the value any job or function brings can often be totally opaque to an outsider and it requires actually talking to people and understanding total value chains to fully understand where technology can be used to improve things.
> Similarly, we think the purpose of code review must obviously be for reviewing code until we look deeper and understand the sociological purposes of code review.
The truth of this was made clear to me when everyone started doing asynchronous online "code reviews" where the reviewers are just looking at the code (in theory, anyway).
That alone eliminated the majority of the benefit of code reviews, where the author of the code walks through it and explains it in real time. It was amazing how many times I'd seen devs get partway into their explanation then stop when doing that gave them an important insight or revelation that otherwise would never have been surfaced.
One thing I enjoy when working on a new feature is to schedule a team call for me to walk through the code, detailing the changes or improvements I've made, thought processes and overall just give better context into what the wall of text they are going to review is all about.
Likewise, I enjoy when colleagues take the time to do the same with their own PRs. It's something I've tried to promote, but I think everyone is just in a default mode of ship-ship-ship, so people aren't eager to have another meeting to attend.
(Ideally, we shouldn't be submitting PRs that are so huge, but sometimes this isn't always feasible.)
Probably be more aptly called the "elevator operator fallacy".
The elevator operator ensures the safety and security of the passengers, makes sure the elevator is properly maintained and assists the elderly and disabled along with numerous other important tasks.
People believe the elevator operator is only responsible for operating the actuating lever and mistakenly believe they can be automated away without fully understanding their full value to the operations of elevators.
We look at a doorman and might naively think their function is to open doors so if we can replace their function, we can replace the person. Then we build an automation, fire the doorman and subsequently discover the doorman was responsible for a multitude of social tasks, like taking in the mail, co-ordinating services, providing small tasks for the residents etc. and that physically opening and closing doors was actually the least important part of their job.
Similarly, we think the purpose of code review must obviously be for reviewing code until we look deeper and understand the sociological purposes of code review.
Technologists have a bad habit of entering into a field they don't know, observing but not talking to any of the people they're trying to automate and assuming only the most legible parts of anyone's job are important to grok. It's important to understand that the value any job or function brings can often be totally opaque to an outsider and it requires actually talking to people and understanding total value chains to fully understand where technology can be used to improve things.