Clicked for me recently that working hard is like driving in first gear. Necessary initially, but if you don't shift up into higher gears, you're probably not doing it right, and not getting as far as fast as you probably should. If I'm tired, it's necessarily because I'm mismanaging my work and time, and that's a signal it's time to step back and figure out what's wrong.

Some people are really good at that initial torque boost on projects and can sustain it longer than others, but if work doesn't get easier it's because you're doing something wrong.

From a market-fit perspective, I think startups that drive around in first gear never get very far either. Things are only hard because we're being stupid. Nobody ever looks at a person driving a ferrari and thinks, "wow, they must have washed a lot of dishes to afford that car," and yet we still think "if I just wash these dishes hard enough I'll drive a ferrari one day."

I'm guilty of this as much as anyone, but burnout is my body intervening to tell me I'm being stupid.

My SO helped with the crowdsourced civilian effort to dispatch water rescues of stranded people. The effort is wound down now; it will likely be hailed as a coup of "social media", but that's overhyping the social media aspect. Social media got the word out of where to go online to enter the coordination, but had little to do with the actual coordination itself. The group my SO worked with coordinated mostly through the Zello mobile app, Glympse mobile app, houstonharveyrescue.com (going dark soon, due to PII concerns), and a Google Sheets to track water rescue requests.

TFA is mainly discussing use of drones in the recovery phase, and only tangentially touched upon drones for rescues. Drones were not used much for long-range water rescues, because they were a hazard for the many volunteer helicopters that responded.

This pointed out the need for a solution (preferably as automated as possible) that allocates helicopter and drone flight paths in a disaster area.

The whole experience was very eye-opening for me. There isn't a good solution for coordinating disaster response by civilians, but even just the ad hoc quick-and-dirty collection of apps used by the various civilian groups that responded showed how much leverage Internet-enabled coordination delivered. The latency of civilian response is much lower than government response, but once the government landed resources, the government response had much greater volume. Mix both groups at the right times, and you'd have an admirable disaster response, pretty much what happened in Houston.

Observations from listening in on my SO during meal times (the only times I could break from work):

* Misinformation is rife. This is a difficult problem to address. Example: rumor starts that a rescuer was slashed with a machete. Story morphs into shot and slashed, then slashed-got-sepsis. Turns out a guy stepped on glass and got a nasty gash.

* No good solution to map rapidly-changing road conditions. Piles of rescuers with valuable boats in the first critical hours of response were diverted to drive around to find a way into the right areas of Houston to deploy. Need a way to effectively intake reports from people with just trucks (lots of citizens responding with no boats wanted to help in some way), snapping pictures at a specific location, giving location and time, and reporting road closures due to specified height of water, electrical line, etc. Bonus for AR-enabled measurement of water depth, based upon baseline measurement of vehicle. Extra bonus for measuring water speed by tossing a recognized object into the water and tracking it. Then people who pull up the heat map of closures will flood-fill (pardon the pun) out possible routes, avoiding lots of redundant checks of possible routes. A lot of valuable time was wasted on this, the first few hours were filled with civilians an hour from arriving at the area (as instructed over social media) calling in and asking how they can reach where they can drop their boats, because the main routes were all closed.

* No good solution to map flooded areas, how deep, and forecasted levels. People pieced it together by hand and passing along the grapevine. Depth matters: below a certain level, outboards were getting stuck. Below a different level, and all boats had to watch for fences they could get snagged on (had a few that capsized on such obstacles). Ideal: remote-reporting gauges scattered in a grid pattern throughout the area, or gauges that can be dropped down during the initial rescue efforts, and reclaimed later.

* We reached out to Uber and Lyft. IMHO, this was a PR coup sitting around for the taking. You have a system that optimizes for efficiently tracking and queuing requests, matching requests to vehicle capacity, directing the closest vehicle to the request, and showing requesters the live status. This was precisely what the water rescue coordination needed. Uber gave a canned "we're standing down for the safety of our drivers, for those who are outside of the areas of Houston that kicked us out that we can still operate in". Lyft said great idea, but the conversation black holed after that.

* Any app-based solution will have to be very sensitive to energy usage. Rescue requesters ran out of power on their phones distressingly often. Zello was established early on as a bad way to communicate with requesters; it drained batteries very quickly. Instead, requesters reached out to relatives/friends they knew who were safe, instructed them how to get Zello and get on the rescue channels, then put in a request, and then those relatives/friends would periodically query for a status update on the request. Use strongest WiFi if available, fall back to cell data (lowest-tech with strongest signal available), then SMS, then voice.

