Software engineer’s workflow

We've all been there: you're at your computer and working on a project. You have this great idea in mind and want to deliver fast. Then you realise that this work is going nowhere fast because some crucial pieces are missing in your codebase. This can end up in a frustrating colossal merge request which is hard to review.

Does this sound familiar? If yes, I recommend reading this post further. There are a couple of things you can do to improve the situation.

Design a workflow that helps you make your work more organised and easier to share.

A workflow is a set of steps that you can follow. I’m not talking about the general team workflow. Like using Figma for designs, Jira for tasks, Git(Hub/Lab) for code reviews, etc. These are all essential things. It’s just not what I mean here. What I want to talk about is an individual workflow of an engineer.

What are some characteristics of a good workflow?

1. A good workflow incorporates essential stages of the process. Building and testing are the two most important phases of software development. This might seem obvious, but I see engineers delaying writing tests too often. In the end, they sometimes cannot add tests at all.
2. It employs modularity to help you create reusable code and make it easier for your team to maintain and test it. Modular code consists of smaller pieces with clear interfaces between them. Modularity and good design help you focus on one thing at a time.
3. A good workflow happens in small steps. Modularity from the point above also helps with that. Smaller steps help you get feedback faster and make progress more visible.

Why should you design your workflow?

We all think differently. We have different codebases. It’s impossible to cater for everybody with a single workflow. I recommend finding something that works for you, your project and your team.

For an individual contributor, there are quite some benefits.

You don't need to "load" a context of a massive task into your head at once because you've split it into smaller chunks. The scope is narrow and crystal clear, and you always know where you are.

Dealing with interruptions is easier. We all face interruptions. Especially since Corona hit and many of us went (almost entirely) remote. Checking emails and chats becomes a habit, especially for more senior roles. Even for those beginning their careers, pull requests need reviews, product owners might have questions, and so on. The most considerable pain of context-switching is getting back into what you’ve been doing. When you work in small steps, it’s easy to stop and switch because you know exactly what to do next when you come back.

Another positive thing is if you git commit as you work, it’s easier for your teammates to review your PRs. They can go through it one commit at a time and follow your train of thought.

Compare:

Example 1—all changes in one big commit:

• feat: customer service matrix - 10 changes

Example 2—small scoped changes:

• refactor: extract file upload form - 2 changes
• feat: customer service matrix upload form - 1 change
• feat: display customer service matrix - 2 changes
• feat: download customer service matrix - 1 change

Which one looks more reviewer-friendly? And if you update your tests first, you can also be more sure that each step does not introduce regressions.

Do you need to share your workflow with the team? It depends on the team and your way of working. If the feature is small enough, doing it on your own or creating subtasks in your task management system as you pick up a ticket is okay. Suppose the user story is quite significant for your team. In that case, it’s your responsibility as an engineer to voice it during the refinement session. For example, you can suggest splitting the ticket into several smaller ones.

There are situations when a standardised workflow can help your team. There are unique and complex tasks, and we'll set that aside for now. I doubt there is a ready-to-use universal approach to solving an extraordinary task. But there are also repeatable tasks, like adding a new API endpoint or fixing a UI bug. What if you could describe this process? What if you had a ready-to-use algorithm for working on a task? What you would find out is:

• It’s now easier to do this kind of work because you don’t need to reinvent the thinking process;
• It’s easier to onboard new team members and mentor less experienced engineers. For example, you can have the workflows documented in your repo's README file.

Still in doubt? Feels like it's just getting back to the basics? Yes, it is. Try it—and let me know how it goes.