RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
59% Positive
Analyzed from 1293 words in the discussion.
Trending Topics
#code#need#fred#thinking#writing#more#system#same#things#write
Discussion (25 Comments)Read Original on HackerNews
The rest of them seem to avoid thinking outside a small info bubble/closed system, not sure why, but it looks like it creates anxiety when they start feeding too much info. Instead of trying to extract abstractions that make it possible to model the complexity and fuzz the non-important parts.
The same people, when they come up with a product implementation idea, avoid thinking about all the things required to be in place for the product to actually satisfy some real need/want. The product ends up detached from user need. The tech doesn't work.
And it doesn't matter if they can code or if Claude can work, because the directions required to define what needs to be there are not present.
I realized I need to take the thinking of these people as their ideas and advice — as inputs that need to be sanitized. The easy way I found is to remodel why they think the way they think — it's like having a safe VM running their code (thinking) through my computer (my brain).
These same people, usually years later, realize you were telling them things they were not able to comprehend at the time, but they realized those things were so important and would have saved them from suffering so much. They start to treat your voice with reverence instead of thinking through with their own minds and stress-testing against reality.
I would love to read some research about this and how to take advantage of it, or at least avoid the toxic influence such minds can have against one's own well-being and success.
Fred was very knowledgeable, and Fred could think. But Fred had deeply held preconceived notions that interfered with the utility of his thoughts.
Fred also had something else, though -- he could set aside those deeply preconceived notions. Not for himself, mind you, but for someone else.
I could, and did on a very regular basis, go to Fred and say "Fred! Assume X, Y, and Z. What happens if A and B?" Now even though Fred was completely sure that I was wrong about at least Y and Z, he could set aside those prejudices, and (correctly!) reason through what would happen.
Fred reminds me of the people you describe, except that instead of having Fred's code running through my brain, I was able to insert my code into Fred's brain.
The person who takes a business problem and proposes an expansive solution that requires a big team that they lead to victory, that person climbs the ranks.
The person that takes the same business problem and carefully simplifies both the problem and the solution, and delivers it themselves, is rewarded but not at all like the team leader.
If I can close 100 tickets with less code than someone else, I've still closed 100 tickets.
I've seen a host of other imperfect measuring sticks, including the "tickets" metric I cited. But the post to which I was replying said that people are judged on how much code they write.
But as new requirements appear, the clean design slowly turns into layers of patches and exceptions.
you discover a deeper pattern that absorbs the complexity back into the core, and you do a rewrite.
Then the cycle repeats.
I don't worry about writing a perfect system anymore, i realize there is more to a system i do not currently know about, many things will surface once the foundation is laid.
wonder if it was on purpose...
[0] https://shvetsm.github.io/posts/who-looks-at-the-code/
[1] https://shvetsm.github.io/posts/keep-the-kitchen-clean/
It makes no sense for me to use the limited UIs that companies present anymore. Let alone signup processes - it should all be LLM friendly. Simple APIs that are called by your agent.
My company uses Teams and it's ecosystem. And for email I get a lot of crappy system updates, etc.... And around the UI there are little "AI" buttons or "Ask a question" boxes. No. This. Is. Wrong. Instead I need to be able to ask my OWN agent to check my email and archive anything dumb and inform me of anything important. In fact, don't even make it a one-off prompt- make it a permanently running long-haul agent that interacts with my "personal assistant" agent that is in charge of getting my attention if it's absolutely necessary, which knows if I'm watching a movie.
In fact, writing a video game engine is probably the most common project on the planet to the point there is hardly anything novel about it. That's how engine writing nerd snipes people. They get to feel secure due to the guaranteed possibility of success. Making and designing an actual game that people want to play is much more risky and it is much less dependent on programming skill.
With Vulkan the hard part isn't the typing, it's the understanding and figuring out an abstraction that suits you/your project that is the hard part. And kinda the same with writing a game engine. There is basically infinite resources and libraries to make it easier, but what you actually are spending your time on is figuring out an abstraction that makes sense for the user of the engine. There is a reason why almost no 2 engines end up with even close APIs.
Thinking hard (and discussing with experienced colleagues) before writing any code can dramatically speed up your overall delivery time and completely remove whole classes of potential errors.
If you skip the "thinking hard" bit to "go fast" you will probably end up being 10x slower overall.