5 ms·

Two of the many joys in life are: 1. Having a problem and solving it with a small amount of effort. 2. Having a mental model of some external thing and deligh

Two of the many joys in life are: 1. Having a problem and solving it with a small amount of effort. 2. Having a mental model of some external thing and delighting in seeing that your model is accurate with respect to the actual thing. Elegant, minimal systems excel at providing #2. Big sprawling systems with lots of options and special cases excel at providing #1. Many software engineers seem to be calibrated to extract a lot more joy from experiencing #2 than #1. It's probably something to do with the nature of the work. We work "backwards" by having a mental model of a thing we wish existed and then bring it into being. If we didn't find deep satisfaction in harmony between our mental model and software model, we wouldn't have the drive to keep fixing all of the bugs in our software. But there is nothing instrinsically superior to the joy of #2 compared to #1. It's just a psychological/emotional preference. Many people, if not most, outside of the world of software engineering seem to prefer #1. They just like to get stuff done and make stuff happening. You rarely see woodworkers lamenting about the variety of clamps, jigs, and tools they have. Instead, they delight in finding just the right specific tool to make a job easy. Fishermen love their tackleboxes. Of course, there is an appreciation of #2 in all of us, and you see minimalism everywhere. But I've never seen it raised to such a religious, moral level as I see in software engineering. It's important to remember that that's a psychological choice we're making—a personal preference we impose—and not something fundamental to systems.

wyager 5y ago
> Big sprawling systems with lots of options and special cases excel at providing #1. This is the sales pitch, but in reality you spend so much time configuring and debugging that you rarely actually save any time.
- munificent 5y ago
  > in reality you spend so much time configuring and debugging that you rarely actually save any time. Conversely, that's the sales pitch for minimalism. But the reality is that well-intentioned, thoughtful designers and users seem to end up spending most of their time building and using systems with a lot of complexity. If it really ended up costing them more time to use those systems, it begs the question of why we keep building them.
  - nyanpasu64 5y ago
    > it begs the question of why we keep building them. It's harder to build a minimal system which fits users' needs like a glove, than to stuff in options to fit each new issue discovered. So developers build complex systems (eg. I built corrscope's arcane settings system), often because they don't know the domain well enough to design a clean elegant solution with the right abstractions. But the resulting complex configuration system is harder to learn and use than the ideal solution (which may exist, may be possible to build, or may be impossible). Though minimal systems aren't always viable either, when different users may want different programs. Some people want MS Word for its WordArt, some people want tables of contents, some people want something like Markdown, some people want change tracking. Some people want Vim, some people want Emacs, some people want Notepad++, some people want an IDE. I want tabs in a terminal emulator, because I don't want to throw out my knowledge of stacking WMs which don't have tabs (I don't know why not, BeOS and Haiku are stacking WMs with tabs), and learn a tiling WM with tabs.
avgcorrection 5y ago
This is very insightful. Number 1 can be efficient but it isn’t satisfying if it was taken straight from a cookbook. > But there is nothing instrinsically superior to the joy of #2 compared to #1. It's just a psychological/emotional preference. I’m not sure about that. Feeling mastery and competence is intrinsically rewarding. And that’s easier to achieve with point number 2; if your mental model aligns more with the real thing then you are less likely to make mistakes and to have to look up reference material—you are less likely to get estranged from the task at hand.[1] And you are less likely to be bewildered by all the apparent complexity that surrounds you and that the sage old ones just tell you to put up with and to not question. I don’t think you would even mind being less efficient as long as you are in that sweet groove of point number two. [1]: Modernity + alienation: efficient misery.
- andy_ppp 5y ago
  Yes, the things we derive satisfaction from are because of our ability to slot things into a preexisting framework, proving our opinions correct (which we all love to happen) and releasing dopamine (probably). There is no such thing from applying a specific special case from a piece of software.
  - avgcorrection 5y ago
    I guess you could put it like that.
- munificent 5y ago
  > Number 1 can be efficient but it isn’t satisfying if it was taken straight from a cookbook. That may be true to one degree or another for you, but isn't universal. I also prefer to understand solutions (why pick #1 or #2 when you can have both?), but I have certainly been happy to see a problem evaporate even if I'm not 100% certain why. The result has its own value. > I’m not sure about that. Feeling mastery and competence is intrinsically rewarding. Yes, we all experience #2. My point is just that it's not intrinsically superior to other sources of joy. Preferring it is just that, a preference. There's nothing morally wrong with people who prefer to simply get things done, nor is there something fundamentally flawed with complex software that caters to that.
