Published on

How to not redig the same hole again

937 words5 min read
Authors

Introduction

Throughout my software engineering journey, I've encountered numerous bugs and issues that required fixing. One common frustration that resonates with developers worldwide is the dreaded process of rediscovering a bug or issue that you've already tackled in the past. The sinking feeling that accompanies this realization can be akin to a truck hitting you, especially when it involves not only bugs but also the repetition of implementations and features you've previously worked on.

Recently, I stumbled upon a thought-provoking blog post by Simon Willison. In his post, Simon delves into how he leverages GitHub issue threads as a means of communication within his team, effectively preventing the need to repeatedly rediscover bugs or implementations.

In this blog post, we'll explore this problem, Simon's insights, and practical strategies to ensure that you never have to redig the same hole again in your programming journey.

The Problem

The problem is that we as developers tend to forget things. And this is not just limited to developers, but to everyone. We tend to forget things that we have done. Essentially this is not a bad thing per say, but it can be a problem when we have to rediscover the same thing again. And this is where the problem lies. For this we have to adopt a well defined process that we can follow to prevent the need for rediscovering the same thing again.

About the blog by Simon Willison

Simon is the co-founder of Datasette. Datasette is a tool for exploring and publishing data. He is also the co-creator of Django framework. As developer he maintains and contributes to a lot of open source projects. And he has a lot of experience in the software industry. In his blog post he talks about the need for documentation, automated testing. He learned about his process while he was working at Eventbrite.

What he really stresses on is that in a large team of developers that is spread across the globe, it is really important to have a well defined process of communication, to everyone on the team is on the same page. And this is through a good documentation and automated testing. So he also took this to his own projects. And created the model of The perfect commit. Which consist of implementation, documentation, testing and link to issue thread. He is developer who maintains 185 projects on Github. And this process has helped him a lot.

The - Oh Wow! Moment

What really struck me the most apart from the fact to always add new implementation with updated documentation and unit tests(to make sure the code works as expected) was the fact that he also adds a link to the issue thread. This was such a simple thing, but it was so powerful, and its readily available through Github with a lot of features.

How to use issue threads

After reading the blog post, So as someone who works on solo projects, I had lot of occasions where I had to rediscover the same bug or implementation because I don't maintain. the solutions anywhere.But with this approachI can dial it up a notch. Now the process is everytime I have to work on a new feature/bug it will go into issues board of the project. And I will create a new issue thread for it. Since I am the only one working on the project, I will start having coversations with myself on the issue thread. This might sound weird, but it is really helpful. And I could really write down the entire thought process that I had while working on the feature/bug.

Example of how to use issue threads

Let's say I am working on how to setup Kubernetes cluster on my local machine. I will create a new issue thread for it. And I will start having conversations with myself. And I will write down the entire thought process that I had while working on the feature. And I will also add the links to the resources that I used to learn about the feature. Now in the future if I work on a project where I have to setup Kubernetes cluster on my local machine, I can just go to the issue thread and I can see the entire thought process, since its your own thought process, you can easily understand it. And can straight away start working on the feature.

How Cool is that!

Same applies to when you left a project for a while and you come back to it. You can just go to the issue thread and you can see the entire thought process that you had while working on the feature/bug. And you can straight away start working on it. And you don't have to rediscover the same thing again.

Conclusion

So in conclusion, I think what Simon has done is really great. And I think we can all learn from it. And I think we should all adopt this process. And I think this will help us all to be more productive and efficient. And we can all prevent the need for rediscovering the same thing again. The core idea is to have a well defined process of communication. And I think this is a great way to do it.