Now that we are clear on who the users are, we can develop a better understanding of their worldview. There is likely a massive disparity between the skills, experience, and domain knowledge between you and your users, and even between you and future you. This where most technical tools and software libraries fail. Think back to when you just started with Go. What did your code look like? Were there any language features in Go that you weren't using yet? Personally, I come from a Java background and, because of this, I entered the field with some preconceived ideas:

• I thought that threads were expensive (and that goroutines were threads)
• I thought that everything had to be in a struct
• Being used to explicit interfaces meant that I was not as enthusiastic about using the interface segregation principle (ISP) or the dependency inversion principle (DSP) as I am now
• I didn't understand the power of channels
• Passing lambdas around blew my mind

Over time, I have seen these sorts of things pop up over and over, particularly in code-review comments. There is quite an effective way of answering the question: What are the users capable of? Write an example and ask your colleagues the following questions:

• What does this do?
• How would you have done it?
• What do you expect this function to do?

If you don't have any users that you can quiz, another option is to ask yourself, What else exists that is similar? I am not suggesting that you follow other people's mistakes. The basic theory here is that if something else exists, and your users are comfortable with it then, if yours is similar, they will not have to learn to use it. This was perhaps best illustrated to me when using lambdas. Colleagues from a functional background were happy with it, but those from an object-oriented background found it either somewhat confounding or just not intuitive.