Modular code is the priority

It’s been a while since I last wrote about my startup, Zenc Labs. My previous article “Learning to fail” outlined my initial forays into the wild world of startups. It wasn’t a conclusive experiment yet.

A brief summary in case you’re joining halfway

I was a software engineer at Google, and I decided to embark on a startup adventure.

My goal? Build innovative development tools to improve the way we write code and help my fellow developers become more productive.

It’s a topic I’ve been passionate about for a long time. I spent a major chunk of my time at Google refactoring and cleaning up code, but I wanted to have a wider impact. Google already has top-of-the-field engineering practices and benefits from extremely powerful internal tools (some of which have since been open-sourced, like Bazel). I wanted to see what the outside world was like, and unlearn the Google “tech bubble” bias.

In late March 2017, I started exploring by building a ton of different prototypes. It was a great learning experience as each prototype shaped the way I thought about one or several aspects of the programming process. After a couple of months (and a yoga teacher training), I had an idea for a revolutionary product that would change the world. I spent three months building it, before realising that it wasn’t the right tool: even I didn’t want to use it for my own work.

I then tried building another two products (Deploy and AppMaker), which didn’t work out either. In both cases, while forcing myself to build something more concrete and specific, I lost the passion that came with solving a big problem: fixing programming at a larger scale.

What happened since December

In 2018, I decided to expose myself to real-world challenges for inspiration. I started offering consulting services (e.g. reviewing an entire codebase for non-tech startup founders) and later joined a development agency part-time.

It had a tremendous impact on my motivation. For example, I experienced first-hand the pain of exploring and commenting an unfamiliar codebase while reviewing a large app with 150,000+ LOC. I decided to scratch that itch by building a code review tool (alpha here). Because I have a concrete reason to use my own tool, unlike the previous products I had built, my motivation to build and improve it is incomparably high even while I’m its only user.

Joining a development agency also brought about a ton of inspiration, as I could see pain points in my own work and hear other developers complaining about them.

The master plan

I no longer feel pressured to make Zenc Labs a successful million-dollar startup. Instead, it’s become a long-term, part-time research project to improve the way we write code. Open-source is a priority, and while there may be future opportunities to earn money and build up a development team, it doesn’t have to happen right away.

Here’s the plan.

Part 1: Modularity

Humans aren’t very good at handling complexity. We can only think about a handful of things at a time, or less. Programmers are no different. That’s why modularity is so powerful: by hiding away large chunks of code into modules with a clear API, we can simplify our own thought process and take our code to the next level. While a common trend nowadays is to use a “microservices architecture”, the underlying benefit often comes from modularising code and isolating it behind well-designed APIs, and not necessarily from splitting it up into separate servers.

Microservices or not, most codebases become increasingly complex as they grow. A codebase corresponds to a folder, and as much effort as you expand into organising it well and refactoring code, it will become large. There are generally a few layers of abstraction in a single codebase (e.g. SQL -> ORM -> Controller -> HTTP endpoint). There’s usually also a number of separate end-user features in the same codebase. It wouldn’t make sense to start a new codebase for every new feature you add to your project.

In the current software engineering world, large codebases are the norm. Each codebase has its own build and test configuration, a set of conventions, and it corresponds to a single repository (or a single directory in a monorepo). When the codebase represents a server, it conveniently describes a set of HTTP endpoints that will be accessible on the same host. But is this actually the best way to structure code?

Experienced developers keep a “map” of the codebase in their brain that helps them navigate it and maintain its structure. Wouldn’t it be nice to make it more explicit? What if we were not constrained by considerations such as build systems and folder structure? What if we worked on small independent modules, and the structure of the codebase automatically adapted around it instead of the other way around?

Part 1 of the roadmap is about helping developers think modularly:

1. Make it easier to define APIs and write API-centric code (like this)
2. Separate build and test configuration from actual code so that splitting up a project is no longer a major hurdle (like create-react-app)
3. Encourage writing code in small “black boxes” with clear, easy API testing regardless of the implementation language
4. Leverage the universality of APIs to gradually eliminate programming language barriers
5. Invent more flexible ways of storing code than fixed folder structures to eliminate the limitations of current codebases

Part 2: Visualisation and Interactivity

Another aspect of programming that is in serious need of innovation is the way we write the code itself, in text editors or IDEs.

I’d invite you to watch Bret Victor’s excellent talk to understand exactly what we’re missing out on:

youtube:https://www.youtube.com/embed/PUv66718DII

Some of it looks magical, but it doesn’t need to be. We just need to build it.

Unfortunately, the complexity of most current codebases makes it hard to build a delightful coding environment. This is why modularity comes first: once developers start working on small modules instead of large codebases, it should become much easier for development tools to understand exactly what you are building and provide the right kind of environment for the job.

Part 2 is about rethinking how code is written, read and experienced. We don’t have to wait for part 1 to be over. I plan to start with better ways of visualising code (an early prototype) but there are so many different ideas worth exploring. Code doesn’t have to be ugly or confusing.

This is the plan for the next few years. I’m always keen to hear people’s thoughts, so shoot me an email with your thoughts and ideas at f@zenc.io. If you’re in Sydney, I’m always keen for a coffee.