albertzeyer 5y ago
Out of my experience, #2 is often superior over #1 though. For some limited well understood context, well defined application, well defined task which will not be extended later and only lots of variations are needed, then yes, #1 is probably better. It's nice to have options like enable_fancy_feature=True. However, in practice, you often have none of these. The context is often not well defined. It's often not yet well understood. The application is not well defined, neither the specific tasks. The scope and tasks will likely be extended during the development. In that case, it can often turn out that you made the wrong abstractions, wrong options in case of #1. The software itself becomes more and more complex and becomes very hard to maintain, and new things which should be simple are now difficult to do because of too much interdependencies. Now, an elegant minimal system, or collections of small building blocks or tools, will turn out to be much more effective in solving some new task later on.
gizmo686 5y ago
The issue is where developers spend mostnof their time. Almost by definition, we don't spend time dealing with scenerio #1, because things just work and we are done. Where we spend our time is when things don't work. If it doesn't work, but everything fits our mental model, solving the problem is generally straight forward. We may need to see how everything fits together. We may need to add some logic to put things together correctly, but it is gennerally just a straight forward part of the job. When things don't work, and don't fit your mental model, the work becomes an exersise in frustration. Do that enough times and you start to develop callasus to avoid the frustration.

wyager 5y ago

> Big sprawling systems with lots of options and special cases excel at providing #1. This is the sales pitch, but in reality you spend so much time configuring and debugging that you rarely actually save any time.

munificent 5y ago
> in reality you spend so much time configuring and debugging that you rarely actually save any time. Conversely, that's the sales pitch for minimalism. But the reality is that well-intentioned, thoughtful designers and users seem to end up spending most of their time building and using systems with a lot of complexity. If it really ended up costing them more time to use those systems, it begs the question of why we keep building them.
- nyanpasu64 5y ago
  > it begs the question of why we keep building them. It's harder to build a minimal system which fits users' needs like a glove, than to stuff in options to fit each new issue discovered. So developers build complex systems (eg. I built corrscope's arcane settings system), often because they don't know the domain well enough to design a clean elegant solution with the right abstractions. But the resulting complex configuration system is harder to learn and use than the ideal solution (which may exist, may be possible to build, or may be impossible). Though minimal systems aren't always viable either, when different users may want different programs. Some people want MS Word for its WordArt, some people want tables of contents, some people want something like Markdown, some people want change tracking. Some people want Vim, some people want Emacs, some people want Notepad++, some people want an IDE. I want tabs in a terminal emulator, because I don't want to throw out my knowledge of stacking WMs which don't have tabs (I don't know why not, BeOS and Haiku are stacking WMs with tabs), and learn a tiling WM with tabs.

avgcorrection 5y ago

This is very insightful. Number 1 can be efficient but it isn’t satisfying if it was taken straight from a cookbook. > But there is nothing instrinsically superior to the joy of #2 compared to #1. It's just a psychological/emotional preference. I’m not sure about that. Feeling mastery and competence is intrinsically rewarding. And that’s easier to achieve with point number 2; if your mental model aligns more with the real thing then you are less likely to make mistakes and to have to look up reference material—you are less likely to get estranged from the task at hand.[1] And you are less likely to be bewildered by all the apparent complexity that surrounds you and that the sage old ones just tell you to put up with and to not question. I don’t think you would even mind being less efficient as long as you are in that sweet groove of point number two. [1]: Modernity + alienation: efficient misery.

andy_ppp 5y ago
Yes, the things we derive satisfaction from are because of our ability to slot things into a preexisting framework, proving our opinions correct (which we all love to happen) and releasing dopamine (probably). There is no such thing from applying a specific special case from a piece of software.
- avgcorrection 5y ago
  I guess you could put it like that.
munificent 5y ago
> Number 1 can be efficient but it isn’t satisfying if it was taken straight from a cookbook. That may be true to one degree or another for you, but isn't universal. I also prefer to understand solutions (why pick #1 or #2 when you can have both?), but I have certainly been happy to see a problem evaporate even if I'm not 100% certain why. The result has its own value. > I’m not sure about that. Feeling mastery and competence is intrinsically rewarding. Yes, we all experience #2. My point is just that it's not intrinsically superior to other sources of joy. Preferring it is just that, a preference. There's nothing morally wrong with people who prefer to simply get things done, nor is there something fundamentally flawed with complex software that caters to that.

albertzeyer 5y ago

Out of my experience, #2 is often superior over #1 though. For some limited well understood context, well defined application, well defined task which will not be extended later and only lots of variations are needed, then yes, #1 is probably better. It's nice to have options like enable_fancy_feature=True. However, in practice, you often have none of these. The context is often not well defined. It's often not yet well understood. The application is not well defined, neither the specific tasks. The scope and tasks will likely be extended during the development. In that case, it can often turn out that you made the wrong abstractions, wrong options in case of #1. The software itself becomes more and more complex and becomes very hard to maintain, and new things which should be simple are now difficult to do because of too much interdependencies. Now, an elegant minimal system, or collections of small building blocks or tools, will turn out to be much more effective in solving some new task later on.

gizmo686 5y ago

The issue is where developers spend mostnof their time. Almost by definition, we don't spend time dealing with scenerio #1, because things just work and we are done. Where we spend our time is when things don't work. If it doesn't work, but everything fits our mental model, solving the problem is generally straight forward. We may need to see how everything fits together. We may need to add some logic to put things together correctly, but it is gennerally just a straight forward part of the job. When things don't work, and don't fit your mental model, the work becomes an exersise in frustration. Do that enough times and you start to develop callasus to avoid the frustration.