Tag: programming

When performing a task, even if it's a one-off, I believe it's a mistake to approach it with a short-term vision. We might solve many problems just for one occasion, but that's the nature of any project; each one is unique and happens only once. Should we really ship it with a short-term vision and skip automation, documentation, and testing just because they require more effort? Should we be so lazy?

I believe being lazy can be a good thing, but we shouldn't be so lazy that we skip essential steps like testing, documentation, information processing and retention, automation, collaboration, asking questions, and improving processes. These efforts will surely pay off for our knowledge and efficiency, or if not for ours, then for the team's knowledge and efficiency, for maintainability, and to reduce tech debt and bus factor. Of course, that requires thinking like a chess player, calculating our moves, and doing some planning.

For example, during an infrastructure migration, we faced many integrations that needed testing from the ops side, yet we lacked internal QA expertise. We rushed to collaborate with others to gather information on testing their flows. Even though we didn't have time to write automated tests immediately, I documented all the information so we could use it for future monitoring and automation purposes.

Another instance is our workspace setups, which were initially painful, yet many developers accepted it. When I had to use their setup script, I found many outdated or irrelevant steps and undocumented instructions. I automated those steps and fixed the instructions. Now, newcomers recognize the value of this, and even people external to the project can set it up without prior knowledge, saving days of effort and enabling easier contributions.

When I have to do a task, even just once, I try to make a script and document it. If I have to do it more than once, I try to automate even more parts. Each time I return to a task I'm becoming too familiar with, I feel the urge to improve the process, document and automate it, make it configurable, flexible, shared, robust, and efficient. When performing repetitive operations, I script them, always. At least partially if not fully. If mistakes occur, the fixes are likely to be automated or documented.

When asking for help, I provide context, and when doing something useful, I share the news or update the docs so people can be aware and benefit from it. I often receive positive feedback for this approach, as people start to realize that automation is more efficient, forgiving, and less risky than repeating operations manually.

Sometimes it's more tempting and fun to spend two days automating something rather than spending an hour running an imperfect automation hundreds of times. You have to balance the pros and cons of fun versus efficiency, depending on your priorities. However, it's risky to automate something you don't fully understand. You need to acquire some level of expertise in a topic before embracing automation and contributing improvements. It's dangerous to automate something you don't know how to run, debug, or test manually.

LLMs can help automate tasks, but you should be able to code and debug without them. You need to perform a task fully without LLMs or scripting before attempting to script it. It's good practice to study the documentation, API, and man pages of the tools you use and learn to troubleshoot effectively.

I believe every second counts, and even if we're solving a unique problem for the first time, the knowledge gained is worth documenting. This way, we can extract a process or history from it, which can be helpful for us, our team, or anyone else if shared.