HN user

romellem

1,038 karma
Posts12
Comments107
View on HN
GitHub Is Down 3 months ago

Literally just had this same signal with PR review comments. Checked the status page, saw it was green, and (correctly) assumed “not for long!”

TypeScript 6.0 RC 5 months ago

Some of these missing checks were why Flow was an attractive choice when weighing [Flow vs Typescript][1].

For example, it wasn't until Typescript 2.0 that we got null checks!

- https://www.typescriptlang.org/docs/handbook/release-notes/t...

  function getLength(s: string): number {
    return s.length; //  Runtime crash if s is null/undefined
  }
  
  getLength(null); // TypeScript <2.0 would not error here

[1]: https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.ht...

The experience you describe has been completely different from mine. I’m not a big poster, but I use Bluesky daily for:

- Sports

- Law

- Authors

- Comedy

- Video Games

- Programming news

- Other general news

Really feels like you are projecting a bit.

Should say "Made in America*", since:

  Not all of its parts are U.S. made: Other components come from China and other Asian countries. [...]
  The screen and battery come from China and the rear-facing camera comes from South Korea.
Also, what is this bit at the end about tariffs?
  Tariffs likely won’t affect his costs at his current production rates
  because he ordered a large batch of parts when he started and still has
  them in supply at his facility. Weaver says that a long-term tariff on
  imported electronics could make the Liberty Phone’s manufacturing cost
  more competitive, since the cheap components would only see marginal
  increases, and more components are likely to be built in the U.S. soon.
They won't affect his costs because he has a huge stockpile? That's like when people said "I don't need the government to force me to get health insurance. My husband is a doctor."

Also "more components are likely to be built in the U.S. soon" - says who? How much is "likely," and how soon is "soon?" Lazy reporting at the end with practically no push back from the WSJ writer.

I largely agree with these, except for #4:

  Ship First, Refine Never
  
  Write good enough code that solves a user’s problem and only optimise when metrics demand it.

  Too often, we’re focused on perfectionism or premature optimisation, which prevents getting our code in the hands of users quickly.
  
  - Identify the critical components of your feature.
  - Deliver only those to the user.
  - Users just want to click the button, do the thing, and move on—anything else is wasting time.
This only briefly touches on “only optimize when metrics demand it,” yet equally import is “collect the metrics and analyze them!”

Namely, talk to your customers, or use software to see how they are using your product. Often times, we don’t get something right the first time, so the idea that you’d aggressively deprioritizing refinement seems like a mistake.

Contrast Meta's stance with Costco's, when [Costco responded][1] to a shareholder that proposed Costco prepare a report on "the risks of the Company maintaining its current DEI roles, policies and goals."

  Our success at Costco Wholesale has been built on service to our critical stakeholders: employees, 
  members, and suppliers. Our efforts around diversity, equity and inclusion follow our code of ethics: 
  For our employees, these efforts are built around inclusion – having all of our employees feel valued and 
  respected. Our efforts at diversity, equity and inclusion remind and reinforce with everyone at our Company 
  the importance of creating opportunities for all. We believe that these efforts enhance our capacity to attract 
  and retain employees who will help our business succeed. This capacity is critical because we owe our 
  success to our now over 300,000 employees around the globe.
[1]: https://materials.proxyvote.com/Approved/22160K/20241115/NPS...

mostly useless comments about not having periods at the ends of lines

Oh my god, this sounds like a nightmare. I definitely would not be able to tolerate this for long.

Did you try to get them to change? Were you just not in a senior enough position for anyone to listen?

Being skeptical of abstractions is something I have been adhering to for a while in my career, and I have found it to be a successful strategy for long term project health.

This passage really connected with me:

Asymmetry of abstraction costs

There’s also a certain asymmetry to abstraction. The author of an abstraction enjoys its benefits immediately—it makes their code look cleaner, easier to write, more elegant, or perhaps more flexible. But the cost of maintaining that abstraction often falls on others: future developers, maintainers, and performance engineers who have to work with the code. They’re the ones who have to peel back the layers, trace the indirections, and make sense of how things fit together. They’re the ones paying the real cost of unnecessary abstraction.

I find this mentality to overlap with (the resurgence of?) discussion on DRY vs WET principles, with some other good links on this including:

* https://overreacted.io/the-wet-codebase/

* https://www.youtube.com/watch?v=TqfbAXCCVwE