Breaking things down

May 10, 2014

Tackling a large, daunting project is something I have not been particularly good at. Being as impulsive as I am, I would start a new project, decide this new project isn’t really that fun to work on after a while, and drop it, only to do the very same thing again shortly after. I just never learn, do I?

Well, lately, I’ve learned how to stay on task. You want to know the secret? Of course you do!

I’ve tried tons of self-help techniques to improve my discipline, goal-setting, or other organizational traits that I lack. Usually, those things would work for a short time (a matter of weeks), but I inevitably would slip back into my old ways…and the cycle would continue.

Breaking Things Down

So how did I learn to crawl out of this hole? Well, rather than thinking about things in terms of “One Big Thing”, I have to break it down into separate, much-smaller tasks.

My favorite analogy to explain this concept is Thanksgiving dinner. There is so much great food to eat, so I pile on all of the stuffing, cranberry sauce, turkey, mashed potatoes, squash, bread, and everything else…and I suddenly have very daunting task ahead of me: cleaning this massive mountain off my plate. Looking at it must makes me feel full.

However, if I just break the meal down into smaller portions, I find myself eating far more than if I simply loaded a huge amount on my plate at once. Although I’m giving my stomach plenty of time to recover between portions, I think the hurdle I place on myself is mostly mental. It wasn’t one big plate, it was a long series of smaller plates.

So the point I’m trying to make is…

While eating as much as I possibly can in one sitting might not be one of my long-term pursuits, the concept of “breaking things down” would apply well to other aspects of my life, including software development. Although it’s really hard to admit this, it’s pretty much impossible to learn about advanced new topics all at once. I have to accept that it will take time to not just learn the technical skills, but the context when it would be most beneficial to use them, and how to best apply them. This well-known article amongst software developers serves to prove my point.

Don’t be a fool who thinks he/she can solve all the world’s problems in an evening. Break it down!

Next: Specialization