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.

> If I can't Google it (at least in a reasonable amount of time) and I suspect it may come up again, I'll jot it down.

With how much google at least has become incentivized to push results further down for their other features I've been glad that I've had a habit of storing the links for useful/non trivially found results with the queries originally used for a while now.

That said, maybe having AI summarize the curated results to store along with them wouldn't be a bad idea as well with things seeming to fall off the internet with dead links or migrated URLs more and more.

To me the point of the saying is more that the assumptions and environment that the software was written with are almost always going to change. Meaning the business and requirements rather than the technical implementation choices. Software doesn't exist in a vacuum, but rather to solve a certain set of business requirements that have the potential to shift out from under you depending on the industry, legislation, and your leadership. The things that you have negligible control or foresight over, rather than knowing that there's going to be another major framework update next quarter.

There are certainly horizontal slices of every stack that can be written to remain stable regardless of the direction the business takes, but those are rarely the revenue drivers that the business cares about beyond how much they have the potential to cause instability.

> As this relates to software, I think it goes something like: you learn the magic incantation to make the computer do what you want (solving a hard task becomes habit), then you learn why that incantation works (solving it becomes easy), then you figure out better ways to solve the problem, such that the original friction can be removed completely (you find a more beautiful way to solve it).

I've come to a less pleasant way of putting a similar workflow. If something hurts(in the sense that you dread doing it, even though it needs to be done), make it hurt as much as possible and keep doing it until it doesn't. Along the way you'll find the ways to make it easier, faster, more efficient, etc but if you put it off every time until you can find the fortitude to embrace the suck then it's never going to get noticeably better.

Most of the time this is business process related, especially when inheriting legacy systems. Ideal outcome is that you understand it enough after really digging into it to cut out or replace entire swathes of the processes without losing confidence that it will continue to operate smoothly.

The number of replies I cut & paste to my notes archive far exceeds the amount of posts I actually make. I still find it valuable to work through my own thoughts to better prepare myself to have the same conversations in more impactful circumstances, but there are some things I just don't care enough about persuading the other person - or believe the other person is actually going to consider the words as carefully as I put them together.

This was very much taught in some of the business school electives I took. Some of the projects are quite literally to give a realistic pitch for products or businesses that you never intend to actually build. It might be only be taken as subtextual in the most charitable view, but being able to bullshit like that is definitely taught.

> This seems political.

Say it ain't so - tariffs are now being used for political reasons instead of economic? I hope the administration gets word of this.

With how unstable the situation is and Framework being a small outfit shipping out of their processing & QA center(every unit is hand assembled and tested before shipping), it makes far more sense to just pause it all than risk tariffs being raised to 104% arbitrarily before they can process an order.

My hot take is that I personally feel 'flow' is already dangerously close to vibe coding, so I'm not surprised that vibe coding is seemingly taking off like it is. If you need to be buried in your subconscious to achieve any meaningful work then it's likely you've failed somewhere in your design or your baseline productivity/discipline.

Not to say that it has as many negative side effects as vibe coding or that context switching is 0 cost, but it's interesting how similar they feel in my mind even discarding the 'embrace the exponentials' rhetoric.

There's another more thorough version from the same author, for what it's worth. Just moved on from that company but the overall points are the same https://diataxis.fr/

> This is the wrong way to think about things. You cannot usefully compare the value of time spent on work vs on hobby.

I'd consider this sort of move of house maintenance to be more of a chore than a hobby project, though maybe that's just because I've already done it before and it's not interesting or satisfying to do it again.

In any case - I do agree that attempting to apply the same thinking to the hours spent in day to day tasks as work needs to be done very mindfully, or even carefully. One of the worst practices I had early in my career when I was freelancing and had a few clients that were happy to give me as many hours as I wanted to take was to use that as an excuse to replace other tasks with work. Paying someone else to do 30 minutes of grocery shopping so that I can work an extra half hour and end up with a profit, ordering lunch multiple times per week because the time it'd take me to cook and clean up would end up 'costing' me more than just continuing to work on something I enjoyed.

Before you know it you start thinking of chores as complete wastes of time rather than normal things that are good for your character to be able to do consistently. Ended up with a significantly better financial outlook than I'd have had otherwise since I had the work ethic/life balance to take advantage of that situation and not completely tank other aspects of my life, but looking back I'd rather have kept the more mundane discipline.

> I asked him how he managed to code, and he replied with something that stayed with me: a good programmer should organize software in such a way that every piece of code has a clear and logical place. The organization should be so intuitive that anyone could build a mental model of the structure and navigate it easily, even without seeing it.

I had a similar conversation with a blind classical guitarist before I ever played, which was echoed by my instructor when I started to learn a few years later. Something along the lines of "If you don't know a piece of music to play it with your eyes closed then you haven't practiced it enough for a performance."

I'm not sure I follow the same idea with not utilizing available tooling in software development, but I do believe that most developers would benefit from intentionally going 'back to basics' and limiting their use every so often and shining a light on what you might think you have a solid grasp of but are actually at the limit of your unassisted capabilities.

Personally, I can understand that for initial setup but hate that the way they're implemented means that it has to always be running, and it frequently has to be restarted to recognize the mouse correctly and apply those settings. Many keyboards have figured this out and don't require anything to be running to keep their settings across multiple devices so it feels like logitech will never improve in this area for the sake of keeping their bloat/spyware on your machine.

Meanwhile I'm wondering what 'draw a line around' something means, when they use circle in other parts. If they meant circle, they'd have said circle, no?

Personally, I feel more like I'm a monkey in a circus than in a rat race. I'll dance for the music when we're in the big tent, but the show stops for me when the tent is pulled down for the day.

There are two ways I've found success where I've come into a team with these issues:

1. Differentiate critical comments vs opinions/nice to haves. Not every comment needs to be resolved as part of that specific PR, they can be addressed in a follow up after it is merged in a disciplined team.

2. Be okay with reviewers contributing to the PR themselves. Some developers just get too caught up on 'ownership' of code that makes it in, when the team is responsible for it in the end(when you have a blameless/improvement focused culture at least). I don't need the original branch owner to fix a typo or nitpicks when it will take me less time to fix it. I haven't found any code suggestion features that are amazing for this, so sometimes you'll end up with back/forth disagreement and have to rebase a commit out, but most of the time it's fine and overall improves velocity. Basically turning the PR into async pair programming.

There are different levels of risk involved with different types of changes, and there's also risk involved in not making some changes. But aside from that, it is useful to separate the meaning of deployments(pushing a build from a code change to production) from releases(enabling the functionality of that code for users/consumers).

Releases? Sure, you want those to happen early in the week so that you can monitor the rollout and how users interact with it. Deployments? Ideally, deployments change absolutely nothing about the performance characteristics of the system until a feature flag is enabled. There is some cruft in that and it requires cleaning up after yourselves, but when used right it's no different from standing up a new deployable that nobody interacts with yet as far as risk goes.

All in all, if you have a healthy CI/CD setup, use risk mitigating strategies such as feature flags/automated rollbacks, good monitoring/alerting on performance and SLOs, and you're not introducing something like 200+ novel lines of code to an existing workload running in production then I don't see the point in waiting to deploy.

Maybe I'm just too much of a fan of finding things that hurt and making them hurt as much as possible so that we are incentivized to improve them though. If something goes wrong on a deployment/release on Friday, it would go wrong on Monday too. Find what was broken about your process that let it slip through and fix that.