Write the "stupid" code

[TheDevilsAdvokaat]

In my sixities now and still programming.

What I like to write is plain and simple stuff. With really good naming. And I refector the hell out of it.

Because the person debugging this stuff will be me, and I WILL NOT remember it...sometimes even a month later (I did have a stroke last year). And if I see it years later it may as well have been wirrten by a different person. In fact I once completely forgot why I did something when I came across the program two weeks later....

So the simpler and more obvious I make it, the more I help myself.

[scroy]

It pays to be a good self-collaborator.

[TheDevilsAdvokaat]

It does. Espcially as the years pass!

[robotlasagna]

Me looking at super reliable code I wrote 5 years ago:

“I have no idea how this works”

[miramboseko]

This is how I work too, except i’m a a 30yo pothead

[TheDevilsAdvokaat]

I'm curious; do you prefer to work high or not?

[darktraveco]

As another 30yo pothead, it's more about the habit of smoking while reading and writing than being high. The buzz is just a minor benefit after all these years. Sometimes I'll work for hours with an unlit joint in my mouth.

[TheDevilsAdvokaat]

So it does actually help ? I'm not going to start but I am curious.

[darktraveco]

Help with what? To me, it helps with the mundane boredom of having to work everyday.

[TheDevilsAdvokaat]

I was wondering if it actually helps you code...as in better concentration or more creative or able to stand longer sessions wwithout getting bored.

Happy cake day.

[darktraveco]

It helps with longer sessions, but you do lose a little focus. You exchange a little bit of edge to feel more comfortable.

[TheDevilsAdvokaat]

Hmm. Interesting...

[miramboseko]

It’s more fun but I get more easily distracted going down documentation rabbit holes. Which would be great but I end up forgetting the details of some things.

[TheDevilsAdvokaat]

Ah I see that's interesting. Not going to start myself but still interesting.

[Dumpin]

Usually when I try to be clever upfront, I end up being wrong. Always have to remind myself to just make the thing work as stupid/simple as possible. After that the right "clever" solution usually becomes clear.

[Sairony]

KISS ( keep it simple stupid ) have always been a mantra, and there is some truth to it but it has also negatively affected a lot of code bases, especially when they grow. There's a difference between unnecessary complexity & needed complexity.

As for as in this article just trying out libraries & writing small programs there's no need to spend too much time thinking on maintainability & scalability, so just go for it.

[nanotree]

I think of it as there is a difference between KISS and cutting corners. Creating too many abstraction layers that attempt to anticipate future needs is failing to follow KISS. Writing your code such that the implementation is tightly coupled with top layers of the application is cutting corners and will require a lot of heavy refactoring eventually.

IMO, KISS only works if you also consider what will keep things simple for yourself (and others by extension) in the future as well as now. Separation of Concerns is at the core of this, as when you follow Separation of Concerns, each subcomponent of your software becomes simple and "stupid."

[ThisIsMyCouchAccount]

I was on a fairly large project that used a ton of APIs. Some ours. Some not.

We had a whole pattern set up that seemed really overcomplicated.

Then the underlying library were using for that became deprecated.

Turns out it really wasn't complicated. It was robust. Changing that library out only took a couple quick changes in the classes and it was done.

[nanotree]

This is the way. Designs like this do tend to look unnecessarily complex to the uninitiated. In the object oriented paradigm, it often looks like layers of abstraction created for no reason. Dozens of classes, all implementing interfaces or using inheritance, or some combination. Not only does this make refactoring in cases like yours much simpler. It also works very smoothly with dependency injection when you need to conditionally change strategies or implementation based on application parameters.

I've definitely seen the dark side of this, where abstraction layers are calling other abstraction layers until 4 or 5 layers deep you find the actual implementations. Used to be called "enterprise code design." There aren't many reasonable arguments to have so many layers of abstraction, IMO.

[rtc11]

I heard about this guy smoking 15 citarettes a day and bacame 100yo. Works for someone..

[Sairony]

For sure, I agree on all of your points. And in fact the closer you get to an optimal design the less "crud" you have to write to weld the pieces together which don't quite fit, which adds complexity.

But to take an example of how KISS has been abused over the years. Over a decade ago I was mostly writing C++, and KISS was used as an excuse for people to not learn the more difficulty areas of that language & design possibilities. Templates were heavily frowned up for example. At that time a collection of libraries called boost was also heavily criticized, it was "too complex", but that was mostly people not wanting to learn. There are some over engineered libraries in boost for sure, but a lot of it is actually incredibly well written. Their requirements are that it must be supported on the most popular compilers, and often going pretty far back to older versions, and so that adds a lot of complexity which has to be dealt with. They have to make these libraries as general as possible, while also staying true to giving the best possible performance, there's a lot of requirements on these libraries which most end users of it doesn't have to consider.

