For example, how many things does "link" mean? "Process"? "Type"? "Local"? It makes people (e.g., non-technical people) think that they understand what I mean when I talk about these things but sometimes they do and sometimes they don't. Sometimes we use it in a colloquial sense, but sometimes we'd like to use it in a strict technical sense. Sometimes we can invent a new, precise term like "hyperlink" or "codec" but as often as not it fails to gain traction ("hyperlink" is outdated).

That's one reason we get a lot of acronyms, too. They're too unconversational but they can at least signal we're talking about something specific and rigorous rather than loose.

I feel like programming has become increasingly specialized and even before AI tool explosion, it's way more possible to be ignorant of an enormous amount of "computing" than it used to be. I feel like a lot of "full stack" developers only understand things to the margin of their frameworks but above and below it they kind of barely know how a computer works or what different wire protocols actually are or what an OS might actually do at a lower level. Let alone the context in which in application sits beyond let's say, a level above a kubernetes pod and a kind of trial-end-error approach to poking at some YAML templates.

Do we all need to know about processor architectures and microcode and L2 caches and paging and OS distributions and system software and installers and openssl engines and how to make sure you have the one that uses native instructions and TCP packets and envoy and controllers and raft systems and topic partitions and cloud IAM and CDN and DNS? Since that's not the case--nearly everyone has vast areas of ignorance yet still does a bunch of stuff--it's harder to sell the idea that whatever AI tools are doing that we lose skills in will somehow vaguely matter in the future.

I kind of miss when you had to know a little of everything and it also seemed like "a little bit" was a bigger slice of what there was to know. Now you talk to people who use a different framework in your own language and you feel like you're talking to deep specialists whose concerns you can barely understand the existence of, let alone have an opinion on.

For everything else, I think you're right, and actually the dialog-oriented method is way better. If I learn an approach and apply some general example from ChatGPT, but I do the typing and implementation myself so I need to understand what I'm doing, I'm actually leveling up and I know what I'm finished with. If I weren't "experienced", I'd worry about what it was doing to my critical thinking skills, but I know enough about learning on my own at this point to know I'm doing something.

I'm not interested in vibe coding at all--it seems like a one-way process to automate what was already not the hard part of software engineering; generating tutorial-level initial implementations. Just more scaffolding that eventually needs to be cleared away.

If I still used bash, starship would be a non-starter for me, in part, since it's fork/execed in the prompt command. Further up this thread someone says that the zsh installation is different and it's a native shared library that gets loaded into zsh. That seems neat.

(The other reason it's a non-starter is that maybe I can stomach sending over a dotfile to various systems, but selecting a platform-specific native binary is too much configuration management to be done to prepare for an SSH session/kubectl exec. Eventually I made my peace with doing this for emacsclient so I could have local editing of remote files, but that's a lot less critical of a piece to miss than something that appears in your prompt. Conceptually, if you want to ship over/config-manage a native binary, you might as well install a better shell, which became a compelling argument to me when I switched to Powershell).

On the occasion where I'm even tempted to interact with a list of files, it seems easier to do

  git diff development --name-only | gci | ocgv | sco -exp fullname | xargs e

If there's one thing I've observed about developers in general, it's that they'd rather build than learn.

But even when the overall goal is either obvious or explicitly stated, it's very common for none of the described options or actions to provide a motivation for the action or option that connects to the goal.

In other words--yes, I can read some rules that say "on your turn, you can draw a BLANKLY card, play a FARB token, or advance one of your MORTGAGED BULLETS on the community barrel."

But why would I do those things? So many rulesets could improved by adding motivation, like "If you think an opponent that owns your MORTGAGE is getting to close to the BULLETPROOF PIT, then you can beat them to the pit by advanced a MORTGAGED BULLET toward the target." Ah! Okay, those are the circumstances under which I might want to do that.

Or, "If you aren't getting enough FARB tokens to block opponents, you might need more of the FARB-earning resources you can get by drawing BLANKLY cards. Remember that you're trying to either build a ROBOT--using parts on some of the FARB tokens--or destroy others' ability to build ROBOTs by shooting them."

The rules of the game aren't really "how you play"; and a newcomer doesn't have a playstyle. You need to mix the basic strategy with the rules instead of just giving a bunch of options and no pointers as to why you might want to do one thing over another.