About a month ago, I was invited to contribute to a group looking to help Ukrainian refugees in Poland. The group consisted of volunteers, including some people from the rationalist community, who knew they wanted to help, and were searching for high impact ways to do so, likely through software. I had been intending to find a way to help Ukraine, so when this opportunity to use my programming background to help arose, I felt elated to finally be able to do something.′ I took two weeks off work the next morning (thank you, my employer, for letting me do that) and optimized my life to spend as many hours as I could on the project without harming myself.
The group consisted of some really amazing people. There were two students from the US, Soren and Luke, who had more or less dropped everything, sold their cars, and just moved to Poland to help. They were our eyes on the ground and the ones starting the project. My close friend, Leonardo, was the one who invited me, and he was the one who inspired me to take time off work by doing it himself first. And a lot of other brilliant people with very valuable contributions, who I won’t list to keep the cast small for the reader. Just know I’m very thankful for everyone who helped out.
We knew we wanted to help somehow, but we didn’t know how. We focused on looking for problems we could solve with software since the group had a high density of software people. Over the course of the first few days we went through a concept of tracking the movements of people through the country (dismissed because it would be a GDPR nightmare and also very abusable), a concept of assigning refugees entering the country to different destinations so not everyone ended up in Krakow (depended on a model of reality that was much too simplified, and also had problems with how to gather data to base algorithmic decisions on) and we finally arrived at a concept around a certain kind of buses.
Somehow I ended up in a leadership position along the way, a de facto product manager so to say, and I created the bus concept from something a volunteer hosting refugees in his office space had said. They had been in contact with a municipality from Norway who had space for refugees and was sending buses to directly transport refugees. This seemed to be a regular occurrence, where individual people, small aid organisations or municipalities were sending buses and cars to Poland. Then they would show up and nobody would want to get on, because no one knew they’d be there, what it’s like where they would be going or if they could be trusted.
So the concept was to create a website where the bus drivers could see a heatmap of where refugees willing to go to their country were and plan their trips after where there were too few buses compared to refugees. And the refugees (or rather, volunteers helping refugees) could sign up to add to the data set the heat map comes from, and then see which planned trips would be nearby, and then “follow” them for updates and mark interest for which ones they’d want to go with. Having access to contact information in advance would allow them to get an understanding of where the trip would be going, have time to look up the country, maybe see a “day in the life” video to understand what the country feels like and to some degree vet the bus driver in advance. By not addressing the things that worked, such as the trains, flights and regularly scheduled buses, and focusing on connecting small scale actors with other small scale actors that need each other, we wanted to make a difference at scale by enabling many small interactions.
After we’d worked on refining the concept from Wednesday to Saturday, as well as starting development and looking for more devs, I was put in contact with a senior product manager, Shira. She was kind enough to read through our concept docs and our source material and offer her feedback. I greatly appreciated the additional perspective, because it had been bugging me that no one had said that my obviously too large feature set was large yet. Soren and I chatted with Shira for a while and she more or less dismissed the entire project. Or well, not necessarily the project, but definitely the amount of verification of the concept we had done. Soren and Luke had certainly talked with a _lot_ of people at that point, but we would need more than the ~7 sources of corroborating evidence that supported the bus concept. There were a lot of large scale questions remaining:
* Did the buses occur in a relevant enough numbers where an information exchange service would help? * Would bus drivers actually want to use such a service? * Would volunteers on the refugee side actually want to go through the trouble of learning and using a service in the midst of the chaos of a refugee crisis? * While both sides would have an incentive to use the service after a critical mass of users appeared, how do you reach that critical mass? * Even if we’ve understood the world correctly right now, what ensures that the same problem will exist in two weeks/a month when we’re done with development and can launch? It’s a chaotic situation that changes quickly. * How could we counteract our service being misused for human trafficking? Could we make the percentage of trafficking cases smaller than without our services? And would possibly enabling more human trafficking to happen, even indirectly, be too big of a cost for the potential good? (On the other hand, would someone using our service for evil even be on our conscience, provided that we make it harder than it would be without our service?) * What legal implications would there be, especially considering it’s a service interacting with people in such a vulnerable position? * If our service would see mass adoption, what political implications would there be of encouraging relocation to other countries? * And finally, the blanket question of “is our model of the world correct and complete enough to suggest an intervention?”
Shira found it incorrect to start tentative development with so little verification of the concept, and I had no problems changing my mind to agree with her. We also realized we had no realistic chance of knowing the solution would help. In a way, it was freeing to not feel the weight of the world on our shoulders anymore. I had previously entertained the thought of “is us searching for a systemic solution actually higher value than just working for a week and giving our pay to a charity?” And after our talk, I put the project on the back-burner with the plan of letting the people on the ground collect more data, I ended my two week pause from work early, worked my day job the second week and donated the equivalent of that week’s pay to related charities.
I think the realization I had generalizes to my demographic: software developers that enthusiastically want to help, and are completely outside a situation. We see a problem from afar, think we understand it, and decide that software is the solution (hammer, meet nail). In cases where you can actually model the entire problem (from talking to the ten users you’re designing some company software for, like I have in the past, or through extensive research efforts) this works great, but when you jump to designing the solution too early in proportion to the complexity of the problem, you’ll create a great software that perfectly solves a problem, but where the problem doesn’t exist.
In crisis situations such as these, this is especially true, because crises are just _so large_. There are millions of people involved, so you just can’t model the entire crisis. We got blind trying to have a large impact that we sacrificed having an impact at all. Shira expanded on this.
Her model is that efficiency is for orderly things. These crises are chaos. Every day brings unforeseen challenges, and you can’t predict, plan and structure something that dynamic. Software is great at creating efficiency inside the box of what you design it for, but if the box always changes it can’t do much. The volunteers working on the ground will solve todays new challenges in the most inefficient way possible, because when you constantly need to think outside the box, _that’s the only way that’s available_. If we want to help, we need to help them do their constant improvisation, by either going down there ourselves or just giving them more resources, such as money.
In such a chaotic situation, any money you send will be inefficiently spent. Drivers going into war zones will charge a premium for the risk to their life. Shipments will be lost, funds will be skimmed. But even if the charity you pick only yields 1 euro of value from the 1000 you send, it’s still be better to send the money. Because the alternative is doing nothing. Anything that helps the volunteers save one more life or improves the life quality of the refugees a bit more has a bigger impact than nothing, anything that helps volunteers work through another day of the chaos will help.
Of course, crises need some software, but any software that actually helps is bound to solve a small enough problem, helping refugees do what they already do in a slightly better way. Shira is an example of this: she led a team creating software to help a group of volunteers transport refugees out of Ukraine. Scope of the project? A software to send a message to 20 WhatsApp users at once, instead of sending it to each user manually. Helped a small group do something they already were doing slightly better. There’s no time for paradigm shifts. Well, unless you have the information flow of a major NGO, in which case you shouldn’t be taking my advice. Go back to saving the world!
So in summary, if you’re a software developer and you want to help, don’t try to create a clever react app, do what I did. Continue working for money, and donate that money to a charity. Accept that nowhere near 100% of your money will reach the target, especially in the chaos of crises, and realize that 10% or even 1% of your money of an inefficient charity is drastically more than the 0% of you not giving. And as software developers on average have a high income, you can have a disproportionately high impact if you just give money.
If you want a concrete recommendation of where to direct your donations, Soren saw World Central Kitchen do good work on the ground. Providing food will always be needed and it’s politically uncomplicated, so that’s where I sent most of my donation. If you’re reading this later, after the Ukraine crisis is over, or would like a charity that’s independently evaluated to be effective, GiveWell does great work in that field. If analysis paralysis grips you, just give to their maximum impact fund, which they allocate to where it can do most good.
You can totally help charity with code. You just have to convert it into money first.
Crises Don’t Need Your Software
About a month ago, I was invited to contribute to a group looking to help Ukrainian refugees in Poland. The group consisted of volunteers, including some people from the rationalist community, who knew they wanted to help, and were searching for high impact ways to do so, likely through software. I had been intending to find a way to help Ukraine, so when this opportunity to use my programming background to help arose, I felt elated to finally be able to do something.′ I took two weeks off work the next morning (thank you, my employer, for letting me do that) and optimized my life to spend as many hours as I could on the project without harming myself.
The group consisted of some really amazing people. There were two students from the US, Soren and Luke, who had more or less dropped everything, sold their cars, and just moved to Poland to help. They were our eyes on the ground and the ones starting the project. My close friend, Leonardo, was the one who invited me, and he was the one who inspired me to take time off work by doing it himself first. And a lot of other brilliant people with very valuable contributions, who I won’t list to keep the cast small for the reader. Just know I’m very thankful for everyone who helped out.
We knew we wanted to help somehow, but we didn’t know how. We focused on looking for problems we could solve with software since the group had a high density of software people. Over the course of the first few days we went through a concept of tracking the movements of people through the country (dismissed because it would be a GDPR nightmare and also very abusable), a concept of assigning refugees entering the country to different destinations so not everyone ended up in Krakow (depended on a model of reality that was much too simplified, and also had problems with how to gather data to base algorithmic decisions on) and we finally arrived at a concept around a certain kind of buses.
Somehow I ended up in a leadership position along the way, a de facto product manager so to say, and I created the bus concept from something a volunteer hosting refugees in his office space had said. They had been in contact with a municipality from Norway who had space for refugees and was sending buses to directly transport refugees. This seemed to be a regular occurrence, where individual people, small aid organisations or municipalities were sending buses and cars to Poland. Then they would show up and nobody would want to get on, because no one knew they’d be there, what it’s like where they would be going or if they could be trusted.
So the concept was to create a website where the bus drivers could see a heatmap of where refugees willing to go to their country were and plan their trips after where there were too few buses compared to refugees. And the refugees (or rather, volunteers helping refugees) could sign up to add to the data set the heat map comes from, and then see which planned trips would be nearby, and then “follow” them for updates and mark interest for which ones they’d want to go with. Having access to contact information in advance would allow them to get an understanding of where the trip would be going, have time to look up the country, maybe see a “day in the life” video to understand what the country feels like and to some degree vet the bus driver in advance. By not addressing the things that worked, such as the trains, flights and regularly scheduled buses, and focusing on connecting small scale actors with other small scale actors that need each other, we wanted to make a difference at scale by enabling many small interactions.
After we’d worked on refining the concept from Wednesday to Saturday, as well as starting development and looking for more devs, I was put in contact with a senior product manager, Shira. She was kind enough to read through our concept docs and our source material and offer her feedback. I greatly appreciated the additional perspective, because it had been bugging me that no one had said that my obviously too large feature set was large yet. Soren and I chatted with Shira for a while and she more or less dismissed the entire project. Or well, not necessarily the project, but definitely the amount of verification of the concept we had done. Soren and Luke had certainly talked with a _lot_ of people at that point, but we would need more than the ~7 sources of corroborating evidence that supported the bus concept. There were a lot of large scale questions remaining:
* Did the buses occur in a relevant enough numbers where an information exchange service would help?
* Would bus drivers actually want to use such a service?
* Would volunteers on the refugee side actually want to go through the trouble of learning and using a service in the midst of the chaos of a refugee crisis?
* While both sides would have an incentive to use the service after a critical mass of users appeared, how do you reach that critical mass?
* Even if we’ve understood the world correctly right now, what ensures that the same problem will exist in two weeks/a month when we’re done with development and can launch? It’s a chaotic situation that changes quickly.
* How could we counteract our service being misused for human trafficking? Could we make the percentage of trafficking cases smaller than without our services? And would possibly enabling more human trafficking to happen, even indirectly, be too big of a cost for the potential good? (On the other hand, would someone using our service for evil even be on our conscience, provided that we make it harder than it would be without our service?)
* What legal implications would there be, especially considering it’s a service interacting with people in such a vulnerable position?
* If our service would see mass adoption, what political implications would there be of encouraging relocation to other countries?
* And finally, the blanket question of “is our model of the world correct and complete enough to suggest an intervention?”
Shira found it incorrect to start tentative development with so little verification of the concept, and I had no problems changing my mind to agree with her. We also realized we had no realistic chance of knowing the solution would help. In a way, it was freeing to not feel the weight of the world on our shoulders anymore. I had previously entertained the thought of “is us searching for a systemic solution actually higher value than just working for a week and giving our pay to a charity?” And after our talk, I put the project on the back-burner with the plan of letting the people on the ground collect more data, I ended my two week pause from work early, worked my day job the second week and donated the equivalent of that week’s pay to related charities.
I think the realization I had generalizes to my demographic: software developers that enthusiastically want to help, and are completely outside a situation. We see a problem from afar, think we understand it, and decide that software is the solution (hammer, meet nail). In cases where you can actually model the entire problem (from talking to the ten users you’re designing some company software for, like I have in the past, or through extensive research efforts) this works great, but when you jump to designing the solution too early in proportion to the complexity of the problem, you’ll create a great software that perfectly solves a problem, but where the problem doesn’t exist.
In crisis situations such as these, this is especially true, because crises are just _so large_. There are millions of people involved, so you just can’t model the entire crisis. We got blind trying to have a large impact that we sacrificed having an impact at all. Shira expanded on this.
Her model is that efficiency is for orderly things. These crises are chaos. Every day brings unforeseen challenges, and you can’t predict, plan and structure something that dynamic. Software is great at creating efficiency inside the box of what you design it for, but if the box always changes it can’t do much. The volunteers working on the ground will solve todays new challenges in the most inefficient way possible, because when you constantly need to think outside the box, _that’s the only way that’s available_. If we want to help, we need to help them do their constant improvisation, by either going down there ourselves or just giving them more resources, such as money.
In such a chaotic situation, any money you send will be inefficiently spent. Drivers going into war zones will charge a premium for the risk to their life. Shipments will be lost, funds will be skimmed. But even if the charity you pick only yields 1 euro of value from the 1000 you send, it’s still be better to send the money. Because the alternative is doing nothing. Anything that helps the volunteers save one more life or improves the life quality of the refugees a bit more has a bigger impact than nothing, anything that helps volunteers work through another day of the chaos will help.
Of course, crises need some software, but any software that actually helps is bound to solve a small enough problem, helping refugees do what they already do in a slightly better way. Shira is an example of this: she led a team creating software to help a group of volunteers transport refugees out of Ukraine. Scope of the project? A software to send a message to 20 WhatsApp users at once, instead of sending it to each user manually. Helped a small group do something they already were doing slightly better. There’s no time for paradigm shifts. Well, unless you have the information flow of a major NGO, in which case you shouldn’t be taking my advice. Go back to saving the world!
So in summary, if you’re a software developer and you want to help, don’t try to create a clever react app, do what I did. Continue working for money, and donate that money to a charity. Accept that nowhere near 100% of your money will reach the target, especially in the chaos of crises, and realize that 10% or even 1% of your money of an inefficient charity is drastically more than the 0% of you not giving. And as software developers on average have a high income, you can have a disproportionately high impact if you just give money.
If you want a concrete recommendation of where to direct your donations, Soren saw World Central Kitchen do good work on the ground. Providing food will always be needed and it’s politically uncomplicated, so that’s where I sent most of my donation. If you’re reading this later, after the Ukraine crisis is over, or would like a charity that’s independently evaluated to be effective, GiveWell does great work in that field. If analysis paralysis grips you, just give to their maximum impact fund, which they allocate to where it can do most good.
You can totally help charity with code. You just have to convert it into money first.