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.
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?<p>Next, ask him to add a new piece of work into that process, and see how he approaches it.<p>Finally, whatever he does, use the techniques he used to describe his old work to help him envision your code.<p>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.
Your junior colleague is trying to solve a few problems at once. This is overwhelming them, and likely frustrating them. They're trying to simultaneously solve, "Why do I need to represent data visually?", "What data am I trying to present?", "How can I represent this visually?", "How do I map these things in code to this thing on paper?" without understanding any pre-existing solutions to these questions.<p>In comparison, you have a mapping from "I have a problem" to "this type of diagram will help me solve it."<p>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?<p>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.
Many of my former students had wildly inaccurate mental models so I built a platform that focuses on addressing that particular issue: <a href="https://wakata.io" rel="nofollow">https://wakata.io</a><p>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.
I came across @mappletons[1] profile, she is behind the illustrations of egghead.io and has a blog and newsletter about visual metaphors for explaining tech concepts, highly recommended.<p>[1] <a href="https://twitter.com/Mappletons" rel="nofollow">https://twitter.com/Mappletons</a>
When I was a junior, I had similar problems. I can think of ideas, even solve problems and fix bug but when it comes to building something bigger, I was afraid. My problem the entire time was if soemthing goes horribly wrong. What if the data we are collecting is not stored? What if the code I am pushing is not properly documented? For me it was the fear of making mistake.<p>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.
Diagrams of system architecture usually mystify me. A common issue is that it’s unclear what the various boxes and lines and arrows represent.<p>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.
I have experience teaching complex software to uninterested field personnel, so allow me.<p>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.<p>There is a rare case that this doesn't work. But that is not your fault.
I've been surprised there isn't more of "Call graph" automatic generation for code. I would have thought having a visual representation of which functions call which functions can <i>in some cases</i> help tremendously.<p>I started working on <i>TypeScript Call Graph</i> to see if it's useful -- an experiment of sorts [1]<p>Could anyone chime in about call graphs and whether they are useful?<p>[1] <a href="https://github.com/whyboris/TypeScript-Call-Graph/pull/1" rel="nofollow">https://github.com/whyboris/TypeScript-Call-Graph/pull/1</a>
Are you sure it is just because he is junior (I mean that may very well be the thing but maybe not?) in my case I am not a visual thinker, in high school they tested my understanding of visual relations and I was in the lowest 3% of the population, understanding of written text I was in the highest percentile of the population (since then I believe visual has improved and textual degraded by all the stupid things I've done)<p>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.
Unless you're following a regimented and formalized diagram paradigm, drawing is no different than writing. You have to be comfortable with failure and starting over.<p>I love drawing, but also struggle to make my diagrams relevant and useful in tech applications (software).<p>On the other hand, diagrams in software have a long and rich tradition. One of the topics I discovered which was fascinating and highly informative was a course on Business Process Management from TU Delft on Edx (though I can't seem to find it now).<p>I was amazed to discover business concepts diagramed and executable! How's that for formalized.<p>Besides that, it might just be a case of visual literacy. Katy Borner of Indiana University [3] had a great MOOC, Information Visualization at Edx (though, again, it's not available now).<p>[1]: <a href="https://en.wikipedia.org/wiki/Business_process_management" rel="nofollow">https://en.wikipedia.org/wiki/Business_process_management</a><p>[2]: <a href="http://ebooks.iospress.nl/book/challenging-the-chain-governing-the-automated-exchange-and-processing-of-business-information" rel="nofollow">http://ebooks.iospress.nl/book/challenging-the-chain-governi...</a><p>[3]: <a href="https://info.sice.indiana.edu/~katy/" rel="nofollow">https://info.sice.indiana.edu/~katy/</a>
I've personally found that sometimes using a tool like PlantUML[1] or others (lot DOT graphs) to sometimes be easier to create visualizations with. It seems to allow me to focus more on various pieces as the big picture is built. It also seems to provide a great way of ensuring various parties thinking is similar. There are many more diagram types than many realize.<p>[1]: <a href="https://plantuml.com" rel="nofollow">https://plantuml.com</a>
Think of your experience and context as “ground floor.” You have a lot of it, which makes your starting point much higher than your colleague’s. Some things you are likely naturally taking for granted, he may have no context for. You can’t fake “taking for granted.”<p>Your goal should not be to help him do something that is hard. It should be to understand how to make it easy.<p>So, perhaps guide him towards the path of least resistance. He is likely not wanting to draw the wrong thing either; tell him to treat the first version as a draft and make him promise he will throw this one away.<p>Maybe draw something out for him and be willing to make mistakes in front of him, so he doesn’t feel self conscious about getting it perfect on the first shot.<p>Lower the stakes, focus on smaller problems, and find a shared vulnerability.
When I've taught friends to code I start with a program flow chart to describe the logic of the program.<p>Then when things get bigger than a single file/class I introduce the dependency diagram, which helps figure out which components depend on what... This helps you separate concerns logically<p>Some good tools which help:<p>- <a href="https://code2flow.com/" rel="nofollow">https://code2flow.com/</a><p>- <a href="https://draw.io/" rel="nofollow">https://draw.io/</a>
I used to always make pictures and I still do make a fair amount but it tends to be higher-level system or data/process flows.<p>When it comes to getting a handle on complexity, I find it better to list all the dimensions of variability and decide how they relate. Any before-and-after (but not necessarily during) invariants are gold. Then I can choose where/when to deal with which dimension(s) while other parts are agnostic to those.
For 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:<p>- What did you set out to do?<p>- What actually happened?<p>- Knowing what you do now, what would you have done differently?<p>- How does that generalize to a wider class of situations?
When 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.
generally a person that does not do programming have less friction with the topic if you approach him with a functional style. for example, try to get a proof of concept or a big picture of the problem in excel and build up from there. it does not have to be something complex, replace services and databases with simple rows.<p>As a programmer also I recommend to learn category theory, which is known for its diagrams (drawing!), its hard for a while, but when you get to adjunctions I found it makes easy to navigate any problem and as a consequence, you can explain/reason about it better.