This is profound and beautiful description. Thank you for sharing. Totally can relate to that. Been there, seen that.

Do people like that exist?

Totally.

But seriously, I guarantee you the opposite is more common- the incompetent devs which can't manage shipping anything, keep trying to do "surgical and small edits" after 1 week of thinking about them and then have them blow up in prod for someone else to fix quickly because if it's up to them, it'll take 2-3 sprints

10 years ago I was a lot closer to what y'all talking about. After having more and more colleagues I can no longer agree and suspect this is mostly the opinion of incompetents which try to discredit regular devs.

Another thing they always lack is the ability to see when a large change is necessary because that's just what is necessary to achieve the feature in a stable manner. Sorry to say this, but starting of this discussion while trying to discredit large change sets in the age of ai is incredibly inept.

When you wrote your software well, large changes are possible and increase stability when you actually need to add a fundamental change of behavior. Which can come from a miniscule requirement.

But to close off on the topic of this article: they made the right call. In the open source context you cannot have this kind of incentive anymore with openclaw continuously shitting out one PR after another

	▲	toraway 7 minutes ago \| parent \| next [-]
		From the excerpt it sounds like the author is just describing one specific archetype from within a list of others included in the book and doesn't make any claims about it being a uniquely common type within every org, or the most common type of bad engineer in general. In fact it gives the opposite impression by specifying "at least one", which implies the category is supposed to be distributed widely enough to be recognizable in an org of sufficient size, but not dominating the ranks of software developers in droves. That seems more like a strawman you're arguing against.
	▲	varjag 3 hours ago \| parent \| prev [-]
		Amen. There has to be some people like that statistically but literally every prolific programmer I know is also pretty damn good. Proficiency tends to be a function of practice.