At my old employer, the penultimate technical operation before delivering a satellite to a customer or rocket company was a “Day In The Life”, or DITL, test campaign.
During this event, the integration and systems engineering teams exercised all the satellite’s subsystems, from attitude determination and control, to power storage, to communications. They looked at the performance of both hardware and software, and paid particular attention to mission-specific engineering. They simulated anticipated events of a day in the life of the satellite in orbit.
The underlying goal of DITL was to ensure that the vehicle as actually assembled would work in space, and would be able to contact Earth after it deployed from its launch vehicle. This was critical, because if something went wrong before the satellite could phone home, we’d never know it.
In this sense, DITL wasn’t generalized to any day, but focused in on that first day in space.
The test was necessary to show things experimentally that couldn’t be demonstrated analytically or at the subassembly level. For example, since we could observe battery performance in tests before we built them into the satellite, we didn’t have to do those specific tests on the entire satellite.
In this sense, DITL is the culmination of the entire pre-launch battery of tests; it’s the last chance for engineers to identify and resolve issues with the hardware or software while the spacecraft is on the ground.
“Day In The Life” has another meaning though, one I find far less useful. The term describes a sort of (typically) short-form audio or written content about either a representative or actual day.
I have read precisely one day in the life piece of content that I thought was really valuable, and Solzhenitsyn wrote it. Part of what makes One Day in the Life of Ivan Denisovich so interesting is how identical each day of the protagonist’s sentence was to the adjacent ones — at least from an external perspective.
Most Day In The Life content doesn’t actually follow this premise, because it doesn’t hold for its creators. They have jobs that are necessarily different each and every day. Perhaps there are similarities across days, but the schedule varies, the activity varies, and certainly the timing varies.
In fact, they seem to like to create this content specifically because their days are so interesting and different from each other. Maybe that means I’m missing the point. But maybe the lack of standardization renders this type of content essentially incomplete, in an Adlerian perspective?
At this point, it’s quite clear to me that for VC investors and early stage startup employees, there is no standard day. As a result, I’m unconvinced DITL content is meaningfully representative of the work any particular creator in these fields undertakes on a regular basis.
Furthermore, DITL content tends to come from people who’ve “made it” in whatever respect they’re thinking of themselves, with the apparent intent that it should be consumed by people who haven’t yet gotten there.
While I appreciate that it can be worthwhile to see what life after success looks like to understand whether the payoff is worth the effort before beginning, I think it’d be much more helpful over the long term to create content about what it took to initially be successful.
Ultimately, the point of DITL as construed by engineers is to demonstrate mission-critical steps in its lifecycle as closely as possible while on Earth. DITL is a direct simulation of what is to come for the device under test. The entire value-add of this process comes from the confidence that this individual flight article will be able to accomplish the key things that the activity validates.
In my mind, this is what anything calling itself DITL ought to be doing.
I don’t think it needs to be engineering. And I’m certainly not opposed to creator content about this on principle.
But I do think it needs to be more tightly focused on what critical events entail, rather than surveying the day more broadly, than I’ve seen most content focus on.