Dive 7: The ONE thing solo creators struggle with when joining a team

Avoid becoming this!

Hey, it’s Alvin!

I’ve been working as a professional software developer on teams big and small for over a decade. Sometimes, I also make small projects on my own as a hobby. Over the years, I saw solo developers join some of my teams, and they often struggled a lot in the beginning. Today, I’m diving Below the Surface of creative collaboration. If you’re a solo creator planning on collaborating with others for the first time, there’s one secret that will boost your chances of success: serving your teammates.

The other day, I saw someone boasting online about how they “don’t have to keep code clean, refactor code, write unit tests, or write documentation, and still managed to make an app that turned a profit.”

Before I even checked his profile, I already knew he was a solo developer because all those things he listed were practices of collaboration.

You keep code clean so it’s easier for other developers to read, so they can maintain and build off it. It’s like keeping sentences simple and easy to understand when writing.

You refactor code to keep blocks of code structured consistently, so the application is easier for other developers to follow at a higher level. This is like, when writing, you want to divide a long wall of text into smaller sections that are easier for others to read.

You write tests to help other developers know when the new code they wrote broke something else. Because as software grows in complexity, it becomes increasingly hard to know how one part of the software will affect another part, especially when different developers are working on different parts.

You write documentation to help other developers understand why the software was built the way it was because the code itself can’t tell the whole story.

A software development team may spend months or years iteratively improving on a software product. During that time, people will join and leave the team. Without these collaborative practices in place, it would be impossible for the team to move quickly without making costly mistakes.

Of course, these practices can benefit a solo developer, too. If you plan on improving on a software product for more than a few years, these practices will save you time in the long run because you won’t remember all the esoteric reasons code was written a certain way 300 days ago.

BUT… these practices are also time-consuming. A solo developer’s going to know their project inside-out, so they might not need documentation or clean code. And small projects often fail with zero interest from other people. For a solo developer whose project has a totally uncertain future, it might not make sense to test code that no real user will ever execute. That’s why it makes sense that a solo creator would see these collaborative practices as “useless.”

So, you don’t need these collaborative practices to succeed on your own, but they’re critical as more people join your mission. And if you’re a solo creator planning on joining a team, get ready to embrace collaborative practices in your field.

I still remember a solo developer who joined a former team of mine. Our team of five developers had documentation, tests, and style guides. We documented coding standards and conventions every team member had to follow.

He followed NONE of it.

He also didn’t like writing tests or documentation, believing them to be “wastes of time.” So, one day, his code broke. He struggled to find the problem, so team members tried to help him out. But no one could understand his messy code. Then, the team leader, who already had to work overtime, had to sit down with him so they could walk through the code together.

Unfortunately, that wasn’t the only occasion. And at some point, the team felt enough burden that he was let go.

In a similar vein, in my early days as a software developer, I encountered my first ever bug. The team’s business analyst told me to write up a ticket. So, I copied the error text in my console into the ticket, and submitted it so it could be prioritized, and eventually, fixed by another developer.

The business analyst looked at the ticket and said,

“Alvin, you have to list the steps you took to get the error. Give as many details as possible. You want to make it as easy as possible for other people to understand what the problem is. Make other people’s lives as easy as possible.”

That’s the key difference between a solo creator and collaborator.

When you work with others you don’t just serve your clients, you also serve your teammates. It takes work you wouldn’t need if you worked alone. But it’s the price you must pay if you want to achieve something greater than what you can achieve on your own.

I hope you enjoyed this dive Below the Surface on the hidden price of teamwork. Reply to belowthesurface@substack.com if you have questions or comments. Let me know of any other hidden costs of teamwork you think I missed. I’d love to hear from you.

Thank you for reading. Have a wonderful day. And I’ll see you in the next one.