Almost any advice is useless if you write code purely for your own enjoyment. This is why the context is so important. If you enjoy writing convoluted unmaintainable useless code then who is to stop you? Just understand most advice does not apply to your context.

Most software development advice tacitly assume you want to write code which works and is long-term maintainable (potentially by someone other than yourself) and which fulfills some purpose beyond just the fun of writing the code.

> If you enjoy writing convoluted unmaintainable useless code then who is to stop you?

Does anyone actually do this? I think it's the opposite.

I've spent truly absurd amounts of time thinking about how to do things properly. I read books, read other people's code, read programming language implementations, I just read and learn as much as I possibly can before I even start doing anything. I want my code to be right. I want it to represent the truth of how the world works.

In a professional context where people actually have deadlines, working code is usually enough to satisfy them. How complex and maintainable it is tends to be a lesser concern, to be addressed at a later time or never.

> > If you enjoy writing convoluted unmaintainable useless code then who is to stop you?

> Does anyone actually do this? I think it's the opposite.

Code style, structure, and design are more of an art than a science, so different people will have wildly different opinions (extreme examples notwithstanding).

I don't think anyone deliberate writes unmaintainable code except as a joke. Hard to maintain code happen when some other objective takes priority - performance, abstractions, architectural purity, DRY or whatever else a developer might enjoy focusing on.

The most maintainable code tend to be the least clever. But developers enjoy being clever, so without any outside pressure to deliver maintainable code, developers will tend towards less maintainable code.

And, as the article says, your advice and the GP’s are contextual.

If you’re interested in creating software that makes people happy, solves their problems, gets cherished and recommended - then work hard to not lose sight of that goal in the thick of crafting a massive code edifice.

If you’re interested in pushing the limits of your own creativity, and building a technical structure capable of handling domain complexity with ruthless efficiency - then sure, don’t worry too much about how it looks, how it reads, or how others respond to it.

If you’re lucky, you might get to do both in the same body of code. But not likely.

Even if YOU are the only user, you're still writing software for a human.

Hopefully.

With that argument you could say that everything humans ever did was for humans. So either it is a platitude or it is wrong.

You could say that, but my cat thinks you'd be wrong.

However, I'm yet to see my cat boot up the computer.

Ultimately pets are for humans, whatever you do for your cat you do for humans. The same logic works there.

With cats it's the other way round: the humans for cats.

And from a computers perspective all human work is ultimately for computers. Either making them or feeding them data. The purpose of the cat is to generate cat pictures for the computer etc.

My cat would often turn the computer on or the tv off, and I swear he did it on purpose because that's when he was complaining he didn't got enough attention.

My cat has turned off my computer on me - does that count?

You’re writing software for all of your future selves.

http://www.catb.org/~esr/writings/unix-koans/prodigy.html

Thank you for posting this. I feel understood.

But then we can also go the other way, and forget how crazy and diverse humans are. So you will still, eventually, end up facing the same challenge, framed differently.

Well, you could create software as art. Basically to create it for the fun of creating it, not to use it.

But yeah, the end result is useless then, and can be thrown out.

Or, like some art, of variable degrees of folks caring about it based on other interesting properties - and made for some purpose other than maintainability.

Demoscene, obfuscated coding contests, etc. seem to fall under that category.

Uselessness in the eye of the beholder or something like that.

But in those cases you are creating for other people. The point was made about software that didn't have any use for any people.

In those cases, only the creation itself has a use, not the end result. By definition.

Don't forget to write for future you. They'd appreciate some consideration as well. Mostly along the lines of "wtf does this module do?"

The best one for me was documentation to complicated for me - by me.

You seem to have a complicated relationship with your past self. I foresee further trouble in your future. Its best if you take a torch or you'll be eaten by a grue.

> when you don't care about the users and just do it just for the fun of doing it

Yes!! That makes me so happy.

Or they write it for themself and not _other_ humans.

Your future self can be seen as “other” humans given a long enough time frame.

Anybody who has looked at their own code done more than 5 years ago can surely attest.

5 years is optimistic. A lunch break can be enough.