Some truth in there, but I have to admit that most simple static generators I have written I wrote out of fun and curiosity and not because I thought all existing ones had flaws (even if they did).
It is okay to do things and abandon them later, that is how we learn. We programmers are multipliers, which gives us special responsibility. If we create a shit tool with a shit workflow that wastes time, we waste time multiplied by the number of users of our software. If we save time or bring joy, the same is true. That can be beautiful and devastating.
But every software needs to be maintained somehow and maintainability is a technological choice as well. I have an embedded project running for well over a decade without a single maintenance step of either the hard- or the software. I could have built that project also with more dependencies to the outside world, or in more sophisticated ways with more moving parts, but I wanted to not deal with the consequences of that. This choice isn't always easy, but it is a choice. Ask your sysadmin which things worked for the past decades without having to touch them and investigate. Typically it is boring tech with boring choices.
Another aspect the article does not tackle is that if you know to repair or build many things, people will naturally also come to you asking you to do precisely that. But that again produces maintenance work and responsibility. This is why I like working in education, you can show people how to do it and then it is their project.
It is okay to do things and abandon them later, that is how we learn. We programmers are multipliers, which gives us special responsibility. If we create a shit tool with a shit workflow that wastes time, we waste time multiplied by the number of users of our software. If we save time or bring joy, the same is true. That can be beautiful and devastating.
But every software needs to be maintained somehow and maintainability is a technological choice as well. I have an embedded project running for well over a decade without a single maintenance step of either the hard- or the software. I could have built that project also with more dependencies to the outside world, or in more sophisticated ways with more moving parts, but I wanted to not deal with the consequences of that. This choice isn't always easy, but it is a choice. Ask your sysadmin which things worked for the past decades without having to touch them and investigate. Typically it is boring tech with boring choices.
Another aspect the article does not tackle is that if you know to repair or build many things, people will naturally also come to you asking you to do precisely that. But that again produces maintenance work and responsibility. This is why I like working in education, you can show people how to do it and then it is their project.