Last week I read an LA Times article about allegations of plagiarism leveled at Olivia Rodrigo. Rodrigo is a very talented artist (“good 4 u” gets stuck in my head for days at a time), but is she a thief? I haven’t heard the songs mentioned in the article, so I can’t say in this specific case.
But in the general sense, my bar for “plagiarism” in music is pretty high. The entirety of popular music is based on artists incorporating things they’ve heard before to varying degrees. Rob Paravonian’s Pachelbel rant is a great demonstration. I’ll grant that “Canon in D” has long entered the public domain. But imagine if musicians had to wait a century to reuse a few bars of music.
My personal view—which may or may not match copyright law—is that unless it’s taking audience from the previous song/artist, it’s fine. This is similar to one of the factors in fair use. As a concrete example, Vanilla Ice’s “Ice, Ice Baby” definitely takes from Queen & David Bowie’s “Under Pressure”. And that’s fine. The existence of “Ice, Ice Baby” hasn’t stopped anyone from listening to “Under Pressure”.
Cultural works, particularly in music and Internet discourse, rely inextricably on remixing. We should embrace a very permissive paradigm.
About a month ago, I wrote that Indiana has surrendered to COVID-19. That remains the case. As you might expect, the trends have continued in the wrong direction. Since August 9, daily deaths are up 57%, hospitalizations 85%, and cases 150%. The lone comfort is that hospitalizations aren’t rising as fast as cases and deaths are rising even less. The vaccines work, if we can only get people to take them.
Not only have cases been increasing since early July, but the rate of increase has increased, too. Only in the last week or so has the week-over-week new case difference started to drop.
Hospitalizations had been showing an alarmingly exponential rise. In late July, we saw the highest week-over-week since records began on April 8 of 2020. This has slowed recently, although it still rivals the increases we saw last fall.
The death rate appears to be leveling off. However, this could be due to reporting delays, so it’s a little early to feel good about it yet. Especially since COVID-19 remains the number two cause of death in Indiana in the past week.
In a Twitter thread on Friday, I used November 9, 2020 as comparison to where we are right now. That date had a comparable number of hospitalizations as we currently have and it was on the upswing. At that point, we were about three weeks away from peak hospitalization. However, the rate then was higher, so we may peak earlier. Alternatively, we may have a broader peak since we have fewer mitigations in place as we did then and—while non-zero—our vaccination rate remains infuriatingly low.
I also looked at ICU bed usage and ventilator usage. The ICU beds devoted to COVID-19 patients is about the same (27.8% of total capacity then compared to 28.4% now). Ventilator usage is higher now (10.4% compared to 8.5% then), which is a cause for concern. What’s not clear to me is if capacity is reported as physical beds and ventilators or the number that can be appropriately staffed. I suspect the state is using the physical counts, which makes me wonder what the true utilization is. Local hospitals say they’re at a breaking point, and things are likely to get worse before they get better.
The Institute for Health Metrics and Evaluation (IHME) have increased the daily deaths in the last few model runs. However, the most recent one dialed the forecast back a bit. The bad news is that we’re tracking it pretty well so far. The good news is that their model is running high on the hospitalizations, so that may mean the death toll is over-forecast, too. We should hope this continues, because both overall hospital and ICU bed usage is forecast to enter the “extreme stress” category later this month. We did not reach that category during last winter’s surge.
It feels like there are more uncertainties now than a few months ago. The IHME model does not explicitly account for school reopenings. The note that “[t]he second Delta surge in Scotland after a peak and a decline when schools opened is potentially a warning sign on the potential for school openings to drive increases in transmission.” Additionally, while mask usage has increased, we’re only at about 25% of adults saying they mask up when they leave the house. And the percentage of Hoosiers that say they have been or probably would be vaccinated remains steady just below 60%. If either of those numbers increase significantly, things could be much less bad than expected.
What to expect
It’s clear to me that Governor Holcomb will continue to do nothing. I’m not sure what it would take at this point. In fact, his recent executive order apparently reduced quarantine requirements for schools. Someone at the state health department had a moment of clarity, which was deleted.
I’m hoping to spend some time today adding Tippecanoe County school stats to my COVID-19 dashboard.
Fostering trust in our organization (video) — I join fellow Open Organization Ambassadors Jen Kelchner and Bryan Behrenshausen to discuss ways to help people feel empowered to propose their own solutions. I suggest leaders shut up for a little bit.
Open seems like it leads to hurt feelings (video) — I know that open organizations are places where people expect candid feedback and honest dialog. But that seems intimidating to me, because it seems like it can lead to harsh conversations and potentially hurt feelings. Is this true?
One of the lessons that I’ve had to repeatedly re-learn over my career is “understand the problem before you fix it.” I try to fix a problem as quickly as I can. It’s a laudable goal, but a fix without understanding may not actually fix the problem. And it may not prevent future occurrences. If you’re particularly unlucky, it will make the problem worse.
I learned this lesson late last week. On Thursday, someone reported some HTML appearing in some Fedora documentation on translated pages. “Oh! It was probably that PR I merged yesterday,” I thought. So I reverted it.
Then I started digging into it some more. And I realized that it’s probably not that change at all. In fact, it worked locally and on the staging server. It was just broken on the production server. It’s not clear to me if both staging and production sync the translation data on the same schedule (without getting too sidetracked, the staging environment isn’t really a staging environment. It needs a better name). But I became convinced that it’s not a problem in the docs infrastructure, but in the translations. So I reverted my reversion.
This is not the first time I jumped in to fix something before I took a look around to see what’s going on. Unfortunately, it probably won’t be the last.
Here’s the thing: most of the time, a slight delay doesn’t matter. No one’s safety was at risk. We weren’t losing hundreds of thousands of dollars a minute. There was no real harm in spending 10 minutes to figure out what was going on. Perhaps I could try to reproduce it. After all, if you can’t reproduce the error, how do you know you’ve fixed it?
Hopefully the next time I go to fix a problem, I’ll understand the problem first. As astronauts do, I need to work the problem.
The idea of unlimited paid time off (PTO) has been around for a while. I wrote about it in 2015 shortly after my then-employer changed from a traditional PTO policy. But unlike many practices in the tech sector, unlimited PTO has not become ubiquitous. It’s still a matter of debate, especially since it can result in pressure to take less time off because there’s no signal about the appropriate amount.
The joys of unlimited PTO
My old company was small, engineering-focused, and fully-remote. Everyone wore a lot of hats and there wasn’t a lot of redundancy to go around. But the unlimited PTO model worked for us. Employees that were there a full year before and after the switch used, on average, about half a day more of PTO in the unlimited model.
We had a minimum policy: you had to take at least two one-week periods off each year. This helped make sure people did take time off and established that “unlimited” wasn’t a way of saying “don’t actually take time off, we just don’t want to carry this liability on our balance sheets”.
For me individually, I didn’t take much more time off than I had previously (I’m pretty bad at taking PTO to begin with). What I really liked about it wasn’t the lack of a limit, but the lack of having to think about it. Need to take a day off? Just do it. There’s no “hm. Well, should I only take half a day so that I can make sure I have some at the end of the year if I need it?”
After Microsoft acquired our company in 2017, we were back to a traditional model. We received about the same number of days off as I had been taking under the unlimited policy. But now I had to think about it. At Red Hat, we also have something like the traditional model. And I’m bad at taking it. In part because I tend to flex my work time in order to attend off-hours community events. In part because I’m just bad at it. I long for the day when I can just take time off and not worry about whether or not there will be any left for me at the end of the year.
To track or not to track?
Over the weekend, Alyss asked about tracking unlimited PTO:
I can understand the hesitancy. If your manager can reject PTO requests arbitrarily, then you don’t actually have an unlimited PTO policy. But the request/approval process can be useful for coordination. You don’t want to show up one morning to find a dozen people in your team have decided to take off for two weeks. In that sense, what’s needed more is acknowledgement than approval.
Tracking can also be abused, but I think it’s good on the whole. As a manager, if you can see that someone isn’t taking PTO, you can kick them out of the office for a week. (Not really, of course. But you can encourage them to find some time to not be at work.)
At Nest With Fedora last week, someone said “I also gave my presentation without speaker notes. It’s like doing slideshow karaoke with one’s own slides.” That sparked a discussion of the different ways people use (or don’t use) speaker notes. So I thought I’d write about my own practice.
Speaker notes, if you’re not familiar, is the feature of most presentation tools that allow for additional notes not shown on the slides. These are usually displayed on a second screen that might also include a timer, the next slide, etc. The idea behind speaker notes is that it gives the speaker a reference for what they want to say. This avoids the speaker having to memorize the presentation—or worse, make slides full of text that they read to the audience.
How I don’t use speaker notes
I have never gotten in the habit of using speaker notes. Perhaps it’s because my formative slide deck years were ones in which I had but a single monitor? Even now (well…in the Before Times™), I occasionally end up in a venue where the second screen option doesn’t work well. And if you have to fall back to a PDF of your slides, then the notes won’t be visible either.
So how do I avoid the wall-of-text slides? Sometimes I don’t. But mostly I do it by preparing. For most presentations, I start by building an outline. Then I write a long-form version. This is sometimes useful with minor edits as an article or blog post. From there, I build my slides. Then I practice a couple of times. So by the time I get on stage, I’m pretty familiar with what I want to say.
How I do use speaker notes
Where I find speaker notes useful is for people who are looking at the presentation after the fact. I’ve been told “the slides shouldn’t be useful on their own.” That advice isn’t about intentionally making a bad experience, but because the slides should reinforce what you’re saying. Otherwise, you should just hand out a document.
This means if anyone looks at your slides later, they need the greater depth that you’d speak. This is where speaker notes come in handy. And that “anyone” can also be Future You. I gave a talk earlier this year that I hadn’t delivered since fall of 2019. I used my speaker notes to remind myself what the images were supposed to represent. Speaker notes are also a great way to add additional citations, etc.
I’d really hoped to not have to write another of these. The optimism I felt at the end of March when all the numbers were on the way down and vaccination was becoming widely available has now vanished. As the so-called delta variant races through the country, all of Indiana’s numbers are heading upward again.
After a slow downward trend to start the summer, the last few weeks have shown an increase in COVID-19 deaths.
This is to be expected given the increase in cases and hospitalizations. In fact, the hospitalizations have increased faster than any time since the state started keeping records in early April of 2020.
The state had over 1,000 people in the hospital on Thursday (the latest data available) for the first time since May 4. If Friday was also above 1,000, that will mark the first time with consecutive 1,000+ days since mid-February. Hospitalizations have gone up 146% in the last month.
The state used to update its COVID-19 dashboard daily. Then it stopped on Sundays. Now it’s just updated on weekdays. There’s no sign that the state government will do anything to require either masks or vaccination. Some local governments are re-implementing (or at least considering) mask mandates. I haven’t heard much about vaccination mandates except for at universities.
With schools starting or about to start, some districts have decided to have a mask mandate after all. (My kids school is among those, thankfully.) Others are leaving it up to individual families. Considering roughly half of K-12 students are not eligible to be vaccinated yet, this seems like a monumental policy failure. This is even more true if the delta variant is more severe in children than previous versions of the virus. At the moment, that appears to be more than a hypothetical.
It seems to me that the state has just surrendered. The governor is nowhere to be found on this, despite doing fairly well in the early days. In a recent press briefing, the state’s Health Commissioner was very diplomatic, but my interpretation of her answer to a few questions was “I wish we’d stop being dumb as a state and have some smart policy here. But my hands are tied without support from the Governor or the General Assembly.”
Unsurprisingly, the Institute for Health Metrics and Evaluation (IHME) forecast model continues the trends for the next few months. The latest model run projects a peak in daily deaths in the low-30s in mid-October. This is the “reference” scenario. The “worse” scenario peaks around 55. The worse scenario isn’t out of the question with an increase in in-person school and work. So much will depend on whether or not people wear masks and get vaccinated.
The good news is that if the reference scenario verifies, it will be lower than the previous two major peaks in deaths. The bad news is that a lot of people will still die unnecessarily.
As you may notice in the graph above, I had a long gap where I wasn’t adding new IHME model runs. Since it’s now clear that we won’t be done with COVID-19 any time soon, I’ll probably go back in the next few days and fill in that gap a bit. This way we can get a better sense of how the early summer model runs did.
I’ve made a few changes to my dashboard this weekend. First, I’ve changed the moving averages to be centered instead of trailing on all of the graphs. This keeps the last few days of data from distorting the trend.
In addition, I’ve added columns for a percentage change in deaths and cases week-over-week. The idea here is to produce a graph that shows the trends in cases, hospitalizations, and deaths. This would allow the viewer to see the relationship and delay between the three measures. To make it less noisy, it’s actually a comparison in the cumulative data over a seven-day window. That’s not necessary in the hospitalization data because that census is conducted every day. But cases are subject to a lot of variation throughout the week, and even the same-day-last-week comparisons seemed all over the place. Deaths are a relatively small number so small changes can be a big percentage.
I’m not going to bother putting the resulting graph in this post. It’s still a lot of spaghetti and not particularly informative. Later on I might play around with doing a second derivative. Perhaps showing how the rate of change is changing will be easier to understand.
Future dashboard changes
I’m beginning to hit annoyances with Google Sheets. In particular, inserting a new column (unless it’s at the far right of the data) means I have to re-adjust all of my graphs. I’ve been toying with the idea of using the Python Pandas package to do analysis and graphing. Then I could publish the graphs to a static website. It would also allow me to do a little more analysis, like listing the top 10 days for a particular stat or trend.
Another option I’ve been thinking about is splitting the sheet into multiple tabs. I could have a tab for the observations, another for models, etc. I’m not sure how well Google Sheets would like that, but it’s something to toy around with. It doesn’t seem like as much work as completely rebuilding it in a new system, but it’s also not trivial.
Given my lack of free time and the amount of effort that either of these options would require, I wouldn’t expect to see either happen for a while. However, it seems like I’ll be maintaining the dashboard for quite a while, so who knows?
In 2010, I attended my first conference. My friend Matt—who I met because we read and commented on each other’s blogs—was leading the blog team for USENIX’s LISA conference. He wanted to add a few people and asked me to join. I was thrilled.
That fall, I went to San Jose not knowing what to expect. I was a system administrator (in a large installation, no less), but there were so many things I didn’t know. Would I fit in? Yes, as it turns out.
The community was large, but incredibly welcoming. I got to have dinner with some of the Big Names in system administration, all of whom were kind and gracious. For six days, I woke up early (because time zones), attended sessions all day, went to BoFs and social events in the evening, then stayed up late to write a couple of posts for the conference blog. By the end of the week I was exhausted, but having the time of my life.
For several years, I was a regular attendee and blogger. In 2016, I served as co co-chair of the Invited Talks track. In 2018, I was on the program committee. Since then, I haven’t been involved with LISA (except for a lightning talk this year) because my career has taken a different direction.
But even though my job is no longer system administration, I’m still friends with so many people I met through LISA. And it’s not a stretch to say that being on the LISA blog team set me up for success as a writer. Of course, it gave me a lot of practice writing on tight deadline. But it also helped connect me to people who have since given me a boost in my career. I doubt that I’d be working on a book right now if it weren’t for the LISA conference.
So you can imagine how sad I felt when I saw the news that the LISA conference has come to an end. All good things must end, of course. LISA had a terrific run. But the field—and the world around it—has changed. So we must bid goodbye to the conference that started me on conferences. I learned so much and met so many wonderful people. And I’ll always have that.
Recently, my friend said she quit a job leading development at a company after the CTO went on a 15 minute rant when she said reading code is just as important as writing it. I don’t blame her. I agree. I might even go as far as saying it’s more important.
Of course, there’s no code to read if no one writes code. I’m not saying that writing code is unimportant. But even for developers, reading is a critical skill. You’re not writing new code all of the time. So much development work is reading existing code to fix bugs, add new features, etc. Of course, developers spend a lot of time reading code people wrote on Stack Overflow, too.
Reading code is also critical for people who aren’t developers. I could probably code my way out of a proverbial paper sack, but just barely. But I’ve been able to point developers in the right direction by being able to dig into code. The ability to read code—even if you don’t fully comprehend it—is invaluable in troubleshooting technical issues.