this post was submitted on 21 Apr 2024
131 points (95.8% liked)

Programming

17432 readers
221 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 1 year ago
MODERATORS
 

I don't entirely subscribe to the first paragraph โ€“ I've never worked at a place so dear to me that spurred me to spend time thinking about its architecture (beyond the usual rants). Other than that, spot on

you are viewing a single comment's thread
view the rest of the comments
[โ€“] Dark_Arc@social.packetloss.gg 5 points 7 months ago* (last edited 7 months ago)

I agree; I prefer a "hammer and chisel" strategy, I tend to leave things a little less precisely organized/factored earlier in the project and then make a some incremental passes to clean things up as it becomes more clear that what I've done handles all the cases it needs to handle.

It's the same vein as the "don't prematurely optimize."

Minimizing responsibilities of individual functions/classes/components is the only thing that I take a pretty hard line on. Making sure that I can reason about the code later and objectively say simple sentences like "given X this does Y." I want all the complex pieces to be isolated into their own individual smaller pieces that can be reasoned about.

All of the code bases I've been in where I go "oh my god why", the typical reason is been because that's not true; when I'm in the function I don't know what it does because it does a lot of things depending on different state flags.