Mastering Problem Solving in Programming with Venkat Subramaniam – Techstrong Unplugged EP16

Hey everybody, and welcome back to Techstrong Unplugged. This is episode 16 of our series, and I'm your host, Natan Solomon on Techstrong Unplugged. We dive into all things tech can get people up to speed with everything happening across the industry.

Recently, our cohost, Cassandra Chen, went to the Great International Developer Summit, also known as gis 2024 at gis. Cassandra met up with Venkat Supermanium, who gave 12 sessions at the conference. Venkat chairs his journey from learning algorithms without a computer to becoming a passionate advocate for problem solving and programming.

Without further ado, let us, let's head over to GID 2024. Welcome back to Textron Unplugged. I'm your host, Cassandra Chin, and today we have Venkat with us here today.

Who's giving how many sessions? 12. That's a lot of sessions.

So how did you get started into technology? Well, it was a interesting path. Uh, I was in, uh, college, not sure what my major should be.

Uh, obviously I'm talking about 40 years ago, not, not yesterday. And, uh, I had an uncle who was, uh, faculty, but was deeply interested in, uh, software design and software development. But we didn't have computers back then, at least not as affordable to have it at home, but it got me excited into algorithms.

So my journey into programming was through algorithms. So whenever he came visiting, he would gimme a problem to solve. I didn't have access to computers.

I didn't know what they were, but I would write these algorithms on a piece of paper, and then he would be my compiler. So the next time he came around, he would review the algorithm, gimme some suggestions. So I kinda learned programming without computers.

When You say algorithms, you mean like numbers? Your kind of patterns. Um, Solving problems.

So essentially you take a, a mathematical problem and say device, um, routine to solve this particular problem. So essentially I would be sitting and devising the flow chart, for example, uh, describing what the steps you would take to solve this problem. So in fact, in a way, he taught me that programming is actually problem solving.

That's what it really is. So I learned problem solving before I started programming, which kind of stuck to me because now I know that programming is not the end goal. Solving the problem is the, is the, is the, you know, real essence.

So, uh, thanks to him I learned that, uh, through that journey. I agree that problem solving is actually more important than learning syntax sometimes. Yep.

And what's your approach to like technology education? So one of the, um, things I emphasize to, uh, so I also teach part-time at the University of Houston, uh, in addition to, uh, working in the industry. And one of the things I, I often, uh, tell my, uh, students is, uh, you don't learn by, well, let's put it this way.

You don't learn music by reading. You, you learn music by creating really, really bad noise. And then as time goes on, the noise turns into something a little bit more audible, and then eventually it turns into music.

Coding is exactly that. You start writing really, really bad code. First you get critiqued, you improve your code.

And by way of that, by practice, you become a better programmer. So different people learn differently, but my, um, way of learning is, I often say it's, it's one hour of reading and 10 hours of coding. So I learn by doing rather than only by reading.

I'm not suggesting we don't spend time reading, uh, or listening to a video. Those two are important, but that's only a small part compared to actual practice and, uh, getting critiqued, getting feedback, and then improving on it. So it's really like you learn by doing As you learn by doing, and you learn by redoing.

And, and, and that's why the practice becomes really important. Uh, the way I teach my courses to my students is, uh, I realized years ago with, with all respect to all the teachers, uh, my students don't learn by listening to me. They learn by writing code.

So we do active code review every single day. So 4:00 AM to 7:00 AM doesn't matter where in the world I am, I pull the code, I review it line by line, give them feedback, and they have a few hours to work on it, and then push the code back into the version control, and then we review it again. So it's three and a half months of extremely intense code review and rewriting the code and re refactoring it.

And at the end of the three months, they often say that in not even end of the three months, within two weeks to three weeks after the semester starts, I get emails from students saying, in the three weeks they've learned more in the course than they did in the four years of their college. And then that's my goal, is to really give them that intensity so they actually learn really well in depth. So do they keep tackling the same code problem?

