4 ms·

One of the constant lessons I preach to my engineers is to make everything as simple as possible. You can always complicate it later if absolutely needed. Once

One of the constant lessons I preach to my engineers is to make everything as simple as possible. You can always complicate it later if absolutely needed. Once you make 20 simple things and start to mix them together, you are already in a combinatorial explosion beyond man’s comprehension. The good old devs know this instinctively. The young ones haven’t learned the hard way. The old ones who never learned the lesson must be avoided at all costs.

nunez 3y ago
Simple is in the eye of the beholder IMO
- sureglymop 3y ago
  That's true. I think that in reality, the complex has to "live" somewhere.. It is inherently present in the world. If the engineer simplifies their solution by relying on a dependency that abstracts away all of the complexity that doesn't mean the complexity is just gone. Should the engineer ever have to deal with that complexity, should that dependency break, they might be screwed. On the other hand, if they over engineered a more complex solution themselves, the engineer would at least know how to deal with it and fix it if it breaks. I would say usually the issue is lack of time to generate quality work (even if complex) and lack of time to adequately document it, mainly due to the "agile engineering" trend. It amounts to this: if there exists complexity, there must exist responsibility for that complexity (in my example in the form of the one engineer who created the complex component).
jxramos 3y ago
I also like language constructs which have constrained definitions, eg in python list and other comprehensions vs for loops. The comprehensions are very limited in their side effect outcomes and intent, the for loops are much more open ended. Don't use a more open ended construct when a more narrow one can be used. This is sort of analogous to the using narrowest scope possible rule of thumb, use the narrowest conceptual space when authoring software.

nunez 3y ago

Simple is in the eye of the beholder IMO

sureglymop 3y ago
That's true. I think that in reality, the complex has to "live" somewhere.. It is inherently present in the world. If the engineer simplifies their solution by relying on a dependency that abstracts away all of the complexity that doesn't mean the complexity is just gone. Should the engineer ever have to deal with that complexity, should that dependency break, they might be screwed. On the other hand, if they over engineered a more complex solution themselves, the engineer would at least know how to deal with it and fix it if it breaks. I would say usually the issue is lack of time to generate quality work (even if complex) and lack of time to adequately document it, mainly due to the "agile engineering" trend. It amounts to this: if there exists complexity, there must exist responsibility for that complexity (in my example in the form of the one engineer who created the complex component).

jxramos 3y ago

I also like language constructs which have constrained definitions, eg in python list and other comprehensions vs for loops. The comprehensions are very limited in their side effect outcomes and intent, the for loops are much more open ended. Don't use a more open ended construct when a more narrow one can be used. This is sort of analogous to the using narrowest scope possible rule of thumb, use the narrowest conceptual space when authoring software.