PyDev of the Week: Daniel Zingaro

This week we welcome Daniel Zingaro as our PyDev of the Week! Daniel is the author of Learn to Code by Solving Problems: A Python Programming Primer and Algorithmic Thinking from No Starch Books. If you’d like to see what else Daniel is up to, you should visit his website.

Daniel even braved sky-diving once!

Now let’s spend some time getting to know Daniel better!

Can you tell us a little about yourself (hobbies, education, etc):

I’m a computer scientist now, but that almost didn’t happen. When I was a student, I really loved my psychology courses. Like, obsessed: I’d study and study and study those courses and then, way past the point, I’d make my way to my Computer Science stuff. I maintained both psych and CS majors for three years and then finally got overwhelmed and chose CS. Not totally sure why — there’s just something about the type of problem-solving that computer scientists do, I guess.

I’m glad for the effort I put into my psychology studies. Understanding people and understanding computers are equally important skills for writing a programming book.

In the mid-2000s, I did a master’s degree in CS, in an area called Formal Methods, where you prove that systems have no bugs (or, you know, you fix stuff until you can prove it). I liked it, but I felt that I wouldn’t be able to make contributions in that area. I’d sit there for days and days, slogging through a single paper, when in my mind others would be able to read and understand much more quickly. I remember going to a research conference once; after it was over, I thought, “no way can I do what these people are doing”. But of course, I couldn’t: they were veterans in the area and I was just learning. I’m certainly more patient with myself these days.

At the same time, I had the opportunity to guest teach one lecture about compilers. One lecture only, but it was enough to show me that I wanted to focus on how to teach CS. That’s what I do now.

Writing is an important part of my life… an important part that I, unfortunately, neglected for many years while I focused on my academic research career. My wife is a writer, and she helped bring me back to it. I had a one-year sabbatical from teaching in 2018 during which I wrote with an urgency I hadn’t felt in many years. The result was a book called Algorithmic Thinking, which is a no math, no proofs, but rigorous introduction to how to think about data structures and algorithms. After that, I was compelled to write more, and Learn to Code by Solving Problems is the result.

Learn to Code by Solving Problems is based on my decade of research into one question: how can we help students better learn programming/CS material? This, for example, is why the book material is focused around solving problems (not on learning syntax on its own), why there are in-text conceptual questions where I want the reader to pause to make sure they’re on track, and why all exercises (even those at the ends of chapters) have sample solutions. Another explicit goal was to write with compassion. Learning to program is hard. The last thing we need for budding programmers is pretending otherwise.

For fun, I’m trying to read all of Stephen King’s books. I used to read Animorphs books, too, but I have had to ban myself from that activity, otherwise I’d just read them through and through and get nothing else done (hello, Summer 2014).

Why did you start using Python?

About 15 years ago, University of Toronto moved from Java to Python for their introductory CS course sequence. I came to University of Toronto shortly after and had the opportunity to teach an intro programming course. So I had to learn Python, and fast! 🙂

I think Python is a great first programming language to learn. The available libraries are so rich that we can use them almost immediately to have students work on fun, motivating, and media-rich projects. I think this is a plus for encouraging diversity among students and broadening woefully out of date conceptions of what a computer scientist is and what they do.

What other programming languages do you know and which is your favorite?

I have two favourites: Python and C, depending on the project. I go to Python for when I want to work at a high level. And I go to C for systems programming or whenever I feel like writing small programs close to the hardware.

I haven’t seriously used many other languages. I spent a few years back in the day with Visual Basic 6; I used it to make accessible audio computer games.

For those just getting started: I think doing a little background research (what do you want to build?) and then diving into a suitable language is preferable to trying to choose the perfect language from the outset. A huge chunk of what you learn is going to transfer to other languages. And languages come and go, anyway, so a focus on fundamental, cross-cutting concepts is key. This is what I’ve tried for in my book: I want you to be a programmer and, oh right, you’ll be a Python programmer, too.

What projects are you working on now?

I’m currently exploring some other book options. The two recent books I wrote — Algorithmic Thinking, and Learn to Code by Solving Problems — were two that I had to write. I wasn’t able to think about any other books until they were written. Now that they are, I’m working on a few different book directions. Those two books tore out of me. I suspect that any future books will take a little more coaxing. I look forward to the opportunity and challenge that may bring.

Which Python libraries are your favorite (core or 3rd party)?

I really should experiment with more libraries! For now, I’ll say that I’ve gotten a lot out of Pygame in my teaching. It helps me develop game or graphical projects that motivate some students. (It’s important to use other domains besides games, for sure. But when I do want a gaming context, Pygame is what I use.)

You mentioned that you are blind / visually impaired. How do you write a book or code with those kinds of challenges?

Things have changed dramatically in this regard over the past 30 years, to the point that, today, I need just one piece of free software (the NVDA screen reader) to do all of my work. If you’re already an intermediate/advanced programmer and you wanted to buy my Python book more to support what I do than to learn: please consider donating instead to NV Access, the folks who make NVDA happen.

One thing that took me a while to get used to in Python is its indentation! It looks nice on the screen, I’ll bet, but unlike braces or begin/end, indentation is mostly invisible to me. These days I use a feature of NVDA that beeps at higher and higher pitches as the indentation increases.

I live for anything that’s funny. What’s funnier than me getting author copies of my books in the mail and not being able to read anything I’ve written? Or writing code to generate diagrams that I can’t use myself? I’m grateful to my editors at No Starch Press, without whom I’d probably be using size 6 font, ASCII tables, and headache-inducing crosscrissing diagrams.

What are some lessons you have learned while writing the book?

Sometimes, seemingly distinct interests/lines of inquiry can come together in surprising ways.

A few years ago, I became interested in competitive programming. It’s true: programmers compete in international problem solving competitions. I was taken by the creativity of their community and began widely reading what they produced. Most of their resources are focused on advanced programming and data structures, and I’ve since incorporated some of that into my seniour level courses. They have thousands of unique, high quality problems that are not found in books.

Separately, I’ve taught introductory programming many times. Most of my research is about introductory programming. And one thing I learned while teaching and researching was that context can help many learners. Some learners will be cool with learning about loops for an unspecified, abstract future purpose. But others want to know “why loops”, “why functions”, why do I need this stuff?

When writing Learn to Code by Solving Problems, I was able to combine my experience and research of intro programming with my awareness of the vast problem set generated by the competitive programming community. (It turns out that competitive programmers have designed thousands of intro level problems, too!) Without these two lines of inquiry, I couldn’t have written this book.

Is there anything else you’d like to say?

Learning to program can be challenging. Don’t worry about how long it takes you. Maybe your friend picks it up faster than you. Maybe you’ve been told that people like you can’t program. Maybe you’ve tried before and got nowhere. Or, wait. Maybe you *think* you got nowhere. It’s not easy to measure progress, especially at the beginning. Don’t let people stop you. Work on your own timeline. You have ideas and priorities that no one else has. If you want to learn, I hope you find the resources, strength, and energy to do so.

Thanks so much for doing the interview, Daniel!