Opening the codebase up to everyone
My hidden workforce of non-programmer programmers.
One of our core beliefs at Tanda is that the barrier to entry for writing some code and shipping it should be low. Anyone in the company should feel welcome to give it a try, as long as they’re willing to do the work.
This beliefs stems from personal experience. I started Tanda when I was 21 and at uni. I wrote a lot of crappy code and made a lot of mistakes, but got enough things right that we were able to grow it into a business that employs hundreds of people and ensures hundreds of thousands get paid correctly. This experience drowned me in hubris (hence this blog), but it also made me think that other people without much experience could probably figure things out too.
The most obvious way we expressed this view was by hiring lots of university graduates and giving them outsized responsibility. “Experts” in high growth tech will tell you that you should only ever made senior/experienced hires, so that you can just focus on scale. Leave the training to someone else and de-risk your hires.1 At first we resisted this advice because we couldn’t afford it; these days we hire some seniors, but more juniors, because from day 1 our company’s existence is a contradiction of that advice.
Anyway. Hiring young people is not something we pioneered. An experiment I’ve found even more interesting over the years is opening up the codebase to everyone. What does this mean?
Anyone at the company who can make a Github account will get added to our repos.
Anyone at the company who wants help setting up their codebase will get that help (via the same docs/assistance that programmers get on their first day).
Anyone at the company who can make a pull request will get that PR reviewed.
This policy has created a lot of extra work, headaches, and overhead for more senior programers that have to support it. By my best estimate, less than 2% of our code is written by non-programmer programmers. Despite all this, I’m very glad we did it.
How it started
Our first full time hire, Adam, was a mate of mine from high school. He was grinding out a maths degree when he started, and had seen code a few times but was definitely not a programmer. He started off doing some projects, then went full time as our first Customer Success person. The company at the time was something like 6 or 7 people, and I was the only programmer. The product changed all the time and there were plenty of bugs. At least once a day, Adam would find an issue that he couldn’t fix through the UI, and the easiest way for me to fix it was to open the Rails production console and fix the data directly (and hopefully fix the bug later). Because I was a professional engineer with high standards of quality, Adam would look over my shoulder while I deleted duplicate records or whatever else was needed to fix his issue.
One day I noticed that rather than sending me links to problems, Adam was also trying to write the code needed to fix them. He didn’t really know Rails, or Ruby, but that was fine. Most of the fixes were finding some object in the database by its ID, and then destroying it. Generally you could find the ID by looking at the URL or viewing page source, and the rest you could just guess.
As Adam grew in his role I encouraged him to learn more Rails than just destroy!, and set him up with the codebase. This enabled him to debug things that couldn’t be worked out from the URL. Eventually I stopped needing to fix his scripts before running them, and I got tired of just copy and pasting them, so I gave him production console access too. This made my job a fair bit simpler.
One day he started making pull requests and tagging me in them.2 This was a bit of a surprise, until I reflected on it. I didn’t learn about pull requests at uni, and most of the programming I knew came from teaching myself or learning on the job. Of course the same would apply to anyone else.
How it’s going
I could write a long list of things built by people who were not professional programmers. Here’s some highlights:
Several account managers taught themselves SQL, and use it to build ad-hoc reports and dashboards in Metabase. We built a feature enabling them to embed these in the product so they can improve the in-product experience for their customers.
An implementation team member built several Single Sign On integrations with platforms like Azure, because he found it easier to build it himself then go back and forth between the customer and the developers (particularly when there were long wait times on the customer side that didn’t fit neatly into dev cycles).3
Salespeople have learned how to build and connect our API to others via Zapier or Retool. This made it easy to build simple proof of concepts, which sometimes turned into fully fledged features. Once a salesperson built an entire feature on top of Zapier, and once we were totally confident in the business logic (and had a few customers use it), we rebuilt it inside the product.
A former lawyer learned enough Ruby to contribute bug fixes to our legal compliance product. He was able to combine huge domain expertise with just enough coding knowledge to be very effective. The most interesting thing (in my opinion) was how much easier collaboration became once the subject matter expert could read and write unit tests.
There’s lots of other examples.
In 2023, 53 people have contributed code to our repo. 5 of those I’d categorise as non-programmer programmers. So it’s not like we’re drowning in them, particularly as they write less code than dedicated programmers do. We’re talking about a lot less than 5% of the code written.
What I’ve learned
If you told me 10 years ago that it would be a good idea to let anyone write code and send it to me for review, my knee jerk reaction would have been that this would create lots of extra work for me. That’s certainly true. But over time I’ve come to learn there’s many interesting benefits.
It’s tempting to assume the non-programmer programmers would work on trivial things, or try to contribute to core projects or features (but slow them down). In my experience they tend to be great at finding areas that are under-resourced, and becoming experts at them. As long as these things actually matter and are worth working on, this is a great outcome.
This is not surprising when you consider how they prioritise things, which tends to come directly from customer interaction. The typical flow of “customer feedback —> product manager things —> developers working on the problem” is shrunk down. Now, all within one brain, the customer feedback comes in, and the code comes out.
Where non-programer programmers really struggle is three areas:
Code quality
Architecture
Going too deep
Code quality is the easiest to deal with. Non-programmer programmers don’t care about lint rules or type checking, they just want to build something that is going to get merged. This can be annoying when their code is hideous (which is why you want good lint rules), but it’s also a breath of fresh air once they find their feet, as they tend to be very easy to work with as long as it moves their PR forward. Just hold their work to the same standard you would hold any other junior, and don’t feel bad about being strict.
By architecture I sort of mean code quality too, but it’s made trickier by a special combination of inexperience and enthusiasm.
I’m not sure why, but non-programmer programmers tend to hone in on relatively complex product areas; complex because they have lots of business logic, or because they are technically challenging. These are the areas where brute forcing a solution is least likely to be a good idea. Yes, it works for this very specific set of test steps. But does it work at scale? For every customer?
Experienced programmers can struggle to answer these questions, but at least they know how to ask them. When mentoring non-programmers you need to ask the question for them. This can feel like you’re slowing them down, particularly when you can’t articulate why. “I can’t put my finger on why, but my gut says this isn’t a good idea” is not satisfying for anyone, but sometimes you just have to say it.
This is amplified by going too deep. Non-programmer programmers tend to find a niche that they can really specialise in, and then they become subject matter experts in it. This is great for a while; finally someone can fix all the annoying known issues in that space that have been lingering for a while. But without discipline, it can quickly lead to building things because you can, not because you should. If something is only getting done because someone that "isn’t a dev resource” wants to work on it, then that’s a sign that it shouldn’t be getting done.
In short: by inviting non-programmer programmers to contribute to your codebase, you trade great prioritisation and a direct translation of customer needs into code, for lower quality code and over-enthusiasm on things that might not matter. If managed well it can work great, but it does need fairly regular supervision.
How to get started
My “how it started” story about Adam wasn’t a once off. I’ve never successfully told someone to go and learn to code and start making PRs. But plenty of times the PRs have appeared on my doorstep.
If you have smart, self motivated people in customer-facing roles, you can turn them into non-programmer programmers by opening the door just a crack. Add them to Github and let them browse around. Don’t expect everyone to take to it - most folks will (correctly) point out that the devs will make the changes they want much faster than they ever could.
But occasionally someone will take the bait, and if you help them just a little it can work out really nicely.
At time of writing, he’s shipped 747 PRs.
This same guy became the CTO of his own startup a few years later. He didn’t code when he started with us.
Interesting approach. I often pair tech and non-tech to enhance business cross-functional understanding, but this is an extreme version. It sounds scary at first thought but need to ready it again and let it digest/ferment, certainly interesting.