This is why I truly love support-driven development.
While it’s possible to prioritize problems that don’t affect most people (squeaky wheels) it’s a hell of a lot more effective than most of the methods I know to have a very low barrier to contacting you for users, and fixing the things that come up.
GetCalFresh.org. Way easier way to apply for food stamps. Felt good to have left after 6 years going from helping 1 person get help to over a million. Still going strong.
Also lots of strangler pattern iterations! That was fun.
I'm really sorry you're dealing with this. I'm going to mostly share info about public benefits in case it's helpful, just because that's what I know (and I don't have as much knowledge about some of your other questions.)
What state are you in? I know you mentioned SSDI, but just to relieve some of the stress of getting by, you should try to apply for as many public benefits as you might be eligible for (SNAP/food assistance, Medicaid [medical care], affordable connectivity program [internet], Lifeline [phone.]) With little or no income, you should get some decent support from these programs.
For getting disability support (SSDI, or SSI), you might consider getting a lawyer. You're right it can take a long time to get this, but odds go up if you have a lawyer helping you. You can also contact your local legal aid which you may qualify for based on income.
In terms of jobs I'll do some thinking and see if I can post more. Are there any activities that you can definitely do without getting stuck due to your disability? There are definitely options for flexible computer work, and also things that are more phone-oriented.
I love my reMarkable — got the 1.0 once the price dropped due to 2.0.
e-Ink is a blessing after so much time on screens, and the rudiments make it quite hackable. So I get a device that pretty much CAN'T try to grab my attention, a calm device, and I can modify it to do more if I want.
(For example, since it can OCR and send notes, I've prototyped a little "message queue" on the other end to receive my notes, parse them ["TEXT Jake this is a text"], and do actions.)
I've even produced some custom e-ink maps which look great for no-phone navigation. (Feel free to let me know if that's interesting to you, happy to share an example and how.)
> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.
I think this is at the root of it — most web devs today don't see that some plurality or small majority of web app use cases these days just don't require the tradeoffs of SPAs.
But there's a generation of devs who've come up exclusively on JS tooling (Node, Express, React/Redux or Angular) and the crowding effect has therefore made those the default choices, if only because the labor pool is big.
My honest belief is you can more quickly build most functionality needed for most businesses with a plain-old full stack framework like Rails or Django these days.
But the real value of those frameworks doesn't show in the initial speed to build (though it's there!) — it really shows up in how much common functionality (logins, file uploads, etc.) you get for free 6-12 months in, and how low your cost of change stays over time as a comparable SPA app becomes a pain in the butt to add new features to.
There are a lot of people who have built this app — but they're concierging! (aka... not an app)
The reason is that the work you're describing (which is effectively organizing) doesn't have the unit economics of tech automation.
All of this info can be created but it's pretty hard for a computer to generate it because of the specifics of every project, across every different city/municipality.
Layer on top of that the fact that the biggest bottleneck is the activation energy it requires for people to actually show up, and an app is just less effective.
But you know what turns out to work shockingly well? A social aspect to organizing. Have everyone show up to the meeting, and go grab a drink after together to bond and make it so that folks feel good and want to do it again, that they feel a part of it.
I think the motivation behind this is right. In my experience many in Silicon Valley don't understand the mechanics of long-term institutional change. In part, that's simply because — much like entrepreneurship — expertise comes from practical experience. Tacit, not-easily-transferrable knowledge dominates.
I find Ezra Klein's recent line here useful:
"[W]hatever the recommendations, the same thing is needed: A sustained and concerted movement that cares about institutional reform. But people get much more excited about building something, anything, than about reforming existing institutions. Meta-building isn’t a popular pastime, and the patient, focused work it requires is particularly frustrating, in my experience, to entrepreneurial personalities." [1]
I confess that I myself find it incredibly frustrating. See a government program that's incredibly difficult to deal with, friction-laden up and down, with reams of paperwork with legalese?
One can build a layer on top that eliminates most or all of the friction. But it will always be limited by the resource models that can sustain it. And many problems simply have no workable models other than state financing and operation (market failure, in other words).
Instead, doing the work to make that program much better institutionally involves long-term (frustrating) strategies like:
- Think tanks / white papers: influencing the epistemic landscape among policymakers
- Organizing: shifting the Overton Window to make the change you want to see broadly accepted
- Coalition-building: working with allies with overlapping agendas to get more muscle behind your own priorities
And even... waiting. You often have to wait — years! decades! — for a window to come where you can get a big thing done. People worked on big healthcare reform for 3 decades of effectively zero progress — and then in a year they passed Obamacare.
That work is long, hard, much more probabilistic than product work, and much less directly-controllable by a given person.
BUT there are playbooks to get it done. And I do wish technologists looked to those tools more to make the institutional changes we need to make it so the opportunities (individual and societal) of entrepreneurship were more widely accessible.
One concrete example: I've long thought that a basic source of friction in public services is because user experience isn't well-monitored, and therefore not well-considered in public policy decisions.
Technologists are great at measuring friction. It is a craft well-honed in an environment where conversion is a live-or-die metric. But translating that craft into institutional change requires something like a think tank, and/or an organized movement with an agenda.
I think we'll get there, but it will take some risk-takers who understand that long game and financial backers who aren't as well-versed in it, but who have the risk tolerance of SV and the savvy to see that playbook does work, and point it at a problem with significant leverage.
I'm really sorry to hear that. It's unclear to me if you're in Costa Rica, but heads up if you're in the US your situation likely qualifies you for the new unemployment benefits (Pandemic Unemployment Assistance.)
The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building.
The way I think about it is that you're giving weights to one of two different goals:
1. Building the right thing
2. Building the thing right
I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals.
The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn.
I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.
> Here, I propose Scott’s Law: never put order in a system before you understand the structure underneath its chaos.
James C. Scott wouldn't probably never underwrite re-ordering of systems from the top down.
Central to his argument is that viewing complex systems from any singular position requires a process of simplification (legibility) that prevents a complete understanding.
The presumption that one has gotten to a place of "understand[ing] the structure underneath [the] chaos" is in fact the false confidence he attributes to most of these ordering projects.
I think if you want to wrangle a suggestion from Scott's book, it's more about making lots of small pokes at a system and seeing how it reacts, and slowly building on positive reactions from the system.
(Also, messiness and complexity are not intrinsically linked to the efficiency of a system — systems can optimize for lots of variables and it's really context-specific. So as much as you shouldn't take order to be innately good, don't take messy to be innately efficient!)
Moralizing the incentives of politicians while framing business leaders' behavior as rational responses to their incentives somewhat betrays a lack of sophistication of thinking here.