Divide and conquer — as important in daily programmer work as for everyone side projects
My main way to spend time during travelling to work in January was reading Medium networks The Writing Cooperative and The Startup — first to find some ideas about what kind of content do I want to post on this blog to keep it interesting, and second as a way to find some new ideas for creative use of my programming skills that would bring me joy.
I learned the term ‘struggle porn’ somewhere along the way — if you are spending all the time reading about how to be successful, instead of doing anything by yourself then congratulations, you are just on some struggle porn binge on your own. Of course, by going through those articles you will probably assume that the only thing you lack is just do it approach — all of the rest is already there, right? For sure you have a great vision, huge amount of ideas about ‘what you would like to do when you finally have time for anything’, dozen of ways to perhaps make some extra cash on the side from it… But if only you had that time, right?
But you never do. Days and weeks are passing by, and there is always next excuse to not do anything that day for your side-projects. Sometimes it’s just a hard day at work after which you only wish to go to be, on other occasion stomachache and hangover after another Saturday party. Perhaps you were going to do something after work, but just as you were leaving the office your co-workers invited you for beers — and how could you even refuse? (Actually you can — I encourage you to read Do I Have to Go to That? in your free time) There is always something else to do, which is more urgent (even if not more important than your side projects).
So is there a way to somehow start working on your side projects, and keep it up without losing interest along the way?
In computer science there is an approach for designing algorithms and writing your code, called divide and conquer. Basically it means splitting big task into set of smaller tasks, and then split them further until you get very basic and easy to solve tasks for each part of the main problem. After all every big process in our lives is just a specific order of very basic behaviours that everyone can do, right? You can teach anyone to just blindly mimic some work, and after some time and trials he will be able to exactly reproduce the steps, even without knowing why he is doing it. The secret is not in doing those tasks, but in knowing the sequence at the proper point of time.
There is a practice for teams working in Agile project management methodologies to split the work into set of small tasks — this is also a divide and conquer in practice. We are talking here about business processes, rather than writing some code. But hey, it’s the same for other parts of our everyday life — cooking recipes are also split into simple steps like ‘add 10 grams of flour’, right?
For most of teams that I was working with, we were trying to split the job into tasks as small as possible. This is not something that Scrum or any other agile framework sets as a rule, but I found that most of the teams feel confident with taking the tasks that would take less than one day. There is a magic in that ‘one-day rule’ — we all crave for success, and would like to have that dopamine rush as often as possible. And finishing something definitely does the job in this case. And by keeping it under one day length, you can be sure that almost everyday you will be able to say with satisfaction “today I achieved something”. Even if that achievement is just a stepping stone for the bigger scope of the whole project.
But of course, that’s our daily work. We are obliged to it (mostly by contracts we signed ourselves) and it gives us money to spend on life necessities, as well as things that we don’t necessary need, but would like to have. It’s easy to properly plan and organize job that you are expected to do. Perhaps sometimes your job is already organized by someone else, and you just need to meet the quota for the day. But what about projects that you would like to do, but nobody is making you do?
After spending some time on analysing how to be more satisfied with my off-work time, I came to conclusion that applying divide and conquer approach for side projects could be a way to go. Let’s say that I want to learn how to do proper, fully working website using technology that I didn’t had chance with previously. If your goal will be to create a fully functional website using technology A, there is a rather huge chance that you will stop midway, just because you didn’t had time, found some new (and new is always better, right?) idea that you would prefer to start. And each time the vicious circle continues.
That’s where thing like hackathons or game jams come into place. People who find their hobbies to be creating software go to that kind of events on their free time, mostly just to spend some quality time being productive on their own terms. I don’t recall any hackathon that I attended where there would be a strict constraints on what you are doing. Of course, there is something like ‘main theme’, but most of the times it’s just a suggestion to follow, rather than rule to oblige. And the goal of that event is simple — create properly working software or game within some time limit.
You cannot do anything big and grand in 48 hours. You cannot polish every scenario that user would go through, create magnificent and fully responsive UI and offer a lot of functionalities at the same time. You can of course try to get one of those things right, but then you will probably fail in the other parts. So instead of trying to get a perfect solution, you should aim for something that just works. Nobody pays you to be perfect, so don’t waste time for it. Perfect is the enemy of good.
And perhaps that is also true for your everyday side projects? If you will cut scope of your project to set of small elements, then perhaps by focusing on working on one thing at the time instead of trying to get everything right at once you will finally achieve your results? By keeping up with example above about new technology for website creation — perhaps instead of trying to create a whole functional site during your free weekend, just focus on one element of it? “During this weekend I would like to learn how to create a fully-working login page using this framework” sound more doable than doing everything else that is required to have that working website.
And then, when you finally finish this part, just stop your work for the moment. Appreciate what you have accomplished, and leave yourself something to do for the next time you would have a free weekend. It’s usually harder to go back to already started work, than starting it from the scratch. Prepare your next small scope, instead of rushing forward without aim just because you already have something done.
And after some time, you will probably be able to create a final goal just by putting together all the blocks that you have created along the way.