Hacker News: et1337

New comment by et1337 in "Passkeys were invented by engineers with zero understanding of consumer brain"

et1337 — Wed, 22 Jul 2026 17:39:55 +0000

Throwing my hat in the ring, I think passkeys were also invented by engineers with zero understanding of the average developer: https://etodd.io/2026/04/06/passkeys-are-too-hard/

New comment by et1337 in "AI boosts research careers but narrow the span of ideas explored: study"

et1337 — Sun, 12 Jul 2026 21:52:41 +0000

This is the most interesting study I’ve seen: https://unessays.substack.com/p/talk-is-cheap

Funny enough, it basically says the exact same thing about software engineering that TFA says about science:

  First - developer level productivity has improved
  …
  Second - overall system flow has slowed down at every step

Slow Tuesday Night (1965)

et1337 — Sun, 05 Jul 2026 19:49:34 +0000

Article URL: https://www.baen.com/Chapters/9781618249203/9781618249203___2.htm

Comments URL: https://news.ycombinator.com/item?id=48797382

Points: 5

# Comments: 2

New comment by et1337 in "The short leash AI coding method for beating Fable"

et1337 — Fri, 03 Jul 2026 16:25:29 +0000

Perhaps my "reject the premise" comment was a bit too provocative. I didn't intend to start an argument. I wanted to share a story of a person who was put in the position you described (working as a manager on a large project, required to have an overview of the project but not necessarily to actually write or review much code), failed miserably, changed the rules of engagement (partly by reviewing code), and subsequently succeeded. So my _personal_ answer to your question of how to build a mental model in that scenario would be to do something in the same vein as that story. Not necessarily _exactly_ what that guy did, but I think the principles still apply today. Nothing really changes.

New comment by et1337 in "The short leash AI coding method for beating Fable"

et1337 — Fri, 03 Jul 2026 12:39:11 +0000

I am not able to find it now, but there was an amazing story recently from the 60s or 70s where an engineer was in exactly this position. His team was building a new, complex, ambitious operating system, but it was late and over budget and didn’t work. It nearly wrecked the company. He talks about hitting rock bottom and asking himself what went wrong, and one of the fathers of computing (can’t remember which) shouts from the hallway in passing, “that’s easy, you didn’t understand what your people were doing.” So the guy turned it around by implementing a new rule: he had to understand every line of code his team wrote. They started over with the company’s existing OS in use by customers and implementing a few of the most requested features. Much less ambitious, but it actually shipped. Gradually they achieved all their goals by upgrading the existing system.

The “I must understand every line” constraint didn’t sound like a power trip that succeeded because the guy was such a brilliant code reviewer. I think it was a blunt instrument that enforced simplicity.

I guess what I’m saying is, I reject the premise of having technical oversight without writing or reading much code.

New comment by et1337 in "Tokenmaxxing is dead, long live tokenmaxxing"

et1337 — Sun, 28 Jun 2026 20:03:24 +0000

Folks have been saying “things are different now, the agents are now compounding success instead of error” for at least a year now, but I just don’t see it. I was lucky enough to receive a weeklong $50k per head AI training from the people saying these things, and one of their few helpful concrete recommendations was to constantly clear context all the time, to avoid things going off the rails.

However, I think finding security vulnerabilities is one use case where it doesn’t matter. Tokenmaxxing is absolutely effective for that. We as an industry are in the middle of adopting very expensive, complex continuous fuzzers.

New comment by et1337 in "1worldflag: A blue dot on a transparent background"

et1337 — Mon, 08 Jun 2026 04:17:12 +0000

Can’t wait for CGP Grey’s review of this flag

New comment by et1337 in "The VibeSec Reckoning"

et1337 — Wed, 27 May 2026 15:08:37 +0000

> prompting for test-driven development is not the same as enforcing code coverage thresholds in your build tool

Are they actually different? I would guess they have roughly the same efficacy. 100% code coverage means nothing, and this is especially true with LLMs.

New comment by et1337 in "Designing for and against the manufactured normalcy field (2012)"

et1337 — Tue, 26 May 2026 03:40:08 +0000

