From the lessons of nature, we know water goes pretty much wherever it wants to. Digs through any rock, no matter how hard, or any man-made barrage. However, if it has a chance, water would rather avoid the obstacle, and go round, through a more permeable terrain.
Maybe you will be surprised (not), but this post is not about nature or water, instead about software development.
I started thinking earlier today about the development planning used by the Leo team, which was shared publicly on a couple of AMAs by Khal.
What they are doing is this:
- At any time, Khal has a list of thousands of items to do, including scaling and back-end stuff, new features, bugs to fix, UX to improve, etc. Many of them are reports from users who send #feedback via #threads.
- Every week he selects 100 of them
- Even though this is an "ordered list" (prioritized), devs have the freedom to choose whatever they want to work on from that list
From what he said, it seems to be have better results than trying to focus on certain points (eventually using multiple devs), until they are completed.
My impression is he is right and has found and implemented a much better way of planning development.
In the software development world productivity varies. Sometimes you are very inspired and seems like lines of code keep popping up in front of your eyes, or even more, your typing speed isn't keeping up with your mind. Other times you hit a wall and you can't progress one inch in a week on a certain matter.
The best thing you can do when you hit a wall is let it go after a while of trying and move on to something else. When you come back to it, you'll see the problem you face with different eyes, and potentially see the solution much easier. Sure, if that doesn't happen, it would help to have some feedback from a colleague too. Maybe you're missing something.
Even more, when you hit a wall, your morale drops. If you go clear some smaller tasks from the to-do list, you get a dopamine boost that restores your morale.
If the wall doesn't break, maybe it's time to think of a different solution, to go around it. Even if it's more work. At least it's progress.
I know not many people reading this are developers. After all, they are busy coding. Some, like me, maybe were at a time. Others may know developers and this way they get to understand them a little better.
And if you work with them, without being a developer yourself, try understanding these situations, and finding a plan that works through the periods when they hit a wall and get them out of the blockage. It should improve your developers productivity.