MurphyA/hacker-news huggingface dataset:
by DannyBee | 2025-04-14 13:03:12+00:00
Google is just really bad at this, but seems to think it's not bad at this. It's sad since there is no excuse for it - plenty of companies conduct regular layoffs and role eliminations in more compassionate ways, it would not take much to survey and learn from their practices. Hell, IBM was often more compassionate about layoffs than Google.

Some of it they've tried to become more formal about in ways that actually make it worse - so for example, the timing of this (which the person complains about) is because (AFAIK) they now have one day a month where ~all role eliminations that are going to happen that month, happen. Or so i'm told this is the case.

Ostensibly so you don't have random role eliminations every day, which makes some sense, but then you have no way for people on the ground to do anything more compassionate (like move the timing a bit) because they can't get through the bureaucracy.

In the end - it's simple - if you disempower all the people from helping you make it compassionate, it will not be compassionate. The counter argument is usually that those folks don't know how to do it in legally safe/etc ways. But this to me is silly - if you don't trust them to know how to do it, either train them and trust them, or fire them if they simply can't be trusted overall.
by roxolotl | 2025-04-14 13:03:13+00:00
One thing I don't quite understand in all of these discussions is why there seems to be a fundamental disagreement about the importance of the dollar at the core of them. Maybe we really just don't know that much about how global trade works historically? I guess there just is a fundamental disagreement at the hear of macro econ about this?

It seems to me like being the country that everyone else relies on to facilitate trade is an incredible thing that you'd never want to give up. And yet that's where we are, and what the disagreement is about. In the past few years there's been a lot of talk about BRICS and how it might undermine the reserve status of USD. Other countries appear to envy this position.

I've read some of the Hudson Bay Capital piece[0] on this, the article linked in the post describing why reserve status isn't great, I guess I'm just going to have to read it in full to get a better understanding of the other side.

[0]: https://www.hudsonbaycapital.com/documents/FG/hudsonbay/rese...
by kragen | 2025-04-14 13:03:20+00:00
As for "non-functional requirements" ("NFRs") Wikipedia suggests examples:

1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time).

2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6]

Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.
by Aurornis | 2025-04-14 13:03:29+00:00
> 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system.

I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward.

The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative.

The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.
by kbolino | 2025-04-14 13:03:52+00:00
I would actually say even in 2012 the observation was probably wrong already, but notably Pike actually made it in the mid-aughts and was simply relaying it in 2012. However, being wrong about what was good for the future of C++ isn't really here nor there; Thompson also famously disliked C++. Designing a language that intentionally isn't like C++ does not equate to me as a rejection of expertise.
by freilanzer | 2025-04-14 13:05:13+00:00
> It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.

That doesn't even make any remote sense. "I don't get the fixation with the JVM. It sounds like you write code as a black box, then compile and run it to see what it does because you don't understand it by yourself."
by thegagne | 2025-04-14 13:05:15+00:00
Efficiency and ease of adoption would be my guess.

The APNIC Ping podcast did an excellent 2 part series on the problems of DNSSEC. It puts more responsibility on the DNS systems that are already complex and doing a lot of work.

The CA system with root trusts is just super efficient and easy, so it won.

It’s not perfect, so I’m sure someday it will be replaced, but not by the current options.
by tristor | 2025-04-14 13:05:40+00:00
So your response is to accept someone's speculation when the company themselves says they are piloting a recording program in the US (however they say the case in the article was not part of this). Given what is in the article, the speculation you linked to is irrelevant.

You are taking a threat model that assumes all recordings have equivalent risk of leakage. On a long enough time scale, you're probably right. I think there is a spectrum of risk that is also based on trust. I trust a company focused on audio/video to handle the materials appropriately a lot more than I do a company where this isn't their core competency.

While /any/ recording presents a risk, recordings you are unaware of are significantly higher risk because you can't do much of anything about them.

You are making a false equivalence and desperately trying to defend it. The two things are not the same.
by ldom66 | 2025-04-14 13:06:12+00:00
Completely agree. What is a tragedy though, is that if Google treats their most hardworking engineers like this they are creating a culture of minimal effort. If this is "just a job" as you can expect to be laid off at a moment's notice with no care for the value of your contributions, then what is the point in doing anything more than what the job description entails. It's just incentivizing people to treat their job the same way the company treats their employees. A culture of distrust and minimum effort. It's very sad to see.
by globular-toast | 2025-04-14 13:06:22+00:00
> I'd prefer the red lights many places to instead count as either a stop sign or yield for cyclists

This is law in some places. It's known as the Idaho stop[0]. One of the most sensible laws IMO. It's almost like whoever came up with it has ridden a bike on the road like at least once.

