Phlebsy

Right? Lawyers can get into deep shit if they misrepresent their ability to well, represent a client on a case outside of their area of competence. How are medical professionals that often won't even tell you what they think about a test result and refer you to a specialist to actually get a diagnosis able to ethically represent what a patient actually needs?

The problem that exists is that you cannot just willy nilly try out entirely different desktop envs/window managers/audio frameworks on an existing install of any other distro and be certain everything will work exactly as it was when you remove it. Especially as an only moderately knowledgeable user that won't know every single piece of config that needs to be changed back. Unless you're trying everything new out on a fresh install then there's a big risk.

NixOS gives you that just by opting in to using it, and while AI also speeds up config changes and translating your existing knowledge to a new tool you're trialing in other distros as well it really shines with NixOS where you don't even have to care what it messes up while you're trying something new. You just revert and you know that nothing that was done to configure that new thing - which likely would have broken your existing configuration on other distros - has persisted.

> What this meant was that instead of leaving nitpicky comments, people would just change things that were nitpicky but clear improvements. They'd only leave comments (which blocked release) for stuff that was interesting enough to discuss.

This is my dream; have only had a team with little enough ego to actually achieve it once for an unfortunately short period of time. If it's something that there's a 99% chance the other person is going to say 'oh yeah, duh' or 'sure, whatever' then it's just wasting both of your time to not just do it.

That said, I've had people get upset over merging their changes for them after a LGTM approval when I also find letting it sit to be a meaningless waste of time.

I would settle for accurate estimates being a requirement if sticking to the estimate and allocations is as well. Every project I've been a part of that has run over on timeline or budget had somebody needling away at resources or scope in some way. If you need accuracy to be viable, then the organization cannot undermine the things that make it possible to stay on track.

Only have issues with it on my machine with an Nvidia card. Understand that it can be unstable and accept that when it happens - but with AMD/integrated graphics I don't have the same problem.

Either way, only serves to further the point that Linux is in a pretty good place and the experience should only be better on more stable options.

I get ~weekly crashes using an Nvidia card with arch/hyprland, but honestly it's less problematic for me to deal with than windows updates. I can format and rebuild my machine from scratch in less time than windows takes to download and perform an update.

Flawless experience on non-nvidia hardware though.

Sure, if the warning levels are poorly tuned I might configure my LSP to ignore everything and loosen the enforcement in the build steps until I'm ready to self review. Something I can't stand with Typescript for example is when the local development server has as strict rules as the production builds. There's no good reason to completely block doing anything useful whatsoever just because of an unused variable, unreachable code, or because a test that is never going to get committed dared to have an 'any' type.

It just feels obstinate to me. Most people will jump through all sort of bureaucratic/performative hoops when they're in a job to keep it or angle for promotions/minor raises, but this one that has a much higher average RoI turns them off. If you put your foot down on that sort of thing too then fair enough I suppose.

> just

Or you can just learn a handful of puzzle patterns in exchange for more job opportunities that would have the potential for higher overall pay. Seems like a fair trade to me.

I'm a fan of writing tests that can be either. Write your tests first such that the real dependencies can be run against. Snapshot the results to feed into integration test mocks for those dependencies so that you can maintain the speed benefit of limited test scope. Re-run against the real dependencies at intervals you feel is right to ensure that your contracts remain satisfied, or just dedicate a test per external endpoint on top of this to validate the response shape hasn't changed.

The fundamental point of tests should be to check that your assumptions about a system's behavior hold true over time. If your tests break that is a good thing. Your tests breaking should mean that your users will have a degraded experience at best if you try to deploy your changes. If your tests break for any other reason then what the hell are they even doing?

Why do users insist on using tools that can get them fired? This is either a policy or culture problem, not an AI problem.

Hell, just make a macro to replace all the funny anachronisms and a prompt that can reference your own writing style to massage the output.

Coupled with weeks if not more of regularly scheduled sleep deprivation so you never actually recover from any of those hard days.

Same. I have a tmux-sessionizer like script that when I open a new tmux session for a project will automatically build out all the standard windows and pane setup for the type of project it is. Start neovim or rider, the dev server/browser if it's hot reloadable, start a test daemon to rerun tests on uncommitted file changes, etc.

If it's something I'm going to need most of the time when I open that project type then I automate it from bash scripts using simple identifiers like whether a go.mod, package.json, *.sln, etc exist. If you want to get even fancier then you could make scripts specific to each repo with a fallback, or make it search the existing sessions and close out any competing ones that would use the same ports or images. It's one of those things that does truly save 30 seconds multiple times a day, with minimal setup time for new projects once you know how you always structure your dev environment.

Something missing is the confidence that comes from being perceived that way as well. You're a high performer at a high prestige/competitive school - you're going to feel more like you can do everything the other successful people from that school can do compared to someone from a no-pedigree state school who wouldn't have access to those role models or tracks to see what's possible and be more likely to just go with the flow and accept a safe job offer.

Even if we assumed that there was nothing special about the capabilities of people who finish Ivy League educations, that's still a powerful effect. Add in that they are either competitive enough or have well connected enough families to get into said school, and it's a multiplying effect on top.

The ones that get me are the billboard barges on Miami Beach. Like at least biplane banners have some charm.