The Architect vs The Gardener Approach — A Programmer’s Dilemma
A while ago I watched an interview with George R.R. Martin. During one section, the interview mentioned that many of Martin’s scenes in Game of Thrones felt very organic, and Martin went off to say that there are two kinds of writers: the gardens and the architects. The architect gives meticulous attention to detail, while the gardener just plants the seed and adds a little bit of water every now and then, and improvises as and when needed.
To be honest, I would love to use the architect approach who just think’s about every possible solution, chooses the best one, write’s code and boom! Done! Next! But in reality, I am more of a gardener who write’s a lot of code spontaneously, deletes a lot of it, and rewrites it with a different approach.
While writing code I encountered a lot of errors on a daily basis. Seeing errors are not ideal, but whenever I encountered an error, I looked at the stack trace and tried to reason the error from the trace only. If needed, wrote down the logic on a piece of paper and figured out where it went wrong. If that fails, there’s always documentation to the rescue. Documentations are great resources of learning. Not only are they readable, but also they are written by many smart people. In my opinion, this is the best resource to push yourself to the next level.
There were times when I had a solution at hand but didn’t want to implement it that way as there could have been a better solution that I didn’t know about. This was when I caught myself being the perfectionist, again. That was the time I realized that perfectionism is just a fancy word for fear.
Inaction breeds doubt and fear. Action breeds confidence and courage. If you want to conquer fear, don’t sit at home and think about it. Go out and get busy — Dale Carnegie
Thereafter, I would write down a practical solution first and would tell myself “I would come back and refactor it later”. Sometimes I found a better solution and refactored the code and sometimes I didn’t. If the former happened then I learned how to implemented a functionality using two different approaches; if the latter happened, I at least have some code that works.
“Its all about knowing where the extra attention to detail will payoff and when you’re wasting your time.”
Although being a trail and error solution, gardening process paid off in the long run. It helped me learn why things didn’t work the way I thought they would. Those issues escalated my understanding to the technologies I am using. So, I would say write a lot of code because that’s the only way you are going to learn.