3 ms·

> I deliberately try to make things complex, but not more complex than they actually are I don't understand. Is it an elaborate way to say that you expose your

> I deliberately try to make things complex, but not more complex than they actually are I don't understand. Is it an elaborate way to say that you expose your juniors to the full complexity of the problem, rather than feeding them a "simplistic" view of the problem? > This is more often due to insecurity than accident or technical ignorance and while their motives are often unintentional (non-cognitive) the actions are often exceedingly deliberate (cognitive decisions). I don't understand. It looks like they are actually "cognitively" doing their job to me, that is they try to separate the essential complexity from the accidental complexity. They are trying to cut the Gordian knot, I don't see how this is linked to insecurity. Maybe you should simply tell them that someone already did that job and they should not second-guess them? > Again, its all about risk or performance in the product versus the individual developer's confidence displayed as a convenience. No, the convenience is to do as Mister Senior Developer said, as a good code monkey, so you can leave early and work on your side project.

austincheney 8y ago
Economically speaking, the problem is. It isn't necessarily complex or simple. Whether, or not, you are willing to accept that there is are risks and possibly second or third order consequences to your approach is the true complexity. Exposing the fullness of the problem isn't a creation of complexity. The same amount of complexity is already there unchanged. Are your juniors willing and capable to account for this to devise a simplistic resolution that actually lowers risk and with the smallest amount of code? Conversely are they imposing unnecessary layers of abstractions to remove themselves from the directness of the problem? Another way to think about it in "junior" terms is whether its simple or easy. Those aren't the same.
- nomel 8y ago
  I really like this view. I see problems as a messy graph. There is a node on the far left that represents the problem and a node on the far right that represents the solution. There are nearly infinite ways to traverse this graph to complete the problem, but there is a minimum number of nodes that must be passed, along some optimal path, in order to actually solve the problem, as defined. No less is possible, unless you change the problem. I think being able to see something close to this minimum complexity, and that it is the problem, is what you’re referring to. After identifying this, the problem/solution nodes can be reassigned intentionally.

austincheney 8y ago

Economically speaking, the problem is. It isn't necessarily complex or simple. Whether, or not, you are willing to accept that there is are risks and possibly second or third order consequences to your approach is the true complexity. Exposing the fullness of the problem isn't a creation of complexity. The same amount of complexity is already there unchanged. Are your juniors willing and capable to account for this to devise a simplistic resolution that actually lowers risk and with the smallest amount of code? Conversely are they imposing unnecessary layers of abstractions to remove themselves from the directness of the problem? Another way to think about it in "junior" terms is whether its simple or easy. Those aren't the same.

nomel 8y ago
I really like this view. I see problems as a messy graph. There is a node on the far left that represents the problem and a node on the far right that represents the solution. There are nearly infinite ways to traverse this graph to complete the problem, but there is a minimum number of nodes that must be passed, along some optimal path, in order to actually solve the problem, as defined. No less is possible, unless you change the problem. I think being able to see something close to this minimum complexity, and that it is the problem, is what you’re referring to. After identifying this, the problem/solution nodes can be reassigned intentionally.