ajdecon

> The idea of the dashboard is the following: I run the Codex through a web chat to identify the relevant quotes — relevant for my dissertation topic — and how they are relevant, it combines them into a number of claims connected with each quote with a link. And then I review each quote and each claim manually and tick the boxes.

I’d be most concerned about this component of your process, tbh. IIUC, you’re not just using the LLM to identify relevant papers, i.e. a fancy search engine. You’re also extracting specific statements, divorced from their context in a given paper, and using these to make claims for your research.

Even if you validate that the quotes are actually present in the papers, are you also reading the full papers to ensure you understand the overall results of the paper and what the quotes mean in that context? Or are you just identifying hopefully-relevant snippets and combining them?

FWIW, folks on lobste.rs are (mostly) friendly and willing to extend invites if you seem like a real person. My understanding is that the invite system is primarily in use to avoid drive-by spammers and the like.

Feel free to send me an email (findable via my HN profile) mentioning that you found it via this thread, and I’m happy to extend an invite.

It’s worth noting that one of the paper’s authors is Todd Gamblin, the Spack project lead.

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 was already remote, but I’m moving from Seattle to Denver.

Combination of family and a more favorable climate. The somewhat lower cost of living doesn’t hurt, but it’s not like Denver is cheap.

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.