Comment by QuercusMax

I dunno, “it doesn't have to be that way” is very contextual. I think the peak group coherence and idea integration available in physical proximity is probably considerably above the peak available with current-day telecommunications (and current-day social/psychological technologies/practices surrounding it). But of course most groups won't be able to reach either peak, and the peaks for particular individuals or groups may be reversed from that, or there may be other factors that reverse them. (For instance, being able to more legibly put effort into communication practices with the excuse of “we need to relearn to work together because remote”, even if doing the same thing while in proximity would have had even better effects—and not necessarily because of external pressure, since the same emotive mechanic can operate within the group.)

One of the complaints about remote work at my company that I keep hearing (and also feel myself) is that our staff miss having "random" conversations. I quote random, because it isn't about the literal randomness, but kind of closer to "unstructured and unintended" conversations. We run an ideation-to-prototype event at the company and currently the teams are struggling with ideation that used to happen in such a "random" manner rather easily in person.

My field, medical device software, has very long product cycles. It's not that my teammates are taking a long time to learn, it just takes time for a project to reach maturity.

Additionally, we've all been learning to collaborate in a new mode, with immense distractions. Prior to our reorg, we'd never actually worked together before. And we all had our own deadlines we were trying to meet. The last 11 months have been pretty awful, ya know?

It's not a one-way transfer of information.

- The student has questions that it wouldn't have occurred to the teacher to answer.

- The student gets confused and asks for things to be rephrased or reframed.

- The student has questions that don't currently have static answers, but get computed by the teacher in real time, according to an intuition and assimilation of the facts that the student is only beginning to develop.

- The teacher's answers are up to date, whether or not he has actually exercised the diligence to maintain the textbook.

- The teacher fields the questions that the specific students ramping on the project actually have, rather than trying to anticipate all possible questions of all hypothetical students (and still failing).

There is a reason we have college and not just reading lists. And those are subjects where the economics support massive investments in discovering the best / most broadly useful ways to present the ideas. The average software project isn't that.

The commoditized software factory is an MBA fantasy. The expertise held by "key persons" is a software team's greatest asset.

Reading and writing scale in theory. They require an organization staffed with people who are strong readers and writers. Unfortunately, many people, especially those forced into remote work during the pandemic, are not. They will not read through explicit, clear, but long documentation; they will not respond by writing questions of their own, and will often fail at writing explicit and clear documentation of their own.

You are who you hire.

I think it should help in a way. But I also believe that people overestimate how well one can learn in depth about a complex problem from reading or any mainly passive activity alone.

I know there is this theory about learning styles but it's largely debunked.

To get a really solid understanding of a topic such as a business domain and it's interaction with a complex process and application, it takes a certain amount of time and contact with real problems. The only time that people can quickly pick up new ideas from reading is when they have mastered all of the underlying concepts of that knowledge. But applications generally have layers of very specific knowledge required to understand the problem and existing solution.

The point of the article I think is that it's usually going to take a significant amount of time for new developers to become familiar, regardless of how good the source or documentation is.

Unfortunately for me, I started developing really bad RSI around January of last year, and typing has been incredibly painful. In the past I would have discussed things using whiteboards, sitting down side-by-side with code, etc.; these are all very hard to do if typing causes pain.

Interactive sessions are also very helpful, as there are so many assumptions and background material baked into things that often take a long time to unwind. Being able to gauge on-the-fly if the audience understands can save tons of time and confusion.

I've got 17 years of domain experience across 3 companies in the industry; there's no way I'm going to write all that down in my docs.

I think the point that Naur was trying to make is exactly that this process (unfortunately) doesn't scale.

That is my experience at least (even in very well documented projects).

It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful.

Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.