[codingdave]

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.

Finally, whatever he does, use the techniques he used to describe his old work to help him envision your code.

It is far easier to adapt pre-existing ways of thinking and working to a new topic than to ask someone to tear down years of habits and rebuild from scratch.

[bane]

You're not wrong, but learning how to draw out a system is a critical communication skill in almost every Engineering discipline. It's so important in Software that there's even an entire set of industry standard diagramming grammars for this under the umbrella "UML".

[codingdave]

I feel like UML was way bigger in the 90s. I haven't been on a team that used UML since 1998. To be fair, it seems like the Java community still uses it more. But I've seen a big backlash against tools that are so formalized.

[scoot_718]

UML is usually a bad smell rather than a best practice.

I've seen good sequence diagrams and good high level architecture diagrams, but nobody decent uses UML. It's far too cumbersome and at the wrong level for an explanatory diagram.

[DelightOne]

What is being used instead?

[ozychhi]

Common sense

[AnimalMuppet]

In a bit more detail, and perhaps with less snark:

UML has some decent diagrams. What they communicate, they communicate well. But don't diagram everything - that's a waste. When you need a diagram for something, a UML-ish diagram is fine. When you don't need it, don't draw it "just because". We're actually not in the business of producing UML diagrams.

[_y5hn]

Wonderful suggestion. Find the right medium first.

I think programming is an iterative approach. If he's experienced with existing codebases, adding features and bugfixing, the existing structure and design might still seem like "magic" - because someone else figured all that out. That historical process become "lost art" to those not involved. While most people can learn to follow a map, very few create the opportunity to sweat out the ability to be able to create the maps themselves.

In design, there's both a bottom-up and a top-down approach. Both are required for a software developer:

1) Have the person build a small meaningful project from scratch using the very smallest building blocks (ie. stdlib). Have them build on top of that again. Make them iterate on design and codebase. Refactoring becomes a natural learning experience in its own why and how.

2) Have the person design the simplest overall system architecture from memory as free-form drawings (or other preferred method). The fewer boxes and lines initially, the better. Have them iterate on adding details for components and subsystems. The idea should form how free-form drawing is natural and the results be usable in understanding, improving, optimizing, discussing and communicating.

3) Combine #2 and #1, preferably as free-form personal projects. Just this time you start with #2. Knowing #1 is solvable by iteration; iterate on #2 and try out designs in #1. Inventions should be prototypes that are thrown into garbage bin until satisfactory design and code structure, or a better idea, has arrived.

This is by no means easy for most or not time-consuming. So a person must learn to love the processes and intricacies of discovery and invention, in order to put enough effort to improve. If there's resistance to go forward with one approach, one need to invent other approaches that works individually, so that some progress can be maintained. Developers are problem-solvers after all.

Alternatively, there might be other type of work needed to be done that suits the personality better, and where results flow easier.

[neogenix]

That's a good point, I usually try to teach others to understand my reasoning, so I'll definitely try this approach and see how it goes.

[benjaminsuch]

I like your advice. I'm often asked myself if people understand me when I explain something to them. I will try your advice!