Sure, you can maybe be a great driver without caring about the car or the crew, but it is definitely going to have its limits. Likewise, at the end of the day the crew is there to make the driver shine, and need to be invested in understanding how they operate.

Creates a much better sense of culture and collaboration, and overall better products, when everyone can see the part they play and how important the relationship is to their peers.

Between the network latency and low end machines, there is an enormous lag between chatgpts response and being able to reply, especially for editing a canvas.

I've been sitting there for up to a minute plus waiting to be able to use the canvas controls or highlight text after an update.

Expected the difference with Ubuntu as it packs more out of the box for the enterprise behaviours, not so much with Fedora. I've had no freezes, faster startup and shutdown, generally more responsive desktop etc. with Arch.

Generally, though a rolling release it also has fewer moving parts as well - only having to deal with the main repo + flatpak (and a select few AUR pkgbuilds) is nice compared to Ubuntu where I had to layer deb repos + PPAs + flatpak + brew to get my tooling in place without having to script my own git-driven installers.

One thing that tripped me up on any distro - the defaults for TLP (vs power profile daemon) seem hyper conservative wrt performance, probably by design. I never bothered digging in, just switched back to PPD, but it definitely prioritises power savings above all else.

It's a footgun avoided by reading the spec and (maybe) remembering it in practice, but it feels like it would be safer to throw a comp error and force the user to deal with it when a user is trying to exceed the cap of the underlying array?

Alternative is defensively using len() and cap() for slice ops in which case error-ing out feels more ergonomic.

Working on a python gig targeting an airgapped windows server, different OS architecture from everything else on-hand, restrictions on building and deploying VM's, poor dev/prod workflows etc.

After a couple of months of app dev we ran into weeks of grinding through building a reproducible process (including a sneakernet step) for python dependency resolution and binary builds to get the payload dropped on the server. It was brittle and a bit overwhelming.

Go was "big enough" at the time to be a reasonable next step and after a few weeks of porting we had a cross-compilation process up and were done.

Go actually _shits me to tears_ as a language compared to python, rust, or even Lua, but as a back-end dev it's still where I do most of my work as I'm nearly guaranteed to be able to i) predictably solve something in a way i can share it with a team and ii) get it deployed without too much pain.

I have a paper notebook that lets me be more present in different scenarios and only capture stuff like actions or critical facts. Likewise key data around policy numbers, cost codes, etc. go into a markdown file.

I used to be a voracious note-and-knowledge capture type between Standard Notes and Obsidian. I'd keep both a daily rolling log of everything I did + cross-ref and expand key items into broader knowledge capture.

It probably has some intangible benefit I didn't pick up on but overall it just felt like a waste of energy compared to letting stuff go, sometimes having to google stuff again, and putting effort into building things and talking to people.

I also started to wonder, what is the value? Documentation, code comments, communication all help to take an idea or understanding from Me -> People. Hoarding notes and digital content for myself really didn't accomplish much other than demanding attention.