What does HackerNews think of unmaintainable-code?
A more maintainable, easier to share version of the infamous http://mindprod.com/jgloss/unmain.html
Fortunately masters in this art have codified it's techniques in this classic tome: https://github.com/Droogans/unmaintainable-code
* This is ridiculous. Why would you do this? Which made think of this quote: "Which is ridiculous and unnecessary but when has that ever stopped programmers?" from one of my favorite Tom Scott videos: https://www.youtube.com/watch?v=gocwRvLhDf8
* How to Write Unmaintainable Code: https://github.com/Droogans/unmaintainable-code
"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less."
Very ugly, ill-defined, uncodified democracy. No one tells you when you vote, no one counts up the votes, there are no official results.
When you speak or communicate with someone else, you are voting with them. "I vote this word means X, for a poor/crude/coarse agreement of what X is the first place."
And this is propaganda at its finest. Evil doublespeak: say one thing, and it actually is another. Snuck in.
Fantastic.
But what this article is actually about is about entanglement of individual parts. Under-engineered implies spaghetti code with lots of entanglement. Over-engineered code does have the minimum needed amount of entanglement.
Of course this is right on the topic of entanglement.
But this is not so much my understanding of the terms over-engineered vs under-engineered.
I understand over-engineered as having too much abstractions. And those can turn out to be the wrong abstractions when they are actually used, which then requires more work to refactor this.
I understand under-engineered as having too little abstractions, and having build in some assumptions which might hold for one use case but not anymore for others. This can also require some effort to fix this.
In practice, this is also a continuum, and you might even have both things mixed.
And when actually writing some new code, it is often hard to know the right amount of complexity.
This is why the overall quality greatly improves when you do a couple of iterations of rewrites from scratch. Because you keep improving on just the right needed abstractions.
Related:
http://number-none.com/blow/blog/programming/2014/09/26/carm...
It's one way to achieve job security for life though: https://github.com/Droogans/unmaintainable-code
For good general advice on productive criticism, I recommend How to Criticize with Kindness, by the philosopher Daniel Dennett. [1]
[0] https://github.com/Droogans/unmaintainable-code
[1] https://www.brainpickings.org/2014/03/28/daniel-dennett-rapo...
Doing valuable things in secret won't help you. Doing visible things whose value others don't understand won't help either.
Point 4 is a joke. It is better developed here: https://github.com/Droogans/unmaintainable-code . Your time is better spent on the other 3 areas.
Very well said. If only more developers would understand this.
Yes I know, creating interfaces, inheriting everything from the void, adding as large amount of layers to create the beautifully constructed reusable structure is a nice drive but it might happen no one will reuse it as doesn't want to dive itself trough infinite level lasagna with rolling ravioli around it (and - thanks god, go doesn't have try/catch - throwing exceptions trough all the layers to force you to go down the guts of the construct to figure out what it means). Or, as it often happens, will be forced to reuse it, complicating his life and is code.
I do understand that inheritance, even operator overloading has its meaning and is extremely useful. But it has another side - everybody are overdoing it as "might come handy later" and the code becomes a case for "How to write unmaintainable code"[2].
When I am coding I am not doing it for philosophical reasons and go has until now succeeding being a very helpful tool without much of "meaning of life" complications. And i would love to see it stay that way.
If you are forcing me to read the documentation / code (presumably I know what I am trying to solve) to be able to use the "beautiful oo construct" and forcing you to read your beautiful design, you have failed making it and I have seen it in java everywhere. I just hope the same people making everything complicated more than it need to be wont skip from java[1] train to go train. I really don't want them anywhere close.
[1]https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
[2]https://github.com/Droogans/unmaintainable-code (and 20 others)
That seems almost straight out of https://github.com/Droogans/unmaintainable-code (which has good anti-hints on naming)
If you can’t resist the urge to be a bit playful, use xerox for such a thing. Way more people would get that.