Git repositories are really good sources of truth. But right now the interfaces for working with them are almost exclusively designed for engineers.
A git repository is really just a folder—a collection of files. We think of them as places to store code, but that’s a limitation we impose, not of the technology. Files could be almost anything—structured data, narrative prose, photos, diagrams…
At Button School, we keep all of our learning materials, our internal tools, our website content, and our experiments in a monorepo. We aren’t unique in this: many companies keep documentation in their repo alongside their apps and services.
This means that the whole team, me, our learning designer, our product lead, and even our content advisor all work with our repo. Our content can be versioned, we use pull requests to review changes before we finalize them.
There are points of friction working this way: it means everyone has an IDE set up on their machines, which is not everyone’s natural working environment. It’s right there in the name Integrated Development Environment. We accept it because of all the other benefits we get from working this way.
Non-engineers are already coming into our repos, and there are only going to be more of them. The question of if they should is being answered on its own. We need to answer the question of what kind of tools they need.
Where are the content environments, design environments, management environments, product environments that can work with a local repository? What’s the amount of abstraction these kinds of environments should apply? How can environments shaped for these perspectives feel like a working homebase for non-engineers to work with git-based workflows, branches and worktrees and remotes and pull requests and all?
What will concepts like linting, package management, environment management, automated testing, project scaffolding look like for content, project management, design concepts, scenario and strategy planning, research ops?
How will these environments handle sensitive data that shouldn’t be committed to a repository? How can we make a seamless experience for pulling in data sources and media assets from outside of the repository without them having to set up Docker and environment variables? Can we?
As technologists, we’ve spent a ton of energy on developer experience (DX) for the past decade-plus. It’s time to expand that idea outside of this narrow idea that a developer is someone who writes code. Content, strategy, insights, planning, design, experiments: these are all developed as well. Let’s turn our attention to making what has traditionally been our home feel welcoming for everyone else involved in developing digital products.
The robots absolutely will not do this for us.
This project will take all of us in the same way DX has taken countless small side projects, long conversations, advocacy, standards governance, and education. I really hope we are up for the challenge.