Han builds solo- photo by Unsplash

When you’ve got to go it alone, how do you make the most out of it?

Most developers work as part of a team. However, at some point in our careers, we’ve had to (or we’ll have to) work alone. And while much of product development involves being able to manage or work with the rest of the team, it’s equally as important to develop good practices while working solo.

A quick note about “working solo”

Solo typically means doing something alone. But we’re using it in this context to mean anything that’s done by a small number of people in an unofficial, unstructured environment. It could be just you, or you and a few other folks. Examples include:

An open-source project, such as a package or library

A personal product, which could be commercial or free

A freelance gig for a client

The common thread here is that there are no established rules like you’d typically have in a company.

Why should I bother about my engineering practices?

By Ashley Knedler in Unsplash

Here are a few reasons why they matter:

You’ll be an asset to your team.

Let’s consider the possible scenarios that could ensue when you join a team:

You join a team that follows the practices you’re used to. Great! It means you’ll be ready to start contributing from day one.

You join a team that follows a different set of practices. If you’ve grasped the general concept of good engineering practices, it shouldn’t take you too long to get used to it, and you’ll become productive soon, too.

You join a team that doesn’t follow any good practices (oh no!). In this case, depending on the team, you might be able to bring your knowledge to bear and improve their processes. Otherwise…maybe just leave.

Either way, it’s a win-win.

You’ll be a better developer.

Software engineering is about more than just coding. There are lots of moving parts involved in bringing a product from conception to launch, and then keeping it running beyond that. Inculcating best practices will help you keep on track and avoid frustration.

If you love coding (like me), there’s always the temptation when working on something new to jump right in and start coding. But I’ve seen over time that having some kind of structure in place, while still maintaining the flexibility that comes with working solo, helps me to avoid many bumps in the road.

Let’s consider some of these good practices.

Stick to a workflow

A workflow is the series of steps that are involved in transforming an idea in your head to a finished product. Some of the things your workflow should cover are:

when a change is decided upon, what processes do I follow to implement it?

how do I deliver new versions of this product to the end user?

how do I track changes made to this product?

how do I track bugs, problems, and future plans for this product?

Why? It might seem faster to get things done without a defined workflow (“just write code and push to master”), but as a project increases in complexity, you’ll find that having clear definitions makes it easier to determine what needs to be done and to focus on it. When working on a team, the workflow becomes a pipeline that helps each member be more productive.

What you can do:

Use issues (GitHub, Gitlab, BitBucket or wherever your code is hosted). Issues help you keep track of bugs, feature requests and major changes to the project. Also, writing out an issue title and description force you to crystallize the thoughts in your head and define exactly what the problem is and what the solution should involve. You can also take this one step further by adding project management tools like Trello and GitHub Projects.

Use pull requests. Many devs prefer to push directly to master when working alone. However, there are benefits to making changes via pull requests. It’s easier to see all the changes involved in that feature or bugfix and how they’ll affect the codebase when merged. Also, when pull requests are paired with issues, it makes it easier to observe how a project has evolved without having to read the code and figure it out.

Review your code. It might sound strange, but you should review your code like it was written by a different person. Some folks suggest making a PR and walking away for a few minutes or hours, then coming back to review the code before merging or updating. Code review, away from your IDE where you are king, allows you to see your code with (somewhat) fresh eyes, helping you to catch bugs and identify things you forgot. Code review also forces you to question yourself. Why did I implement this that way? What could go wrong? Is there a better way?

Maintain meaningful Git history. Try to commit like you would if you were on a team — avoid large commits, keep commits focused, meaningful commit messages. Like code review, writing a descriptive commit message forces you to slow down. What was I trying to achieve in this commit? How did I attempt to achieve that?

There will be instances where you can allow yourself to break the rules. For instance, you might decide that for really minor fixes (such as correcting a typo), it’s okay to push directly to master, in order to avoid slowing things down.

Regardless of what you incorporate into your workflow, it’s key to be intentional. Successful products don’t just happen; they’re built with love and care. Being intentional means stepping back, looking at the pain points you face and thinking of ways and tools to improve them.

Organize and share components

Think in accordance to the DRY, SOLID and FIRST principles.

Compose software out of smaller, encapsulated, atomic reusable components. Use tools like Bit to organize, share and discover components to compose new applications like Lego. You will build faster, and compose better software.