Engineering Intensity | Hacker News Reader

Engineering Intensity

ruiper.es

83 pointsRPeres13 comments

Large corporations have this sort of structure where you're a node in a graph performing a niche service(s) in a series of steps where there are dependencies and you are also a dependency for later stage services. Working every second of the day and working really hard, doesn't actually do anything since you're just one cell in a slime mold. Rather, you wait for another node to deliver some sort of task, do your part on it, and send it further off in the appropriate direction. The most meaningful parameter here is time. A soul being in the right time and place, filling a spot, communicating and working on the right thing at the right time. Sure you can fill the rest of the time if you wish or for political reasons but the important stuff happens at unpredictable timing and often isn't very abstract, only specific.

Yeah this mirrors my thoughts as well. Individual training for endurance, speed, accuracy, power all have analogues in for intellectual work. So if you're optimizing for your own individual performance then this analogy makes a lot of sense.

But in a team setting, the goal is some external output that depends primarily on efficient collaboration. Individual capabilities still matter, but it's how they are applied in concert that delivers results. From this perspective, pacing the team isn't necessarily about preventing burnout, but more that it hits diminishing returns pretty quickly, and becomes counter-productive when the team gets stretched too thin to react to new inputs that inevitably come.

I've always use the analogy of congestion collapse when you try to shove to much "stuff" (network packets, cars, work, whatever) through the pipeline.

Great point. It’s never occurred to me until now, but Amdahl’s Law has great application here.

I never want to be the “weak link” in the chain, but overworking myself to deliver my piece in a large project usually has negligible impact, if any. Usually it just ends up providing buffer for other teams that end up using more time.

Something very similar is the theme of the book "The Goal" by Eli Goldratt, which outlines the theory of constraints in a factory setting. The key is to identify bottlenecks and use them to increase/control throughput to match the downstream demand.

For a more elaborate explanation of a similar mental model, check out the "pacing" section in Will Larsons article about a 40 years career.

[1] https://lethain.com/forty-year-career/

this also implies that you can train for more sustained intensity, which I think is absolutely true. You can become a brilliant engineer by finding the right balance of intensity and R&R, assuming this is what you want

How’s this compare for teams collecting a mostly fixed wage vs a cooperative where the workers share in the value they produce? I for one found wage labor incredibly alienating. It wasn’t an intensity issue.

You're talking about getting motivation by increasing the % of revenue you're getting from the company - that seems to not have anything to do with the article at hand, which is about intensity of work and long term team output with constant high pace vs constant low / medium pace.

No. It’s an article about getting more productivity out of workers without burning them out.

So you think one can do more work without burning out by getting paid more money, or being a shareholder vs just a worker?

I would think this would come more from the nature of the work than from the structure of ownership of the company.

Not by getting paid more, but by having ownership of the output of my labor (whether private ownership or public contributions) vs having it stolen from me through coercion under threat of violence

Please stop talking to me - you specifically

> Please stop talking to me

If you don't want people to talk to you in a public forum, don't post in a public forum.

Reply on news.ycombinator.com