et1337

Joined 13 years ago

Karma
2,718
Submissions
337
Member since
Sep 11
https://etodd.io
View on Hacker News

Recent submissions

Comment · 1 day ago
Ah, that makes sense. I didn’t get too much of that in my degree because for me, college was primarily a financial thing. If I was just pursuing the love of knowledge, I would have loved to take philosophy, but it didn’t count toward my electives.

I definitely would have felt differently about college if money was not a concern. I got accepted to CMU but didn’t go because I didn’t want the debt, and at the state college I attended, I didn’t major in what I wanted to do. Looking back, I do feel some regret, but also, if I had chosen differently, I would still be paying for it today. Even if you’re looking for an amazing learning experience, the unbelievable cost forces it to be a primarily financial endeavor, at which point it makes more sense to forgo niceties like philosophy and study it on your own time, or audit classes or something.

Comment · 1 day ago
Counterpoint to your blanket statement: You do get some life experience, but for me, having a job gave me more experience than doing group projects. And as far as learning things, I often feel that I would have learned more by just goofing around on the computer on my own. In fact, I did.

To be fair, I commuted for two years and didn’t really have the full social experience. But does higher education actually deserve any credit for that aspect, or would it happen naturally with any group of young people?

Comment · 3 months ago
Comment · 3 months ago
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
Comment · 4 months ago
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.
Comment · 4 months ago
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.

Comment · 4 months ago
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.

Comment · 4 months ago
Can’t wait for CGP Grey’s review of this flag
Comment · 5 months ago
> 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.

Comment · 5 months ago
Comment · 5 months ago
Asking random people to write SVG gives even worse results
Comment · 5 months ago
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.
Comment · 5 months ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton