3 ms·

"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be a

"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well. In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be able to to mirror it.)

CaptainOfCoit 1y ago
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.
johnh-hn 1y ago
I think this is only half of it. Years ago, I worked at a company where my time was split between working on a bespoke platform for an older client and a generic platform that would be used for all clients going forward. The bespoke platform was essentially being used to fund the development of the generic platform. The contrast between the two was stark: the bespoke platform was legacy in all its weird glory, and the generic platform was considerably higher quality. Seeing that contrast up close, and flipping between working on each one, was immensely useful to me. It made it clearer why I favour certain approaches over others, and it made concepts easier to explain to others. Since then, I'm of the opinion you should aim to work with both the good and the bad to clarify the "why" of things.
cardanome 1y ago
I don't think code is inherently bad or good without defining the exact context and purpose of the code. It all depends on what field you are in, the business requirements, the team and so many other factors. What is the most important aspect: Easy to extend, easy to read or most optimal performance? Is your team more comfortable with the functional style of programming or OO? Do you follow existing conventions your team has established or current best practices? Do you implement everything yourself or do you use external libraries? Do you write code that makes you look smart using tech that looks good on your resume or do you use the simplest method to solve the program? The is no one right way to program.
- fragmede 1y ago
  > Do you write code that makes you look smart using tech that looks good on your resume > The is no one right way to program. Those two statements taken together makes me suspect you think there is.
  - cardanome 1y ago
    I do. I am not free of an ego. I just try to not confuse my taste for objective good or wrong though I sometimes fail.

CaptainOfCoit 1y ago

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.

johnh-hn 1y ago

I think this is only half of it. Years ago, I worked at a company where my time was split between working on a bespoke platform for an older client and a generic platform that would be used for all clients going forward. The bespoke platform was essentially being used to fund the development of the generic platform. The contrast between the two was stark: the bespoke platform was legacy in all its weird glory, and the generic platform was considerably higher quality. Seeing that contrast up close, and flipping between working on each one, was immensely useful to me. It made it clearer why I favour certain approaches over others, and it made concepts easier to explain to others. Since then, I'm of the opinion you should aim to work with both the good and the bad to clarify the "why" of things.

cardanome 1y ago

I don't think code is inherently bad or good without defining the exact context and purpose of the code. It all depends on what field you are in, the business requirements, the team and so many other factors. What is the most important aspect: Easy to extend, easy to read or most optimal performance? Is your team more comfortable with the functional style of programming or OO? Do you follow existing conventions your team has established or current best practices? Do you implement everything yourself or do you use external libraries? Do you write code that makes you look smart using tech that looks good on your resume or do you use the simplest method to solve the program? The is no one right way to program.

fragmede 1y ago
> Do you write code that makes you look smart using tech that looks good on your resume > The is no one right way to program. Those two statements taken together makes me suspect you think there is.
- cardanome 1y ago
  I do. I am not free of an ego. I just try to not confuse my taste for objective good or wrong though I sometimes fail.