Hacker Newsnew | past | comments | ask | show | jobs | submit | habitue's commentslogin

This is an interesting distinction, but it ignores the reasons software engineers do that.

First, hardware engineers are dealing with the same laws of physics every time. Materials have known properties etc.

Software: there are few laws of physics (mostly performance and asymptotic complexity). Most software isnt anywhere near those boundaries so you get to pretend they dont exist. If you get to invent your own physics each time, yeah the process is going to look very different.


For most generations of hardware, you’re correct, but not all. For example, high-k was invented to mitigate tunneling. Sometimes, as geometries shrink, the physics involved does change.


This just doesn't explain things by itself. It doesn't explain why humans would care about reasoning in the first place. It's like explaining all life as parasitic while ignoring where the hosts get their energy from.

Think about it, if all reasoning is post-hoc rationalization, reasons are useless. Imagine a mentally ill person on the street yelling at you as you pass by: you're going to ignore those noises, not try to interpret their meaning and let them influence your beliefs.

This theory is too cynical. The real answer has got to have some element of "reasoning is useful because it somehow improves our predictions about the world"


...and will also have a deeper understanding of the problem that will help solving other problems down the line?


Skills wont use less context once invoked, the point is that MCP in particular frontloads a bunch of stuff into your context on the entire api surface area. So even if it doesn't invoke the mcp, it's costing you.

That's why it's common advice to turn off MCPs for tools you dont think are relevant to the task at hand.

The idea behind skills us that they're progressively unlocked: they only take up a short description in the context, relying on the agent to expand things if it feels it's relevant.


Your reply unlocked some serious, yet simple understanding for me. Thank you.


These kinds of tools should be standard in understanding code


Pylon (https://pylonlending.com) | ONSITE Menlo Park, CA

What Stripe did for payments, Pylon is doing for the mortgage industry: We're taking a sleepy industry with backward technology and re-building the stack from the ground up. We're first-principles thinkers, and our team is small, talented and ambitious.

I'm hiring generalists who love coding and want to build something beautiful in an industry where technology written in the 90s is the norm. We're Series A, well funded, and we have traction with customers. Come to Menlo Park and help us turn the $13 trillion US mortgage industry into a set of APIs.

https://jobs.ashbyhq.com/pylon?utm_source=hn-whos-hiring

If you like:

- Programming languages

- Functional or Logic programming

- Operations research & optimization

- Working on an amazing team on a really hard problem

Come join us!


I mean, bcachefs is basically the equivalent of rewriting all that code, without explicitly trying to be a clone. Same for btrfs


And how hard it is proves that zfs didn't make a bad choice in not trying the same. (though it would be interesting if either had a goal of a clone - that is same on disk data structures. Interesting but probably a bad decision as I have no doubt there is something about zfs that they regret today - just because the project is more than 10 years old)


I think Co-* is probably better, though more obscure I guess


We did this at stripe when deprecating TLS 1.0, and called it a brown out (I don't know the origin of the term in software).

You do it when you have a bunch of automated integrations with you and you have to break them. The lights arent on at the client: their dev teams are focused on other things, so you have to wake them up to a change that's happening (either by causing their alerting to go off, or their customers to complain because their site is broken)


have also heard this as doing a “scream test” — turn it off, see who screams about it


There has to be adverse selection here from the amount of money being offered right? Like ok, very few people could turn it down, but it's not going to result in a motivated team.

I am imagining all these overpaid founders etc just sitting in a room like reality show contestants. Trying to make smalltalk, brainstorm jamming for months, not really producing much because... who cares, they have unbelievable money and this is the weirdest scenario ever.


I would imagine there is some sort of incentive structure for the megamillions being offered by meta to these people not just throwing all of the money at them upfront. Payout structed around meeting measurable goals not just show up and collect fuck you money. Or maybe it is silcon valley redux and they will set on the roof with big head what do I know.


You’re assuming they’re not ambitious, self-motivated, or curious.


Usually things that go away with lots of money and corporate structure. I bet a good part of those new hires will land on the roof sooner or later.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: