Solving Problems with Algorithms-Ace Dan Zingaro

 

Cover of Algorithmic Thinking, 2nd EditionOur latest Author Spotlight is on computer-science whiz Daniel Zingaro, author of Algorithmic Thinking as well as its soon-to-be published second edition, and Learn to Code by Solving Problems (2021). In the following Q&A, we talk with Dan about his favorite childhood computing memory, how he went from nearly dropping out of CS classes at university to teaching them, the accessibility tools that helped him become a programmer despite being severely visually impaired, and why fellow educators should feel empowered to write books about the subjects they teach.

Daniel Zingaro, PhD, is an award-winning associate professor of Mathematical and Computational Sciences at the University of Toronto Mississauga, where he is well-known for his uniquely interactive approach to teaching, and internationally recognized for his expertise in Active Learning. In addition to writing, educating, and researching, Zingaro is one of our go-to technical editors, whose work includes Python for Kids, 2nd Edition (2022), Data Structures the Fun Way (2022), Python for Data Science (2022), and Python One-Liners (2020).


No Starch Press: Congratulations on the second edition of Algorithmic Thinking! One of the things that really makes it unique is your show-not-tell approach to teaching algorithms, where you present the problem first and then guide the reader toward finding the fastest, cleverest solution. It can’t be a coincidence that you’re also an award-winning college professor known for your “active learning” method. Did your experience as an educator influence the way you wrote the book?

 
Daniel Zingaro: Oh, definitely. I've learned so much about teaching from my students, and I always try to incorporate as much of that as I can into my writing. The reason I flipped the book to be "problem first, material second," rather than the opposite, is because many people are not motivated to learn abstract stuff without understanding why it might be useful or matter to them. If I can have a reader read a description of a problem and be like, "Yo! I don't know how to solve this thing," then I feel like the real learning can begin.
 
I've also tried to make the book inviting to students who might otherwise not feel welcome. For example, I didn't put proofs or theorems or much math in there, because I know what that stuff does to many students: "Theorem 1: let x, y, and z be ... oh hey look, a new YouTube video!" So why force students to learn in a specific way? Because we happened to learn that way? Because that's the only way to teach it? Those reasons aren't acceptable to me. Students provide constraints on how they want to learn. If we professors are all we think we're cracked up to be, let's rise to this challenge and teach under those constraints. There's no right way to teach. If someone (like, literally, I mean one person) learns from it, then it is right.

 
NSP: It’s hard to believe that you twice came close to dropping out of Computer Science while attending university — and nearly failed a course that you later went on to teach. But it must be true because you disclose this personal trivia to your students. Why is it important for you to be so open about your past struggles?
 
DZ: It's true! I really need to dig out my old transcript and post it online for students so they can see my nearly failed grade. It's very important to me to share these low points with students because many students experience low points of their own. The way I connect with the world is through humor and making personal connections. If there's anything I can share with people that helps me make these connections, then I will do it. 
 
My waffling on whether to drop out of Computer Science, and suffering some poor grades, offer ways for me to make these connections. How funny, right? A professor that almost failed a course? It's really too bad that it's funny – I mean, the only reason it's funny is because it's so rare. With the poor grades and other challenges, I'm fortunate to have still gotten here. But I did, somehow. I figure that maybe my struggles can somehow help someone else with their own struggles.

 
NSP: Let’s talk about accessible computing for a moment. A lot of our readers may be surprised to learn that you’ve been blind your entire life, which would put you in the very small category of visually impaired students who successfully learn programming and earn advanced degrees in the subject. What adaptive tools helped you overcome the challenges you faced? And, how has the level of accessibility in computing evolved?
 
DZ: Yep – that's why my books don't have any extraneous pictures. Or cute sidebars. Or cute icons.
 