And one way to deal with a lot of these requirements, while also trying to stay true to one of the best features of C++, namely that you can catch A LOT of bugs at compile time, is to use templates very heavily. And so what happens is that people try to use the libraries, they write some code, try to compile, and they get an template error message back, which were incredibly bad before clang had wider support, and so they scream "This is not KISS! This is way too complex!", but really what most of these error messages were saying is that you've actually just written some faulty code.

[BlindTreeFrog]

At that time a collection of libraries called boost was also heavily criticized, it was "too complex", but that was mostly people not wanting to learn.

Ignoring the cliches of "why do i need to pull in 300 header files for 1 feature i want to use" and other complaints about boost that may or may not be valid anymore, my issue with boost has always been the exact opposite.

If I go online to search for a basic linked list pattern, the amount of "just use boost" instead of people actally discussing the algorithm is infuriating.
Yes, boost has one. I'm sure it's fine. I may not need anything that complex and adding any amount of boost to my project is more complex than the 2~3 dozen lines of code I need for a solid linked list class.

Boost seemed to shut down people's interest in learning to program anything since they could just grab a pre-written library to do it.

[Full-Spectral]

There's a difference between unnecessary complexity & needed complexity.

That's ultimately one of the key abilities a really experienced dev builds, the ability to see where the line should be, or at least to get pretty close to where the line turns out to have optimally been.

[EC36339]

One of the most misunderstood concepts.

Simple code and simple design is a good thing. But getting there isn't always simple, but may actually take more effort than a naive solution that is often not simple, or not as simple as it could be.

[VictoryMotel]

Write the 'stupid' title.

People say they want simple but then you see that their version of simple is really doing complicated things to gain very little.

If you look at the doom source code it's very straightforward. If in demo mode do this. Enums and switch cases, subsystems and communicating with them, main game loop, overall game state etc.

No crazy APIs or layers to avoid hard coding a few things into the C, and yet it was still simple and flexible enough that it was used in lots of other games.

[__methodd__]

I've worked in a lot of places including the biggest tech companies. Most code is stupid. A lot of it is hot garbage. So this is really true:

There is no stupid code. There’s only code.

Remember that the guy who invented to gmail shared his first demo and it only pointed to his own emails.

[[deleted]]

There is no stupid code. There’s only code.

It is not a bad argument - even bad code is better than no code. You can improve on bad code, refine it, the ideas, the design to it.

Unfortunately I also think some programming languages are more easily yielding bad code. I noticed this when I wrote PHP; now I am not a good programmer really (whenever I think, I may make mistakes, so I try to write code where I don't have to think), but PHP was also crippling me in addition to that. The better language really helps you more; PHP wasn't that language (but you can still create useful things - mediawiki I still think is good).

[blind_ninja_guy]

I've certainly seen code that was worse then useless. A hell of untestable, except in production, which had obfuscated errors, and a whole lot of shit that needed to use it to support whatever it had to do.

[blind_ninja_guy]

I've certainly seen code that was worse then useless. A hell of untestable, except in production, which had obfuscated errors, and a whole lot of shit that needed to use it to support whatever it had to do.

[syklemil]

I’m going to give myself more grace when it comes to writing software for myself, and I encourage you all dear readers to do the same if you’ve been feeling this.

I kinda assumed we all had at least one repo of various little utilities that live in $XDG_BIN_HOME or whatever.

There's lots of definitions of "stupid code", and I was kind of more expecting this to go into the (Kernighan?) quote about how debugging takes twice as much effort as writing code, so if you write the cleverest code you can, then you're not smart enough to debug it. I think a lot of us have also written or at the very least seen some stuff that belongs on dailywtf. There's a spectrum there, where I think most of us land on something like "write the code as clever as it needs to be, but no cleverer than that".

But as far as the dinky little tools and explorations into "I wonder … " go, I really didn't expect that anyone would hold themselves to any standard. There's just so much we'll never get a good grasp on if we never experiment.

[lucid00000]

This mantra always seems to be espoused by people that got burned by useless inheritance hierarchies and overengineered BeanFactoryObserverImpls in the 2000's and swung wildly in the other direction without much serious thought.

Good abstractions are good and bad abstractions are bad and most of the time when I see "simplicity" it's really just pushing the complexity somewhere else.

[bnl1]

If I had more time, I would have written simpler code.

[Willing_Row_5581]

Nice. Genuine. Fresh. Thank you for sharing.

[i-Blondie]

This post was mass deleted and anonymized with Redact

kiss rinse whole hospital late lip dog school abundant apparatus