How I learned to plan... again
Back in 2006 Obilo and I set out on our most ambitious project at the time. We were creating iGbadun.com. This was a social network for Nigerians. It was a mashup of facebook (only American Colleges had it at the time) and hi5, which was a better-known social network in Nigeria at the time. This was our second PHP site, we were noobs with an ambition. Looking back, it would actually be a compliment to say that our code was atrocious, if code was peer reviewed the way scientific papers are, we would be laughed out of our profession. We knew nothing about frameworks so we coded every aspect of the site in raw php, with no libraries or helpers or anything. From implementing our own login system from scratch to writing our own SQL and database connection for every single query we ever did (using include files). Ironically the site worked and it was fast. It actually is to date the must fulfilling project I have ever worked on but I digress.
For the time we spent coding the site I remember one weekend in particular. I drove down to Obilo's dorm in Cornell on a friday and we spent the next two days with a total of about 8 hours of sleep between us, with the aim of finishing and launching the site before I returned to RIT. At the time we lacked ability many coders take for granted today. The ability to easily translate the logic in your heads into code. At the time if I wanted to write a private messaging system, I would sit down think of the database structure, think of EVERY kind of information we might want to store, why and how we would store them. I would think of the front end, how to represent this information, what might be the possible road-blocks and how to overcome them. All this before we wrote one line of code. We did it this way because for many of the things we built it was our very first time coding something like that, we did not know if it was possible or if we could do it. We were forced to plan out every feature in detail. I remember we took breaks were would stare at the ceiling or write in books to try and grasp the whole structure of what we wanted to build and then when the person does we would cheerfully declare "I see the code in my head" paying homage to The Matrix, a reference to Neo's line "I know Kung-Fu".
Overtime, building more websites and learning more languages I became more conversant in computer logic. I realized I could code something without thinking too much about it. If I had built it before I could recall all the structures and edge cases and sometimes I could understand how something worked and not even be able to explain it in English. Realizing this ability I became lazy. I stopped planning and when I got the whiff of something slightly interesting I would directly jump into coding it. This is akin to speaking before you think and as you would imagine caused me a lot of trouble. I would make promises I could not keep, give estimates at work that were way off and worse of all, build systems that at the very end I realize I architected it wrong. After a few cases of these I realized my problem was I stopped planning.
A quote by Benjamin Franklin comes to mind. "If you fail to plan, you have planned to fail". Noticing this I started looking into planning better. There is also going to the extreme of planning, where you write down every single thing you plan to create and from experience that does not work either. So after a lot experimentation I found a sweet spot and my idea to implementation process goes like this:
- Brain Storm - I Think about what I want the product to do and how I think it should work.
- Paper Sketches - I Scribble on paper, words and diagrams that help me keep track of all the various ideas and parts I am trying to grasp
- Bulleted list of To-dos - I break down all the things I need to do, into small goals and list as much as I can down, so I can tick them off as soon as I complete them. This is where i celebrate my little victories.
- Code - Once all the above is done and I have a solid understanding on what I am trying to accomplish. I jump into the fun part. The code.
Using these couple steps has helped me get a better grasp on working on big projects. Similar to when I started coding I make sure I see the code in my head completely before I proceed and that has actually led to more successful happy sessions than sessions where I want to punch my computer screen.
Subscribe to The Art of Coding
Get the latest posts delivered right to your inbox