The computing tools for accessibility these days are making huge advances. I use the free NVDA screen-reader to do all of my computing tasks. But looking back, the tools only helped me because my parents gave me the opportunity for the tools to help me. My parents are in the Acknowledgements section of my book because, without them, there is no book, there is no career, there is no who-knows-what-else. If you have a disability or are otherwise being excluded, then (if it's safe to do so): advocate for yourself. That's what I learned from them. Could I have advocated for myself otherwise? Could I have advocated if I didn't feel safe in Canada doing so? Probably not. That's scary. I may have worked hard, but the world gave me the opportunity for my work to mean something. How many people work even harder and never have the opportunity to benefit? That's a tragedy.
 
I try to use one of my lectures every year to show my students the tools that I use to teach. They're computer scientists and are going to be building tools that all of us will use in the future, so I like to show them how much accessibility matters, for real, to a real person. And I always start with a 10-minute discussion of how I hope they interpret what I'm about to show them. It seems natural for them to hear my super-fast screen-reader speech, or the handheld device I use to read Braille, and be like, "holy cow, Dan is epic!" But I'm not. The tools are epic. Actually, wait; that's not quite it. We're all epic. Many people can read or write or do amazing things. And, yeah, the way that most (non-visually impaired) people do it is different than how I do it – but at the end of the day, the technology exists and makes it so that I can do it, too.
 
Also, a big shout-out to everyone who cares about accessibility and/or works to make software or processes or the world in general more accessible. We need people (including ourselves) to encourage us, and we need the accessibility tools to realize that encouragement.

 
NSP: Another thing our readers might not know about you is that you're the technical editor behind some of our bestselling books, including Data Structures the Fun Way and the new edition of Python for Kids. Since you've already made a name for yourself as a writer, what drew you to the unsung-hero role of technical editing, and can you tell us a little about what you actually do in that regard?
 
DZ: I find technical editing to be quite fun. I find learning fun, and editing books helps me sharpen what I know about a particular topic, so it's kind of fun by default. I also welcome the opportunity to help authors produce even better books. It's the best when there's an author doing great work, and I can in some small way help that author even further. Sometimes I'll be editing a book and think, "dang, this is so good! Why couldn't I have written this?" But, the reason is that I couldn't write their book even if I tried. The author has a particular voice, a particular expertise. Editing permits me to revel in that expertise, to just be grateful for the fact that here we have another author who has the ability and opportunity and life circumstances to share what they know.
 
What I do when editing is annoy the author with every tiny improvement/possible improvement that I can think of. (No, really – ask them.) I check all of the code and text, of course, but that's not my favorite part. My favorite part is using what I know about teaching to offer suggestions where I suspect learners may get particularly stuck. A lot of the topics covered in these books are ones I haven't taught before, and even if I have, I know only a small amount about where and why learners do or do not make progress. The challenge really never goes away, that's for sure, but I welcome any opportunity to try my best to be helpful given what I do know.
 
 
NSP: Like many of our authors, you’ve been into programming since you were young. What’s your earliest memory of enjoying computing, and when did it go from being a hobby to a career path?
 
DZ: One of my earliest computing memories also happens to be one of my favorites. My family was trying to get me a computer loaned to us with screen-reading technology on it (as it was expensive in those days and involved several interacting software and hardware devices). We were at an assessment center to look at some models, and my dad and some employees were talking about computery stuff that I didn't understand. Honestly, all I wanted to do was play a computer game or type something funny on the screen, but the adults just kept talking. Finally they stopped and wanted me to try out three different types of computers to see which one I could best work with. I started with the first computer, typing a little story. And then I managed to do what turned out to be the best thing ever: I froze the machine. But not just a normal freeze, a hilarious freeze where the screen-reader thing kept repeating the same “ah ah ah” syllable again and again, with no way to stop it. All of the fancy computery people were trying fancy things but simply could not make it stop. I was doing my absolute best not to laugh, because I desperately wanted the chance to take home a computer that day. Eventually they gave up and had to completely shut it down by flicking the power switch. Once they did that, I just couldn't hold it in anymore and burst out laughing (while also realizing I probably blew my chance at getting them to give me a PC). But, no! It turns out that they were actually impressed that I had successfully frozen the computer, and agreed to loan it to us on the spot. Looking back, I didn't do anything impressive – probably just pressed a bunch of keys at the same time or some such nonsense.
 
Presently, I'd say I'm more of a teacher-person than a computer-person. Computing happens to be the thing that I can apparently teach best, but I get my true motivation from teaching in and of itself. I often catch myself learning something new and then immediately thinking about how I might teach it. Or I'll solve a computing problem and then be thinking about which chapter of a book it might serve as an example in.
 
 
NSP: You’ve been a professor at UT-Mississauga for nearly a decade now. What’s the most significant thing you’ve discovered about teaching Computer Science in all that time?
 
DZ: The most significant thing I've learned is that every book is total junk for a subset of students. For any one of the textbooks I use – say, a classic CS book – there is a subset of students for whom that book just doesn't work. In fact, my happiest teaching days usually involve a student telling me that my book isn't working for them. Now, it might not be their happiest day, because then I try to drag them into a two-hour conversation about why it isn’t working. But I really do want to learn from them and try to do better. And they know how passionate I am about learning, so I don't feel too bad about that!

 
NSP: Much like sky-diving, writing a book takes a leap of faith — and you’ve done both. What advice can you offer to fellow CS educators who have thought about becoming an author but are scared to make the jump?
 
DZ: I'm married now, and I'm pretty sure I signed some wedding papers that make me not allowed to skydive anymore. (I'm guessing that book-writing is still okay, though.)
 
I think CS educators are in a unique position to write books that teach. They have so much experience in the classroom, and I myself was surprised how much of it I was able to carry over into my writing. I'm not an algorithms researcher. I don't know a whole lot more about algorithms than what I put into the book. (You'll know that I learned new algorithm stuff if you ever see a third edition of Algorithmic Thinking!) But, you know what? I think not being an algorithms researcher was a blessing for this book. I'm not so far removed from remembering how challenging it was for me to learn these concepts the first time. And the approaches I know best are the general (not specialized) ones that are applicable to a wide variety of problems that programmers might run into in the wild. I hope readers can see in every chapter how excited I am to learn even more about algorithms, and I hope that excitement helps fuel their own excitement.
 
So, say you teach a web programming course. Or an architecture course. You've tuned it. Your students respond well. Who cares if you're not the foremost expert on web programming or architecture? You're a teacher who knows how to connect with students and, as such, your book is valuable.