* These status update requests (see previous entry) took up a lot of bandwidth at the height of rescues, and added to the stress on the rescuers. A queuing system that operated over WiFi if available, then over cell data if not, telling requesters they are number N in line for the nearest rescuer, would have made the coordinating a lot easier.

* A unique ID was eventually established for assigning each request. A voice recognition system could easily listen in on a group and automatically assemble in timeline form all conversations that mention a particular ID, so anyone looking at a particular rescue request could see all historical discussion about that request.

* The Zello conversations quickly got unwieldy when there were too many people vying for "the microphone". Fortunately, people figured out how to manage this somewhat, splitting into Port Arthur and Houston-specific channels, for example. An app to auto-split by role (dispatcher, rescuer, requests, etc.) and density-based geography (bounded by neighborhood boundaries, perhaps) would have helped some of the confusion.

* A voice recognition system to simply assign people to the right channel based upon their initial request would be helpful. There was an opportunity here for someone like Twilio to set up a single phone number that did this. In the first few hours, people did this through their personal lines: "Call me at xxx-xxx-xxxx when you are an hour out on I-10 from Conroe to get the current rally point." Then you hear later: "I'm an hour out, called xxx-xxx-xxxx number as instructed, and it's been busy for the last 15 minutes, what else can I do to find the current rally point?"

* Most useful feature of Zello: historical recording of every single transmission while you were listening. This let people go through them and follow up on water rescue requests, then mark them safe if they were rescued. This was a big problem at first: rescuers were pulling up a map on the web app, rushing to a request, then getting disappointed when they find out the rescue request was long since taken care of by another rescuer. Zello could improve on this: the historical recording was only for the duration you were listening; a feature (even paid) that pulled last N minutes/hours from their servers would be even better. Even better is a solution that tracks a rescuer to a rescue request, then presents a simple confirmation screen (# of adults, elderly, children, disabled, babies, pets rescued, any variation from pre-arranged drop-off point, any voice notes required), and auto-marks a request.

* Need a solution that maps water conditions at a specific location, ideally with tagged input of submitter, time, audio/picture/video, and NMEA data. At one point, the flat-bottomed boats were having a lot of trouble navigating choppy waters as Harvey came back in and churned up the flooded areas. Fold in with weather data, and predictively age out the conditions if possible, displaying that the computer model thinks conditions might be so-and-so but be careful because it could still be the reported condition, until another submission confirms calmer conditions.

* People REALLY love to help. But if their efforts go unappreciated, or go to waste (about the same as unappreciated), they will get dejected very quickly. This is why precise, comprehensive coordination is so critical to manage.

* There was initial concern about fake rescuers. This concern should not be dismissed, but as far as we could tell, this didn't happen.

* Need a solution that maps shelter facilities / government resources as they come online, capacity, and current utilization, so rescuers can efficiently forward rescuees to the best available facilities, most of whom are somewhat in a state of shock. Many shelter facilities early on were just school gyms, churches/temples/mosques, warehouses, and retail stores.

* A large number of private helicopters volunteered early. Knowing the most urgently medical-critical requests to prioritize was all manually performed.

* I suspect that the ad hoc, thrown-together approach of apps to coordinate the rescues is close to their scalability limit. About 10K rescues were logged, in round numbers. I don't think the same approach will work beyond 3-50K rescues, because bottlenecks were becoming apparent to me even with what we had.

* Best part of Internet-enabled rescue coordination: anyone now has a choice to actively participate in the rescue no matter where in the world they are. That's incredibly powerful and a game-changer.

That's all I have off the top of my head.

All in all, I'm quite impressed how well this went, despite the difficulties and setbacks I saw, and it shows some of the best humanity has to offer. There are some really interesting, deep CS and software engineering problems to solve in disaster response management and coordination.

Special shame to Joel Osteen: after his weak response compared to the area churches and mosques with far less funds who threw their doors open within the first hours after Harvey hit, he should be ostracized, as if "prosperity ministry" wasn't bad enough on its own. Didn't know who this bloke was before Harvey, other than "some guy who runs a megachurch", but after reading the news stories, I can't believe he convinces so many parishioners into following him.