1. 23

  2. 5

    See also ‘maximizers and satisficers’. I wrote something about that aspect of this question a while back:


    1. 3

      if your goal is simply to accomplish some task, rather than spending too much time fretting about finding the perfect tools to accomplish the task with.

      To a maximizer, it’s not about finding the perfect tool to perform a task. It’s about finding the Right Way™ to do it. Rob Pike truly nails it when he says:

      C++ programmers don’t come to Go because they have fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it. To them, software isn’t just about getting the job done, it’s about doing it a certain way.

      For example, Stepanov is a maximizer:

      STL, at least for me, represents the only way programming is possible. It is, indeed, quite different from C++ programming as it was presented and still is presented in most textbooks. But, you see, I was not trying to program in C++, I was trying to find the right way to deal with software.

      Back to your post:

      In some instances, actually reducing people’s choices makes them happier. Python’s “one good way to do it” makes everyone happy, because both maximizers and satisficers know that they’re doing things right, and don’t have room to worry.

      To a maximizer, this is only as good as the extent to which they agree with the “one good way to do it” that Python suggests. Otherwise, they will have a lot to worry about.

      EDIT: Added example.

    2. 2

      I think it’s important for any kind of infrastructure decision to evaluate how commonly other people do similar things with the tool. Assuming a uniform bug density across functionality space, how much of that functionality are you going to be the first one to ever exercise? The more you’re using something in a way you haven’t heard of others doing, the more you need to be willing and capable of fixing the system yourself, or be able to wait on the maintainers to fix things. Just because a big name is behind the tool, it doesn’t mean it gets used at all in the way you intend to use it.

      Do bugs get fixed at all anymore?

      Are there people from outside the origin organization that contribute to an ecosystem of supporting tooling? Will the entire ecosystem become legacy when the hot SF startup that built it dies / cancels the project?

      Was it built by someone who has ever been on-call before? Or do you have to write telemetry into the system before you can safely deploy it?

      Am I going to have to teach the organization everything about it, or is there a rich ecosystem of existing documentation?

      Do the creators support graceful transitions across major upgrades, or do you need to write your own export/import tooling when bugfixes you depend on lie on the other side of the great migration?

      All this should be considered after actually determining semantic fitness, of course!

      1. 1

        When my students draw diagrams (E/R, Venn, …) using Preview.app’s markup tools I cannot really blame them, as it essentially gets the job done. However, using 100 circles to fill another circle with a color (I’m not making this up) does not quite seem right to me. Although I would have preferred a proper drawing tool (actually LaTeX/TikZ), which would look much more professional in my opinion, they solved the exercise. I still find it difficult to argue why I think the presentation is as much contributing to solving the exercise as the content. After all, we are communicating thoughts/information, I guess?