When I have a repetitive task, I tend to create an optimized routine that suits me best and follow it thoughtlessly each time I do the task. I don't stubbornly stick to a fixed routine, though. I gradually improve it based on experience or increased relevant knowledge. A routine could be called "the best method I currently know to do this job well." And when executing it, I just do it without overthinking. I only focus on each step.

For example, the apartment I live in has recycling pickup once a week. Even for recycling, there's an order for sorting things to throw away, and a sequence and method for grabbing the sorted recycling bag. A routine isn't something grand; it's light and everyday like this. Since there's a routine for such simple tasks, naturally, there's a routine for development too. I talk as if only I have them, but you probably have many routines, consciously or unconsciously. The more unconscious and primal they are, the more likely they are bad habits.

When I started working as a programmer, I initially created small routines almost unconsciously and proceeded with my tasks. I agreed with the saying "There's an order to work." Then one day, I encountered a short sentence from Kent Beck. "make it work, make it right, make it fast." In a way, this sentence clearly reflects the philosophy of TDD. While such sentences are open to interpretation, it was similar to the routine I was practicing at the time. I thought this way of handling tasks wasn't bad. So, I modified my routine further to fit the sentence. I started consciously thinking about routines, taking them seriously, and calling them routines. Almost 10 years have passed since then. My routine, interpreted from Kent Beck's sentence, is as follows.

The “make it work, make it right, make it fast” Routine

1. First, make it work

If the task at hand is already familiar, some parts of this stage might be passed quickly. This can be seen as the learning and prototype stage. Anyway, it's the stage of making the code perform the necessary actions, even if it's messy. If it's a familiar technology, the learning phase might be skipped. Otherwise, some R&D, big or small, is needed. While studying the necessary things, write code so that the requirements you're trying to solve are met somehow. The code doesn't have to be clean. You can try various things out of curiosity. Depending on the content, if TDD is applicable, meaningful Test Cases (TCs) should be created in this process. Ultimately, only the TCs might remain useful from this stage. The usefulness of TCs means that through prototyping or experiments, the module's interface design is somewhat complete, ensuring the module can fulfill its responsibilities and roles within the structure. The detailed implementation can be a mess.

2. Make it right

In the first stage, you might have learned a lot by trying things out while learning, but the code could be messy. Some code used during learning might be inefficient, leading to many detours, or there might be unnecessary or redundant code. And since only the code necessary for operation was implemented, it's likely very optimistic code, not considering the possibility of failure. Edge cases need to be checked. Supported user environments might need consideration too. For front-end, cross-browsing tests might be necessary. The impact of changed or added code on other areas or features also needs review. Side effects must be avoided. Anyway, it's about changing it into practical code using the best currently known (understood) methods. The second stage can essentially be seen as the refactoring stage. Refactoring is the time to fully concentrate on the internal code of the module, trusting the established interface and TCs. The goal is to improve the code while maintaining the input and output as much as possible. A single module might be split to increase cohesion or for a better structure. Thus, previously hidden functionalities can be reborn as separate modules with distinct roles and responsibilities. Regardless, if split, test cases must also be moved, added, or modified. Reaching the second stage generally means the task is complete. Now you can create a PR and request a code review.

3. Make it better

Right is different from better. Better is something beyond right. This is actually the hardest stage, and for familiar tasks, it might already be resolved in the second stage. It's the stage of finding performance bottlenecks or making the code use fewer resources. In this process, the cleanliness of some code might be sacrificed for performance. This third stage doesn't end with one go; it's a stage where additional work can continuously occur as you acquire related knowledge over time. You might even restart from the first stage for a better implementation. Kent Beck called the third stage "make it fast," but for me, it holds a broader meaning. I organize what I've learned in my personal knowledge database. I use a journaling tool called Day One to jot down realizations or learnings indiscriminately. Not just in the third stage, but throughout development. These recorded notes can be used to write and share articles or serve as conversation starters with colleagues. It's the stage of making better code or becoming a better developer.

The Need for Order

Each stage can be merged depending on the task, the order can change, and you can go back. However, I consciously try to distinguish each stage at every moment. The routine can be applied macroscopically or microscopically. It can apply to the developed module itself, and recursively to each specific specification of that module. Perhaps truly skilled developers can consider everything from the start and build it all at once – creating practical code while learning, considering performance, and making structurally perfect code. But for ordinary developers, considering everything from the beginning might prevent them from creating even the basics, wasting time. Worrying too much prevents taking even a single step. This leads to rushing under time pressure, resulting in a chaotic mess where nothing gets done properly. Even if you feel rushed, I believe you need to find an order that suits you, allowing you to climb one step at a time.

Routine is Habit

You can't always think about the best approach. For my toy projects, I often stop at the first stage. But the effort to make better code seems necessary for the developer themselves, rather than for the company or client. It's like, "Others might not know, but I do, right?" This line sounds like it's from a drama, it just popped into my head :) I believe this effort leads to an attachment to the code, an attachment to the profession, and sublimates into confidence. Maybe I went too far :) To achieve this, creating and following a routine is important, but I think there's greater significance in continuously learning, contemplating, and improving the routine. Methodologies for better coding keep emerging. TDD is also a routine. Here, another quote from Kent Beck comes to mind. "I'm not a great programmer; I'm just a good programmer with great habits." A routine is ultimately a habit.

Conclusion

The routine is abstracted in my mind so I can apply it to any task. For instance, if I need to write a report or technical document, first, I jot down the contents I want to write, randomly as they come to mind. Second, I organize the written text, change the order, and add substance to meet the intended purpose and level. In the third stage, I re-examine the work for errors, find logically weak parts and reinforce them, or request review from others and reflect on their feedback. First, do it; then, modify it to meet the purpose and expectations; finally, make it more plausible. If I had to put it in numbers, it's like making it about 0.5, then making it 1, and then making it around 1.2.

I still have a long way to go, but I believe that by striving to build good routines and good habits, I will definitely improve little by little and eventually become slightly better. At the very least, I want to create and develop habits that allow me to perform at my best within my current capabilities. This could include exercising, sleeping early and waking up early, meditating, etc. It's like boosting my 'ability efficiency,' similar to cost-effectiveness. If my ability is 1, I want to perform at 1 every time, not 0.8 or 0.9.