Nobody wants to be a user
=========================

[Published 2022-02-16]

If you are a programmer and you want to write some code to solve a
problem, there are two ways you can think about how to solve it.

1. "How do I use library/framework X to solve the problem?"
2. "How do I understand the problem so that I can make a solution?"

As a programmer I prefer option 2 because it's the option that lets me
do my job, which is to program.  Option 1 is not programming, it's
using a product.  Using a product is not fun.

This doesn't just apply to programmers.  If making food is your
interest, what you want to do is to make the food; you don't want to
buy something half-made and just add eggs to it, or just press a
button to let a machine make the food.  In general, I think that
people like to do the things they are interested in, not just pressing
a button to make a machine do it for them.

When I solve a problem by using a library/framework, I don't get to
enjoy the process of coming up with a solution and understanding the
problem, which programming is all about.  As a programmer, what I want
to do is programming.  Please let me be a programmer.

---

When you create a product for people to use, you are turning them into
users.  This is not a good thing because nobody is interested in being
a user.  People want to think about the things they care about, not
about how to use your product.  Using your product is not something
they want to do; it's something they have to do in order to get the
thing done that they care about.

When you add a library/framework dependency to a project, you are
forcing the other programmers on the team to become users.  That's not
a nice thing to do.  You are forcing them to use a product.

The best thing you can do, I think, if you have to create a product,
is to give the user as direct access as possible to the thing that the
user is interested in.

Here are some things you can do to minimize how much your users have
to be users:

- Make it easy for users to remove things they don't want.
  - Good: A program that can be uninstalled.
  - Bad: A program that can't be uninstalled.
- Don't make your thing dependent on other parts of your code.
  - Good: int foo(float bar);  // The user only needs to use
                               // your function
  - Bad: Result foo(NumberType bar);  // The user has to use both your
                                      // function and your types
- Don't make your thing dependent on other products.
- Don't introduce extra behaviors that are not already in the
  underlying problem.
  - Good: A programming language that has an obvious mapping between
    the code and the generated machine code.
  - Bad: A programming language that behaves differently from the
    machine.
  - (This example assumes that the user is interested in programming
    the computer more than some abstract ideas.)

So please, let people do what they are interested in, which is never
to use your product.