While the underlying model is certainly different, and my understanding is that current LLMs don’t learn “live”, the principle seems worth keeping in mind.
“The Elements of Computing Systems”, by Nisan and Schocken, starts at logic gates and works up to a functional computer that can play Tetris. So not quite Ohm’s Law, but close.
They also have a two part course on Coursera I think. It helped clarify some things that I didn’t quite understand in the book and help keeper me on pace. For full disclosure, I’ve only done part one so far.
I’ve seen most of these recommendations before, but the “mic-drowning case” to muffle room audio is new to me. Certainly makes sense, but are there any common commercial phone cases that advertise this feature?
I just spent my first winter in Boulder (moved from NYC) and thought the winter was incredibly mild. All my friends and family back home kept asking how I was handling the cold, but I thought it was worlds better than slushy, frigid NYC.
I'll second that. The lack of humidity really helps keep things comfortable outside when it is cold. That specific heat of water is killer in a Midwest winter.
Low humidity is also why we get the really powdery snow that is great for skiing.
Many large companies have structured mentorship programs, but this is mostly for onboarding. Your mentor will help you learn about the company itself, e.g. all the different internal practices, tooling, teams, etc. (This is nothing to sneeze at, given how big these orgs can be!) It may include some more general career development but this is often aimed at early-career folks.
For more general mentorship, especially as your career develops, it’s the same as anywhere, you have to find someone you get along with and who can help you learn. The advantage at a big company is that there’s a huge pool of potential mentors, and you can see their calendars and coordinate more easily than if you were hunting in the community. :)
One of my favorite recurring team conversations is the one where everyone shares stories of the outages they've caused or the systems they've broken. This conversation has happened eventually on every SRE (sysadmin/PE/devops/whatever) team I've joined, usually when a junior team member causes their first outage and is having an emotional meltdown. I remember my own meltdown of that form, and I remember it helped hearing about the terrible problems my friends and mentors had caused in their turn.
The first outage where I thought I was going to get fired: I was working on a system that had a single-point-of-failure server, and through a mishap with rsync I accidentally destroyed the contents of /etc. That SPOF also had no backups. (I'm not claiming it was well-designed...) Thankfully the job that depended on that server would not kick off until morning, so my team slowly reconstructed its functions on a separate machine and swapped it in behind the scenes. I helped as much as I could while vibrating with anxiety, and my team was incredibly kind throughout. I was not in fact fired. :-)
The most recent outage I caused? Yesterday! I accidentally rebooted most of the machines in a development cluster. It's a dev system, there's no SLA, on the whole I don't feel horrid, but it definitely ruined a few people's work for an hour. This morning I spent a few minutes putting in a guard rail to prevent that particular mistake again...
If you're in this job long enough, everyone breaks things -- it just happens.
There are rack designs out there built on this idea, but they are usually pretty specialized. For example, the Cray XC series has racks with built in power, network, and out of band monitoring.
A downside of this kind of thing is that it makes upgrades and maintenance harder, and you often have to do any hardware work on a whole rack at once. Heterogeneous setups get really hard. And it’s usually very vendor specific.
It doesn’t support OpenVPN, but I’ll leave a plug for the Outline VPN from Jigsaw (Alphabet). [0]
It’s similar in concept to Algo, in that you deploy your own VPN server on a VPS rather than use a hosted service. However, it provides a polished desktop app for deploying the server, and walks you through creating a VPS on DigitalOcean very easily.
This is incredibly helpful, because most folks I’ve helped with VPN setups are not comfortable aren’t handy with a CLI, and I’ve been able to walk more than one person through setting Outline up very easily.
I'm glad to see Jigsaw tackling the UX side of things, but some caveats about shadowsocks (the protocol backing Outline): it's an encrypted proxy, not a VPN, and there are some open questions about weaknesses (not necessarily flaws) in its design[1].
I think easy-to-manage platforms like Outline will probably be the future, but I'm not convinced that shadowsocks is the right foundation.
"Unfortunately this tool doesn't exist for blb++, but we should still improve our coding style for this application. Is there another way to improve our correctness testing? If we allocate some time to improving unit testing, maybe we can do this refactor once we have X% coverage in these critical parts of the codebase."
I.e., acknowledge that both goals are valid, and look for alternate solutions to make incremental progress towards both. Finding middle ground is unlikely to be satisfying from either viewpoint. In this example, Dev A isn't getting a quick win from fixing the coding style right away, and Dev B needs to allocate some time to improving testing. But especially when working on big teams and projects, this kind of piece-wise progress is where I've seen most things get done.
This kind of solution might be pointed out by either Dev A or B, or they might need to bring in a fresh pair of eyes if they're both already frustrated. :)
While the underlying model is certainly different, and my understanding is that current LLMs don’t learn “live”, the principle seems worth keeping in mind.