Becoming a Better Engineering Team | Hacker News Reader

Becoming a Better Engineering Team

thenewstack.io

65 pointskiyanwang13 comments

  > “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?

A 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?

> 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.

"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."

Like injecting a tracer into the blood and seeing how it flows through the system -- that does sound super fascinating. Have you ever actually done it? I'm trying to think of how in practice you'd go about it, given how much noise there is for any signal. Any more specific tips would be welcomed.

I did not read the article that way. But then I've been a manager for a while now. Implicitly, there is a discussion about phases of team/product.

My experience is that the way to build great software is by small teams, with skilled programmers. Aka your artisan model.

Unfortunately, at least in my experience again, that does not scale as a company grows and the demands grow. You need more features, more people get involved, you can't just build/maintain the product within a single team. And you really want to avoid relying on specific individuals because it is too risky.

So that tension between craftmanship and commoditization of skill is definitely there. I wish there were a way to see a workable scalable model that does not involve commoditization in one way or another. I have not had the chance to see one yet.

I have. Or at least closer to it than you seem to have seen. The way it works is to do the talented artisan / engineer thing within small teams, and the managerial / communication focused thing across those teams. The really hard part is drawing and maintaining the right lines between teams, within which each team can work independently.

The way you scale is not to disregard artisanship, it is to design the right interfaces and abstractions, and allow for ownership at the lowest possible level with a hierarchy of “artisan leadership” that has equal power to managers and other paper pushers. Easier said than done, but it is the only way. The commodification approach is the blind leading the blind, where the gears get more and more gummed up until someone realizes they need to call in expert help. And when they do, it will inevitably be—surprise!—a small team.

Getting the right interfaces/abstractions between teams is kind of what's hinted in the article, no ? It is needed both at the code/architecture level and at the team/org level

In my mind, commodification does not imply getting people who don't know what they are doing. But you need to move away from individual ownership as the main model, which at least in my mind is implied by artisanship. You need to be able to replace almost anyone by somebody else as you grow.

if correct, you're describing SEO spam. And, I think you correct. thanks for catching it.

This article is just a summary of an interview. You're probably right that the person writing it isn't really qualified to present their own novel ideas on software engineering management, but that's not what they were attempting to do.

Communication has become a catchall for MBA types who are drawn to fast revenue generation in tech. Often they talk more than think or read.

You might be onto something here. Communication is important, but so is the craft. It feels like we are going from one extreme to another.

I have found over 17 years in the industry that theres more&more talk/meetings, and less&less written word.

Reminds me of the saying that most of mans problems are caused by the inability to sit quietly in a room with their own thoughts…

Reply on news.ycombinator.com