> “I think the bigger you get, the larger the company,
  > the more time you’re at it, that tends to get deluded over time,
  > [...]

This quote made me stop and think. Not the quote itself, but the mistake the article's author made in transcribing, and the implications it has for how much the author truly understands the meaning of what they're reporting on.

First, is it just me, or have I already read this article? Maybe not the exact arrangement here (there's a recent date at the top), but the content seems the same as every management-oriented "how to build an engineering team". There's a type of online writer who functions as a human GPT-3, and given a prompt like [[ team culture tech ]] will produce text by paraphrasing and re-synthesizing from the ~decades of prior art on the same topic. This process does not involve understanding, there's no comprehension necessary, so mistakes like 'deluded' instead of 'diluted' aren't (can't) be noticed.

---

Second, there's an interesting bit of sophistry at the very start which I'm not sure the author understands the implications of:

  > Technology work has moved far past the idea of the code monkey
  > or button pusher. If we are truly knowledge workers, then tech
  > work should be as much about communication as code.

Is that the choice for tech workers? Between (1) a "code monkey" who merely transcribes someone else's ideas, or (2) talking about doing things instead of actually doing them?

There's some set of people who would say yes. They view software development as primarily taking place in team discussions, project proposals, email threads, and so on. For them, once the team has agreed on what to build, the actual building -- the writing of code (or copying it from Stack Overflow) -- is almost an afterthought, like a novelist dictating their great works to a minimum-wage typist.

In this worldview, it is true that "tech work" used to be left up to the "code monkeys" for some incomprehensible reason. Nowadays, it is safely handled by people who can't read an RFC but have strong opinions on email etiquette.

However, there is a different way of thinking about tech work, which places the programmer in the role of a skilled artisan. The design of software takes place in an IDE, as code, which embodies both the canonical design and the proof of feasibility. Project outcomes are largely determined by individual skill and experience of the programmers, with communication and team culture taking more of a backseat role.

What does it mean for this article -- supposedly about organization of tech teams -- that the author ignores (or is unaware of) this fundamental disagreement? Have they never been part of an engineering team before? Do they have any insight into the topic that couldn't be convincingly faked? Or is this article the HN equivalent of a highschooler writing a last-minute book report after reading the Wikipedia article?