The lab folder

I've probably already written about this somewhere though I don't think it was on the blog so we're adding it here now.

The post is based on my workflow of how things end up in git and also kinda prove the level of dumbness that I'm at.


I'm a do first, thing later kinda guy and this shows almost everywhere and most of the work you see has gone through a filtration stage ( might not believe it since hardly anything I write is useful)


The first step in my not so organized life is to take this tiny little idea down somewhere, which is mostly the iOS notes app since that's what is around me almost always, either on the mac while I'm working or on the iPad later when I'm watching something to chill

These ideas fill up a folder in the notes app and stay there till I choose to go through them again.

Tooling and Packages

The tools and packages on the other hand go into an existing project that I'm working on and are built as a part of that project first. Then they are moved out into a package if I feel like it's something that devs might need at some point.


Don't let it fool you but there's no actual structure in here, it's literally just pickup whatever and do whatever thing. The 2nd stage is basically writing down the code for whatever the idea was.

There's not much difference here since both these things go into the lab folder.

lab folder?

Being an impulsive guy, it's really easy to try to do everything at once and the probability of messing up things with this is quite high. I can't change my nature but I can work with it.

For a smarter person this could be easily solved by changing workflows to be very focused but I'd like to avoid that restrictive workflow, this got me to the whole approach that we are going to be talking about.

Everything goes first to the lab folder, which is a simple folder that's named lab nothing else, it doesn't have special scripts (it does have scripts, they aren't really special though). This folder just represents being a dump of ideas, a place of experiment and no restriction, and I can fill it up with whatever on earth I want, since it never goes public.

If you thought that "reaper has 256+ git repos and only 4 usable tools", trust me, I could've made 1000's and chose not too (I could've have hogged up github's storage if I wished too)

The scripts here are basically a bash script that allow you to select the kind of project I wish to start, the script itself gets updated every time I pick up a new language so it handles the steps to create a new project. There's no templates, no specific method, just a bash script that goes through multiple commands that I'd write in the shell.

example, here's what the script looks like

#!/usr/bin/env bash

set -euxo pipefail

mkdir -p $1
cd $1
go mod init "$1"
touch main.go
echo "package main" > main.go
nvim .

This would do the following in order of the commands

  1. use bash
  2. set the script to fail on first error and the commands that are being executed and fail on unset variables
  3. make a directory of the input name ex: ./create/ commitlog would create a directory for commitlog
  4. change into the directory
  5. initialize a go module
  6. safe create a file to avoid overriding if the file already exists
  7. echo the base package line into the file
  8. open the editor of choice (might change as I change editors)

The JS is a similar one, it doesn't setup tooling or anything else, it just sets up the main index file that the code will go into since before it even becomes a package, it's supposed to be functional.

Also, I've gone through various packaging methods over the years for nodejs packages to learn about the shortcomings of each and so I spend more time writing the package scripts and tool configurations than I spend writing the actual package (which, isn't a good thing but it's fun)

Publish / Deploy / Push

Before anything is pushed, the idea is filtered out (yes, after doing it), reason being that there's stuff that people could write themselves in very small lines of code and that'd be a waste to be added into a package.

2nd, more often than not, someone's already built a much better and more robust solution to it and has been spending time maintaining it, me making a useless version of it and throwing it out there doesn't make sense. It's still advantageous to do since I learned how the core logic of that implementation works but that doesn't mean I have to post it out there.

A good example would be the toyvm I wrote, while it's public, the sole reason for writing it was to learn, the reason it's on github is because that's something I'd like to refer to later on and since I work with multiple devices having that reference on all devices makes it rather convenient.

8/10 times that's the reason the experimental project is up there.

Next up, once the prototype is ready, the way of working changes a bit based on the project.

  1. A pure client side webapp get's dummy deployed using vercel's CLI, checked and then permanently deployed by linking it to the git repo
  2. A server and client side webapp gets pushed onto a compute instance (Digital Ocean, AWS, etc) using docker's remote context
  3. A npm package get's a CD script to publish to the registry
  4. A go package just get's pushed with a tag (the simplest god damn flow!)
  5. A go binary get's CI/CD to build the releases on tags and then I spend the next 1 hour figuring out why a certain OS + Arch combo doesn't work for that specific binary.

code folder

Once the above is done and I've pushed to a remote git server (github, personal server, etc etc etc) , the project from the lab folder is deleted and a fresh clone from the git server is taken into the code folder (when I decide to polish the app or improve it) till then, there's no record of that project on disk.

This is done for 2 reasons, a cluttered code folder makes it hard to find projects that are similarly named and hog up space and node_modules is not a joke! (just kidding, i use pnpm)

But, to be honest, as long as the clutter is away it does help to get to code quicker and the code folder normally also has projects that i'm contributing to, so the folder does have quite a few projects when combined with my projects.


Unless you're like me, there's a good chance that your working on just 1 or 2 project and you might pick up the polishing phase a lot quicker than I do.

But, more often than not, your project has probably reached this state

This is where you might spend time on polishing it, though I rarely do it unless I've been using the app/tool/package quite a lot. examples would be

These are my primary tools and the one's which are updated over time significantly.

  1. commitlog has a whole new CLI
  2. conch got a perf boost
  3. mark got a UI Revamp and usability improvement
  4. migrated the whole thing to a proper database and improved the API's being used.

If I sit down to improve everything I've ever written, trust me, I won't have time to sleep (not that I can sleep for more than 4 hours).

anyway, this is basically how having a separate dump of ideas helps an impulsive monkey like me

And that's about it for the post, Adios!