I often find myself in situations where I start a new task. From zero. It’s like I’m at the bottom of a mountain covered with pines, and I need to chop the pines into wooden sculptures. And I don’t have a hatchet or a wood knife. Sometimes I don’t even know that I need a hatchet or a wood knife. The first steps are crucial in order to get the job done respecting a deadline, and without losing your sanity in the process. This is certainly true for software development and software-related activities: you can have tools that can help you greatly, and you can have obstacles that present themselves at the worst possible moment, for example discovering at the last week that the implementation cannot satisfy a primary constraint. The first steps are crucial. So, what’s the strategy?
The goal is to make those first steps count at the end. The goal is the efficiency of your task. Minimize energy, maximize job done. The first steps must prepare to the real work so that at the end, you are glad you took those first steps. The first thing to do is working to work less. This seems a contradiction, but it’s actually a short-term compromise for a long-term advantage. At the beginning you work for something that does not directly involve the task you need to do, but it prepares to work on that task more efficiently. I tend to distinguish between hard-work, that is the work that must be done, and soft-work, that consists of the planning and the preparations. Ideally, after some soft-working you start to really hard-work at you task, and you hard-work so efficiently that you surpass the results you would have achieved without initial soft-working. The point where the benefits get real is what I call the Freaking Sweet Point, the point where you understand you’ll end the task with saved energy. The month when your cashflow has a “+” sign in front. The 3-point buzzer beater after you trained for weeks at the street basket field. You release the A button and the charging punch lands in the face of the final boss. You chop the pines of the mountain maneuvering a Mad Cat MK II. Freaking sweet.
The figure above plots on the axes the time and the work done on the assigned task. The red line represents the traditional way of working, the green line shows the initial soft-working phase, where you have no progress on the assigned task, and the efficient hard-working phase where at the S(weet) point you outperform the traditional approach.
Real world examples in my field (software development) are well-known.
- Preparing code snippets to use through your project.
- Writing a script that automates some boring and/or error-prone manual procedures.
- Analyzing the problem and designing the application before starting to code.
- Searching for existing libraries that do what you need.
Note that some of those example don’t follow exactly the figure above. Sometimes the soft-work is done while also hard-working, for example when you write code with reusability in mind. Sometimes (e.g. while documenting a project) you soft-work in order to save someone else’s hard work. Sometimes your soft-work can be considered a task itself with its own sub-soft-work and sub-hard-work components. In general, soft-work improves the speed and efficiency of the hard-work. The more you soft-work, the less you hard-work, in the long term; and the Freaking Sweet Point gets closer and closer.
My dearest advice is to soft-work like you should hard-work till the end of the remaining time. Soft-work until the deadline gets menacing. Experience the Freaking Sweet Point against a hard-working co-worker: he’s the red line, you’re the green line. Then improve his work into a green line too. Take your time, create your time. Freaking Sweet.