HN user

jakequade

129 karma
Posts1
Comments37
View on HN

If the company is already huge and makes a tonne of profit, there's little/no need to double-dip on an accessory service that already makes a good case for pushing people into their main service (i.e prime video is free if you use amazon prime -> using amazon's main website/service).

It's not about the market cap specifically, it's stating that prime video doesn't need to operate at a profit in order to benefit amazon's core business.

If you have punitive anti-drinking policy, and a racial group susceptible to that problem, it becomes a racist policy. There's alternatives that don't set people with problems back even further.

it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is

... is it? The fact that a bug exists means there's a logic gap. You can try and patch it with theory, but that's just adding assumption to a scenario created from broken assumptions. Also, the job of telemetry in incident reporting isn't to be vague - its to add precision.

I didn’t need comments if I wrote self-documenting code.

More than any other approach to coding (x-based-development etc), this has come up most frequently for me personally, and it astounds me how many people have this mentality.

Comments are a way to break out of whatever terse syntax your given language requires and speak directly to the developer. A single comment can house so much more context and insight the best-formatted code could ever hope for. When the only downside is some holier-than-thou idea of "I shouldn't be doing this" (despite the fact you clearly need to), I'm surprised so many people fall for this terrible mentality.

whether it's fair or not, personal connection and trust play a huge role in collaborating effectively and deciding who gets what work, who gets promoted, etc.

You're assuming a bunch of stuff here. There's something to be said for:

1. Having known people pre-covid, and so having a predefined "connection" with them. 2. The kinds of work that would or would not be more susceptible to personal bias. Web development, for example, is more impervious than people-management.

Ultimately what you're talking about is bias, and bias is shit and should be minimised. Remote working shouldn't be compromised as a result of people not being able to be impartial in their work.

Grab a revolut account. They're free, and they have a tool called 'digital temporary card' that is good for one use. After the card number is used, it's cycled.

Not affiliated, I'm in Aus and I use my temp card for anything I don't want to be ongoing. Doubles as a breach safeguard (my credit card involved in a DB dump doesn't matter if it was a one-off number).

There's other good reasons to use revolut but will save it :)

Also, they have no fucking idea what we're talking about, and "can't read their messages" just flat sounds like a bad idea to them.

I love haskell, but personally don't want haskell ideas to be popular until they're possible for a given language. Yes, lazy evaluation and tail-call recursion are awesome... At least they are in haskell. Outside of haskell, it's just a fun trivia fact that some other language does it.

Failure to validate a product before building it? Premature optimization.

I largely agree with your comment, minus this. Unless everything after the initial idea for a product is an "optimisation" - which is quite a claim - building something shouldn't be lumped together with optimising it.

My point is that it seems like you're attributing more to this idea than is fair.

----

Fullstack developer, started in backend, more recently building an app with React Native and GQL. Have a side project in Rust, Rust being my favourite language. In my third year of development work

----

  Location: Sydney, Australia
  Remote: Open
  Willing to relocate: Open
  Technologies: PHP, React, GQL, Rust, Node, Some Haskell
  Résumé/CV: https://bit.ly/3crRyUM
  Email: j2k4@protonmail.com

I think you're both giving marketing too much credit in the product's creation, and inverting the creation process in general.

It’s like waiting to build the backend until the frontend is 100% complete

It's more like building a backend, then realising that the data structures could be improved when you're building the front. Marketing at best provides enhancements, not core changes (unless your product itself was incorrect to begin with).

Honestly, if your marketing affects your product as much as you're suggesting, you have a pretty unstable product.

Attempts to make a system more 'legible' often ignore (or don't fully comprehend) why they exist in a certain way. Remaking the system without understanding these aspects leads to something that makes more sense 'on paper', but undermines the complexities and nuances of the original system.

Example (from the text):

- British implementation of a 4-tier caste in India, as their way of comprehending what was (allegedly) a much more complex social structure. It's now the default caste system in the nation.

- Turning forests into agriculture-like rows of trees creating a fatal monoculture.

- Spanish colonization of the Philippines. In an effort to make records/taxes easier, the Spanish created the "Alphabetical Catalogue of Surnames", restricting the number of assumed names. This countered Filipino culture, which had both assumed Christian names, and siblings having different last names.

"We're hiring, here's some blog posts.

What's that, you want to know about the roles? Oh, they're _all_ in this link. Most are sale-BUT here's some info on our stack!"

Lame.