Software engineer working in philanthropy/crypto. Former co-founder / Head of Tech, Effective Altruism Funds
SamDeere
Karma: 1,151
Senior Full-stack Haskell Engineer @ Lantern Ventures
Location: London, UK, Flexible working (minimum 2 days a week from the office—fully remote can be considered)
Salary: £90k − 130k (depending on experience) + discretionary bonus
Hours: Full time
Contract type: Permanent with a 3 month probation period
Closing date: 30th of April 2024
Apply NowAbout Lantern Ventures:
Lantern Ventures is a London-based proprietary trading firm specialising in cryptocurrencies. We use technologies developed in-house to identify and execute on trading opportunities arising in cryptocurrency markets worldwide. Lantern Ventures is a strongly mission-driven organisation, donating 50% of firm profits to highly effective charities; applicants with an interest in this mission will be favourably considered.
Skills/Experience:
4+ years back-end experience using Haskell or a mix of Haskell and other FP languages professionally or open-source
2+ years front-end experience using React/Typescript
Proficiency with SQL strongly preferred
Experience working with heterogeneous time series data, especially financial data, is a plus
Experience with one cloud provider AWS/GCP/Azure, Infrastructure as code, Docker is a plus
Experience with Redis is a plus
Strong written and verbal communication skills in English required
Experience working in small teams in a startup-like environment and building and shipping products that are critical to business success is a plus (figuring out what is required, how to build it, how to fix it, iterate on it)
Four Ideas You Already Agree With
We do, although it looks like it’s not showing on the site. I’m just fixing the issue, will update when it’s there.
What’s the logic here? Expected value is the same in all cases right?
Yep, the expected value remains the same, it’s just a suggestion to encourage people make an entry that has a non-negligible chance of winning. As we say in the preceding sentence, there’s no minimum entry size, so if you want to enter with a very long shot, that’s entirely possible.
Can you share who the guarantor is this year?
As in previous years, the lottery is guaranteed by funds held at CEA on behalf of Carl Shulman.
Announcing EffectiveCrypto.org, powered by EA Funds
The 2021 EA Funds Donor Lottery is now open
We currently only require an email address to make deposits under $500k (so if you have an email address that doesn’t identify you then this would get you most of the way there). With larger donations we’d likely need to collect more information for KYC purposes.
The system as described above isn’t really set up to take deposits from smart contracts. The main issue is that EA Funds doesn’t take ‘unrestricted’ funding (as a normal charity would), and in order for us to allocate the donation correctly, we need a matching payment record from the donor (which you create when you go through the donation flow on the website) that tells us where the money should go. However, for one-off smart contract donations valued at >$10,000 we can probably work something out. Feel free to message crypto@effectivealtruism.org if you’d like to discuss further.
Donating crypto on EA Funds: more coins, low fees
Thanks for this writeup. I’d also add that EA Funds accepts cryptocurrency donations, is tax-deductible in the US (501[c][3]), the UK, and the Netherlands, and doesn’t charge additional fees (fees are just whatever our exchange charges us, which is typically on the order of 0. 2% or lower). Donations can be made to any of our four Funds, or to a list of ~40 supported effective non-profits.
At the moment you need to get in touch with us directly to make donations, we support ~20 coin types, and our minimum donation size is $1,000+ or equivalent. However, we’re planning to roll out a new system (integrated with the normal donation form on our website) that supports over 120 coins and will have much lower minimums in the next month or so.
(Disclosure: I’m a co-founder of EA Funds)
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).
EA Funds has appointed new fund managers
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.
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.
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!
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.
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)
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
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.
Thanks for this—both should be fixed