Drivers who think others who aren't operating motorvehicles should have to follow the same rules need to grow up. They want all the privilege with none of the responsibility. I firmly believe the roads would be better for everyone if cycling proficiency was a requirement for even applying for a driving licence.

[0] https://en.wikipedia.org/wiki/Idaho_stop
by yen223 | 2025-04-14 13:06:23+00:00
If you have trouble committing to an option, it's usually because the options are equally good as far as you know.

There are two ways to go about this:

1. If the stakes are low, you can just pick one option at random and commit to it.

2. If the stakes are high, come up with a way to reduce your uncertainty around the options. Set a time limit, and perform an experiment that will inform your decision. If that experiment doesn't conclusively settle the options, just pick one and commit to it.
by fnordian_slip | 2025-04-14 13:06:28+00:00
Letterlocking itself is great fun, especially since seal stamps and wax are so cheap nowadays. I highly recommend trying it out by sending letters to friends again.

https://youtube.com/@letterlocking is a great resource, and fountain pen network or similar forums are great for cheap but beautiful fountain pens and ink (also for very expensive variants of the same).
by PaulHoule | 2025-04-14 13:06:38+00:00
(1) The UCSD p-Machine was contemporaneous and made it feasible to compile Pascal for machines like the 6502 which were terrible targets for conventional compilers. It was atrocious in every way, particularly atrociously slow. At the time many CS professors with Microsoft BASIC being the dominant teaching languages but UCSD plus the inability to do systems programming in ISO Pascal made a generation of young programmers hate Pascal with passion.

(2) Scott Adams made an adventure interpreter was was similar but less sophisticated than the z-machine but similarly portable, in fact you could write a Scott Adams interpreter in BASIC [1] but he also wrote interpreters in assembly for the most popular platforms

https://6502disassembly.com/a2-scott-adams/interp.html

(3) Infocom developed the games on a PDP-10 machine which might be the last general purpose computer that survived with other than the 8-bit byte. (Though it had bitwise addressing which helped it cope with the industry going in that direction).

[1] Notably if you tried to write an adventure game in straight up BASIC you'd struggle. It's not like you could look up a verb in a hashtable and dispatch to subroutine. You'd be writing incredibly long if-then-else ladders nested inside if-then-else ladders which is bad enough in a civilized language.
Ask HN: Why is SaaS discovery still hard even with Deepresearch/Manus?
by fiiico | 2025-04-14 13:07:33+00:00
I still find myself searching for a SaaS solution to a technical problem for way too long. And then a few days/weeks later I come across a product that solves that problem really well and wish I had found it earlier.

Gpt or deepresearch doesn't do a good job at going in depth, I still have to read the documentation and blog posts of a bunch of tools before getting a good idea of what'll work.

Do other people feel the same? What has worked best for you?
by torginus | 2025-04-14 13:07:38+00:00
My understanding is that Lisp and most functional languages map very well to PL theory and how compilers and interpreters manipulate programming languages (functions as graphs of code, types as contracts etc.), while procedural languages map well to how CPUs execute programs, and the abstractions operating systems provide (functions as mappable pieces of memory, types as memory or register layouts etc. )
by solardev | 2025-04-14 13:07:59+00:00
It really depends on your role. I still think our job is ultimately to solve problems for users and/or other stakeholders, and that coding is just one of the tools we use.

But it's not always the best tool. Even as an IC, I've done far more with emails and meetings than just writing code without thinking, whether that's discussing UX implementation details with the designer or pushing back on some half-baked over-engineered solution from management or fighting some evil advertising and tracking scheme from marketing. We don't just write code but also gatekeep it with some level of professional judgment and ethical discretion. (Or at least should.)

I think the orgs that don't give you any autonomy or agency beyond "code monkey" are the more problematic ones. Not only will you burn out having to repeatedly implement things you have no input into, you'll also be the easiest to replace if all you do is code.
by mcv | 2025-04-14 13:08:03+00:00
Layoffs are one thing, but to be cut off without any notice, that really sucks. I usually know months in advance that when I'll leave, so I'll have time to finish what I'm working on and train the people who will take over my responsibilities. It seems weirdly destructive for a company not to allow for that.

As for email, calendar etc, I think the lesson here is not to depend on anything from your employer. Keep everything under your own control, so you won't lose too much when you get fired.
by CharlieDigital | 2025-04-14 13:08:13+00:00
> So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that?

