Developers love to code. Most of us would rather spend time coding or learning about code than do anything else. I am no different. As a beginner web developer, whenever I start a side project, I dove straight into code. After doing this for a while, I realized that I'm going about it wrong.
What I was missing was the preparation before the coding. Once I started doing that properly, I realized I'm saving more time and being more productive than if I started to code right away.
There are other fields where experts do this kind of preparation. Chefs spend a lot of time doing what's called Mise en place. It's the act of preparing the ingredients and placing them in a way that provides easy access while they're cooking. A similar technique is used by LEGO builders called Knolling. It's the act of putting all the LEGO pieces at right angles in the table so the different kinds of pieces can be seen all at once. This takes time but it's much more efficient when building a complex LEGO structure. In this article, I break down my process of doing the preparation, what Harry Wolff lovingly calls, the Metawork.
What is Metawork?
Metawork is the work you do before you do the actual work. It's the work that dictates how to do the work. In our case, it's the act of writing down what we'll be coding, deciding on the scope of our project and its features, and figuring out the basic interactions in the UI.
Why do the Metawork?
It saves us time. A lot of time. When we dive straight into coding, we're flying blind. We're making things up as we go. This usually results in a lot of work and rework because we will realize halfway through the project that some of the decisions we made were wrong and have to be changed. It's much better to make those decisions before we start coding.
Metawork also makes us productive. Instead of figuring out minor details, we're spending time, solving the problems that we care about, you know the reason why we started working on the project.
Rules for doing Metawork
In Shape Up, Ryan Singer the Product Manager at Basecamp talks about how Basecamp does metawork. In the book, they explain the properties of shaped work (or metawork). You can read the book online for free or download the PDF for offline reading from the Shape Up web page. Here's the watered-down version:
- Metawork is rough: It's unfinished and they don't figure out all the details. Too many details and the developers are just implementing a spec with no room for creativity. And that is not fun. Too few details then you're flying blind and it causes scope creep. Striking a middle ground is optimal but takes practice. So don't be afraid to experiment with the preparation.
- Despite being rough, metawork is solved: The main elements of the projects are thought through. Let's say you're building the next Twitter. What are the main components? A place to write, user profile, user connections (following and followers), and the feed. Next figure out how they connect. How does data flow between the components? Once you know the main elements, it's easier to break them down into smaller tasks and start working.
- Metawork is time/energy bound: Metawork also decides what not to do. When working on side projects, without knowing what not to work on, it's easy to work on something that won't move the project forward. Like, do you really need a dark mode option at launch? Can you get away with not having a settings page? These are auxiliary features and you can usually do without building them. Deciding what not to do, what not to spend energy on, and setting a deadline goes a long way in increasing our productivity. While this sounds great in theory, it doesn't always work out perfectly in practice. More often than not, we'll realize halfway that the scope we decided on is still too much to meet the deadline. So keep the scope variable and don't be afraid to reduce it.
The full book is a fascinating read and is filled with useful, practical information and guidelines for how to put it into practice. I urge you to read it, especially if you're working in a team. Even if you're working on your own, there are ways to implement it for your projects.
How I do the Metawork
Whenever I get an idea, I note it down on Notion. I create a page and write down the idea, how I got the idea, what I have in mind for the project and what features I think it should have. This step is crucial because inspiration strikes us at random times. When that happens it's beneficial for our future selves to offload that data into a long-term medium.
When I decide to work on an idea, I'm not starting from scratch. Instead, I have an existing set of notes that will remind me what I was thinking of when I wrote the idea down. This is where I start the metawork.
I create a few empty toggles (/toggle command in Notion which will create accordions). It usually follows this structure:
- Features
- Feature 1
- Feature 2
- Feature 3
and so on. Under Features, I list down all the features that I would like to see in the project. These could be things I will work on right away or things I will work on in the future. Next, I choose 3 to 5 features and use a separate toggle for each. These features are the main elements of the project. Inside each toggle, I write down some more details of the feature. I include things like what the UI will look like, any interaction I'd like to remember when I build and create a scope for what to stick to, and what to ignore for now. The last part is crucial and will allow me to set a deadline that I can meet.
After doing this, I do rough sketches in a notebook or head over to Figma for creating high-fidelity mockups. I have several UI kits that I've downloaded from the web and a couple that I purchased. These UI kits give me a starting point so I'm not creating atomic components from scratch. I quickly mockup a few screens to make sure I'm not missing anything.
Now it's time to break down each feature into smaller, manageable tasks. I use Linear for project management but anything you're comfortable with is fine. I create a project, then create tasks and subtasks, tag them, and set deadlines for each task.
Once that is done, I switch to the terminal, create a Next.js project and start coding. To make things easier, I've created a Next.js application starter called Sparter. It comes with all the configurations I usually do when I start a new project. It includes things like TypeScript, Chakra UI, ESLint, Prettier, pre-commit hooks, Google Analytics, Sentry error tracking, and Prisma ORM. I'm also working on adding NextAuth, Stripe subscriptions, transactional emails, and file uploads (all of which will be available sometime next week).
Hope this was useful. These are things I learned over time, by working with developers, designers, and marketers, and by building plenty of projects for internal hackathons and on my own.