Lazy coding done right

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.

Real DevOps do/dont – a list

[hint: this is not a serious post, I'm sorry if you feel attacked by this]

Inspired by Google search results for "Real Devs dont" (https://www.google.com/search?q=%22real+developers+dont%22).

  • Real Devs don't use UI - they use CLIs instead (https://terminaltrove.com/).
  • Real Devs don't need an IDE like VSCode, instead they code in production using Vim (and of course real devs use Nano. No, Emacs, https://xkcd.com/378/ ).
  • Real Devs don't use frameworks, they use libs.
  • Real Devs don't comment their code, there is no time for that.
  • Real Devs don't test their code, instead they throw all changes in production to save time.
  • Real Devs don't use their trackpad, instead they do practice touch typing (https://www.typingstudy.com/) and learn every app shortcut by heart, or build their own.
  • Real Devs don't need unit tests, instead they build programming skills.
  • Real Devs don't use debuggers, instead they stare at the stack trace for hours.
  • Real Devs don't joke or laugh at work, instead they blame every failure on poor colleagues competency.
  • Real Devs don't use Website builders, instead they code in raw HTML and CSS and throw JS away.
  • Real Devs don't trust anyone.
  • Real Devs use mechanical keyboards.

Honest tech definitions for dummies

  • AI Agent: a cheap junior employee who has root access to your system and production and will fake competency and waste your money. Have fun.
  • All-in-one calendar/messenger/file sharing app: oh, look, they generously manage your most sensitive data with good intent and cheap costs: your security and privacy is not a problem it seems. Run away even if it's free.
  • Anti-AI: someone using AI but bitter about it officially.
  • Application logs: something you stare at while thinking about the sense of your life.
  • Backups: something everyone is supposed to do but never does. Tip: you can have world-class data backups for free, feed them to some LLM prompt or share them in private LinkedIn messages or in private GitHub repo, they will likely leak later in some hack or some LLM output.
  • Bugs: something that occurs to you because you didn't RTFM.
  • CDN: a disaster waiting to happen.
  • CI/CD pipeline: a glorified shell script that compiles your code, usually wrapped in YAML or in Groovy or a messy mix of both. Nobody cares it until it breaks. If you are a developer, blame any pipeline failure onto the CI/CD tooling pretend your code works on your machine.
  • Coding: some ancien art you go back to after wasting 4 days debugging AI-generated code.
  • Contabo: cheap plastic VPS.
  • Cloud: a big garage with computers, related to random outages and expensive certifications.
  • CloudFlare: a tool to protect robots from humans trying to use internet.
  • DevOps person: someone debugging your code and your production environment.
  • Docker: a packager for your bloated app and your dependency hell.
  • DuckDuckGo: a private search engine hosted by big tech and using big tech search results and funded by big tech. Yeah very private.
  • Ecosia: a green washing search engine.
  • Git: a simple version control tool to make your life miserable.
  • Google search: a search engine for ads.
  • Hetzner: cheap VPS for your piracy stuff self hosted business applications.
  • Home hosted: piracy stuff or very sensitive stuff running on a Raspberry with zero backup. Do not mixup with Self hosted.
  • JavaScript: sugar for the web.
  • Kubernetes: because Docker wasn't complicated enough, this is a glorified infinite loop that restarts your bloated apps when they crash, and they will. It's also good to have on a resume.
  • LLM: a tool for text generation you can use to save you from developing skills. Some people call it general AGI. Ok, AGI, go win the lottery for me.
  • Newsletter: legal spam nobody reads.
  • Passkeys: a tool to prevent humans from using a tool on multiple devices.
  • QR Codes: links that force you to be glued to your phone and run a crappy app to avoid talking to human beings. It's the modern way to ordering anything. If you want I can generate infinite QR Codes for only 10$ per month.
  • Quantum: a marketing term to make any bullshit sound more legit. Oh, there is it, a quantum LLM.
  • Reboot: something you do when you are too lazy to RTFM.
  • RTFM: reading the manual is something you never do unless to prove someone else wrong or when it's time to understand the programming language you are using for ten years.
  • Self hosted: some barely secured docker containerized app running in some cloud like Hetzner. What is "self" about it? You decide. Maybe the fact it's installed by some human following a recipe. Impressive.
  • Spotify: a scam acting like a glorified Winamp clone that randomly removes content from your favorite playlists, rob you and artists.
  • Substack / Bearblog / Dev.to and other blog platforms: a recycle bin for your ideas.
  • Seedboxes: A place for exchanging free Linux distributions,.NOTHING ELSE of course.
  • the Onion, Le Gorafi: satire websites that compete with D. Trump for the most stupid headlines.
  • URL shorteners: a good legal way to ease phishing attempts. It's also a tool used to hide mostly useless sometimes good links behind magic ephemeral links. You remember that good site? Was it blb.lb/8378hdkf? Or goo.gl/hdk792? Who knew it would be such a terrible idea. Oh, did you see this new quantum URL shortener?
  • VPN: a glorified proxy.
  • Web scraping: a way to fix the lack of APIs. Also a lazy yet professional way to CTRL+C / CTRL+V content from websites.
  • YouTube: ads streaming service.

Prompting tips for maintenance tasks – Part 2

This blog is also a living document for myself so I can improve and reference this working pattern in the future.

Model selection

If using ChatGPT for coding tasks, especially maintenance tasks, opt for o1, other models are crap and will hallucinate or forget more of the original code.

Avoiding regressions

If the goal is to alter existing code, ChatGPT risks breaking existing code by removing as part of the end result, a good prompt is something like below, to reduce the amount of feedback loop and future debugging. This is the prompt I use when I want to optimize for retro-compatibility and avoid too much diff between old and new code.


[SPEC, aka insert-here your own description of your problem to be solved by ChatGPT/LLM, with instructions, followed by the text below]

Here is the code to be modified. I want the complete code as the final result, with the same number of functions as in the original.

Show me the final file with the modifications
.
Do not omit code for brevity, keep untouched code same as before, with no new comments and no change to existing code styling, syntax, indentation and comments.

[CODE, aka Insert here the original code to be maintained/modified/debugged by the LLM]

When ChatGPT is done with the code generation, I output the original and newer versions of the code in something like my favorite diff viewer for code changes, or something like https://www.diffchecker.com/text-compare/, and I review the differences. When it seems good, I test, then I commit.

See also


Soulless code

Code isn’t just a tool—it’s a reflection of the coder’s mind, a part of their soul turned into logic. When I write code, it becomes mine. I take care of it, I understand it, I think about it. Even when I stop working, the code stays with me, like a thought I can’t let go. It feels alive, like something I’ve created, something that matters.

But when the code comes from an LLM or someone else, it’s different. I might use it, but I don’t really make it mine. I don’t take the time to fully understand it. I let others—or the machine—do the hard work. And often, it feels easier to just start over or forget it.

This kind of code feels distant, like it has no home. It’s less work for me, and that can feel good, like letting go of something heavy. But at the same time, it feels empty—like something is missing.

Maybe when we stop owning our code, we lose more than just control. Maybe we lose a piece of what makes coding human.

// Functionally correct. Morally bankrupt.  
// Just like the rest of us.