7 ms·
> “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 a
by jmillikin 4y ago
> “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?
- magnusmagnusson 4y ago
- ossopite 4y agoA truly great comment. On the second observation, my thought on that debate is that we should consider the lifecycle of things made by artisans. Is it true that they are often made and never remade? Software at most companies is rather different. And how about the maintenance of software by people who did not write it? Its hidden complexity makes that a much harder proposition compared to the output of an artisan in a physical medium. Maybe there is a place for programmers as skilled artisans, but maybe not in your typical software company today. If the artisan model has issues for such companies, maybe designing the system collaboratively in the abstract and considering code an "implementation detail" is indeed a better model. Or are there others?
- vasco 4y ago> First, is it just me, or have I already read this article > 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 feeling and the rest of the comment put to words something very real. Not even just in articles but once you read about 15 management books the same thing starts to happen. It's all just different words to say the same things that all just seem to morph into one another. One thing that is related to this is but not really: "what the internet thinks about X". For a lot of topics you can see that whatever a 4chan board or a subreddit initially converge on in a given topic is the source for everything else on the internet for a long time after. You'll pick a topic, research it there, and will find that most articles or comments in other sites will largely be different packaging of the same information. Tracking the source of a new insight from a board/subreddit like that and over the weeks seeing it bleed into other sites, then eventually into real life news programs and so on can be super interesting. Sometimes there's really big events that anyone can see ripples of (like the GME craze), but many other times it's more subtle. The sources vary, sometimes it's a netflix show or something else, but "noticing the hidden source" in any article is a fun hobby in itself if you like the internet.