Things nerds commonly have, but I don’t

Inspiration: https://forkingmad.blog/things-people-commonly-have-but-i-dont/

In a conversation recently with a colleague I casually mentioned I didn't have something. He was shocked... "but how then do you..." was the response.

So here's my list of don't haves

  • Spotify account. I have CDs and I've bought a CD player from KLIM. I just find the CD to be a very nice looking and collectible object, pleasant to listen to. Also I feel it's mine, and I like the creative goodies and packaging that you don't have with a digital copy of an album.
  • A NAS. I don't need a NAS to backup pictures or stream videos through Plex. I have a VPS where I run a Cloudron which hosts most of my web apps, one is for sharing my family pictures. And I also use Syncthing, and Dropbox to keep my photos in sync and backed up in several places. And next to that I use Plex but I just don't host it on my infra, I pay a provider for their generous bandwidth and for the fact they take care of streaming my content through Plex. It's so fluid. I couldn't and wouldn't maintain this at home.
  • A gaming machine nor a gaming chair. Seriously I do not see the point, because I consider most games do not require super advanced graphics or material to be fun. In fact I love minimalistic games with pixellated art. I'm old and also feel nostalgic of specific games that are all forgotten now. Anyway I'm developing the best game ever, which is the only one I play. More about this soon, when I'll buy the domain for the website, after I decide on a name.
  • A mechanical keyboard. Seriously, what's the deal is with those noisy expensive impractical keyboards.
  • A 3D Printer. Seriously, this is so cool to possess one, I just don't have the space for this now. Maybe when I'll have my own space in our future home.
  • A VPN. Sure it sounds secure but it's just someone else glorified proxy, and it's vulnerable to authority requiring logs or to any part getting compromised. You have to blindly and naively trust the VPN and people behind it to not disclose your information when their company will be required to by the authority. If different contexts I use them, i.e at work, of course, wherever it's mandatory.


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.

Empathy in Partnership

Partnership—aka living together—can be challenging, but it also opens the door to step up and lead by example.

  • Don’t take it personally if your partner is mad at you. It could be they feel unsupported, overwhelmed, or just tired.
  • Don’t respond in anger or with resentment if your partner yells at you. Stay calm and see how your help or support can improve the situation.
  • Don’t try to convince your partner at a bad time, like when they’re in a rush. Maybe they just need some time alone.
  • Don’t get mad if your partner can’t decide about simple things. Instead, try taking care of some of their mental load.
  • Don’t get mad when your partner makes mistakes, and don’t “remember that” later just to make them feel bad. It’s hurtful.
  • Don’t answer right away—listen and acknowledge your own mistakes, even if you want to justify your behavior. Keep those explanations for calmer discussions.
  • Keep your harsh words in your head.
  • Support your partner when it’s very difficult for you or when you feel like you’re imploding, because that’s how you grow into the partner they need.

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.

Piracy is now the rule, not the exception

This is so to the point: OpenAI Furious DeepSeek Might Have Stolen All the Data OpenAI Stole From Us (404media.co), thanks to Y. C. for sharing.

The question: if Meta and OpenAI are allowed to steal copyrighted content and make money out of it and out of any legal consent, and if all the LibGen/ZLib/Anna's Archive content was sniffed by AI models it means each of those big tech companies consider it is legal to steal content and grow their business without respect for the law. I would assume so that if this kind of act of piracy is treated as necessary for businesses, piracy is de facto legalized and commoditized.

They are all pirating content directly or indirectly by using AI models or libraries that make this content accessible to any mere mortal and for every business.

I do agree with Anna & their team, this is a clear evolution of the jurisprudence and a copyright reform is therefore needed. Until then, there is no ethical distinction between big tech and "pirates". See also Copyright reform is necessary for national security (annas-archive.li)