Recent submissions

Comment · 2 years ago
It’s from 2010
Comment · 2 years ago
I saw someone posit this exact idea at EuroSTAR in Stockholm on Wednesday, fwiw. Two guys from an Australian company suggest this & how both development and testing will be totally prompt based. It got the reaction you’d expect, but it does exist.
Comment · 2 years ago
There’s always these weird bottlenecks in the supply chain though.

My favorite example is during Covid where reduced boron quantities resulted in less Pyrex glass that makes test tubes meaning transporting vaccines was at points rate limited.

I’ve read similar points in the components for lasers to ASML but can’t remember specifics. Chip shortage is the funny one, ASML require more chips that limit their turnaround times which in itself limits chips.

Comment · 2 years ago
Sweden was "neutral" but big on nazism topics such as eugenics. I spoke about this yesterday with some Swedes (I recently moved to Sweden).
Comment · 2 years ago
Yep, when you get down to the raw materials used for these devices you get to three/four companies the supply chain relies on
Comment · 2 years ago
I’ve been buying shares in ASML and below, such as TSCM and Applied Materials, but it’s a brittle plan if anything revolutionary pops up!
Comment · 2 years ago
Who are their real competitors? They’ve been buying parts of the supply chain recently - they seem to have a real moat unless regulation gets involved

(Serious question: I am just getting into the semiconductor world and haven’t found any competitors yet)

Comment · 2 years ago
Yeah if one instance created one ID, then any integration tests creating more than one user would have failed. There were no testing or logging on a system with live users while doing a refactor between two dynamic languages
Comment · 2 years ago
HN usernames aren't case-sensitive:

> That username conflicts with an existing one. Names are case-insensitive. Please choose another.

Comment · 2 years ago
If I give them a trampoline they shouldn't spend all day jumping on it, just because they can. Especially if they're busy with features.

They literally had 1 instance of the backend per $1 of revenue, and the reason the bug wasn't seen straight away was because they had 40 backend instances each with a single uuid that could be used for users before it broke with non-unique id errors.

Comment · 2 years ago
They had 8 AWS tasks running 5 instances each with code written in TypeScript and Python, with frameworks like next.js, with $40 revenue and only a few weeks dev time?

What the actual fuck hahahaha

This is made worse when they edit saying the reason the codes crap is because of time constraints, but spent their time refactoring across languages and spinning up a distributed system FOR NO REASON. That is self imposed harm juggling features and ridiculous technical complexity. What were they thinking.

Edit: a YC summer ‘23 company who’s product is still behind a waitlist summer ‘24, presumably because of a rewrite to Rust

Comment · 2 years ago
Can’t you set it in the .zshrc file?
Comment · 2 years ago
To quote Hillel Wayne on LinkedIn, which sums this "study" up nicely:

""" Yesterday I read a report claiming that Agile projects had "268% Higher Failure Rates" than projects with more upfront planning.

As a fan of upfront planning, and a fan of Empirical Software Engineering, I read the report in more detail.

And I'm pleased to report that it is the single worst study I have ever read.

It is so bad I do not want to share it for fear of spreading a mind-virus, but I can share some highlights:

- The author surveyed 600 people and somehow got P values of 0.00004

- By how he specifically defined "upfront planning", the number of engineers he found practicing it is logically impossible

- Every major calculation table had some sort of error

- The author edited a whole bunch of Wikipedia articles to promote himself, and claims his results can also cure smoking

Today I saw the same report doing on The Register and Slashdot, who both accepted it uncritically. And the hundreds of comments were people accepting the study or suggesting a "confounding factor".

...C'mon, people. You're better than this.

I normally write about Empirical Software Engineering because I think using science to study software engineering is important. But just as important is knowing how to protect yourself from bad science. Anybody who's read a couple of research papers would see P<0.00004 as a major, MAJOR red flag.

Being in STEM doesn't make us immune to pseudoscience. And we're forever vulnerable to seeing something that confirms our beliefs and not digging deeper to make sure it's not lies. """

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton