Maybe we've got it backwards. The only true problem in software development is miscommunication, and the bigger teams get the worse they perform per-programmer,

Maybe we've got it backwards. The only true problem in software development is miscommunication, and the bigger teams get the worse they perform per-programmer, with the most productivity loss experienced by the most senior team members. On large teams, the most experienced team members are often handicapped by having to operate in a context that remains comprehensible for junior team members, investing so much time in communication that they spend not luch of it on building things. that in turn produces a sort of lowest common denominator effect, where designs are deliberatey kept overly simplistic so they will be easy to communicate. The more expertise is applied to a solution, the less likely it is that people can cooperate on that codebase. The languages and frameworks of today try to minimize the need for expertise to get things done, because expertise doesn't blend well with communicating about code. I think part of the ideas in the article is that by running away from expertise we have often arrived at inefficient solutions. We scale out, with huge codebases that are like cities, sprawling and vast yet with each component isolated and easy to comprehend. Learning from the masters means understanding complex ideas which are based on scaling up, on building a project-specific grammar that encapsulates the problem domain so elegantly that it allows for one line features, at the expense of being incomprehensible to someone new to the codebase or the field.