Some frameworks or coding styles really lean into having lots of tiny files. That necessitates a more complicated directory structure for the project. Locating files eventually tends to requires search capability rather than being able to look through the tree in a sidebar.

None of this is "hard" per se but I find the opposite is nicer to work with typically.

I always tell my teams just skip the middlemen and think of estimates as time from the jump. It's just easier that way. As soon as an estimate leaves an engineer's mouth, it is eagerly translated into time by everyone else at the business. That is all anyone else cares about. Better said - that is all anyone else can understand. We humans all have a shared and unambiguous frame of reference for what 1 hour is, or what 1 day is. That isn't true of any other unit of software estimation. It doesn't matter that what one engineer can accomplish in 1 hour or 1 day is different from the next. The same is true no matter what you're measuring in. You can still use buffers with time. If you insist on not thinking of your labor in terms of hours spent, you can map time ranges to eg. points along the Fibonacci sequence. That is still a useful way to estimate because it is certainly true as software complexity goes up, the time spent on it will be growing non-linearly.

> Long term financial interests, mostly.

It's great that you as an individual feel otherwise (I do too), but there are larger macro forces at work which compel firms to act the way they do: pursue short term growth at all costs. The counter-balance to this is either a strong regulatory environment, or a hope and prayer that a majority of companies suddenly gain a strong CEO who feels otherwise and is not obligated to satisfy shareholders who don't. Only a few such CEOs come to mind, and they're looking increasingly short for this world.

You don't see how these are conflicting viewpoints? What do you think would compel a company to act in some way that is not in line with its short term financial interests? Sheer luck?

> in the latest version of all browsers. Despite marketing, no browsers are "evergreen" according to the google analytics of major websites I've been able to review over the last couple years. (Nothing but safari will likely ever support PTC - which is not an optimization - so that's not really relevant to discuss) Performance isn't important, readability is.

ref: https://github.com/airbnb/javascript/issues/1122#issuecommen...

Have others not noticed the extremely obvious astroturfing campaign specifically promoting Claude code that is mostly happening on X in recent days/weeks?

If there are no comments, you are reading the code (or some relatively far away document) for all understanding anyway. If there are inaccurate comments, worst case you're in the same boat except maybe proceeding with a bit more caution next comment you come across. I always ask of fellow engineers: why is it unduly difficult to also fix/change the comments as you alter the code they refer to? How and when to use comments is a balancing of trade-offs: potential maintenance burden in the future if next writers are lazy vs. opportunity to share critical context nearest its subject in a place where the reader is most likely to encounter it.

Had to add the last sentence for the circa 2020s developer experience. LLM comments are almost never useful since they're supposed to convey meaningful information to another human coder, anything your human brain can think of will probably be more helpful context.