SamDeere

Co-founder / Head of Tech, Effective Altruism Funds

Wiki Contributions

Comments

A Comparison of Donor-Advised Fund Providers

DAFs do make it much easier to donate appreciated stock, and this is good advice. However, if you want to make a donation of appreciated assests and you aren't able to set up a DAF, EA Funds accepts donations of stock (in the US) and cryptocurrency (US, UK, and NL) for donations of more than $1000 (no promises that you won't have to send a fax to your broker if you want to donate stock, but in general that hasn't been the case for most of our donors who are donating from Vanguard etc).

AMA: JP Addison and Sam Deere on software engineering at CEA

For EA Funds this is something that we’re planning to do very soon. It’s something that’s always on the backburner (as shipping features always tends to take priority), but now that there’s a new website that has much better global control of component styling, this is something where I think we can get some easy wins.

AMA: JP Addison and Sam Deere on software engineering at CEA

Not really (we’ve sporadically used Personas in the past, but not very systematically), but I’ve actually just been doing more reading on this. I expect that (at least for EA Funds) Jobs-to-Be-Done will be a big part of our user research project going forward.

AMA: JP Addison and Sam Deere on software engineering at CEA

TL;DR; – For Funds/GWWC, the frontends are React (via NextJS) running on Vercel (previously a React SPA running on Netlify). The backend is a bunch of Node.js microservices running on Heroku, connected to a Postgres DB (running on RDS), and wired together with RabbitMQ. We’ve migrated most things to TypeScript, but a lot of the backend is still JS. A lot of business logic is written in SQL/plpgSQL.

---

EA Funds and GWWC have been on the same platform since 2017, and share the same backend. 

The frontend was a pretty standard React SPA written in JavaScript, but we’re currently in the process of deprecating this for a NextJS app written in Typescript (which has been a huge win in terms of productivity). EA Funds has been ported (compare the new with the old) already, and the incoming GWWC developer will be working with me on porting the existing SPA functionality to the same NextJS-based system. The new sites are in a Git monorepo managed with Yarn Workspaces, meaning that eventually all EA Funds + CEA sites will be able to share components/login architecture/backend connections etc.

Down the React rabbithole a bit: We connect to the backend using Apollo to manage GraphQL queries, we use Immer for immutable state management as needed (though we don’t use Redux or any other global state management). UI components are provided with Material-UI.

I used to use Netlify to host the EA Funds/GWWC frontend, but we’ve moved to Vercel for their first-class NextJS support.

The backend is a collection of quasi-microservices running on Heroku, all written as Node.js apps:

  • An Express web server that handles our GraphQL endpoint, as well as webhooks/callbacks for various integrations (e.g. Stripe payments). 
  • The GraphQL endpoint is provided by Postgraphile, which is essentially a way of generating a GraphQL schema by reflecting over our Postgres DB. This means that we get to leverage the data structure, foreign key relationships, and type safety of the existing database for free in GraphQL. This approach means that a lot of business logic (especially around user-facing CRUD and reporting) are written directly in SQL, implemented as views and functions.
  • The services are connected by a RabbitMQ message bus. Database events (e.g. “db.payment.updated”) and webhook calls (e.g. from payment processors) are pushed onto the RabbitMQ bus , so that other services can react to these events. So, if a user inserts a new payment, the Payments service can communicate with the appropriate payment processor, and when the payment status is updated as succeeded, the Emails service can send out a receipt.
  • The Postgres DB is hosted on Amazon RDS.

---

In addition to EA Funds/GWWC, I’ve also helped set up a bunch of other sites used by CEA (e.g. EffectiveAltruism.org, EAGlobal.org, CentreForEffectiveAltruism.org, the GivingWhatWeCan.org homepage). Most of these are currently using the Metalsmith static site generator, which generates static HTML files that are served via Netlify. This setup has been fantastic for performance and reliability, but eventually these sites will be ported over to the NextJS monorepo for better maintainability.

---

In terms of pain points, it’s generally been a pretty solid system. The biggest challenges have been maintenance. E.g. we’ve migrated to NextJS, partly for the improved performance and DX, but also because the previous SPA was running an outdated version of React, and because of the way the boilerplate I used was architected, upgrading to a more modern version (which many packages now require) was more trouble than it was worth. Similarly, all the static sites have historically been hosted in their own repositories, which has meant that they all have slightly different ways of doing things, and improvements made to one don’t propagate to the others. Hence, the move to a monorepo, where we can share components/logic between sites. Also, the more I use TypeScript, the more I hate using vanilla JS, so I guess that’s something of a pain point in the parts of the backend that haven’t been migrated yet!

AMA: JP Addison and Sam Deere on software engineering at CEA

