3 ms·

I find the biggest problem here is defining "simple" between developers. eg: Concise and simple are not the same and can be at odds with each other. The article

I find the biggest problem here is defining "simple" between developers. eg: Concise and simple are not the same and can be at odds with each other. The article does touch on it with KISS > DRY but I'd love to see more examples that aren't close to WET. Linters/static analysis is generally my first pass over a codebase that I inherit and rules/patterns can often find odd/archaic choices with simpler alternatives. I think writing code with a plethora of "automated eyes" provides some help with writing overall simpler code. Still, nothing beats experience and attention to simplicity.

drewcoo 5y ago
I call that expertise in simplicity "style." Style is what you don't do. Have a style. People have different styles. Sometimes they clash. That doesn't necessarily mean any of them are invalid, but they may not work together. It's easiest to work with people with complementary styles. For a challenge, work with people with contrasting styles. This is likely to fail but it's where real innovation comes from. You don't get the Beatles without both Paul and John.
- tonyarkles 5y ago
  > For a challenge, work with people with contrasting styles. This is likely to fail but it's where real innovation comes from. You don't get the Beatles without both Paul and John. I somewhat agree, although there are some "styles" that I've encountered over the years that are almost impossible to work with. Just like jazz, rock, country, etc. are different styles of music, there's very few people who will be happy listening to "child banging spoons on a pot". I spent a good portion of my career as a consultant that had to swoop in and pick up new codebases quickly; I've got my own style, and I've encountered a lot of styles that are different than mine that I can work with just fine, but yeesh, there's definitely just straight up poorly-thought-through and poorly-implemented code out there :) Yes, riff on different styles, and don't automatically write off anything outside your own. But also don't accept trash :D

drewcoo 5y ago

I call that expertise in simplicity "style." Style is what you don't do. Have a style. People have different styles. Sometimes they clash. That doesn't necessarily mean any of them are invalid, but they may not work together. It's easiest to work with people with complementary styles. For a challenge, work with people with contrasting styles. This is likely to fail but it's where real innovation comes from. You don't get the Beatles without both Paul and John.

tonyarkles 5y ago
> For a challenge, work with people with contrasting styles. This is likely to fail but it's where real innovation comes from. You don't get the Beatles without both Paul and John. I somewhat agree, although there are some "styles" that I've encountered over the years that are almost impossible to work with. Just like jazz, rock, country, etc. are different styles of music, there's very few people who will be happy listening to "child banging spoons on a pot". I spent a good portion of my career as a consultant that had to swoop in and pick up new codebases quickly; I've got my own style, and I've encountered a lot of styles that are different than mine that I can work with just fine, but yeesh, there's definitely just straight up poorly-thought-through and poorly-implemented code out there :) Yes, riff on different styles, and don't automatically write off anything outside your own. But also don't accept trash :D