That's hackertyper in that screenshot, god that takes me back.
896 karma · joined July 5, 2017
You did claim this.
> self identify as autistic. (...) then software employment is full of self-indulgent and highly neurotic people
This is hateful and wrong. Autistic people aren't necessarily self indulgent, and not self evidently neurotic, though it happens to be the case that autistic people have a higher incidence of neuroticism, which is partially due to people describing them, for example, as "self indulgent".
You've shifted your claims, you're not supporting your claims by either argument or reference, and you've added hateful rhetoric. This is very regrettable.
Firstly, in the Big five model, which you seem to be referencing, openness and neuroticism are separate factors- Low neuroticism isn't correlated with high openness. Yes, since neuroticism is a negative trait, one would expect people low in neuroticism to do better than people who are high in neuroticism. This does not equate to "the most creative people" though.
Secondly, I'd push back that people low in neuroticism would be "least concerned by" surveillance. While strictly technically true, that's not a helpful framing, as it seemingly implies surveillance would have a negligible negative impact for people low in neuroticism. If that's what you're implying, I'd like to see references.
I'm not able to comment at all on the conclusing about "degree of disclosure" being moderated by trust level in social environment, especially how "creative people remain equally creative but do not openly expose their creative output". If true, this implies that trust in society doesn't impact primary (unshared) creative output at all- that's a very strong claim in my opinion. I'd very much like references on this.
You're presumably joking? If not, could you elaborate?
I'd turn it around- this is the reason asking questions does work! When you don't know what you want, someone asking you for more specifics is sometimes very illuminating, whether that someone is real or not.
LLMs have played this role well for me in some situations, and atrociously in others.
Github's cli tool `gh` is great for interacting with github in the terminal, e.g. opening PRs, checking workflows, PR status, etc). I do PR reviews on the site, but you can read comments in the terminal with `gh` (it does require internet access)
My day to day requires internet regardless of github, so there's no need to go for disconnected solutions, I think that's a different situation for the author. I quite like the idea of only turning the internet faucet on at select times!
[1] https://climate.mit.edu/explainers/freight-transportation
You've chosen a strategy, broke down the solution into small easy to code parts, validated business logic, noted traps to avoid, searched for all relevant code, set up a context packing document particular to this section of the code base, experimented with multiple agents, reviewed each version of the code to see if you understand it-
That sounds like a lot of work!
And why, so the AI can do the last 10% of actually coding it up? Is there even a speedup here over doing it yourself? There's some evidence against AI speedups [1]. Of course some of these steps are themselves AI enhanced, and some of them are part of the work regardless of whether you use AI.
I still feel skeptical on this workflow and how big the gains could possibly be. I feel more for the alternate approach of writing it yourself, but using the AI for the boring parts (e.g. copy this section, but use those functions), or for sparring / research. I have however no data to show which approach takes less time.
I can however tell you from experimenting with full on vibe coding- you can do it with half the attention you'd give the task yourself. Is that what I'm gaining, that I can read a book during code generation? (https://xkcd.com/303/)
[1] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
Yes technically he did circle the squirrel from his reference point, what of it? that wasn't the point. The point was he couldn't see the squirrel, and this question is only tangentially related.
I also really liked the game designer rule;
> People are very good at noticing when things suck. Not as good at figuring out why (...) If you want to address people’s concerns rather than win an argument, then it is you who must identify and state their concerns accurately.
I'd compare this to the concept of "steelmanning"- not easily dismissing a statement based on some small detail, but trying to adress the statement fully.
Surely you meant the latter? The boring option follows previous experience. No technology has ever not reached a plateau, except for evolution itself I suppose, till we nuke the planet.
I actually can't imagine for the life of me why I'm defending OOP implementation hierarchies here- I guess I got so used to them at work, I've changed my strategy from opposing them to "it's okay as long as you use them sparingly". I have found that argument to do a lot better with my colleagues...
This is why hierarchies should have limited depth. I'd argue some amount of "co-recursion" is to be expected: after all the point of the child class is to reuse logic of the parent but to overwrite some logic.
But if the lineage goes too deep, it becomes hard to follow.
> every time you modify a class, you must review the inner implementation of all other classes in the hierarchy, and call paths to ensure your change is safe.
I'd say this is a fact of life for all pieces of code which are reused more than once. This is another reason why low coupling high cohesion is so important: if the parent method does one thing and does it well, when it needs to be changed, it probably needs to be changed for all child classes. If not, then the question arises why they're all using that same piece of code, and if this refactor shouldn't include breaking that apart into separate methods.
This problem also becomes less pressing if the test pyramid is followed properly, because that parent method should be tested in the integration tests too.
You're saying this with derision, but the ability to quickly add "incredibly specific-to-you" features is precisely what is so cool about it!
You're right of course that this was not without human guidance but to me even successfully using LLMs just for the mutation step was in and of itself surprising enough that it revised my own certainty that llms absolutely cannot think.
I see this more like a step in the direction of what you're looking for, not as a counter example.
A funny comparison to me. Actually, I have to manually disable some EU regulated features every time I get into my car. The alerts every time I go 1kmph over the speed limit aren't very relevant for me, and the lane keep alert buzzes as soon as I'm slightly over halfway to the left, but lets me drive along fine if I'm even over the line on the right.
I'd actually like to use both of these, but only if I could calibrate them to my needs.
...
Just like cookie banners.
> Next, suppose I told you that most doctors get the same wrong answer on this problem – usually, only around 15% of doctors get it right. (“Really? 15%? Is that a real number, or an urban legend based on an Internet poll?” It’s a real number. See Casscells, Schoenberger, and Grayboys 1978; Eddy 1982; Gigerenzer and Hoffrage 1995; and many other studies. It’s a surprising result which is easy to replicate, so it’s been extensively replicated.)