As some geek that likes to code, the development life cycle is vicious when there isn’t a clear goal or established plan. In an attempt to fix bugs or implement something from documentation, I find myself blindly fixing bugs or just copy-pasting code off the documentation hoping that it will work. Which doesn’t, leading me to an endless loop of trying to find the error and fix it. Blindly coding was what I used to spend most of my time on.
Until I stumbled upon something simple and yet effective, that is planning. With planning, this delicious pie represents how I spend my time when developing a website or a side project.
What is Planning?
For me, it is simply taking a piece of paper and writing out what I am going to develop, how it looks like, and the possible issues that I might face. It is like an artist who sketches on a canvas before drawing the image.
Why Planning?
Because it is essential to me, being able to write down my thoughts, brainstorming ideas, and have a visual guideline of what I am going to develop forces me to think. Think of the possible issues that I might run into and solutions for it. Also, it brings forward most of the debugging work that I will encounter. All these, are now written down with a pen and paper.
Aim for progress and not perfection. This is what I have learned while having a plan helps you outline what needs to be done it is not perfect. When writing a plan, it does not cover all the issues that we might encounter, which is why we have to adapt the plan as it is being written.
How to Plan?
Planning is like a puzzle. To gather the pieces, I have to brainstorm and write out all the ideas and possible implementations that are in my head. With the pieces in hand, I will begin to put them together, refining my plans by shifting the pieces around until I feel satisfied. Finally, it is time to assemble, I will start by trying to map out a flow and see if it makes sense.
If the final plan does not make sense, I will refine it until I feel good about it and most of the doubts I have are cleared. This ensures a close to smooth sailing experience when developing, as it potentially irons out most of the errors that might occur. Be it a logic flaw or a data structure model that just doesn’t make sense.
Conclusion
At the end of the day, we can’t escape from debugging or reading documentation as it is part of the development journey. But I believe that with a plan we can find ways to remove potential obstacles, reducing the time wasted on blindly coding.
What do we do with the time saved? For me, I spend that time debugging some random bug, refactor my code or knock off early and start doing some other things. For you, take that time to relax, learn a new hobby, or just have do something outside of work. Work != life.
Top comments (0)