Some weeks back, my backups stopped working. I was using Dropbox, and Dropbox was doing some biiiig upgrade. One side effect of this upgrade was that Dropbox stopped watching the folder it had been watching and started watching some random other folder. I didn't really notice this. Yay, I didn't need to restore from backups in all that time. I changed my backup system so that it used the new folder.
Some days back, Dropbox mailed me to let me know it had stopped syncing my files because I wasn't paying them. Apparently, part of the biiiig upgrade was some change to their billing systems. And they'd forgotten my payment information. For a while, they'd given me a free trial. They'd been sending me emails which I suppose were asking me to tell them my billing information again… which I ignored, because they had subject lines like "Your free trial is ending soon" and I "knew" they had payment information already…
Rather than wait for the next thing to break, it was easier just to set up a new backup system on top of something other than DropBox. If something doesn't work, I'll find out sooner rather than after several days of innocuous emails. There's probably a lesson there about new-development versus maintenance, a philosophical point I'll calmly consider when I can stop worrying about whether my files are really being backed up.
Hopper organized folks to collaborate on designing a programming language. She did this back when folks weren't even sure that programming languages were a good idea. She did this before you could organize folks by saying "I set up a messaging board on the internet, let's talk." She was mailing out physical letters; waiting for physical letters coming back. Getting people to gather in places to talk the issues over. Getting folks to go to all this trouble for a programming language… again, when folks weren't even sure that programming languages were a good idea.
She succeeded—people used COBOL for decades afterwards. In hindsight, I wish she hadn't succeeded so well and so quickly. Maybe if it had taken longer to design COBOL… maybe if hardware memory had been cheaper by the time COBOL came along… maybe then folks would have felt OK allocating four digits to store year-numbers and the the Y2K crisis would have been a tiny blip instead of a whole big thing.
Anyhow, this was an inspiring tale of a nerd who could wrangle computers could wrangle humans, achieving some impressive results in a time of "flint knives and bearskins".
Yes, that's Lisa L. on this side of the pond. Fortunately, our team had enough tall people on it such that you can't see the game clock behind us: We didn't actually escape in time, but went several seconds over. [Update: Actually, we did escape in time. This room gives you a hundred minutes. We went a few seconds over the usual hour.]
Content warning: all the gross bodily fluids
Today I was walking along, minding my own business, and I felt something wet on my hip. I looked down and saw blood and guts on my sweatshirt. My brain slewed into heavy diagnostic mode for a couple of seconds while I figured out that this wasn't my blood and guts. My best guess: fish guts. This was near San Francisco's Fisherman's Wharf neighborhood. I guess a seagull was flying around with a mouthful of fish guts and dropped some. Or maybe a seagull vomited on me. Does that happen? Do seagulls vomit up fish guts? If I ate some of the gross fish-stuff that seagulls eat, I'd throw up all the time. But I don't know how often seagulls throw up. I don't even know for sure that a seagull was involved. Maybe some street lunatic was flinging guts around. Stranger things happen in this city every day. I'm used to the idea that, walking a lot around the city without a hat, every so often a bird is going to poop on my head. There's a superstition that's good luck. I never really thought of bird poop as good luck. But the next time it happens, I guess I can think I'm lucky it's not a glob of bloody fish guts because that is nasty. Anyhow. I got home and spent a couple of whiles rinsing blood out of my clothes. The problem: too much blood.
There's this book Bad Blood about Theranos, that company with the opposite problem. Theranos was trying to make an automatic blood testing machine. There were already such machines around. But Theranos was trying to make a portable machine that didn't need to use much blood in its test. It failed. Well…some of the medical nerds working at the place succeeded in developing a few new mechanisms/processes to test blood, but nowhere near the capabilities promised by Elizabeth Holmes, Theranos' liar CEO.
Along with the scariness of the general situation—how many people were harmed by acting on incorrect blood tests before Theranos was shut down?—tech workers get some additional frights by seeing some tech-company-tropes used to great harm.
E.g., Steve Jobs famously kept departments at Apple in the dark about what other departments were working on. This allowed him to make surprise product announcements—very few people knew of the existence of any new product, and thus leaks were rare. Holmes kept Theranos' departments in the dark about what other departments were doing. In theory, this was following Jobs' example. In practice, this meant that few folks within the company knew how poorly the blood-testing machines worked. There's a pattern to this book's stories of whistleblowing Theranos workers. Worker gets hired. Worker is enthusiastic—portable blood testing machines that can work with small samples would make many people's lives better! As far as worker knows, everything is hunky-dory. Worker is in one of the few parts of the company that actually uses the machines. Worker notices that one aspect of the machines doesn't work well, the aspect they're testing. Worker reports this to a higher-up. Worker gets fired for their bad attitude. Other workers off in other departments still assume everything's working fine.
E.g., working around government regulation. Is it right that a company should follow medical-testing rules made to stop wild-west snake oil salesmen? We're in a new age of engineering, skilled in rapid innovation and we're trying to save lives here— And it all probably sounded pretty convincing at the time. But in the end, it just reminds us that the snake oil salesmen have kept up with the pace of innovation just as well as the honest folks.
The book also points out how folks found Holmes' deep voice to be very compelling. I've worked with a couple of managers who had deep voices; in more than one case I'd find myself nodding along to something one of these guys said… only to head back to my desk, sit down, replay the conversation and realize that they'd been talking nonsense. These occasions weren't happy, but looking back I guess I can say it was lucky that those guys weren't working on medical devices.
It's a book with ways to indirectly find out internet-security-ish info about things. E.g., if you're curious to know whether visitors to your website also frequent the San Francisco SPCA website, you might try displaying an image from that website and time how long it takes for that image to appear. If a visitor sees the image quickly, their computer probably already had info from the SPCA website cached on their computer from previous visits.
Some of these techniques are practical. Some others, uhm, sound like some grad students dared each other find the most bass-ackwards way to "leak" information from systems they already owned. E.g., whoever figured out how to guess at network traffic by using a high-speed camera to monitor lights on a modem, uhm… these people were clever but maybe could have found a better use of their time?
Practical or not, this is some fun reading if you're into that sort of thing.