Code cannot and should not be self documenting at scale. You cannot document "the why" with code. In my experience, that is only ever used as an excuse not to write actual documentation or use comments thoughtfully in the codebase by lazy developers.
I find it to be more difficult. Especially if I can't pane the files in view comfortably (ie. beyond 2 or 3 it gets significantly harder to work across them).
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.
Estimation is an art, not a science. It's always going to be a judgement call by the engineers tasked with giving them to management. Taking all of the factors from this article and beyond can and should go into making that judgement call.
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.
I see them as conflicting viewpoints because as a general rule companies do not focus on
> 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.
> Not a great regulatory move, in my opinion.
> But I really wish ad companies would implement this rule across the board.
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?
Account created 16 hours ago posting highly dubious AI hype? This user is almost certainly part of the intense astroturfing campaign likely financed by Anthropic that has been ongoing for days/weeks now.
Their rationale is written here, May 21 2021 final comment on the closed issue from the creator themself. Even in 2021 this was a dubious argument to make given the browser landscape, and they are clearly just frustrated to be challenged on this topic. They think legacy browsers are forever and furthermore readability of .forEach() is better anyway:
> 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.
Have others not noticed the extremely obvious astroturfing campaign specifically promoting Claude code that is mostly happening on X in recent days/weeks?
I think that's true and it's also a convenient way to "smuggle" in Google's most important doodads: their tracking apparatus which includes all of the single sign on and MFA stuff on top of the usual analytics
The AirBNB JS style guide is kind of like a relic in time from the transition to ES6 etc. Leave it in the past. Their only argument for not supporting eg. "for-of" is because of "legacy" browsers not supporting it. Maybe a salient argument at the time of writing (these issue threads are nearly 10 years ago), but certainly not today.
I'm not talking about unnecessary (nor incidental) complexity. That is a whole other can of worms. I am talking about the complexity required given what you need to a system to spec. If choices are made to introduce unnecessary complexity (eg. "resume driven development" or whatever you want to call the proclivity to chase new tech) - that is a different problem. Sometimes it can be eliminated through practical considerations. Sometimes organization politics and other entrenched forces prevent it.
Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)