Edd1CC

It’s from 2010

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.

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.

Sweden was "neutral" but big on nazism topics such as eugenics. I spoke about this yesterday with some Swedes (I recently moved to Sweden).

Yep, when you get down to the raw materials used for these devices you get to three/four companies the supply chain relies on

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!

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)

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

HN usernames aren't case-sensitive:

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

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.

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

Can’t you set it in the .zshrc file?

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. """

> We’ve built bridges and boats for thousands of years, where the outcome of failure is people die.

We write software that has killed people due to bugs too, such as Therac-25 releasing too much beta radiation killing patients.

> This has a lot to do with why it’s easy to estimate the time and cost to build a house

My parents and in-laws are property developers and I've also been involved in a build; not one was on time or budget. Some are really off budget, beyond the scale software projects that mess up are. In China they've had projects run into the billions and be decades late.

I do understand your points, but this is what I mean when I say you can nitpick any issue with software not being Real Engineering and apply it to other engineering categories too.

But yeah we may have a very different process in 50 or 100 years. I'm only 10 years into my career and it's already pretty different to when I started!

Social media with people showing off how they landed a $350k job after graduating. Really common for the last few years if you're in the target demographic to get videos like "How I spent my $20k monthly salary as a 22 year old in FANG" or whatever. It was inbound marketing to leetcode courses (like neetcode) whose owner did just this, but I think it also caused a huge expectation that if you go to university and learn some puzzles you'll also earn a million before 30.

Examples:

https://www.youtube.com/watch?v=K7s1IYVfvSA

https://www.youtube.com/watch?v=B4h0A9mr6r4

https://www.youtube.com/watch?v=hnmM-0E2bx0

etc...

There's probably some low-hanging concepts of rules, like A can have X of B. I guess if you work out what four or five of the most common rules are you could build just for them and have the rules in the YAML, as they'll be enough for the tools using backends like this.

Limits would be a good name I think for that rule.

Hillel Wayne did a good "study" on this by speaking to a bunch of engineers who moved into software, engineers who stayed in software, and engineers who only worked in software (yes, you can be a chartered engineer in most Western countries including the US and UK purely from software).

The strong consensus was that software is an engineering discipline, and the nitpicking you can have on any particular topic that is/isn't engineering-y can be applied across the board.

But this conversation is totally moot IMO because if you have a bachelors in computer science or software engineering, and a masters in the same discipline, and several years experience, you can apply and become the same chartered engineer from the same association that does "real" engineering.

How will you add rules? For example a doctor can only have 100 active patients

What sort of testing will you get for $50 paying 14 people? Seems rather pointless because no one will take that task seriously

Or a company does this and sells the meta they learn for a monthly subscription (because as they update this on the company side the meta will change).