this post was submitted on 09 Oct 2025
45 points (100.0% liked)

Programming

23053 readers
111 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
 

I’m curious which software design principles you find most valuable in real projects.

Two concise summaries I’ve found:

you are viewing a single comment's thread
view the rest of the comments
[–] SpookyMulder@twun.io 1 points 2 days ago
  • Solve the problem directly in front of you. You are not as good at predicting the future as you think you are. (aka: YAGNI)

  • Organize your code around the problem domain, and name things accordingly. As a basic razor, consider someone seeing your codebase for the first time -- they should be able to easily glean what your app does, not just what language (Java) or frameworks (Rails) or design patterns (MVC) you might be using.

  • Each function must Do One Thing. And yes, each test case is a unit, too.

  • It must be clear to someone reading a function call what is expected to happen. Only use positional arguments when this is true and when order matters and is reasonably intuitive. Otherwise, always use named arguments.

  • Your tests must run quickly. Your code must build quickly. Your CI/CD pipelines must be measured in seconds, not minutes or hours.

  • Take nothing for granted. Declare all dependencies, and avoid implicit globals.

  • Use a linter, and enforce compliance. It doesn't matter what the rules are, but once established, avoid changing them.

  • Never isolate yourself from your team for too long. If you're working on a multi-day implementation, check in with the people who would be reviewing your code at least every couple of days. The longer you isolate, the more exhaustion and conflict you can expect during review, for both you and your reviewers.

  • Learn to work iteratively, validating minimal implementations that fall short of the full feature as requested, but which build up to it. As opposed to One Big Release. It helps everyone to experience and validate early and often how the feature feels and whether it's the right direction.

  • Never rush. Always take the time to build properly. Your professionalism and expert opinion is non-negotiable, even if (especially if) there's a deadline. I'm not saying to say "no" -- rather, just give honest estimates and offer functional compromises or alternatives when possible. Never "try" to do more than is reasonable.

A lot of this, I attribute to Martin's books ("Clean Code" and "The Clean Coder") and his Laracon talk from several years ago (you can find it on YouTube).