And they keep improving their code, uh, For two weeks? So we take in two weeks increment. So we take a problem, well, typically in, in university settings or any school setting, you give an assignment on 1st of February, you tell it's due on 15th of February, students promptly started on 14th of February.

That's the normal behavior we have established in the world. So people normally start the code the night before. The problem is if you start coding the night before, you don't have the time to get the feedback loops and improve on it.

I'm not even exaggerating. I typically post my assignment at 7:00 AM on a Friday morning by 9:00 AM Two hours later I've got students asking for a review. So they have two weeks to work on a problem, and they end up finishing the assignment nearly 48 hours before the deadline.

So rather than starting it 24 hours before the deadline, they finish it 48 hours before getting all these feedback by multiple reviews each day. And then we, once the two weeks is over, we take another problem, rinse and repeat. We do this about four times through the semester.

And then in between those assignments, I also have homeworks where they can reflect on some concepts rather than focusing on the design and the code also. So we switch between code focused exercises to concept focused exercises and then back and forth. I think that's really cool, like you're kind of maximizing their time, like rather than procrastinating for two weeks, they're actually doing code reviews, which is important.

Totally. It also changes their, uh, work habit. Uh, they, I, I got an email from a student, which, which said, which, which is really funny.

And he said, you did what my parents couldn't do. And then he went down to say, my parents always wanted me to wake up early. I could never see the day before 11:00 AM but I, here I am at 5:00 AM sitting at my computer waiting for your review to be pushed thinking, what would s say?

So, so my goal is not for them to learn programming, not learn problem solving alone, but to learn about time management, learn about the feedback and the benefits of it, uh, change their work habits and behavior in addition to taking the time to learn programming as well, so that there's multiple benefits to doing it. I really wish I could learn from you, like learning time management is a really critical skill, which I think even adults have trouble with Or, or especially adults have trouble with. Yeah.

So you're really passionate about your teaching. I I love teaching because one of the reasons I I say that if I was selling, uh, hair products, and if I'm bald, I would be saying I'm the first customer of my product. Well, I teach because I think I'm the first student in my class because I never teach a class where I don't learn something.

Uh, I often say my students are the best teachers in the world because when I give them a problem and when I start reviewing the code, I cannot tell you how many times I would look at some code and say, whoa, that's an interesting way to solve this problem. Or they'd drag in a library or they'd drag in a certain, uh, you know, uh, approach to solving it. So I learned a great deal from, uh, teaching the course.

And that's one of the reasons I truly enjoy. I've been teaching for about 33 years now, and, uh, I feel like I'm just getting started. Each time you teach, do you feel like you learn yourself?

I I continuously learn and I often say that the time you want to stop doing something is when you feel like you're not learning anything more. And the beauty of technology is this. I teach a course on software design, so, but I tell my students, you can use any language you want to use.

So in a class of 30 students, they would bring in four or five different languages and different languages give you different capabilities to design your code. So there's always something to learn because as we know, language is not about syntax, it's about semantics. So we focus on how do you use meta programming, how do you use reflection?

How do you bring in, uh, uh, ability to write better test cases? So there's so many things and uh, I've had students pull in Kotlin and Scala and Groovy and JavaScript and Python and c and c plus plus and Java. And now you are learning about various ways of doing design, but design is twofold.

Design is half requirements based. Uh, they have implementation based. So the requirement may be the same, but the language changes the design because different languages give you different tools.

So, so there's always a learning to, uh, consider you, I first help the students to learn and they help me to learn deeper. And, and that's the fun part of, uh, working with the students on this. I really like how you're flexible to basically any language.

'cause I think a lot of adults get in the trap of being maybe only a Java person or language focused communities. Yeah, I tell, I tell everyone that I program in 15 languages. What that means is I'm not, I'm not good in any one of them, but I just like languages.

