4 ms·

"The very best developers are capable, and avoid complexity. The next best developers are capable, and love complexity. The worst developers are not capable."

by vp8989 6y ago

"The very best developers are capable, and avoid complexity. The next best developers are capable, and love complexity. The worst developers are not capable." It's not always in one's control to avoid complexity. The simplest solution to a problem in a lot of cases may be 2-3x the lift (simplicity tends to require more work, complexity is easy) and thus blocked by the business. A holistically simpler solution may be blocked politically because a certain team doesn't want to own some functionality etc ... I would say the best developers can see complexity coming and have a healthy fear of it, the medium devs don't mind complexity and the worst devs can't get anything done without increasing complexity.

ZephyrBlu 6y ago
It seems like a lot of people are too lazy to simplify things though. You see this a lot with writing as well. It's very easy to ramble on, it's very hard to concisely convey your point.
- 8note 6y ago
  Simplifying usually requires other people to do work. That's much harder than doing less simple work on your own team
zmmmmm 6y ago
> The simplest solution to a problem in a lot of cases may be 2-3x This is such an important point. For whatever reason it has become ingrained in people's heads that the simplest solution must by reductionist logic be the easiest one. And therefore the easiest solution is the simplest one and it is good to be lazy and just introduce complexity everywhere.
- jacobr1 6y ago
  The "right" solution is usually the one that models the underlying complexity of whatever phenomenon the the systems is addressing. If you make it simpler, inevitably you'll grow the system to address those use cases. Sometimes this is good, you don't want to err on the side of an overly-complex system. By this reasoning, I usually find building of evolvability and maintainability the be stronger guiding principles. This is where the whole "MVP" concept got out of hand. MVP didn't mean an overly-simplified prototype. It meant solve one, narrower, problem well. This also pairs well with PGs "do things that don't scale" advice. You are taking on what others might think of additional complexity, to solve a very targeted problem more effectively from others, because using either deeper analysis or first-principles or whatever, you've actually better modeled the underlying complexity. Then you try to scale given those insights.

by vp8989 6y ago

ZephyrBlu 6y ago

It seems like a lot of people are too lazy to simplify things though. You see this a lot with writing as well. It's very easy to ramble on, it's very hard to concisely convey your point.

8note 6y ago
Simplifying usually requires other people to do work. That's much harder than doing less simple work on your own team

zmmmmm 6y ago

> The simplest solution to a problem in a lot of cases may be 2-3x This is such an important point. For whatever reason it has become ingrained in people's heads that the simplest solution must by reductionist logic be the easiest one. And therefore the easiest solution is the simplest one and it is good to be lazy and just introduce complexity everywhere.

jacobr1 6y ago
The "right" solution is usually the one that models the underlying complexity of whatever phenomenon the the systems is addressing. If you make it simpler, inevitably you'll grow the system to address those use cases. Sometimes this is good, you don't want to err on the side of an overly-complex system. By this reasoning, I usually find building of evolvability and maintainability the be stronger guiding principles. This is where the whole "MVP" concept got out of hand. MVP didn't mean an overly-simplified prototype. It meant solve one, narrower, problem well. This also pairs well with PGs "do things that don't scale" advice. You are taking on what others might think of additional complexity, to solve a very targeted problem more effectively from others, because using either deeper analysis or first-principles or whatever, you've actually better modeled the underlying complexity. Then you try to scale given those insights.