Day 1 - Analyze or remain stuck

Published on 2019-11-01 21:48

I can't believe I am doing this. It's been a while since my last try to do n-days long challenge hoping that this time will be different. Anyway I have a side project which needs to be finished and my stubbornness prevents me from abandoning it (SlothCMS was killed and resurrected several times in the last year and a half.), so this series of posts will serve as debriefing and lesson learned. (It's only November thing, I promise.)

"Weeks of coding will save you hours of planning" -- developer proverb

As a half self-taught1. developer my first instinct is to go into code and solve problems there. It is one thing that I am unlearning when working on complex projects, especially my side projects. The unlearning process is not that easy when working in Agile environment because not all Agile teams believe in analyzing and documenting their work beyond cards in JIRA or worse, Trello.

SlothCMS definitely made me a slower developer when it comes to produced lines of code. On the other hand working on CMS from scratch has made me more patient and more productive developer because I am no longer brute forcing through issues. These days my work starts with drawing diagrams and writing down steps of an algorithm instead of opening an editor, it's still not very comfortable but I'm getting there.

Slowly I am also learning to stop during coding to do analysis because my abilities as an analyst are still growing, I am not able to see very far ahead but every time I flex my analyst muscles my analysis gets better. Unfortunately it's not easy to switch contexts between coding and analyzing but it still makes me more productive compared to brute forcing problems in code.

When I was a teenager my dad taught me basics of carpentry, he told me that I have to measure twice because I can only cut once. Ones and zeroes aren't wood but sizing up an issue before trying to solve it has a lot of benefits, saved time is only one of them.