And, and that's what I li like about it is to me, language design is software design. And, and when we learn more than one language, it gives us an opportunity to think this about design very differently. Uh, if a person knows only one language, it truly restricts the way they can design code versus when somebody knows a few languages.

And here's the fun part, you might be programming in one language, but if you know a few different languages, your design in the language you use itself is different from the design that somebody creates when they know only one language. So that's one of the reasons why being polyglot is very useful. Even if you focus on one language, mostly to be able to program in, If you have a task or a program, you need to write, like is it possible to write it in all the languages or are there limitations?

Oh, yep, they're all Turing complete. So the answer is yes, you can write them in all of them. Uh, however, uh, Turing completeness talks about feasibility, but it does not talk about performance, doesn't talk about, uh, conciseness, doesn't talk about expressiveness.

And then that's one of the fun things. So in addition to the software design course, I also teach a course on, uh, programming languages. And, and the reason I like teaching the programming languages course is, uh, what I do in that course is I give a one problem, but the students are required to implement the same problem using three different languages with unit test.

And they would come back and say, whoa, we can see how similar these languages are in, up to some point, and yet how different they are beyond a certain point. And, and so when you take a same problem and implement it in multiple languages, you're really able to able to appreciate the similarities and yet the differences on the design it can bring about. And that's very rewarding to see how it takes shape and how, uh, you can see the same problem, but through the eyes of different languages.

I really love that approach. Like I almost just wanna go start coding and trying different languages for the same problem. Yeah, it's, it's fun.

Definitely. It's, it's a great exercise. It can be very frustrating in the beginning because when we are unfamiliar with something, it feels like it's uphill because the learning curve is very high.

But, but the fortunate thing today is we got really good tools, really good, uh, IDs and facilities and, uh, and, and of course with, um, the tools available to us, it, it really sweetens the journey a lot better today than only a, you know, few years ago. So, so it's worth that journey because Of all the languages, you know, how many IDs do you have to have installed on your computer? You'd be surprised.

Uh, I actually have distilled it to a very minimum. I spend, uh, 80% of my time on vi, which really shocks people. So I tend to leverage more on the build tools.

So I use, uh, you know, as an example, I use Gradle for Java. I use, uh, you know, MS Build for CI use cargo for rust, or when I program in languages like that, uh, uh, paver or for Python. So I tend to really use these build tools, uh, rather than, uh, focus on ideas, which gives me the opportunity to really get down to the, the, the, the raw language rather than, uh, being enticed by the ideas that throw quickly things at you.

So I take the journey a little bit more, uh, the harder, uh, route. But that's also partly because I'm a big fan of mountain hiking. I don't hike mountains, so it can be easy.

I hike mountains, so it can be hard. So, so I enjoy this journey of hiking mountains. I enjoy taking the time to figure out solutions in languages.

So I tend to really, uh, depend on more rudimentary tools. Uh, but of course, my students, uh, need a lot more help. So they tend to really use, you know, tools like via Code or IntelliJ or, or whatever tools they can find.

And then thankfully, most of these tools are very polyglot. Uh, so as a result, they can switch between languages and still leverage the tool as well. Okay.

So like, the tools are very flexible. They can switch between languages. They Do pretty nicely.

They can, uh, trip you up a little bit from time to time. When my students are using, uh, visual Studio for Python, uh, they often, you know, immediately schedule an appointment with me and they say, my gosh, I'm not able to run my code in Python. And I'm like, okay, go here and set the path for a Python.

And then once you set the path, things work. So you gotta figure out a few of these nuances with the ides. But once you know where to look for, uh, then it becomes easier to move forward.

And that's where you help them get started. I, I help them to get started and, and I won't pretend that I know everything, but, uh, collectively, we, we figure out solutions when, when, when such problems arises. I really like your flexible and like, logical approach to teaching.

I almost wish I could learn from you myself. Well, you're kind. Thank you.

Appreciate that. I like, we had a really good chat today, so thank you Venkat. Thank you Cassandra.

I really appreciate it. Thank you.