Imagine you are going out to get dinner with a group of friends. "Hey, Antoine is allergic to shellfish and Lin is a vegetarian" are hard requirements. Now that I have some hard requirements, I may have input on options that fulfill those requirements because there are real constraints around which the choice must be made. With no requirements, I don't really care where we eat, I'll go with whomever has the stronger opinion; I'm really interested in having a great meal together -- why ruin vibe over whether it's Japanese or Indian?

Is there really a need to debate whether it's Japanese or Indian? Am I a coward for not taking a hard line on Japanese being the clearly superior dining option? Why cause friction when both get the job done? But if Antoine and Lin are coming, then I will take a hard line because Antoine is allergic to shellfish and Lin is a vegetarian so let's pick Indian because I like Antoine and Lin's company.

> ...send that NFR in an email...

Yes, this is exactly how real world software engineering works. Just send the NFR in an email and call it a day.
by 999900000999 | 2025-04-14 13:08:17+00:00
>There seems much unfairness sentiment nowadays where people think companies with access to lots of capital are guaranteed to succeed, like some kid with rich parents. Many seem to think that all there is between them and success is money, but in reality that's rarely the case.

Yes, Rich kids tend to have better chances than poor kids. Get in any trouble, you'll have a decent lawyer. You'll attend better schools, your parents will probably buy or help you buy your first home.

Need a doctor or want to see a therapist, you can do so within 24 hours. I'd even argue therapy is largely a luxury for the middle class and up- most of the time Medicare doesn't cover it at all or you have like a year waiting list.

I've been evicted twice in my youth and now I've made 6 figures for a good while.

Money makes things easier. You might run into issues with your friends trying to rob you, but they'll rob you when you're poor too.

Likewise, a company with no funding is basically an idea. Might be a good idea, might be a God awful one.
by eqqn | 2025-04-14 13:08:42+00:00
Another way to view it is a series that accompanies a child to young adult years. (It took me a few years to get through the series inbetween other books. I assume many bedtime reads for the first few, and independent reading for later ones). What starts as fantastical and whimsical, indeed becomes more somber and concerning interpersonal dynamics, especially those within Moomin family and those around them. "Moominpapa at Sea" is probably most relatable to adult readers. The underlying message of family unity, finding ways to cope with certain events, parenting styles, need to break routines (picnics), unrequited crushes.

Moominland Midwinter is interesting character study too, with sporty "artistic" coded Hemulen proving too much for most of the cast to handle, the forgetful grandpa. Perhaps the message was it is okay to not be friends with everyone as it is a bother.

Compare it to "Finn Family Moomintroll" which is just a constantly stacking ridiculous lighthearted escapade with a few more mature jokes mixed in.
by RHSeeger | 2025-04-14 13:09:26+00:00
I tend to do something like this for most tickets I work on (that have choices to be made). I work through all the details and make sure I understand them all, then note what the difference choices are for various things. Where there's a choice to be made that requires "customer" input but that I have a pretty solid idea what the right choice is so am going to move forward on that, I'll make note of it, etc. It also gives me time/space to document ambiguities in the requirements.

