t8sr

I guess I'm officially listed as a "staff engineer". I have been at this for 20 years, and I work with multiple teams in pretty different areas, like the kernel, some media/audio logic, security, database stuff... I end up alternating a lot between using Rust, Java, C++, C, Python and Go.

Coding assistant LLMs have changed how I work in a couple of ways:

1) They make it a lot easier to context switch between e.g. writing kernel code one day and a Pandas notebook the next, because you're no longer handicapped by slightly forgetting the idiosyncrasies of every single language. It's like having smart code search and documentation search built into the autocomplete.

2) They can do simple transformations of existing code really well, like generating a match expression from an enum. They can extrapolate the rest from 2-3 examples of something repetitive, like converting from Rust types into corresponding Arrow types.

I don't find the other use cases the author brings up realistic. The AI is terrible at code review and I have never seen it spot a logic error I missed. Asking the AI to explain how e.g. Unity works might feel nice, but the answers are at least 40% total bullshit and I think it's easier to just read the documentation.

I still get a lot of use out of Copilot. The speed boost and removal of friction lets me work on more stacks and, consequently, lead a much bigger span of related projects. Instead of explaining how to do something to a junior engineer, I can often just do it myself.

I don't understand how fresh grads can get use out of these things, though. Tools like Copilot need a lot of hand-holding. You can get them to follow simple instructions over a moderate amount of existing code, which works most of the time, or ask them to do something you don't exactly know how to do without looking it up, and then it's a crapshoot.

The main reason I get a lot of mileage out of Copilot is exactly because I have been doing this job for two decades and understand what's happening. People who are starting in the industry today, IMO, should be very judicious with how they use these tools, lest they end up with only a superficial knowledge of computing. Every project is a chance to learn, and by going all trial-and-error with a chatbot you're robbing yourself of that. (Not to mention the resulting code is almost certainly half-broken.)

I mean this in the nicest way possible: this paragraph, with all the repetition and constant use of the word "expert", is completely unhinged. I really recommend re-reading what you write.

What you're describing is not how it works. Chiefly, the hiring pipelines are not set up for a single role, but a whole family of them. They are filled ahead of need. (Or were, at a time when this would've been taking place.)

There are other inaccuracies, but suffice it to say, this comment section is full of comments by people who have never been hiring managers talking about how hiring works.

Started 15-20 years ago, whereas Uber and Tesla hopped on the bandwagon late and tried to play catchup. I remember talking about the self-driving project at Google in 2008 or something like that. (IIRC they were trying to use Haskell for something.)

And this is why I now have to read 30 page design docs that could have been 3 pages and said the same thing.

Please try to understand why people have such strong dislike of floral writing, especially in technical texts. If you read a lot of papers or designs, it makes your life miserable.

This is amazing, but crashes with a 500 every 30 seconds.

It's definitely harder, as you say. Not only do you have to think about technical aspects of security and privacy, but also the legal requirements for those things, and how they differ across countries.

But the complexity is not so much worse than it was in 2016, and yet in 2016 we could manage it.

The type of things I see in the FAANG world lately would not be happening 10 years ago: CI that randomly fails 5% of the time because everybody knows React, but nobody knows how to set up a Linux machine. The fact that USB drivers on M1 macs are still broken and nobody at Apple knows how to fix them, or that Apple seems to have no one on staff who knows what EDID is.

We're not failing because of new complexity, it's the stuff we put up to manage the old complexity that we can no longer service. And that won't get better until we accept that the answer is not "rebuild it from scratch, but this time let's have new grads do it with no training."

> I doubt very many of us are working on pure intranet apps.

I think this is part of the problem. The reason why your Mac will kernel panic if you plug in two external screens from the same production run is because nobody is working on "purely intranet apps" like the display driver.

I don't want to sound like I believe we were somehow smarter 10 years ago. But you had relatively solid foundations to build on and people were incentivized and given mentorship to attain mastery. We need to bring that back.

This is nihilistic nonsense. The author's problem is that he's only ever seemingly worked on web stuff. People stay in their domain far too often and then come up with big statements like "I have 20 years of experience and don't know what I'm doing." Is that maybe because you stick around a domain and layer defined by people with an average 2 years of experience, many of whom learned their job from a Youtube tutorial?