We run a pretty lightweight version of Agile. We’ve tried doing more or less of the ‘canonical’ Agile/Scrum methodologies at various points, and settled on what we have because it works for us. Basically, JP and I have a weekly meeting where we set sprint goals, broken down by number of story points (where one story point = ~ half a day of productive dev work). These tasks are added to a kanban board that we update throughout the week as things progress. We do daily check-ins with each other, and with our respective managers, to discuss progress/challenges etc. We also do a couple of pair programming sessions each week.

Tasks are triaged based on discussion with our respective managers, taking into account what seems most important to do next (itself a combination of user feedback, outstanding bugs and feature improvements, org strategy, events in the world etc). We have a loose product roadmap that informs where we expect to be going over the next quarter and year, but we don’t make concrete plans for more than a quarter away.

We’ve iterated a lot on this over the past few years, and I think that we’ve found something that works well. I like that the system is lightweight, and strikes a good balance between giving sufficient direction for what to work on, while allowing for a lot of flexibility and not getting mired in process. It also forces us to make reasonable time estimates about what we’re doing, and these are sanity-checked by another dev, which helps avoid scope creep, or underspecified tasks. Regular check-ins make it easier to stay on track – I find it very motivating to be able to show someone else the cool thing I’ve been working on and get feedback. 

I think that as we grow we’ll probably need to systematise things more. At the moment, it relies on JP and I having worked together for a long time and being very comfortable with each others’ working styles. I could imagine that as we take on additional developers, or that as the projects we’re working on diverge more significantly (as I’m now focusing almost exclusively on EA Funds) that we’d need to make some changes, probably in the direction of more concrete progress reports through the week.

AMA: JP Addison and Sam Deere on software engineering at CEA

For EA Funds (and the pledge management parts of GWWC), that’s me. For the Forum it’s JP. We’re both devs first and foremost though, so we get a lot of input from other people (Aaron who manages the content side of the Forum, Luke Freeman who runs GWWC, Jonas who runs EA Funds, Ben West who manages the Forum team and who is a former tech  startup CEO etc)

AMA: JP Addison and Sam Deere on software engineering at CEA

I think the biggest challenges we face are related to capacity rather than specific skills. So, a really productive fullstack dev could have a huge impact just by virtue of helping us to ship things faster, and cover more surface area. 

That said, a few things that I think would be great to have more of:

  • Experience with analytics/measurement/telemetry and using the insights to drive development of new features or content
  • Exceptional UX/UI chops, to give sites a visual lift and ensure that user flows through our sites are really good
  • A dedicated product management skillset, conducting user research and using that to inform subsequent iterations of each product
AMA: JP Addison and Sam Deere on software engineering at CEA

I’ll first caveat by saying that I haven’t worked at either a typical startup or big tech company.

I think that there’s probably not a huge difference between CEA and a very early stage startup. I think that the most relevant dimension is just scale – currently we’re two devs working on a bunch of different projects, which means a high degree of autonomy and ownership over the code in a way that I expect is similar to a lot of small startups. We’re obviously a more mature org though, so we do have a lot of processes in place (CI, a dedicated Operations team etc) that you wouldn’t find at a really new startup. So, in some sense it’s the freedom and ownership of an early stage startup combined with the security and flexibility of an established org. It also means that there’s a lot of time spent on interacting with users (as opposed to just being siloed in your text editor), which I really like, partly because this is a great community and it’s really nice to talk to EAs who use your software, and partly because it helps you to get better at thinking about product development and making things that serve the needs of your constituency really well.

Another thing that’s a bit strange about CEA as a non-profit, and as an EA org, is that the approach to scaling is a bit different. In a for-profit startup, your aim is to grow as fast as humanly possible (at least, when you hit product-market fit). We’ve deliberately avoided that strategy (at least for now), in large part because it doesn’t seem prudent to scale something like the EA community as fast as possible, because scaling fast trades off pretty hard against the fidelity of your message and the existing culture of the community. This could obviously change in future, but historically it’s been part of our approach. This in turn means that the challenges are a lot about understanding how to build solid products that work for EAs, rather than how to run huge k8s deployments etc.

Why you should give to a donor lottery this Giving Season

The Centre for Effective Altruism UK (the legal entity behind EA Funds' UK operations) is registered in the Netherlands as a tax-deductible charity.

When you get to the payment page you can select which country you'd like to donate in. To donate in a way that's tax-deductible in the Netherlands, select 'UK/NL' as your country, and then optionally select EUR as your currency code. You can donate via credit card or SEPA transfer.

ETA: I've updated the relevant FAQ entry to make this clearer.

Why you should give to a donor lottery this Giving Season

Yeah, I think ‘never’ is correct for donor lottery winners thus far. I’d guess this situation would be pretty rare in practice (even as we run more lotteries), but we want people to be informed that there are some constraints. People have generally checked in with us beforehand if they’ve got something of an edge-case in mind, and the only times I can remember saying a hard ‘no’ were for partisan political organisations (which we can’t make grants to).

Load More