tl;dr:“The first time I went on call as a software engineer, it was exciting—and ultimately traumatic. Since then, I've had on-call experiences at multiple other jobs and have grown to really appreciate it as part of the role. As I've progressed through my career, I've gotten to help establish on-call processes and run some related trainings. Here is some of what I wish I'd known when I started my first on-call shift, and what I try to tell each engineer before theirs.”
tl;dr:“In the last couple of years, I stumbled into a way to avoid getting stuck midway in my projects. It's not just about productivity: this also lets me let go of things when I reach a good stopping point. It helps me figure out what that stopping point should be.”
tl;dr:“You use a programming language as a tool of thought even when you're away from the keyboard. This makes it ripe for learning. You will learn a lot if you make a new programming language.” Notably, you will learn about grammar, language design, parsing and runtime execution. Nicole shares a couple of easy ways to get started.
tl;dr:“Here is a quick survey of some of the hard-and-maybe-impossible parts of getting things into production that I've run into in my own work.” Nicole discusses: (1) Getting started. (2) Creating a maintainable design. (3) Making it robust, and observable. (4) User experience and user interface design. (5) Acceptable performance.
tl;dr:“I was onboarding a friend into one of my side project codebases and she asked me why I was using a particular type of UUID. I'd heard about this type while working on that project, and it's really neat. So instead of hogging that knowledge for just us, here it is: some good uses for different versions of UUID.”
tl;dr:“In 2022, I developed nerve pain in my arms. It came on quickly, and it was bad: I couldn't drive, I couldn't type, and at the worst I couldn't pick up our kids. That episode spontaneously resolved after a couple of months, but flareups happen occasionally. One guaranteed trigger is my laptop: if I use it as, well, a laptop, then I'll have pain for a few days from less than half an hour of usage.”
tl;dr:“One way to get people to go from agreeing it should happen to actually doing the work is to get buy-in. When you have buy-in, people will actively work toward the goal instead of just agreeing to it. Getting buy-in is hard. It's also extremely rewarding, and it's how you get real work done as a leader. Without it, the work falls away when you're not around. With it, everyone will push forward together.”
tl;dr:“One way to get people to go from agreeing it should happen to actually doing the work is to get buy-in. When you have buy-in, people will actively work toward the goal instead of just agreeing to it. Getting buy-in is hard. It's also extremely rewarding, and it's how you get real work done as a leader. Without it, the work falls away when you're not around. With it, everyone will push forward together.”
tl;dr:“Unfortunately, it's common for us to log in ways that are unhelpful. Log levels are inconsistent, and logs are added to fix bugs then removed afterwards. But come on, you saw the title, this is about the log levels, mostly.” The author discusses their logging practices.
tl;dr:If a name is hard to change and the code is likely to evolve, use a creative, "cute" name. A descriptive name becomes a liability if it can't keep up with changes. If a name is easy to change, use a descriptive and unambiguous name, even if it gets verbose. Verbosity signals when something needs refactoring. Nicole shares high-level thoughts around naming.