The author could have just left the "Remote" part out. This piece is really about hiring independents for gigs vs. building and educating your own team.
I thought something quite similar, but upon further reflection the "remote" buildup and conclusion sets the narrative frame for the rest of the article.
Rather than just a "wisdom dump" it becomes more of a story with a purpose.
It does create the framing but I just don't see how it is relevant to the conclusions drawn. There are entire companies that are remote and are obviously able to communicate problem domain expertise and execute effectively.
It is not an attack on remote working. It is an attack on the naive assumption that there is worthwhile value in being handed a stack of detailed requirements and implementing them with no back-and-forth.
Which is very wrong: You get domain knowledge by mapping out the field (as stated in TFA), which can happen regardless of where you physically sit.
Case in point: I've been working remotely for 2 years now, and I've gathered as much domain knowledge (if not more) as I had in previous roles over the same timespan.
What's important is to get your software out there, so you can map the field.
