mattacular

"Byte-for-byte"

What are some traditional automated refactoring tools that can do stuff like those tasks from the example?

For one made by a real band check out Sturgill Simpson's cover

A lot of software engineers do still care how software is produced. That's a good thing!

That's how JWT is designed to work

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.

Test automation is kind of like a religion. It is comforting to believe that the solution to code is more code.

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.

That settles it

It's hard to tell with these releases if Anthropic's astroturfing campaign has come to HN or not but I feel like it probably has

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.

Trade Joe's maybe I could see but how did Whole Foods make this list?

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.

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

Absolute madness and no thank you.

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)

I hear this argument as an excuse not to write comments (sometimes at all). Maybe I am just lucky but I have never had this issue as you've described in codebases, and if I did, certainly not to that extent where it became a memorable thorn in my side.

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.

Explain "why not what" is good general advice. My further advice for comments is: even bad comments can be useful (unless they're from LLM output maybe...) therefore when in doubt, write a comment. Write it in your own words.

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.

The soap opera effect (caused by motion smoothing and similar settings) is the one that bugs me most. It's good for sports where the ball is in motion and that's it. Makes everything else look absolutely terrible, yet is on by default on most modern tvs.

My Nest works great other than the app trying me to get to change my account to Google, which I just close out of every-time. Basic functional UI and works as billed. The unit itself has a nice sturdy feel to it with a very intuitive wheel-and-click interface. It's the only smarthome thing I have besides Hue lightbulbs

Really nice, I found it highly intuitive on first use. Only thing I might suggest is making it more obvious what the "handle" button is that initiates the pick.

They can detect golang pretty reliably by fingerprinting the requests they handle (ie. TLS handshake) unless the app developer has taken some explicit measures to counter it.

The whole web ecosystem was first run by VC money and everything was great until every corner was taken,

Categorically untrue and weird revisionism. Basically the opposite of what actually happened.

And the industry might finally be waking up to the fact that writing code is a small part of producing software.

Typing code and navigating syntax is the smallest part. We're a solid 30 years into industrialized software development. Better late than never?

Genuine question: Why would anyone want to read that? I glanced at the first sentence and decided not to go any further.

It is hollow text. It has no properties of what I'd want to get out of even the worst book produced by human minds.

Even more sophisticated models have a ceiling of pablum.