[HN Gopher] How to help a programming student get unstuck
___________________________________________________________________
How to help a programming student get unstuck
Author : zekenie
Score : 197 points
Date : 2021-10-30 14:15 UTC (8 hours ago)
(HTM) web link (offbyone.us)
(TXT) w3m dump (offbyone.us)
| zanethomas wrote:
| All good advice. But...
|
| After teaching fullstack at a well-known university for a year
| and tutoring many students I feel that about 90% of them will
| never be competent entry-level programmers.
|
| There will be much disappointment ahead for the thousands (and
| thousands) of people being steered towards coding instead of to
| some more appropriate job (of which, I recognize, many have left
| the country).
| cturtle wrote:
| I do a lot of one-on-one programming teaching, and this really
| hit home with how I approach teaching. I especially liked the
| following:
|
| > You're not a machine. Every teacher and every student is
| different. The art of teaching is finding a technique that works
| for the situation at hand.
|
| Just knowing something (like programming) isn't enough to be a
| good teacher. It really is an art that takes time and caring to
| develop. Thanks to the author for putting my thoughts into words
| so well!
| jleyank wrote:
| Hell, it's Saturday and I feel talkative. If somebody is stuck,
| several steps come to mind:
|
| Do they understand the problem(s) they're being asked to solve?
| Toy or otherwise, this strikes me as a necessary condition.
|
| Can they express their solution in discrete steps? Software is
| brilliantly stupid, and must be told in detail what to do. This
| step should be independent of language, and is more of a logic
| exercise.
|
| Can they express their "discrete steps" in the language(s) that
| are required. This is an engineering problem that can be solved
| with references, practice, etc. Perhaps we can think of the steps
| stage as writing in ones native language and the implementation
| stage as writing in a nonnative tongue.
|
| Debugging. This is a generally applicable skill for any multi
| step problem. In the case of software there is language and
| hardware issues in addition to logic and understanding the
| problem space that usually make things worse. But I have found
| that if these two aspects can be separated things go much better
| than blurring the two.
|
| If needed, tuning can be seen as both a (re)design or additional
| debugging step which is outside the initial discussion. But aside
| from design, one should separate making something work vs. work
| fast unless they have a very good grasp of their problem and
| solution. Much of what we do is separable, as things like
| abstractions are so useful.
|
| If a student is struggling, the mentor can help them determine
| which step they are hung up on and the kind of nudging that would
| be most helpful. People who can create sound, stepwise solutions
| are useful - they can apply this to pretty much any environment.
| Knowing the nooks and crannies of a language without good
| logic/design merely creates hard to maintain code.
| throwaway2331 wrote:
| A lot of this is mirrored in "Code Complete" -- especially the
| part about expressing a solution.
|
| Most of it was self-evident information you would naturally
| pick up, as you made your way through your "programming
| journey," but the parts about planning were the ones I took
| copious notes on (and integrated into my own craft).
|
| If you don't know -- exactly -- what problem you're solving,
| then you're either gonna sit there dumbfounded, unsure of where
| to go from there, or you'll frenetically start brute-forcing
| the problem, trying -- sloppily -- everything you can think of.
|
| It never really occurred to me before I read that book that
| writing the actual software shouldn't be just about 95% of the
| process. ~40% should be planning: understanding the problem,
| understanding the tools you have available, and building out a
| rough outline of how everything's going to work (preferably in
| pseudocode comments you can then convert into actual code).
|
| Or that you could write code without painstakingly testing
| every few lines to make sure you "did it right" a la code
| cowboy.
|
| Wasted a lot of time, and spent too many nights up on caffeine
| trying to force my way through a problem (albeit it usually
| worked, with the cost of having to rewrite everything ;).
| jleyank wrote:
| Yup. That was on of the books I read, along with the
| pragmatic programmer and other most technical, Unix-y things.
| People always said I was a step by step kind of guy and that
| seemed to map well to programming/hacking. Although it helped
| seeing external reinforcement to solve things ina logical
| manner without skipping steps.
| andai wrote:
| > you could write code without painstakingly testing every
| few lines to make sure you "did it right"
|
| This technique would eliminate many of the bugs I create
| (mostly careless mistakes), if I could be bothered to do it,
| so I'm surprised to see it presented in a negative light.
| pxc wrote:
| It's tedious, and tedium is unpleasant. What's surprising
| about that?
| ChuckMcM wrote:
| This is all solid advice. I also note that new managers of
| programmers should read it as well. Managers feel the weight of
| the responsibility for the project and when one of their
| engineers is stuck it puts the schedule at risk. For new managers
| especially, their instinct is to just tell the engineer how to
| fix the problem.
|
| That solves the near term schedule risk but does nothing to
| prevent recurrence.
|
| When I'm managing software engineers I try to make it really
| really clear that getting stuck is a "known" thing and getting
| unstuck is a "learned" thing. So to come to me early when they
| are stuck so we can practice ways to get unstuck. If they wait
| too long to ask for help, it is a much bigger problem. (and when
| I am programming for someone I can be just as bad at not asking
| for help soon enough) for one of my employees who was an ex-
| marine and really really didn't like asking for help, I got him
| to think about it as asking someone in their unit to provide
| covering fire, that is "help" and essential to achieve the
| objective. They understood that reference really well and we got
| along great after that.
|
| My point being that everyone is a teacher to somebody, so when an
| article that frames the teaching as instructor to student, don't
| make the mistake of thinking it doesn't apply to you. There are
| things to learn in there.
| lordnacho wrote:
| > Once you understand how it works, it's extreamly challenging to
| imagine not understanding it. This can be problematic when
| teaching because it creates a gap between teacher and student.
| Even the most empathetic teachers can't quite imagine themselves
| in a student's shoes.
|
| This reminded me of my old engineering tutorials. Where I went to
| uni you have these 2/3-on-1 sessions with a tutor to go through a
| weekly sheet of questions across subjects.
|
| After a short time, we came to the conclusion that the more
| decorated the tutor, the less good they were at teaching. I had
| people spanning from just-started PhD students to professors who
| were members of various academies. The more letters they had
| after their names, the harder it got to pick up anything from
| them.
|
| The professors had a couple of things going against them. First,
| they were no longer warm hands. Too long since they themselves
| had to analyze transistor circuits. They might know something
| about how the state of the art is done on an industry grade
| computer, but no way they could go back to hand drawings of toy
| systems. They also probably wouldn't know quite how to operate
| that state-of-the-art system themselves, but trust a postdoc to
| do it. Second, they were busy. Really really busy, mostly with
| the business of running a lab. A lot of not-analyzing undergrad
| level transistor circuits. A lot of grant proposals.
|
| So when you got one of these highly decorated people slumming it
| with the undergrads, they just wouldn't know what it is you
| didn't understand. The best were people who'd just done the
| course not long before you, and understood what to say to trigger
| you to think the right way. They'd been down the same dead ends,
| the same oddly worded questions.
|
| This is why I'm no longer so interested in my kids having a lot
| of professor time. You often hear people complaining their
| expensive degrees are taught by TAs, but in the end the professor
| guy would not do much better for the kid.
| rpmisms wrote:
| Every engineering manager who works with juniors should read
| this.
| MeinBlutIstBlau wrote:
| I think what a lot of instructors fail at is they don't give
| students a working example of how something works. Sure you're
| not really going to learn, but what's the point of me having a
| half-assed assignment that isn't useful for me referencing a
| couple years down the road?
|
| The simple best way to program is exposure, and a lot of it. Not
| these boring petty tasks we do. They're logic puzzles and not
| much else. Showing someone how everything works from start to
| finish in creating a website with a specified framework helps
| tremendously. Or how to work with low level C programming making
| practical applications.
|
| For myself personally I developed a method of TODO's with some of
| what my lead taught me mixed in. My lead doesn't like redundant
| code, but said "working code is better than no code." So what I
| did is made one type of TODO that means "this code sucks or
| should very much be revised." Another one I have is "talk to my
| lead." With those, I don't address it with my lead unless we
| already have a meeting and it'll be quick, or I compound enough
| of them to devote an actual meeting regarding them.
|
| Overall it has helped me stay organized, and it keeps me from
| annoying my lead. So what I'd add is, a system for people to make
| their own notetaking is vital when learning. If you don't have
| that or arent willing to take the initiative to do that,
| personally I think coding is not for you.
| rablackburn wrote:
| I love that taxonomy of TODOs, I'm stealing that ;)
|
| > I think what a lot of instructors fail at is they don't give
| students a working example of how something works. Sure you're
| not really going to learn, but what's the point of me having a
| half-assed assignment that isn't useful for me referencing a
| couple years down the road?
|
| Like everything else in life it's a balancing act (or a chicken
| and egg problem). In a university/college context in particular
| it's not about being practical, it's about learning the
| (hopefully up-to-date) theory. There are concepts, classes of
| problems, and mental tools in computer science that are
| extremely valuable, but if you don't teach them explicitly you
| have everyone reinventing the wheel, and worse, doing it
| without a common vocabulary.
|
| But as a student you can learn/memorise some concept (let's say
| recursion as an example), but you never really 'get it' until
| you've struggled with a real-world problem and realised that
| recursion solves it elegantly.
|
| Sometimes the way we teach reminds me of hypnopaedia/sleep-
| teaching in Brave New World:
|
| ``` A small boy, asleep on his right side, the right arm stuck
| out, the right hand hanging limply over the edge of the bed.
| Through a round grating in the side of a box a voice speaks
| softly.
|
| 'The Nile is the longest river in Africa and the second in the
| length of all rivers of the globe. Although falling short of
| the length...'
|
| At breakfast the next morning, 'Tommy,' someone says, 'do you
| know which is the longest river in Africa?' A shaking of the
| head. 'But don't you remember something that begins: 'The Nile
| is the...'
|
| 'The-Nile-is-the-longest-river-in-Africa-and-the-second-in-
| length-of-all-the-rivers-of-the-globe...' The words come
| rushing out. 'Although-falling-short-of...'
|
| 'Well now, which is the longest river in Africa?'
|
| The eyes are blank. 'I don't know.' ```
|
| The takeaway (in the book at least) is that rote-learning like
| that has no value because its not conscious knowledge (but it's
| great for _moral_ lessons, like 'Ending is better than
| mending'). But I've lost count of the times where I've come up
| against a problem that niggles at the mind and realised I
| learned to solve it years ago at university, and it all falls
| into place. If nothing else, you know what to google for.
|
| So I've come around full circle on how theory-heavy
| universities are (if we don't teach theory at university, where
| would we teach it?), but agree that there's a huge benefit to
| student experience by pairing it with exposure to full systems.
|
| The older I get the more I find myself regretting (/resenting)
| how we've off-loaded so much job training to universities. You
| know how students can get exposed to real-world systems and
| learn real-world lessons? By having them recruited by real-
| world companies who invest in their development.
|
| Seems like a CS degree would be most useful after you've been
| working with real-world code for ~5 years. Perhaps we need to
| split out most of the content of the current undergrad degrees
| into a CS equivalent of an MBA? Let the undergrads focus on
| practicality (ie, making the MIT missing semester the core
| experience), then come back in a few years to learn all the
| "correct terms" for the problems you've been coming across and
| learn the best-practice/optimal approaches.
| dimal wrote:
| > If you find this useful, let me know, and I'll write another
| one about helping students who are pair programming.
|
| Just want to say, I found this very useful! This is a problem
| I've been trying to solve recently, with only some limited
| success. (I also want to second the other comment about providing
| an RSS feed.)
| zekenie wrote:
| Thanks! Will do
| zekenie wrote:
| Done! https://offbyone.us/feed.xml
| kodah wrote:
| This may be good advice for programmers that learned in an
| academic setting, but as someone that taught themselves this
| would drive me nuts. I still struggle with abstract problem
| solving in problems that I haven't solved before. A lot of
| algorithm based interviews I'll totally flunk the first time
| around. Depending on the interviewers behavior I've either bailed
| out from there or tried to learn something.
|
| More helpful is backing up and framing the problem to be less
| abstract. When learning to code, we're learning new ways to
| represent things that we likely already intuitively know. In that
| way, you're teaching expression. The two are taught very
| differently, imo.
| [deleted]
| taldridge wrote:
| As someone who is also largely self taught in cs terms, it's
| actually very amazing to me how even very abstract ideas which
| seem to be very far away from a "solution" to a "problem" often
| fall into place very nicely.
|
| For example consider a unification algorithm (e.g.
| https://reasoning.page/29021/unification-sort-of-in-rust which
| is an explanation of it that I wrote). The individual parts of
| it do not seem that spectacular, and also seem quite abstract.
| It is so simple (in my mind) that it could not possibly be
| correct. However, there is an emergent property when the
| interactions between the different parts of the program are
| taken together.
| exdsq wrote:
| HTDP has a nice 7-step process to designing programs and suggests
| teachers ask the student to point to which step they're stuck on,
| to help formalize it a little bit in their minds. I quite like
| it.
| marginalia_nu wrote:
| Is there a general process for solving problems? These last 25
| or so years I've been programming I've mostly just been
| thinking about the problem until I have a solution. Sometimes I
| go for a walk but that seems pretty hit-and-miss.
|
| My process seems to boil down to not realizing I was supposed
| to get frustrated and give up.
| Jtsummers wrote:
| _How to Solve It_ by Polya is about math, but can be used
| more broadly.
|
| https://en.wikipedia.org/wiki/How_to_Solve_It
| marginalia_nu wrote:
| If it's just a matter of following this algorithm, why do
| we still have unsolved problems?
| [deleted]
| Jtsummers wrote:
| I don't understand your question, I didn't say it was
| _just_ a matter of following this algorithm or process
| described in the book. You also have to possess the base
| knowledge that feeds into it, which is described in the
| book in a mathematical context.
|
| Even then, it's a set of heuristics and guidelines.
| Neither the book nor my comment claim it to be truly
| universal.
| cyb_ wrote:
| Note to author: I couldn't find a RSS/Atom feed for your blog.
| Would be nice to have one so those of us who avoid Twitter can
| still follow you.
| zekenie wrote:
| Good point. I'll add that
| zekenie wrote:
| Done! https://offbyone.us/feed.xml
| hdctambien wrote:
| This is pretty much how I taught my High School Computer Science
| classes.
|
| The biggest step for me was to never touch the student keyboards.
| And then I basically only answered their questions with more
| questions.
|
| Sometimes I would hear students grumble "He never answers my
| questions...", But in the long run, they would start asking
| themselves the same questions they knew I would ask (what did you
| expect it to do?, what did it do?, Why did it do that?)... Then
| they would usually solve their problem without me!
|
| Or, when they called me over they would start with "I tried a, b,
| and c" and got results x, y, and z" which is a way better start
| to a learning experience for everyone than the old "it doesn't
| work, fix it, please"
| devwastaken wrote:
| This works if the student already has a grasp of how to write
| software. The new teacher here does your method with new
| students just learning the syntax, and it's a failure. Treat
| them like they're learning french. First comes meaning of
| words, then how they're applied. Examples of it, what it means,
| and then how you change what it means to mean something else.
| Practice and Exposure is the only way to effectively learn any
| language. These students are going to entirely forget what a
| for loop is after their class and switch majors when the next
| classes depend upon fluent understanding.
| andi999 wrote:
| I still think there are also questions which are best answered
| straight, like 'how many bytes does a float have? Do arrays
| start with 0 or 1 in this language? Is printf of %s with null
| argument, undefined behaviour, implementation defined or
| actually standard conforming'.
| Siira wrote:
| Finding the answer in the docs is itself a skill, so even
| these simple questions might best be not answered directly.
| MathYouF wrote:
| Those kind of questions are a great opportunity to show a
| student where to find documentation and how to read it,
| because that is a daily journey that will never end.
| Zababa wrote:
| Did you find that this method resulted in less, more or the
| same number of students that just couldn't follow? I've been
| thinking about this a lot as in France we have a few
| "alternative software school" that use the "basically figure it
| our yourself" method a lot, and while it's sometimes
| frustrating as an experience, it really prepares you well for
| what you're going to face.
|
| I intuitively think one flaw would be that less student would
| be able to finish the studies, but on the other hand these
| students wouldn't probably make it in the professional world
| either.
| atoav wrote:
| In my eyes learning to programm is on of those things that is
| a out a stract connotations or ideas how we think something
| functions much more than actual experience.
|
| When you learn gravity, of course you can watch an apple
| falling from a tree and fogure it out yourself. But you could
| also watch an apple falling from an tree, try to figure it
| out for a while and then get a fascinating deep dive in the
| physics behind it, and then take another dive at the issue.
|
| Just by presenting the issue in the right way instructors can
| make the difference between people who struggle to grasp
| something and people who already have the right abstractions
| in their head but only need to figure out what it means in
| practise.
|
| The worst peogramming instructors are those who are like: "It
| was nearly impossible for _me_ to learn this, why do you
| think it would be easy? "
| andai wrote:
| I think many of them do make it, and that's not necessarily a
| good thing.
| cinntaile wrote:
| Can you elaborate? It's not clear to me why that would be a
| bad thing.
| mandelbrotwurst wrote:
| I can't speak for the person you're replying to, but I
| suspect the idea may be that the students are able to
| "make it" in the sense of holding down a job, but not in
| the sense of being particularly competent / productive.
| polishdude20 wrote:
| I think this method of teaching works well if this lines up
| with how the students are evaluated. The students willingness
| to accept this form of teaching is entirely reliant on how they
| feel this will impact their final grade. That's why it's
| important to align your grading and evaluation style with your
| teaching style if this is what you expect from students. That
| way, they'll be more inclined to go with the flow knowing that
| it won't bite them on the other end when it's time to take a
| test.
| Buttons840 wrote:
| > Sometimes I would hear students grumble "He never answers my
| questions..."
|
| Did you ever explain why you are doing this? After walking a
| student through their problem I would praise them and point out
| they solved the problem themselves. Some people may perceive
| your style as you being annoyed or unwilling to fully help, so
| explaining explicitly why you're helping that way would be
| good.
| civilized wrote:
| I had a teacher in high school who played the mysterious guru
| game. Instead of answering questions, he would say nothing
| and smile kind of creepily.
|
| He was good, but his mysterious guru bit wasn't why he was
| good, and he should have dropped it.
|
| All this to say, yes, explaining why you're doing things as a
| teacher is better than just doing them and mystifying people.
| tshaddox wrote:
| Yeah, I don't see the point in just stubbornly only
| responding with more questions. As an instructor you could
| actually instruct. Why not say "a good technique when you get
| stuck is to ask yourself these 3 questions..." instead of
| just cryptically asking the questions and hoping they come to
| this amazing epiphany that _wow my instructor wasn't just
| being cryptic because they're a jerk, they were doing it to
| teach me!_
| pxc wrote:
| When I tutored computer science at the community college, I
| often felt like some of our students were constantly trying to
| trick me into writing code for them. Idk if other tutors often
| did that for them or what, but it was frustrating for me.
|
| Avoiding getting sucked into touching their keyboards was what
| I had to do, too.
| hnarn wrote:
| I don't mean to sound cynical, but it's possible that these
| students simply got away with this strategy for their entire
| academic "career" up to that point. I.e. complain about the
| difficulty of the task, throw your hands up, ask for "help"
| enough times until the teacher basically solves/explains the
| entire problem for you and then just copy their exact
| solution.
|
| The idea that a teacher should ever touch a student keyboard
| in a computer science or programming class to me is absurd.
| Ozzie_osman wrote:
| > The same principle applies when learning how to code. Once you
| understand how it works, it's extreamly challenging to imagine
| not understanding it.
|
| There's a formal word for this, the Curse of Knowledge.
| https://en.m.wikipedia.org/wiki/Curse_of_knowledge
| zekenie wrote:
| Oooh, thanks. I added a footnote to it and gave you a shoutout
| MeinBlutIstBlau wrote:
| My teacher in both my Architectures and AI courses had this
| bad. Still to this day have no idea how any ML works in python
| or what the purpose of keras is or how it does any processing.
| Or why certain 1's and 0's churned out of a breadboard.
|
| All I can tell you is that I learned nothing and just paid to
| get them done.
| pedrosorio wrote:
| > just paid to get them done
|
| Paid whom to get what done?
| SilasX wrote:
| Weird, I seem to mostly not have that problem, and vividly
| remember the confusions and mysteries. I'm constantly jumping
| in to improve others' explanations that assume too much. I've
| started calling myself "the translator".
|
| Maybe I should take some teaching role?
| rablackburn wrote:
| All the best teachers I've worked with have this skill. I use
| the "translator" analogy as well.
|
| Though I've found it's not so much "remembering" the
| confusion and mysteries from your own past, but paying very
| close attention to the student(s) so you notice as soon as
| there's some divergence in their mental model from what
| you're trying to relate.
|
| Stop, slow down, address the assumptions you didn't even
| realise you were making, and it's amazing how much complexity
| and knowledge you can seemingly transfer into someone else's
| brain.
|
| Of course they'll forget 2/3 of it over night, but it's
| easier next time, and once they've "gotten" it (and the
| corresponding endorphins) once they've got way more
| motivation to keep going.
| SilasX wrote:
| > paying very close attention to the student(s) so you
| notice as soon as there's some divergence in their mental
| model from what you're trying to relate.
|
| Yes! I call it "finding the NePoCU", Nearest Point of
| Common Understanding.
|
| Edit: or rather, the technique I use to identify where I
| can start explaining from.
| yawnr wrote:
| I'm kind of the same way and have always really enjoyed
| tutoring.
| coverband wrote:
| These suggestions are pretty useful, and most would apply in
| other teaching domains as well. Thanks for sharing.
___________________________________________________________________
(page generated 2021-10-30 23:00 UTC)