So it’s a new task. You’re kind of excited about it.
You think this time, I will consider all the cases which I missed last time. This time it’s gonna be perfect.
And then it ends up being the same. Things seems to be dragging for no good reasons and then finally, it seems that this task is going to be delayed. It’s a frustrating cycle most of us goes through.
But I think I have found some solution to counter this.
And thus, I have written some points to consider before picking up a new task.
Have you done your planning?
It’s pretty impulsive to start your coding editor when you receive the new task. We think that it’s no complicated task and should be fairly simple. Just few code tweaks here and there, and your task is over.
But, I would like you to take a moment and think. OK. Now I have a task. Its seems like a simple tweaks but am I thinking this through?
What if something else stop working because of my code changes. What would be the impact of it?
At this moment, if your code base is built using Test Driven Development (TDD) method, then you live a stress free happy life. As your code changes will detect any possible test case failure which are not intended.
If that’s not the case, then maybe its a good time to start writing your test cases. Many frameworks support doing this, and you should strongly consider using it.
If the project restricts you from implementing TDD, then no issue, we will find another way.
Instead of going to your code editor, first I’ll recommend you to start up your notepad (on screen or off-screen) and start thinking on a blank page.
Divide your task into various minor task. Eg. If I want to implement this feature, then I need to add 2 lines of code in this function, and then other 3 lines of code in that function, etc.
Write it down on a blank notepad. And for god sake save it! You would be needing that in future.
That note will help you to determine the goals you had in mind when you started developing & what flaws does it had. It will also help you to understand the time require for it.
“Just make a plan”. If the things change in future, you should come back to this plan if something is not working as expected or some new requirement comes.
Try to write your code in a block
In scenarios where you along with multiple developers have completed their work. And now some existing features are not working as expected.
Now you couldn’t find the real culprit for this nuisance.
In addition, it’s quite possible that in future, you would like to know, why certain logic was written the way it is.
It could be really frustrating to just see a bunch of code without actually knowing why it was done this way.
For these reasons, I would suggest that you write code in block.
void SomeOldFunction(){
... previous code
//Start - Implementing new awesome feature
...Your code
// End - Implementing new awesome feature
... some other code
}Like given in above code snippet, we already had some old function doing something. And then after thorough investigation, planning & testing, we added our logic.
Now it’s possible that due to addition of our code, other features would act in an unexpected way.
If we have written our code in block, it would have helped to just comment out our code and examine if the problem was due to our code?
It also helps the future developers to understand why your code was written. Adds some kind of modularity to your task 🙂
Try adding as much comment as possible
You might have faced this issue like you’re working on an old project. Reading through complicated lines of code and not realizing why the hell it was written like that.
Its stopping you from developing the awesome new feature you were planning to. The code might not be refactored the way it has to be.
This is called technical debt or code debt. It happens when speed of project development is prioritize over quality. And that’s common around the software industries.
But let’s not propagate this problem.
It is right time to start refactoring your code if possible. Make the function more modular (function doing only one thing at a time. Single responsibility principle).
And write a lots of comment. You could also go ahead and add the whole algorithm in plain English if you want.
Also do consider writing the task name or some reference to your task. So you or some other developer could find the feature reference.
Consider getting familiar with TDD
If possible, and if time allows, start writing test cases first and then develop the features.
This process is time consuming, but trust me, it is fruitful in the longer term.
You’ll make your job less stressful and improve the quality of your work.
These are my thoughts. What do you think?