How I make teams productive

Below are a couple of practices I implement to not only boost my own productivity & speed, but the speed of my team.

Some of them are oriented around getting new devs up to speed quickly, while others are meant for enhancing current team members.

1. Invest in your Dev Environment

For one of the projects I’ve worked on, Prayershub, it takes about a week to setup a dev environment. It integrates with AWS, Typesense, MariaDB, PHPMyAdmin, CPanel, CaddyServer, on top of several dev tools to hot-reload HTML and connect with the accompanying Flutter app.

One day, I finally decided to invest 2-3 weeks into making a predictable, versioned, reliable dev environment. And that investment has paid off very well for itself. To get a new dev onboard (whether they use Windows Or Ubuntu Linux) is as simple as:

1. Install Docker (or Docker Desktop on Windows)
2. Install VSCode (with Devcontainers plugin)
3. Clone repository
4. Copy .env.sample to .env
5. Run

I’ve even setup some integration to get a filtered copy of the production database and import straight through PHPMyAdmin. The entire thing is seamless and takes about an hour.

The Go app automatically starts up and connects with the Flutter app, no problem.

What used to take 3 weeks to setup 3-5 devices can now done reliably in 1 hour, with no loss to hot-reloading tools or performance at all.

I have it setup in several layers, each building on top of each other:

1. A docker/prod/Dockerfile with the necessary components for production (Typesense & FFmpeg)
2. A docker/dev/Dockerfile that builds on docker/prod/Dockerfile and installs all the dev tools for local development (Go, Templ CLI, Actiongraph, Make, etc)

3. A compose.yaml (which builds upon docker/dev/Dockerfile) for setting up environments (separate from tools).

   For example: MariaDB, Caddyserver, Apache (for PHPMyAdmin).

4. devcontainer/devcontainer.json (which builds upon compose.yaml) for setting up extensions for VSCode (and possibly others if the dev wishes to use something like Neovim)

1 is for production, #2 is for quick debugging or testing that don’t require the full IDE experience. #3 and #4 are for fully fledged IDE experiences.

2. Fast Feedback Loop

This refers to the amount of time between making a code change and observing the result. What this means and what can be considered “fast”, varies widely by context and industry.

For example, SvelteKit Hot Module Reloading works in the order of milliseconds. It’s so well optimized that you can make a change, and observe it in your browser (no need to refresh, either manually or automatically).

It does have some quirks to it (a lot in my experience), but for the most part it’s insanely productive compared to other solutions that require rebuilding the entire application to make a color change.

That doesn’t mean you have to throw out your current stack to make your iterative cycles faster though. There’s a couple things you can do across any language or stack to speed up development.

2.1: Decrease startup time

This is the amount of time it takes for the server to startup. You can do this by deferring as much work as possible for later. At Prayershub, startup time was around 5 seconds. This time would be spent downloading fonts, connecting to AWS, refreshing typesense, among others.

Simply deferring this tasks took the iterative cycle down from 5s to 0.4s. Of course, some are more difficult than others, and required new abstractions like Futures and such. Nevertheless, this was a worthwhile investment

2.2: Decrease compilation time

Decreasing compilation time for your projects can mean different things depending on the language.

PHP doesn’t have a compilation time at all. Typescript does (and its among the slowest I’ve used). Golang does, and it’s the fastest I’ve used.

That doesn’t mean it’s time to blame the language. It’s the 100s of packages upon packages you import that determine how slow and bogged down your iterative cycle will be. The language merely puts that threshold a little lower or higher.

For example, in Go, recompiling one of the modules simply took too long, because that module depended on the AWS Go SDK (which hosted the APIs for ALL OF AWS, EVERY. SINGLE. SERVICE). At that moment, I had to make a decision.

Is it better that the whole team gets slowed massively throughout the years, like walking with ankle weights?

Or should I spend the necessary 2 days to make a tiny API that only called out to the single service of AWS we needed?

I went with the latter, and looking back, it turned out to be the best choice.

This advice carries over to other languages as well. It’s not always necessary to import library to solve your every problem. Sometimes, it’s worth it to pay an upfront cost right now, then a slow ongoing cost that charges interest.

2.2: Hot-Reloading Tools are good

I’ll keep this brief, since this is quite obvious. In Go, I used Air when building CLIs, or Templ for websites (so I don’t have to rebuild and rerun the server when I update the HTML, and still have typesafe templates).

Hot reloading is good, and applaud frameworks that strive to make it better. SvelteKit has one of the best, and even industry giants like Angular are finally investing time into making their HMR story better.

3. Invest in yourself outside work

This is probably the most controversial one, although it really shouldn’t be! For an industry were it takes years to get a stable foot in the door, and many more years to become a highly sought-after expert, sticking to improving your skills solely during work is a recipe for failure.

Take time, outside work, to work on hobby projects. Not all of them (or even any of them) need to have an apparent purpose. Just something that interests and keeps your coding and building on your problem solving skills.

I say this because, in any project (work or hobby), there are many side quests you’ll engange in to reach the goal. While the project itself may be of little value, those skills gained from those side quests are very much transferable to real work (and often niche).

As a matter of fact, the only reason I got into Docker was because I didn’t want to setup Apache, then PHPMyAdmin, then find the specfific php.ini out of a 100 php.ini(s) to increase the upload_max_filesize.

Recently learned git blame while debugging & filing a bug for popular template language for Go.

How does this make the team productive?

Simply, being a good engineer with good skills means you can help coworkers. They are entire swaths of people who’s whole job is just unblocking their team members on difficult issues.

Not everyone is willing to do this however. Some people probably aren’t even in a situation where that’s possible. And that’s okay!

But you’ll be a very valuable asset to the team if you do.

Read The Worst Programmer I Know.