101–110 of 221 posts
Reminds me of "The Animal is Tired" (2021) ( https://www.robinhobb.com/blog/archives/2021-05 )
> The animal is aging. Not surprising; I knew it would happen eventually, but I didn't make any provisions to deal with that eventuality. Somehow the reality crept up on me. And now it must be dealt with, day after day. (only ~5 paragraphs left now so y’all might as well finish it :) ) Thanks, lots of hackers can use the reminder.
Not related to the article, but I've seen this thought before and I think its wrong.
This isn't what good academic instructions gets you. Instead, they provide a systematic approach to learning foundational/core formalisms which let you recognize other problems as being of the same kind.
An academic background should let the person reason from a place of pre-explored essential complexity, instead of first having to rediscover & deconstruct the accidental complexity.
Building scar tissue about why things are a certain way is practical experience for (non)academics alike.
Earlier quoted context omitted.
The writing style, if not AI, is at least a bit tryhard. Turning to the substance of the article: why do people feel the need to run this fast? I have certainly experimented with letting coding agents run amok. The first few times you try it, it feels like a superpower. Then you start examining the icky choices they made in a codebase that is now a dense forest. Then you have to expend a bunch of effort beating it ba…
> why do people feel the need to run this fast Because if they don't they feel like they will be replaced by someone who will
But of course the AI guys are preying on this anxiety in order to dominate. They are all over HN, either personally or with their bots. Which is why HN is no longer a place that you could go to get mainly unbiased anecdotes and experience. That is still available but it is being drowned out by FUD because the average HN user is now the mark.
Sadly, this is a question for his boss, not him. It’s not existential. It’s economical.
Earlier quoted context omitted.
I think it all depends on your personal driver: personally I rather see a product I built in whatever way used by ever growing number of people because they find it useful. It means that the time I spent working on that helped other people solving a problem (hopefully). That’s why a was always keen on cutting some corners when and where necessary in order to think about the user first and the code beauty second. Of c…
I don't even want to put 'my' code or apps out into the wild anymore. I've built a a few things I think are useful and I'm using myself but I'm afraid it'll just get called slop or my only users will be bots. What's the point. So I don't get the joy out of sharing it nor the joy of the achievement. But I've widdled down what I thought was an endless backlog of features to nearly zero, I guess that's something.
It is more accurate, in terms of, it only matters when something goes wrong.
Edit:"On the hook" is a general expression that means if something goes wrong it lands on you as the responsibile party, generally in a negative way. As in, if it goes right, you don't get kudos, if it goes wrong, you're on the hook for it
> I came to the formalisms of software engineering through painful experience rather than academic instruction. If anything, that made me take those principles more seriously once I understood them. Not related to the article, but I've seen this thought before and I think its wrong. This isn't what good academic instructions gets you. Instead, they provide a systematic approach to learning foundational/core formalism…
It was a massive disadvantage for them. They could carefully recreate the exact same thing over and over for new products that were similar to the previous version, but it was ALL cargo culted so they were terrified of any change, because they had no idea why a PCB was built in a certain way or what it meant to alter some aspect of a circuit board. So they were extremely, extremely resistant to any sort of change whatsoever.
And I as a young hardware engineer would get laughed at for saying things like "Do we have any fine copper wire? I need to make my own inductor for this test" because they didn't understand that an inductor is just coiled wire. Our board designer didn't understand why vias would be placed in a ground pad to link it thermally with the ground plane on a different layer, and laughed at me when I said we needed to "move heat around". He put a single via in the center of a huge ground pad. I asked him to put a grid of vias, so he humored me while having zero idea what the vias were for, or that having many vias linking two thermal planes would transfer more heat than just a single lonely via in a big pad.
Shit like that.
So I agree with you, the theory learned in academia plus the pedagogy is hugely useful and lets someone skip over decades of blind struggle.
While I appreciate and agree with the key points of the post, Claude's writing style fingerprints are all over it and I guess it's even more exhausting to read someone's AI written article.
I don't think it is AI, but I bet it has been through editing/review to match a corporate style. LLMs were trained on this.
Earlier quoted context omitted.
The writing style, if not AI, is at least a bit tryhard. Turning to the substance of the article: why do people feel the need to run this fast? I have certainly experimented with letting coding agents run amok. The first few times you try it, it feels like a superpower. Then you start examining the icky choices they made in a codebase that is now a dense forest. Then you have to expend a bunch of effort beating it ba…
> why do people feel the need to run this fast Because if they don't they feel like they will be replaced by someone who will
Basically a bad relation to labor and sustainable lifelong work.