I've been programming all my life and creating drawings/diagrams of anything comes very natural to me. While this happens all the time in my head, I still grab a pen and paper sometimes when the mental overhead becomes too much.
Currently, I'm struggling with a junior colleague. He comes from a different background (sales). Adjusting existing code, fixing and improving features is not a problem for him, but as soon as something becomes more complex he struggles a lot - even simply drawing it on a paper completely blocks him.
I'm looking for advice or resources that can help him improve this skill.
Ask HN: How to learn to create/draw mental models for programming?
1–10 of 38 posts
Re: Ask HN: How to learn to create/draw mental models for programming?
#2Re: Ask HN: How to learn to create/draw mental models for programming?
#3First, 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.
Re: Ask HN: How to learn to create/draw mental models for programming?
#4First, 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.…
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.
Re: Ask HN: How to learn to create/draw mental models for programming?
#5https://c4model.com/
Thank you, this looks interesting.
Re: Ask HN: How to learn to create/draw mental models for programming?
#6First, 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.…
I like your advice. I'm often asked myself if people understand me when I explain something to them. I will try your advice!
Re: Ask HN: How to learn to create/draw mental models for programming?
#7For myself, a quick debriefing after something doesn’t turn out the way I’d liked seems to speed the process of learning from experience. It’s basically just taking a moment to answer a few questions:
- What did you set out to do?
- What actually happened?
- Knowing what you do now, what would you have done differently?
- How does that generalize to a wider class of situations?
Re: Ask HN: How to learn to create/draw mental models for programming?
#8https://c4model.com/
Is it still actual and worth time, or paid trainings is already sold? Because slack link is broken =\
Re: Ask HN: How to learn to create/draw mental models for programming?
#9When starting to program so much abstractions take place. So explaining code paths step by step really helps. Plus writing it out, makes it easier to tackle it step by step. Then taking this flow and explaining it to my senior give me great points to ask questions.
Re: Ask HN: How to learn to create/draw mental models for programming?
#10First, 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.…
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.