Hi, we’re JP and Sam, we work as software engineers at the Centre for Effective Altruism (CEA). We’re answering questions about our work on some of the projects many EAs use every day (including this Forum, Giving What We Can, EA Funds, and a bunch of other behind the scenes stuff).
Also, CEA and GWWC are both hiring software engineers, so it’s a good opportunity to ask questions about what it’s like to work here before you apply!
We’ll be answering questions on Tuesday, March 16th.
CEA and GWWC are both hiring software engineers. We build and maintain the tech that any new engineers will be working with (including this Forum), and we know what it’s like to work here. AMA!
JP previously worked at an aerospace startup detecting methane emissions with spectrometers on airplanes. He’s interested in table tennis, plants and economics.
Sam started at GWWC back in 2015, then built EA Funds from the ground up over the course of a few months while CEA was in Y Combinator. He has a past life in party politics.
Ask us about:
- Working on a small team
- Non-profit vs startups
- Our tech stacks
- Anything!
NB: EA Funds is now largely an independent org, so Sam will generally be talking about what it was like working at CEA until very recently. However we still work closely together because we make a good team and are working on very related projects.
Bonus: Although Ben West is no longer primarily an engineer, he built a popular healthcare analytics platform and founded a successful startup. He’ll be managing the new CEA engineer. You can also ask him anything.
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.