It's possible for organizations to get better, even good at building software. The foundations of the field haven't changed much, people just don't learn about them and go on to build towers of overwrought abstraction, which is the thing that keeps constantly changing.

If you think of React and Redux as foundational, then everything you say has water under it. Go open a TCP socket.

The culture around Rust is perfectly calibrated to set off middle-aged C/C++ developers.

1) It's very assertive without having a lot of experience or a track record.

2) It's extremely online, filled with anime references and Twitter jokes, obsessed with cuteness, etc...

3) It's full of whipper-snappers with 6 months of experience who think they can explain your job to you, who have been doing it for 30 years.

IME many arguments around Rust aren't focused on its technical properties, but boil down to "I just plain don't like you people."

If Rust can successfully become "boring", a lot of the opposition will go away.

You hire juniors on potential, seniors to fix a gap. Right now, 90% of hiring is focused on plugging gaps in the next 6 months - that's just where we are in the cycle.

As to why we're here, I think it's obvious at this point that tech massively overhired between 2016 and 2022.

Finally, the growth areas haven't completely disappeared, they've just shifted. If you're a junior right now, you should be getting into ML or something, not webdev. Plenty of entry level roles in ML.

You wrote a pretentious post to say the movie was pretentious.

Maybe Coppola made an obvious movie to say a thing is obvious?

Or maybe not, and neither one of you was being clever.

As a physics student, I feel compelled to point out, to any readers who might now go read Hossenfelders other articles, that many of her views are generally not shared by a majority of physicists today.

She is a real physicist and not a kook, but she has been criticized for presenting her views (e.g. superdeterminism) as having much more acceptance than they actually do. She ignores and misrepresents counter-arguments regularly. Her ideas about, e.g. the explanatory power of entanglement wrt processions of moons around (IIRC) Jupiter are certainly well outside what I’d describe as regular astrophysics.

The golden standard of science communication was set by Sagan, and he always carefully pointed out when he was expressing a personal opinion, as opposed to one shared by the majority. Sabine Hossenfelder is no Sagan.

So proceed with caution. :)

What are you talking about, my marginal tax rate in Switzerland is 50%. When I last went to Prague, I changed trains at a station that prominently said it was financed by “friendship funds” from Switzerland. My taxes already are paying for Germany’s transport infrastructure.

Meanwhile, Swiss students couldn’t go on Erasmus for a year, because someone in Brussels threw a hissy fit.

I’m a fan of the EU, but let’s not pretend it’s not throwing its weight around, just like any other huge federal government.

I don’t buy the idea that it’s mainly because of network complexity and line length. Local lines, even ones that don’t share tracks with any other trains, are routinely cancelled or delayed, as well. Other large countries manage to run trains on time (Japan, Spain…).

DB is uniquely bad and I don’t think we should be making excuses for them.

There is an outward force from the neutrons, called neutron degeneracy pressure. It's not really a case of the Pauli Exclusion Principle, as much as they are both different descriptions of what's going on with the wave function.

It’s watching the system for events like “file was opened” and “process started”, and looking for patterns resembling hackers/malware.

It’s different from AV in that it mostly looks at runtime behavior and not signatures.

The author is unhappy with how signals work, and proposes some really wonky ways to get the behavior he thinks is correct. But for a programmer, it's a lot easier to just do things the way designers of signals intended.

