Wash three walls with one bucket

Building side projects is my favorite way to keep my skills sharp and invest in my knowledge portfolio. But this post is about more than picking good side projects that will stretch your current knowledge and help you stay up on different modes of development. It's also about creating a virtual cycle that goes from:

• Idea
• Building in public
• Sharing progress and thoughts
• Incorporating works into your portfolio
• Releasing and repeating

It's about creating leverage even while learning a new technology or ramping up on a new paradigm and always keeping yourself in a position to seek out your next opportunity.

Having skills is not sufficient

You also need to display those skills, display some level of social proof around those skills, and, importantly, be findable as a person with said skills.

In order to best capture the value generated by your learning, it helps to run your own tech blog as I recently wrote about.

Let's try a real world example to make this advice concrete. Last year, I found myself with the following desires while concentrating on Golang and wanting to start a new side project:

• I wanted to deepen my understanding of how size measurements for various data types works
• I wanted a tool that could help me learn the comparative sizes of different pieces of data while I worked
• I wanted to practice Golang
• I wanted to practice setting up CI/CD on GitHub

How could I design a side project that would incorporate all of these threads?

Give yourself good homework

Simple enough: I would build a Golang CLI that helps you understand visually the relative size of things in bits and bytes.

I would build it as an open-source project on GitHub, and write excellent unit tests that I could wire up to run via GitHub actions on every pull request and branch push. This would not only give me valuable practice in setting up CI/CD for another project, but because my tests would be run automatically on branch pushes and opened pull requests, maintenance for the project would become much easier:

Even folks who had never used the tool before would be able to understand in a few minutes if their pull request failed any tests or not.

I would keep mental or written notes about what I learned while working on this project, what I would improve and what I might have done differently. These are seeds for the blog post I would ultimately write about the project.

Finally I would add the project to my /projects page as a means of displaying these skills.

You never know what's going to be a hit

In art as in building knowledge portfolios, how you feel about the work, the subject matter and your ultimate solutions may be very different from how folks who are looking to hire or work with people like you may look at them.

This means a couple of things: it's possible for you to think a project is stupid or simple or gross, and yet have the market validate a strong desire for what you're doing. It's possible for something you considered trivial, such as setting up CI/CD for this particular language in this way for the 195th time, to be exactly what your next client is looking to hire you for.

It's possible for something you consider unfinished, unpolished or not very good to be the hook that sufficiently impresses someone looking for folks who know the tech stack or specific technology you're working with.

It's possible for folks to hire you for something that deep down you no longer feel particularly fired up about - something stable or boring or "old hat" that's valuable regardless, which you end up doing for longer to get some cash, make a new connection or establish a new client relationship.

This means it's also unlikely to be a great use of your time to obsess endlessly about one particular piece of your project - in the end, it could be that nobody in the world cares or shares your vision about how the CLI or the graphics rendering engine works and is unique, but that your custom build system you hacked up in Bash and Docker is potentially transformative for someone else's business if applied by a trusted partner or consultant.

Release your work and then let go of it

Releasing means pushing the big red scary button to make something public: whether that means merging the pull request to put your post up, sharing it to LinkedIn or elsewhere, switching your GitHub repository from private or public, or making the video or giving the talk.

Letting go of it means something different. I've noticed that I tend to do well with the releasing part, which makes my work public and available to the world, but then I tend to spend too much time checking stats, analytics, click-through rates, etc once the work has been out for a while. I want to change this habit up, because I'd rather spend that time and energy learning or working on the next project.

Depending on who you are and where you are in your creative journey, you may find different elements of this phase difficult or easy. My recommendation is to actually publish your work, even if it's mostly there and not 100% polished. You never know what feedback you'll get or connection you'll make by simply sharing your work and allowing it to be out in the world.

Then, I recommend, while noting that I'm still working on this piece myself, that you let it go so that you are clear to begin work on the next thing.

Wash three walls with one bucket

The excitement to learn and expand your skillset draws you forward into the next project.

The next project gives you ample opportunity to encounter issues, problems, bugs, your own knowledge gaps and broken workflows. These are valuable and part of the process; they are not indications of failure;

Getting close enough to the original goal for your project allows you to move into the polishing phase and to consider your activities retrospectively. What worked and what didn't? Why? What did I learn?

Writing about or making videos about the project allows you to get things clear enough in your head to tell a story - which further draws in your potential audience and solidifes your expertise as a developer.

Your finished writing and other artifacts, when shared with the world, may continue to drive traffic to your site and projects for years to come, giving you leads and the opportunity to apply the skills you've been honing in a professional or community context.

Create virtuous cycles that draw you forward toward your goals, and wash three walls with one bucket.

Where did this phrase come from?

"Kill two birds with one stone" is a popular catchphrase meaning to solve two problems with one effort. But it's a bit on the nose and it endorses avicide, which I'm generally against.

One of my professors once related the story of one of her professors who was a Catholic monk and an expert in the Latin language. He would say "Bullshit!", it's "wash two walls with one bucket" when asked for the equivalent to "kill two birds with one stone" in Latin. I liked that better so I started using it where previously I would have suggested wasting a pair of birds.

For this piece, I decided the key idea was to pack in dense learning opportunities across channels as part of your usual habit of exploring the space and practicing skills via side projects. So, I decided to add another wall.