[celticmusic]

I think it's more about recognizing that structure is like cement in that once it's laid down, it holds things in place and can be a pain to pull up and change.

For this reason, it's better to prefer as little structure as you can reasonabley get away with, not more. Now, this is a nuanced view, a senior person can absolutely insist on more structure up front and avoid issues, but they'll have a good reason for doing so that doesn't involve "it's clean code".

But in general, you want as little structure as you can get away with. It's a lot easier to change something that hasn't been abstracted to death with guesses about what the future is going to hold.

I think part of the issue is a perspective thing. If I spend a day throwing something together and it sits for 6 months, great. I got ROI from that code. If 6 months in new requirements come in and I decide I need to rewrite it, who cares. It worked day in and day out for 6 months off a days worth of effort.

Too many people view code as needing to be long lived and unchanging.

[Fr0styMatt88]

I totally agree. It's hard because management relentlessly pushes you to get things 'done', to move onto the next thing. That thing is done already, why do you want to touch it? Why is this thing going to take so long to do, didn't you do those other parts already? Sure, you can have some maintenance time later.... Maybe, I guess. No sorry this new feature is a higher priority. Also why aren't you quicker?

There's a lot of social pressure that pushes people to view code as a thing that's either done and permanent, or not done, unfinished and therefore unacceptable.