For example, multiple SIGCHLD coalesce, so you are supposed to call waitpid in a loop:

  int status;
  while((pid_t child = waitpid(-1, &status, WHOHANG)) > 0) { // handle zombie

This API is mature and obvious problems like the author points out have already been solved before. The author seems to reject the established practice on purely aesthetic grounds, which is a... choice. But not one you should make, if you want your life to be easy.

How well does this work in practice? I am skeptical about the power of static analysis with a language like Python. Many times, the hidden state in Jupyter lives in another module, or somewhere deep in an object hierarchy.

If you’re going to reinvent the Python notebook for reproducibility, I wonder why not go further, and fully snapshot the program state?

I really want this to work, because hidden state in Jupyter notebooks bites me frequently, but the post and website haven’t convinced me this is a robust approach - maybe I’m missing something?

You get the behavior you incentivize. In the “early days”, design docs were a tool to agree on a direction and provide context to your coworkers about what you’re doing. Later, as new people joined at an exponential rate, they were told by well meaning managers to write the docs for perf reasons, and things kind of spiraled from there. Google’s culture became a cargo cult of itself.

Some companies I worked at after Google were reluctant to discuss their promotion process in detail, because they saw what happens when people microoptimize for it.

This is similar, but actually gives you additional tools and a statically compiled bash: https://github.com/wowsignal-io/android-tools

But you’re not talking about Tim Cook, this is a guy running a company of ~10 people. Someone on the internet, with a following and an audience, has written an essay about how Vlad is a bad person, and now is implying the latter is abusive for trying to have a conversation.

This is psychotic behavior.

There’s a huge spectrum between NY Times writing a sourced article about a powerful business magnate and someone disparaging an SMB owner on their blog. If I took the posts and emails of someone I knew in my life and posted them online, I would probably get a call from the police.

At the risk of sounding grumpy, a big difference between the tech community today and in the Usenet days is that the Usenet crowd's interpersonal skills weren't two standard deviations to the left of the mean at your local Target.

The author's response is perfectly calibrated to drive someone up the wall. Sling some mud and then hide behind "help, I'm being cornered."

Imagine doing this in the offline world. How well would this kind of behavior go over with people at the grocery store, do you think? Why is it acceptable online to behave like this?

Seriously, what audience is Apple playing this to? The insinuations made in this press release should get them sued again for libel. Not to mention how off putting this kind of tantrum is for their customers.

JFC, they really need to fix their PR team here.

This is marketing copy, I think, and not great copy at that. Even after skimming it for 3 minutes, I still have no idea what it's about, other than that they're trying to sell a container control plane of some kind.

This is cool study, and the results match my intuition. Without trying to go off-topic, it's interesting that the actual study involved no walking, or even eye tracking. The data is self-reported from showing the participants images on a computer, and then having them click at where they would look.

Years ago, when I did my driver's license, they showed us a study done in the freaking 80s, that captured with full eye-tracking what drivers were looking at while actually driving.

With that technology now available pretty cheap off the shelf, I'm surprised at how low-tech this is. Is research funding in public health really this low?

The current lack of anti-monopoly enforcement and corporate oversight in the US is a race to the bottom. Should the rest of the world compete by letting corporations run amok, acquire all competition and build monopolies? Or should they try to regulate, but risk driving away founders for whom the American legal environment is extremely lucrative?

It's similar to the debate France had about raising the progressive tax rates - some ultrarich people would rather give up their French residency, than pay higher taxes.

There's clearly stuff the EU could do to be more competitive, but I think the core issue is that American investors can expect less risk and bigger payoffs, because the environment is friendlier to them, but the environment being friendlier to them leads to regular people getting screwed by giant companies that operate with no oversight. Fast forward the 2020s and you literally have planes falling out of the sky.

I don't think there are any great options.

I'm also aware this is a fringe view on HN, kinda by definition. It's a forum for founders, mostly in the US, and the median opinion on what you should be able to do with your company on here is extreme by most peoples' standards. But the echo chamber needs some dissent on this point.

/me sips Alamo from the can

Yep.

I probably over-stated that a bit. I don't think there's a hard stance against it.

I do think it's rarely a good way to structure your program, because it makes it harder to know what's happening, and the goal should be to make it easier to see what's happening, both for the programmer and the poor devops guy who has to debug it when it goes down in production and people are yelling.

Of course the real world is complicated, and DI isn't always avoidable. You are right that Go's accept-side interfaces are neutral w.r. to DI.

There's an experimental feature in Go that lets you write python-like generators that work with range() and the callback is called `yield`. Here's some details: https://go.dev/wiki/RangefuncExperiment

That's probably what the post is talking about.

(I personally don't love this change, but now that it's clear Go 2.0 won't happen, it seems like some of the more outlandish ideas are making it into Go 1.x. Ah well.)