The Pro is because it's a colored display. Though I do agree I can't wait until we're done with the whole "Pro" branding non-sense everywhere in hardware.
Nah, that won’t gain you much (if anything?) over just doing the layer swaps on RAM. You can put the text encoder on the second card but you can also just put it in your RAM without much for negatives.
I'm in a similar situation of yours (I don't feel any kind of regret though, I just feel this is a phase and it will pass someday). Anyway, I still read (and indeed not much more than that) a lot about my passions, but taking notes and writing down ideas to maybe try in the uncertain future has helped me to feel engaged with my intellectual pursuits. Stay strong my friend.
Which is why programming, reality, and even recipes are so hard.
Ever go try to cook something new and you read "Pre-heat the pan on low-medium...", and your programmer brain just can't take it? What kind of pan, what's low-medium on this burner, how much pre-heating are you talking about? These can't be all the instructions.
And perhaps like programming, it takes a few recipes and a few burnt steaks for you "not to worry" about that, you know what's good enough eventually. These lists (and algorithms) are never completely thorough.
Good recipes do explain this though. They say heat the oil until it shimmers, or until it smokes, or until beads of water in the pan sizzle. Or they give an exact temperature, which you can read (imperfectly) with an infrared thermometer.
None of these descriptions is perfect, but each is less likely to result in a burnt steak.
The difficulty is that the more precise you make your recipe, the more you need to account for the specifics of the situation; which you cannot possibly know.
There is one time in my life that I recall legit burning a steak. I did what I had countless times before. Heated the pan until the oil started smoking, put on steak, and reduced stove temperature. Just like how I would have written the recipe before without a second thought. This time, however, the outside was thoroughly burnt before the inside even started to cook. The difference was I was using a cast iron pan for the first time, which has a lot more thermal mass than what I was used to. My old process relief on the steak cooling down the pan.
For recipes I'm reading, I've almost always found the temperature and time details to be nearly useless. If the recipe says to make at 400 F for 30 minutes, I bake on "high" (450F) until done. If I'm in someone else's kitchen, my cooking turns out a bit worse than when I'm at home.
This is a problem you always run into when writing down a process. You need to rely on the knowledge of the person following the process to apply it correctly to their specific situation. Trying to prescribe every detail does not work well.
"Pre-heat" is done until your apparatus reaches the stable cooking temperature. The recipe writer doesn't know your pan size, room temperature, stove power, or anything like that, so they can't tell you the details.
"Low-medium" is just bad instructions. The recipe should be more detailed.
Anyway, what you are complaining about on your example is just jargon ignorance. You need to learn some stuff before you understand recipes. That's not really what makes programming hard. But it does make learning new things hard.
Not everything needs to be rationalised back to programming.
It's not programming experience that makes you ask those questions but because they are basic cooking questions you would ask.
Checklists are either checklists or a set of instructions to follow.
Good instructions would specify some of those attributes, other times experience helps to understand what general pan you might use or what medium-low heat looks like. Exactly to your point, it takes a few burnt steaks to figure it out.
Checklist is for people who have a fair amount of experience doing the task. It's just a reminder to perform the steps. An experienced chef reading "pre-heat the pan on low-medium.." would know what those terms mean.
I'd go even a step further: For the big corp, having a point of failure that lives outside its structure can be a feature, and not a bug.
"Oh there goes Super Entrepise DB Partner again" turns into a product next fiscal year, that shutdowns the following year because the scope was too big, but at least they tried to make things better.
It also can be configured to use Ollama or an API key from other providers (OpenRouter included) and from what I gather the default prompt can be changed too.
When I was working at $samsung_competitor, my NDA'd next gen android phone prototypes (a huge motherboard with a screen) were sent some years earlier. Like Samsung is on S25 now, and we would get boards for S27... It takes a long time for these things to evolve.
I feel like I'm on crazy pills sometimes when talking with people who deal mostly with software. I think SW engineers sometimes think that engineering generally looks like what they do, when in reality SW is a deep outlier wrt process...
The word “engineering” in SWE is just plain wrong. Present day software development has nothing to do with engineering outside of some very niche markets (aviation, mission-critical systems, embedded controllers). The term vibe coding came up really handy because it describes how 99% of software is developed much better than “software engineering“, with or without LLMs. That’s why it’s always fun to read such discussions of hardware vs software people.
