I played Go quite a lot. I switched to Chess recently and have played it way more for the last half a year.

As I was playing Go, one of the frustrating things was that I had difficulty figuring out which move was bad and why.

It’s a little bit easier in Chess. Even without a computer analysis, you can replay your game and find critical points. Oh… here I missed that they can do a fork. Oh… here they pinned my knight, and for the next ten moves, I had to dance around it. You will probably miss a lot of nuances, but you can immediately learn from your mistakes.

Getting back to Go. Quite often, understanding the explanation (why some move was bad) required reading ten moves ahead with multiple permutations, which was WAY beyond my abilities. As a result, it felt like — here is a good position, a lot of magic happens, boom, you are obviously losing.

The issue with such explanations is that to understand it, you need to be at the level where you won’t be asking it anymore.

There were numerous times when I felt similarly regarding some business/career advice. Communications are not my forte. To be more precise, I am good in a low-risk/high-respect environment. I am significantly worse at it in high-risk/adversarial situations.

So, there were numerous times when people who were WAY better than me (about communication in adversarial situations) gave me advice. Usually, it was advice on how I should structure my communication and what should be the fallback plans and what I should and should not say.

And lo and behold. I felt exactly like with Go analysis. The advice didn’t have anything explicitly wrong, but it was applicable to a person who is better in such situations (and who probably could have figured out such a situation on their own).

As I was thinking about it and when I was asked for advice. I kind-of formulated the following rules:

• Advice should elevate a person a bit. It’s an unreasonable expectation to try to bring a person to your level in one step (if the difference is way too big).
• Advice should give a good direction (while giving a person some wiggle room, taking into account that person can’t do a carbon copy of what you do).
• Advice should be actionable.

Just to give you an example from my area of expertise. I worked with a bunch of junior software engineers, and there is a standard question of how to get better/advance. And here are advice that I usually give:

• Read more (well-known) books about programming.
• Try to grab some not-trivial projects and work on them.
• Do what others won’t do (for example: write documentation, etc).

I don’t try to go down three levels down trying to precisely specify the order of execution, exactly what kind of non-trivial projects to work on, how to communicate about it with people and make it visible through the company.

If they follow my simple advice, they will become better and will be ready for more nuanced and complex conversations. And if I dump on their head buckets of extremely complicated advice, they will just snap back to their default mode of operations.

As I wrote in the title — Simplicity is the king.

Giving advice? Simplicity is king. was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.