Recently I was trying to recap my old thoughts on managing workflow in the dev team. It’s pretty obvious that IT project management is an issue quite well discussed and processed in one million (approximately) different ways. Probably most of you have met with many different programs such as Jira or Trello during your work. I’m not trying to convince you that it is something wrong with those. They are very complex pieces of software that can easily improve your workflow. The main problem is rather an attitude than the tools.

In the case of small, beginning startups this is a topic that can cause quite a large discussion in the team. For many developers, the most important thing is just writing the code rather than worrying about properly tracking the progress. It often looks like we devote time to handling such formal issues instead of putting it in a lot of other things. At this initial stage of the company, there is no time or people who could focus only on management. In this article, I will present some of my ideas that can improve communication and task tracking within the developer team.

There is one thing worth mentioning. Team management is a concept that is very often deeply related with the Company philosophy. This is a thing that is rather hard to change. Every team has its own pattern and uses different tools. At the same time, it is worth noting that even using simple tools, you can automate team communication in a very efficient way. Perhaps some of you will find this an interesting way leading to changes in attitude. I hope it’ll help you to open to new ways of communication and work optimization.

The main idea is to adapt some patterns in your daily workflow. Using this mindset you won’t be forcing yourself to manage your work outside of your natural environment.

Comments

Let’s start with something simple. All of us use comments in the code. Typically, they perform quite different functions, from helper messages and hints to comprehensive documentation. The frequency and quality of their use are quite variable depending on the team and approach. Their quality is particularly high in portfolio projects used during the recruitment process. It makes me wonder, whether we use them too often only as a form of showing off the ability to understand your own code. On the other hand, it might show some worries that our code may not be understood correctly. Very often during the actual work, we don’t pay so much attention.

I don’t want to be picked up sarcastically, I’m also a huge opponent of thinking that code must be self-documenting. Yes, it is very important to make your code as readable as possible but we never should assume that this is always the case. We often have to work in a different environment, different technologies and sometimes

I don’t want to elaborate on how and when we can use comments as documentation. This is an idea for a completely separate article. For now, let’s stick to one, in my opinion, the most important use case. Do you know what is more important than documentation? Knowledge! I mean… communication.

Comments should be used to communicate. This is their main function. This way, our teammates can easily read between the code lines. Just like your code, comments should be transparent. They should be written in a communicative, clear way, often with references to the specific team member describing particular problems. Especially useful for this are the extensions to the code editors that offer a bigger visual diversity of comments. In the case of the VS Code, we can use Better Comments. Thanks to this tool we can define any number of colorful comments, and at the same time, we can increase their potential. Different colors can be responsible for different types of messages that we want to deliver to the rest of the team.

Todo

Another really useful and easy-to-adapt tool that supports and automates communication in the team is the TODO tree/list. Again, I’ll stick to the VS Code extension but many of the popular code editors have similar tools (Atom, Sublime, Brackets, WebStorm). The concept is all about putting in different parts of our code comments with the prefix TODO: and then, they automatically jump into separate, cataloged view. This way we can define the task list for the particular days for ourselves as well for other team members.

In my opinion, this is a very powerful tool which can accelerate your daily workflow.

Recently I made a quick test. I decided to open the Todo Tree extension inside the node_modules folder.

As you can see most of the packages uses this methodology. I don’t know though if they’re actually using this extension in their daily workflow, if not, they definitely should. Also, it is a really cool way to learn about different approaches to write meaningful comments (at least, with some of them… Webpack, please 😂).

It’s a good idea to keep some kind of consistency in comments. Use the same pattern, like for example:

TODO: (version)[category]<assignee>: description

Another use case would be simplifying the definition of tasks in case of new, inexperienced programmers (or small startups). The ability to focus fully on the source code during task management can increase productivity and speed up the development process.

Git

We, developers, are simple people. Most of the time we’re using just a couple of commands:

git add
git clone
git commit
git push

and, of course, the one and only:

git push -f

By the way, I strongly encourage you to check out git-flow. It can really speed up the development process, especially when you don’t have much experience with change control.

What do you think, which one of these can be used for communication?

git commit

That’s right. Let’s find a way how to use commit messages to increase our management abilities.

I recently read a cool article by

Dan Goslen

I don’t want to repeat these arguments and ideas so I’ll try to present a different point of view.

Let’s think o minute about the reason why we’re writing commit messages. After reading sections “Comment” and “Todo” you should already know what it’s going to. That’s right — communication. It might seem like something obvious but sometimes, most of us forget about using this idea to create useful commit history.

When we’re writing comments, we focus only on the efficient presentation of our problem in isolation from the development context. Of course, the primary use of the commit message is to summarize the change. In fact, however, we must remember that our message will eventually go to the stack of other messages, creating some kind of documentation of our project. Documentation focused on presenting changes, but, when you think about it, software development is just a series of changes.

Now, lookt at it from a different perspective. Does a good writer instruct each random person to write a separate paragraph in his novel? The result would be quite a chaos as you might imagine.

Commit messages can be used to invoke some actions in third party services. For example, with Jira, you can put a comment on your task using one simple command:

JRA-34 #comment corrected indent issue

I, personally, don’t like that much this concept of using commit messages as a tool just for controlling purposes. Although this concept of automating your work pipeline sounds interesting, I think, we should use tools primarily for their main purposes. Any additional features, for example supporting the automation, should be implemented by “attaching” it to the core workflow. Only if the do not disturb the main use case.

Conclusions

Thank you for taking the time to read this article. Even if you didn’t feel some ideas and thoughts described in it, I hope, it inspired you in some way to think about some other, unusual ways to develop your managing skillset.