“We should create a Github issue and do it later”

There are so many things that you can do when you are developing a new product, many decisions have to be made on how to do it and you very often end up in a dilemma where you have more things that you want to do that you have to time to do them in.

Where it goes wrong!

The problem, however, arises when while you are developing a product thinks about a problem or feature where if you take a shortcut can finish quicker or avoid pain. It can be by not abstracting this code, even though it is a bit duplicated, or making a too simple solution that only nearly works. It is here that if you think:

“I will write it down so I can do it later”

The problem is, 9 out of 10 times that never shows up, you will never get around to do that thing you wrote down, now instead you will have a lot of baggage that you are carrying around, thinking about and maybe stressing you. Instead, I have found out that every-time there is something like that, I think:

Is it important? Should it be done? If “yes”, do it now. If “no”, forget about it!

Once a pull request has been merged it is forever

A pull request is a wonderful thing because it is only a proposal to change something and the quickest way to avoid technical debt is not merge in things that are not good enough or needs to be improved to not cause more problems down the road. That means that a comment can be made:

“I know it should be changed, but I will do it in another pull request!”

That is not so good, because even with the best intention something can change tomorrow that do we will never get around to change it in that other pull request. It can be seen as harsh to not accept a pull request over minor things but the problem is not that one-time small thing, it is when multiple of those small things stack on top of each other that you suddenly have a really large problem!

Helping as the solution

The best solution while reviewing a pull request and you see a problem can be to offer the advice but also offer or maybe even help to do the needed change that will make the pull request be accepted!

What do you do to avoid jumping over where the fence is lowest and to keep the quality of the software high? 😄 Will love to talk about that!