3 ms·

I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only r

I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only remaining option left after removing the "bad" ones. It's also way easier to find out why something is "bad" vs why something is "good" for some reason, not sure why. In the end, all code comes with tradeoffs, so I'm guessing we're really talking about good/bad tradeoffs, rather than the actual code itself.

hellisothers 1y ago
I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.
- matthewkayin 1y ago
  In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them. I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths. In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well. In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.
RangerScience 1y ago
It works better if you “split the axis”; (imo) good code is easy to modify, bad code is hard to understand. Everything else is, as you say, trade offs, and so only evaluatable within a specific context.

hellisothers 1y ago

I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.

matthewkayin 1y ago
In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them. I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths. In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well. In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.

RangerScience 1y ago

It works better if you “split the axis”; (imo) good code is easy to modify, bad code is hard to understand. Everything else is, as you say, trade offs, and so only evaluatable within a specific context.