this post was submitted on 01 Jan 2026
12 points (92.9% liked)

Programming

24336 readers
135 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] squaresinger@lemmy.world 1 points 1 week ago (1 children)

A principle is something you follow blindly, something that doesn't need a judgement call, and these do exist. Stuff like "Don't use goto", "Structure your code well", "No compiler warnings" and so on.

Something like the Liskov substitution principle.

That's why modern guidelines and styleguides separate stuff into "must" and "should", and a principle is always a must.

[–] calliope@retrolemmy.com 2 points 1 week ago* (last edited 1 week ago) (1 children)

I think you could be assuming a different definition of “principles” than Bob Martin was when he wrote them.

They weren’t “principles” like “a basic law or assumption.” It’s the second definition, principles as “a standard of good behavior.” (Such as in Cambridge’s definition here).

That is, using the “should” and “must” phrasing, I’ve always felt the SOLID principles were obviously more “should” than must. Good behavior is “should” but not something you follow blindly.

[–] squaresinger@lemmy.world 2 points 1 week ago (1 children)

Not sure if SOLID was meant as "should". At least when I was at university it certainly was taught as "must" and a lot of coworkers of mine also treated it as "must".

But anyway, it's super old stuff. SOLID was created in 2000. That's a quarter century ago and a ton has changed since.

Even Clean Code will be 17 years old this year. It's time to revisit all that, and most of it is just not nearly as good as it looks.

[–] calliope@retrolemmy.com 3 points 1 week ago (1 children)

I’ve never met a decent, experienced developer who held these as incontrovertible truths. Lots of junior developers for sure. Maybe that’s a lot of what’s left.

Experience proves that holding a dogmatic view of “musts” for things like this is frequently an issue in itself. Maybe it’s time everyone tried to learn that lesson again.

[–] squaresinger@lemmy.world 2 points 1 week ago* (last edited 1 week ago)

I think simple "musts" can be helpful on an organizational level to synchronize work. Stuff like "must use one of the approved languages", "must use git", "must use a linter with a given preset", "must get rid of all compiler warnings". That kind of stuff just makes working together easier, but neither of them are dogmatic truths but just stuff to make organization and working together easier.

But I agree that dogmatic views for broader subjects are very often harmful but at the same time rarely bring a lot of benefit. I've worked at a project before where the former lead dev was a really bad and dogmatic developer who managed to get to this position through intimidation. He followed "Clean code" to excessive lengths, which meant that it was quite common that a simple 1 Story Point change required touching 40+ files. Hardly any method was longer than 5 lines, hardly any class had more than one method, everything was split up like crazy.

Imagine writing code, but instead of lines you use classes instead.

I have met quite a few long-term developers with senior titles and sometimes even lead dev or architect titles who follow dogmatic views to the extreme.

I agree that no decent developer would, but that's a bit of a circular definition (since being dogmatic precludes you from being decent).


And I totally wished universities would be better at explaining that design principles are decent guidlines if you don't have any other basis to make a decision, but that they are ultimately tools in a toolbox and a good developer needs to understand when to use them and when not to.

Too many people come out of university thinking that SOLID or Clean Code are the bible.