Today I’m going to present one of the essential behaviors that distinguishes programmers who can fit well into any project from those who have trouble adapting. It is an approach one uses to complete a task that encompasses many subtasks within itself. Let’s call this strategy a step-by-step approach. It means that the programmer finishes one part of the task before starting the next one. It may seem like an obvious approach to any well-planned work. Unfortunately, many programmers, especially at the beginning of their careers, tend to abandon this idea, completely ignoring potential drawbacks of that decision.
Why do some people not follow that rule?
From my experience as an architect and sometimes a coordinator of a project, it seems that some programmers like to think that when they start working on a task from different angles simultaneously, they will speed things up. Hopefully, they complete essential parts first, then combine them, fix bugs, and implement additional features later. They create a map of precedence based on similarities and false analogies of the implementation. What appears to be alike in code does not necessarily have to be completed within the same timeframe.
That kind of approach may sometimes work pretty well, especially when you want to hack your way through the system and create a proof of concept or prepare a template for others to continue. However, usually, that approach makes complex implementations challenging to track, and sometimes programmers fail miserably without knowing what hit them.
Disadvantages of an incoherent approach
Let’s think for a while about what could go wrong when you decide that the order of implementation does not matter, and you can build a complex solution from multiple angles at once.
There are two major categories of drawbacks regarding this lack of cohesion.
First is your personal responsibility. It is crucial for you to learn what you will implement; having that, you should devise a plan and later verify it by a step-by-step implementation. Otherwise, you may spend valuable time on parts that are not essential, or you may find yourself reimplementing other elements because you didn’t pay enough attention to the details. It happens when the scope is too large and some things are starting to hide from your awareness. Consequently, the realization comes too late, usually throughout the final integration with a close due date to finish. Remember that it is easier to keep a mental model of one or two things, implement and integrate them, and only then move to the next one. Having multiple parts to combine and develop simultaneously is usually very demanding, even for experienced programmers.
Also, you may lose the context of the solution when you have to jump out of the task for a while and then come back. If there are more elements under heavy construction, there is usually more context to remember and restore. That makes jumping back in very difficult.
The second category of responsibility that you have is the accountability within your team. That obligation is even more important, because when you work alone, whenever you complete the assignment correctly and on time is rarely a problem. However, it’s a whole other story when you cooperate with others.
When you work in a team, there are more duties but also more chances to finish the assignment faster and better. Many random things could happen, e.g., a significant change in the logic, a strange bug, or simply a wrong estimation. Whatever it is, you may receive reinforcements from your team, or you may be a reinforcement for others when you finish ahead of time. Either way, it is handy to be able to delegate a part of the task to other programmers. It is easier to transfer the work that is not under development, thus don’t limit your options by jumping around the code.
The implementation is not the last thing that happens. There is also review, acceptance, and deployment, that is many further stages before you can consider the job done. The best approach while working in a team is to allow others to work further with the completed part of your code while you are implementing the next part. Overall, that kind of cooperation speeds things up and enables you to receive a meaningful feedback very early.
It appears that implementing multiple subtasks simultaneously may bring you a lot of headaches and prevent others from helping you. If you want to be a professional, you must perform like one and make sure you do as much as possible to help your team and yourself complete the assignment flawlessly.
How to divide the task?
Right now, it is pretty clear why planning your solution and implementing it according to that plan may be beneficial, but the following question to ask is how to divide the task and devise such a plan. Well, I genuinely believe there is no precise and comprehensive answer to that, there are too many variables to acknowledge. Still, I also consider the one thing that is true in most of the cases you’ll ever encounter — potential help from other programmers.
It seems apparent that you should divide your job into as many independent tasks as possible. Still, the best heuristic to decide whether the part is separate or not should be the question whether this piece may be implemented by a different programmer optimally at the same time. When the answer is yes, you probably got yourself a subtask that is coherent and separated enough to be regarded as a distinct step in your overall plan of implementation.
Are there any exceptions?
Well, as it usually happens, there are no rules without exceptions. In this case, I suggest that you consider performing your work step by step whenever possible. I think you should have an excellent explanation whenever you decide otherwise and choose to leave something unfinished for later.
As a simple example, I can think of a situation when you encounter a significant problem that is a part of your code, but the fix is time-consuming and could be solved regardless of your implementation. Then leaving that work for later makes perfect sense. However, that is because you may define the fix as another step of your plan and possibly cede the work onto someone else and finish the task faster.
All in all, working in a step by step manner may benefit you a lot, and prove your value as a foreseeing programmer, so give it a try when you plan your work next time. Good luck!