Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to learn to create/draw mental models for programming?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Ask HN: How to learn to create/draw mental models for programming?

#21

Post by jcutrell »

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.”

Your goal should not be to help him do something that is hard. It should be to understand how to make it easy.

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.

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.

Lower the stakes, focus on smaller problems, and find a shared vulnerability.

Re: Ask HN: How to learn to create/draw mental models for programming?

#22

Post by codingdave »

bane wrote: post #14
codingdave wrote: post #3

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.…

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".

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.

Re: Ask HN: How to learn to create/draw mental models for programming?

#23

Post by scoot_718 »

bane wrote: post #14
codingdave wrote: post #3

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.…

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".

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.

Re: Ask HN: How to learn to create/draw mental models for programming?

#24

Post by ltr_ »

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.

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.

Re: Ask HN: How to learn to create/draw mental models for programming?

#25

Post by DelightOne »

scoot_718 wrote: post #23
bane wrote: post #14

Earlier quoted context omitted.

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".

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.

What is being used instead?

Re: Ask HN: How to learn to create/draw mental models for programming?

#26

Post by truckerbill »

rathereasy wrote: post #11

Many of my former students had wildly inaccurate mental models so I built a platform that focuses on addressing that particular issue: https://wakata.io 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.

Hi, this is great. A few bits of feedback - let people skip lessons (those variable declarations are very tedious if you know what you're doing). It would also be good to automatically highlight the value field after creating a new frame variable. It takes about 4 keyboard actions to enter the value which is a bit frustrating. I get the forced restart is helpful for newbies to learn but I also found it a bit frustrating coupled with the interface.

Re: Ask HN: How to learn to create/draw mental models for programming?

#27

Post by ozychhi »

DelightOne wrote: post #25
scoot_718 wrote: post #23

Earlier quoted context omitted.

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.

What is being used instead?

Common sense

Re: Ask HN: How to learn to create/draw mental models for programming?

#28

Post by yboris »

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 in some cases help tremendously.

I started working on TypeScript Call Graph to see if it's useful -- an experiment of sorts [1]

Could anyone chime in about call graphs and whether they are useful?

[1] https://github.com/whyboris/TypeScript-Call-Graph/pull/1

Re: Ask HN: How to learn to create/draw mental models for programming?

#29

Post by AnimalMuppet »

ozychhi wrote: post #27
DelightOne wrote: post #25

Earlier quoted context omitted.

What is being used instead?

Common sense

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.

Re: Ask HN: How to learn to create/draw mental models for programming?

#30

Post by recursivecaveat »

yboris wrote: post #28

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 in some cases help tremendously. I started working on TypeScript Call Graph to see if it's useful -- an experiment of sorts [1] Could anyone chime in about call graphs and whether they are useful? [1] https://github.com/whyboris/TypeScript-…

My experience is that such diagrams are only useful if they are hand-designed, not auto-generated. To make a diagram with explanatory power in practice you have to make a lot of decisions about what's relevant, which requires a sortof mental model and some common sense. Jetbrains IDEs can generate call graphs, but they look like absolute spaghetti because they're totally dominated by omnipresent but irrelevant details, like exactly how the logger is threaded through the call chain, or that hundreds of functions call User.id(). Same thing goes for class diagrams. You wouldn't start explaining AbstractEvent by enumerating all 70 child classes, but a program will totally warp the whole diagram to fit them all. They also have the problem that some links are much stronger conceptually than others. A should have an arrow to B because it's semantically a container for Bs, but B having a member of type A because it knows its owner shouldn't even be displayed.
Post reply on HN