I am.. overly verbose in tickets. That being said, it's come in handy many times in the past; some of which are me trying to figure out why I made a specific choice.
by Diggsey | 2025-04-14 13:09:27+00:00
They are definitely more error-prone usage patterns, and coming from Rust the amount of hidden unsafety is quite unsettling (in addition to the obvious potential for user errors, depending on the aliasing model of your language/compiler, which I suspect Zig hasn't figured out yet, this parent pointer trick could even lead to miscompilations...)

Having said that, intrusive linked lists are quite an important data structure in code which is required to be allocation-free. Kernel code, signal handlers and code which requires consistent performance (eg. audio processing) need to be able to move objects between containers or have objects in multiple containers without allocating.
by dijit | 2025-04-14 13:09:56+00:00
In general I don't have a problem committing, but there's also some solid rules of thumb that you can follow, for example: "if all else is equal, take the option that leaves you the most opportunity later".

However I have also employed Weighted Decision Matrices[0] to a pretty high degree of success if they're undertaken seriously and the outcomes taken as a learning exercise.

Ironically when I employed the Weighted Decision Matrix I often didn't like the result, which was equally telling!

[0]: https://en.wikipedia.org/wiki/Decision-matrix_method
by mort96 | 2025-04-14 13:10:01+00:00
Also, getting better at intuitively analysing these situations and picking an option is part of what it means to gain experience and become better at what you're doing. If you're doing things right, you will start out finding it difficult to pick an option when you're new (to programming, to a particular domain, to a particular technology, whatever), and as you get better, you 'll develop a "taste" for what seemingly-equivalent solution you prefer.
by DonHopkins | 2025-04-14 13:10:32+00:00
Ubik was intentionally hilarious, with the never-fully-explained-but-there-you-go eye-eater, and the briefcase psychiatrist intended to drive you insane! (Or maybe that was from 3 Stigmata?)

Mark Weiser told me that Ubik was the inspiration of the term he coined, "Ubiquitous Computing"!

https://news.ycombinator.com/item?id=42790807

The Computer for the 21st Century:

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

I also loved The Weapon Shops of Isher, with the parallel universes and third eyes.
by marklit | 2025-04-14 13:10:58+00:00
From discussions I've seen online, a lot can fail on satellites so there is a bias to do as little as possible on them. There does appear to be plenty of bandwidth to transmit back to ground stations.

The real win will be satellite-to-satellite transmissions where any data collected by the constellation is passed to the satellite that'll next fly over a ground station. This will lower the time from capture to analysis considerably. The fresher the data, the more valuable it is.
by Aurornis | 2025-04-14 13:11:14+00:00
> the 5th by a person extremely non-commital. This person avoids exerting any technically authority, so as not to disturb the team's balance. All decisions are made democratically, all votes being equal regardless experience/seniority. Same goes when being called for estimates.

This is a very common failure mode for first-time leaders and managers. They optimize for minimizing conflict and want everyone on the team to like them.

A difficult lesson to learn in leadership positions is that you can’t make everyone happy and you can’t avoid every conflict.

Hyper-democratic leadership styles don’t work outside of very small and tight knit teams where everyone was already on the same page.

Someone needs to pull that person aside for some intense coaching to train them out of the mindset of people-pleasing and into the reality of getting work done. It’s not a fun transition but it needs to be coached. This is one of the turning points where many people realize they don’t want to be in leadership or management roles because the difficult decisions and uncomfortable conversations are in conflict with their personality.
by shagie | 2025-04-14 13:11:48+00:00
I'm reminded of the last part of 'TLA' form the Jargon File (I had a hard copy back in college that I read cover to cover).

http://www.catb.org/jargon/html/T/TLA.html

...

The self-effacing phrase “TDM TLA” (Too Damn Many...) is often used to bemoan the plethora of TLAs in use. In 1989, a random of the journalistic persuasion asked hacker Paul Boutin “What do you think will be the biggest problem in computing in the 90s?” Paul's straight-faced response: “There are only 17,000 three-letter acronyms.” (To be exact, there are 26^3 = 17,576.) There is probably some karmic justice in the fact that Paul Boutin subsequently became a journalist.
by rsynnott | 2025-04-14 13:12:12+00:00
> The tariffs hit other country's stock markets harder than the USA's

... Did they? Which countries? What made you think that?

S&P500 is down about 9% YTD. FTSE250 (UK) down about 8% (but that's in pounds, and the pound is up 5% on the dollar). Shanghai Composite Index(China) is down 2.5%. Stoxx 600 (Eurozone, broadly) is down 1.5% YTD. The only big one where what you say _appears_ to be the case is the Nikkei 225 (Japan), which is down 15%... but remember that it's denominated in yen, and the dollar's down over 8% vs yen in the same time.

As far as I can see, the only way you could even pretend this was the case would be by ignoring the decline of the dollar, and even _if_ you ignore the decline of the dollar that only really works for Japan, not Europe or China.
by solardev | 2025-04-14 13:12:43+00:00
> WebSockets are superior to all revisions of HTTP except that HTTP is sessionless. Typically when developers argue against WebSockets it’s because they cannot program.

What did you mean by this? Were you suggesting that interactive web apps should maintain a persistent and stateful connection to the server and use that to send interaction events and receive the outputs back, like a video game would, rather than using stateless HTTP calls and cookies and such? Why is that superior?

And sorry if I misunderstood!
by superfreek | 2025-04-14 13:13:27+00:00
Great point in the article about tools lacking output schemas. Makes reliable multi-step planning tough.

We based Xops (https://xops.net) on OpenRPC for this exact reason (disclosure: we are the OpenRPC founders). It requires defining the result schema, not just params, which helps plan how outputs connect to the any step's inputs. Feels necessary for building complex workflows and agents reliably.
by johnecheck | 2025-04-14 13:13:33+00:00
I'm not saying you'd be wrong to blame the bad leader - just that blaming them doesn't achieve much.

The CEO takes the blame, the board picks a new one (Unless the CEO has special shares that make them impossible to dismiss), and we go on hoping that the king isn't an idiot this time.

My reading of history is that some people are fools - we can blame them for their incompetence or we can set out to build foolproof systems. (Obviously, nothing will be truly foolproof. But we can build systems that are robust against a minority of the population being fools/defectors.)