Time: SATURDAY, October 15, 2022 12:00 noon Eastern Time (US and Canada)
Bring your projects and puzzlements. Let the community lend a hand.
9 AM Pacific Time
Noon Eastern time
1300 São Paulo
1600 UTC
1700 London
1800 Paris
2130 Dehli
Beginners especially welcome!
Really fun session today!!! Here is the video and supporting file from our lesson: Tinderbox Meetup- Meetup 15OCT22 Parsing Highlights in SKIM.
Video: Tinderbox Meetup 15 October 2022 on Vimeo
Chat log: meeting_saved_chat.txt.zip (1.7 KB)
I thought it very interesting, not least because—as part of solving a problem in real time—it tripped over a number of real world confusions relating to (‘each’) loops:
var variables have to be declared, why aren’t they for loops? Tech-trained readers: check your privilege here before replying. One person’s ‘obvious’ rule is an unguessable magic incantation to another. Disclaimer: I have a foot in both camps here.These sort of things are, at best, only obvious after the fact.
We whizzed through the topic in the meet, but I sense the task would be useful to revisit in much slower time. Indeed, using some of the mis-steps, as recorded† are useful to show how intuition is often a false friend. Sawing off the branch upon which you are sitting might feel like the right thing to do, but still ends badly.
None of the above speaks ill of the contributions made. the mis-steps in the recording show the errors we all make in the moment. With more time/less rush, we might make fewer mistakes. But, our real aim is to make no mistakes.
†. Seeing mistake can be helpful. It’s useful to see those we think ‘know’ the answers mess up, as we all do. It doesn’t make the hill we have to climb less steep but it does make the possibility of our arrival at the summit more believable. We tend, for concision, to edit out the mis-steps, but I’m coming to see that in a learning scenario they are often more usefully left in: the ‘expert’ is only making the same mistake a learner will.
The problem we solved today was, in essence, the problem we tackled on October 1: Tinderbox Meetup 1 Oct 2022 on Vimeo : how do you split a long notes into chunks? Of course, many details differed, but it’s the same problem at root.
In October 1, I presented a working solution, and explained each part. This time — perhaps more instructively— we worked through the problem from the start, line by line. And (as it happened) mistake by mistake.
I think it’s a good pedagogical approach to try out, once in a while!
One thing to keep in mind is that it’s a big design space, and there are lots of ways to address the problem. @mwra, in the meetup, was inclined to do it this way:
You can do it that way! What we ended up doing was:
I don’t entirely agree that “our real aim is to make no mistakes.” I think it’s fine to make lots of mistakes, which is a good thing because that’s the way I program. The goal is to wind up with the correct solution.
Far from it, amen. mistakes are how us mere mortals learn.
I have to laugh as the method you relate is what (yes!) I thought in the moment. Or rather to do the former, I applied the latter.
The point I was driving at as someone mired in the valley between formal CompSci/programming and no understanding of that is the the differences you eloquently describe aren’t—to those new to ‘coding’—so different. That’s why I think seeing these mis-steps is useful. I’m also old enough to not be embarrassed be seen making the sort of mistake most of us do. The social media age makes us afraid of error, yet most of my most insightful learning has come from my own mistakes or watching those others generous to share their errors†.
†. This is something really flawed in a lot of tech teaching. Of the various trades/professions I’ve worked in, software is the most coy about the fact that your first try will probably fail, but in a way from which you can lean. Now coding is a thing, a profession indeed, it needs to be a bit less insecure about getting it right first time—at least, when starting out. We all have to learn, there is no magic bullet.
TOTALLY concur. This session was pure gold for me; more than anything because it’s helped me trust my own instincts. Beginners like me - specifically, those lacking the instincts and vocabulary of advanced coders - tend to be more tenuous in their logical assumptions, rustier with syntax, unaware of edge-case and grandfathered usage conventions, and generally plagued by doubt regarding regex.
To watch you guys go at it, pause and recover, run logs, insert little chunks of tried’n’tested code lines, re-order commands, and so on, is really valuable and a great motivator to keep pushing, and develop similar perspicacious habits when writing our own code. So thank you very much!!
There’s much clarity in this way of looking at it! And I for one would totally welcome regular 15-20 minute sessions in our Meet-ups where we might go at mini-problems like this. Teach a man to fish, lol.