Making normal things feel weird is basically the whole premise of the delightful webcomic Strange Planet: https://www.instagram.com/nathanwpylestrangeplanet

New comment by et1337 in "Gemini 3.5 Flash"

et1337 — Tue, 19 May 2026 20:46:59 +0000

Asking random people to write SVG gives even worse results

New comment by et1337 in "I don't think AI will make your processes go faster"

et1337 — Sun, 17 May 2026 14:46:39 +0000

Oh no, I’ve definitely experienced that, it’s terrible. But that situation makes me wish for more agency (for example, talking to customers directly), whereas it seems to make other engineers wish for less agency (please hand me a complete spec and I will mindlessly translate it to code). That’s what I don’t understand.

New comment by et1337 in "I don't think AI will make your processes go faster"

et1337 — Sun, 17 May 2026 13:40:03 +0000

I’ve never understood engineers who complain about vague specs… if the spec was complete, it would be code and the job would be done already! Getting a 20 page spec delivered from upon high and mechanically translating it to code without any chance to send feedback up the chain sounds like… a compiler.

New comment by et1337 in "The Third Hard Problem"

et1337 — Sun, 17 May 2026 02:43:06 +0000

Wow, thanks for that, TIL! I’m definitely a code lumper.

New comment by et1337 in "The Third Hard Problem"

et1337 — Sun, 17 May 2026 00:03:16 +0000

I think all three problems are really one problem under the hood:

Are these two things actually the same thing, or they separate?

New comment by et1337 in "Dear friend, you have built a Kubernetes (2024)"

et1337 — Sun, 26 Apr 2026 17:40:37 +0000

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

New comment by et1337 in "What is jj and why should I care?"

et1337 — Tue, 14 Apr 2026 14:43:13 +0000

Jujutsu has a concept of mutable vs immutable commits to solve this. Usually everything in a remote branch is immutable. To work on a branch, I track it and that makes it mutable.

New comment by et1337 in "Number in man page titles e.g. sleep(3)"

et1337 — Mon, 06 Apr 2026 15:52:51 +0000

Thousands of keystrokes saved by not having to type “man syscall”… and millions of hours lost by confused folks like OP (and myself)

New comment by et1337 in "Why I love NixOS"

et1337 — Mon, 23 Mar 2026 04:46:05 +0000

I’ve been driving Bluefin DX for a year or two. On the plus side, it works absolutely flawlessly. This is the longest I’ve ever run a Linux distro without a Nvidia driver update causing the whole thing to explode. It truly is the year of Linux on the desktop.

But I can’t say I recommend it for dev work. It wants you to do everything inside devcontainers, which I like in theory but in practice come with so many annoyances. It wants you to install Flatpaks but Flathub is pretty sparse. I ended up downloading raw Linux binaries into my home directory (which actually works surprisingly well. Maybe this is the future, hah)

I think next time I’ll just go with vanilla Fedora.

New comment by et1337 in "A case against currying"

et1337 — Sun, 22 Mar 2026 22:24:15 +0000

No encapsulation… huge functions with tons of local variables shared between closures… essentially global state in practice. I think ant the time, objects with member variables felt “heavy” and local variables felt “light”. But the fact that they were so lightweight just gave me more opportunities to squirrel away state into random places with no structure around it. It really wasn’t all that horrific, and it helped me ship something quickly, but it wasn’t maintainable. These days I think the “heavy boilerplate” of grouping stuff into structs and objects forces me to slow down and think a bit harder about whether I really want to enshrine a new piece of state into the app’s data model. Most of the time I don’t.

New comment by et1337 in "A case against currying"

et1337 — Sun, 22 Mar 2026 21:46:00 +0000

I also think there’s an interesting effect when cool functional language features like currying and closures are adopted by imperative languages. They make it way too easy to create state in a way that makes you FEEL like you’re writing beautiful pure functions. Of course, in a functional language everything IS pure and this is just how things work. But in an imperative language you can trick yourself into thinking you’ve gotten away with something. At one point I stored practically all state in local variables captured by closures. It was a dark time.