This is really good advice. Myself personally, I have been programming for decades as well and struggle with the curse of knowledge.
Curious what other people do and what struggles they have had.
Having spent time studying Category Theory I see a lot of value to using it in my code but it is not common knowledge and often confuses others when you start throwing around terms like functor, monoid, monad, etc.
At the same time I don't want to write code that isn't as reusable or to that isn't as maintainable.
Are we as an industry limiting our own potential by deliberately not using knowledge when it is beneficial for the sake of greater communication?
My personal philosophy when working with teams is to exclude some of that stuff but slowly introduce it and train junior developers on some of the concepts in the hope that I can push that knowledge forward.
Curious what others think of this dilemma and how they address it.
I also struggle with this issue, but I've never heard the term "the curse of knowledge." I'm happy I have a name for it now. When you try to explain to people that it's difficult to understand that other people don't know something that you know, you sound a little crazy.
Curious what other people do and what struggles they have had.
Having spent time studying Category Theory I see a lot of value to using it in my code but it is not common knowledge and often confuses others when you start throwing around terms like functor, monoid, monad, etc.
At the same time I don't want to write code that isn't as reusable or to that isn't as maintainable.
Are we as an industry limiting our own potential by deliberately not using knowledge when it is beneficial for the sake of greater communication?
My personal philosophy when working with teams is to exclude some of that stuff but slowly introduce it and train junior developers on some of the concepts in the hope that I can push that knowledge forward.
Curious what others think of this dilemma and how they address it.