11–20 of 38 posts
It teaches JavaScript, but most mainstream programming languages have the same semantics. It's particularly challenging because building a good mental model of programming takes a lot of time and effort.
Consider that it might be that your way of drawing diagrams only make sense to you; unless you are able to state clearly what a diagram illustrates, you might just be confusing your colleague by using drawings.
First, I'd stop trying to make him draw - not everyone draws out their systems to think them through. I'd ask him to think about the most complex process he had in his prior role, and teach it to you - pay attention to how he is teaching it. Is he drawing it? Talking about it? Writing it down in a flowchart? With bullet points? Next, ask him to add a new piece of work into that process, and see how he approaches it.…
Draw a state machine, send it a few events, let him follow it with his finger. For a state machine, all he needs to do is to keep the last state in his head.
There is a rare case that this doesn't work. But that is not your fault.
[1]: https://plantuml.com
In comparison, you have a mapping from "I have a problem" to "this type of diagram will help me solve it."
At my first job out of college, my boss was obsessed with diagrams. He made sure that every person on the project could reproduce the system diagram. This means that I was personally given multiple years of instruction on how to visually represent data by someone who was very patiently correcting me. Are you willing to give someone that type of attention?
If you want them to learn the skill in a useful time horizon, and they're willing to improve, you're going to have to practice with them. Pick a thing they know well. Walk through an explanation of the system with them as you diagram it. Then have them draw the system while explaining it and having access to your diagram. Then have them reproduce the diagram without looking at it. This is the beginning - you'll need to do this a lot before they start to internalize a thing you've practiced for years. Over time, you'll realize that you can leave out some of these steps, and over time, they'll have enough bootstrapping that they can produce novel types of diagrams themselves.
At any rate I have always struggled to draw or diagram a solution to a problem. I like to write out a paragraph describing it.
In case of simple bug fixes and minor feature addition, my supervisor would be checking everything so I didn't have to worry. For builidng something bigger, no one would be checking everything line by line. I was own my own and afraid to push my code. My team helped me overcome that fear by showing it's okat to make mistakes and nothing happens if you do that. Make mistake, test code, fix bug... it is an iterative process and nothing to worry.