DAVID MALAN: Hello, everyone.
This is David in Cambridge, Massachusetts.
Can everyone hear us OK?
Well, it's so nice to see everyone.
These are CS50's office hours.
For those unfamiliar, this is an opportunity
typically on campus for students at Harvard to come by professors' offices
literally and ask questions about courses, about life after a course,
and about computer science more generally.
I'm joined today by CS50's own Brian Yu.
Let me turn the floor over to him.
BRIAN YU: Hi, everyone.
I'm Brian, also calling in from Cambridge.
Good to see everyone today, and looking forward to hearing your questions.
DAVID MALAN: And for those less familiar with Zoom,
allow me just to highlight a few features.
Probably along the bottom of your screen,
you'll see a participant's icon, which if you click on that,
you'll see everyone else who's in the chat room today.
You should also see a Chat button.
And if you click on that, it will open up
something else that will allow you to chat with other people in the room.
Please feel free during these office hours to chat with each other,
to share links, to answer questions.
But if you have questions of me or Brian,
please instead go to see cs50.ly/ask, which I've gone ahead and pasted
into the chat window myself.
So keep that open if you'd like to ask questions.
Otherwise, the chat flies by so quickly that we really can't keep an eye on it.
But CS50's whole team behind the scenes is helping
us keep an eye on that form submission.
So we'll keep everyone muted by default. And if we're
able to field your question, we'll call on you by name explicitly.
And please feel free to say hello and where
you're from before asking your question on video.
And indeed, if you do want to ask a question,
do make sure to have your microphone and video on so that we can all
see and hear you.
Now, as you might have seen when we publicized these office hours,
we're joined by a special guest who you might not have seen for some time,
unless you've been taking CS50's games course.
Indeed, if you go into this URL, which I'll paste now
into the chat window, which is that of GD50, or Game Development 50,
otherwise known as CS50G.
This is a course taught by CS50's own Colton Ogden.
And I'm so excited along with Brian to welcome back Colton
to today's office hours.
Colton?
But we can't hear him just yet, but he'll be unmuted momentarily.
Allow me to reintroduce CS50's own Colton Ogden.
COLTON OGDEN: Hi, everybody.
Sorry about that.
Hope everybody's staying safe.
It's my pleasure to join the team here again.
It's been a while.
Hello from Las Vegas.
But yeah, this is awesome, seeing a lot of interaction in the chat--
some cute code formatted hellos.
So, excited to see where the questions take us today.
DAVID MALAN: Wonderful.
And to give folks a chance to fill out the form, Colton,
we thought we, Brian and I, would ask you a couple of questions, if I may.
So this games course--
to which I, of course, know the answer.
But others might not know the origin story of CS50's Game Development class.
How did this class itself come about a few years back?
COLTON OGDEN: So I think the early germs for the course were--
you and I obviously like some classic games, Mario and Zelda.
And we've talked about them.
But we were doing a little bit of a tour in the UK, where we had some workshops.
And I remember you proposing based on the fact
that you know that I was into coding games
that we have a few different seminars on some other topics,
but we don't have anything game-centered.
So you said, hey, you want to put together a little seminar?
So I said sure.
That ended up going well, in my opinion.
It was fun to create as well.
So we did another thing back in Cambridge, Massachusetts following
that to test-drive the ideas a little further.
And then after that, we said, hey, let's turn this into a full course,
and we did.
And yeah, that was a couple of years ago now.
And it's been going for--
it's been going pretty strong.
DAVID MALAN: Nice.
Yeah, and it has.
And it occurred to me in thinking about today's office hours
that whereas most of CS50's classes, like CS50 itself and Brian's web class
and new AI class, are structured each week
around different topics from the field.
The games class is a little differently structured such
that you made the conscious choice to structure each week
around a specific game.
And we were curious to ask how you thought about designing
a course with that kind of structure.
COLTON OGDEN: So for that, I think I was inspired by CS50 certainly
to an extent, being that I was in that environment a lot.
Because CS50 operates very much in the same way, where each week,
there is obviously a lot of topical conversation.
But every week, there is one big project that people are working
on that is pretty real-world feeling.
And especially when I was learning game programming,
it seemed to me that it was pretty rare that you
would learn through the lens of something complete like a code base.
And you would really actually take the more standard approach
of learning topics.
And while it's good, and there's, I think, pros and cons to both sides,
I think personally, I was more attached to the more case-study style
of learning a whole game and getting to interact with that code base
and seeing how you take that week by week and expand on it.
And those early, early ideas are universally
applicable towards the later, more bulkier games.
So I don't know.
I think that was partly unconscious, but I
think those were the more nonconscious factors that played into it.
DAVID MALAN: Interesting.
And perhaps just one other question before we go to the whole group.
The games class uses primarily a language called Lua.
And we were curious to ask why Lua and not something like Java or JavaScript?
And does Lua have usefulness outside of the world of games?
COLTON OGDEN: Sure.
So Lua is, I believe, empirically probably the most-used scripting
language in the world of games.
It's been very frequently used as a scripting layer since at least the late
'90s, probably earlier than that, typically with C++-based code bases.
So if you're modding a game or looking at a lot of games
that have more open code bases, you'll see Lua all over the place.
But additionally, it's just a really nice, simple language to learn,
just like C is.
You can learn it in really a matter of hours
because it's very simple, very small set of features.
Though it's still robust.
It still gives you things like first-class functions
which allow you to program in a JavaScript style,
which can be really cool for a lot of asynchronous programming
which, in games, is very commonly used.
We do some of that in, for example, the Pokemon piece
that I believe uses a lot of that.
But additionally, it was also coupled with the fact--
that would've been good on its own--
but coupled with the fact that Love existed.
And in my mind, especially from a pedagogical standpoint,
Love seemed like the best framework to use
that wasn't so opinionated that you had to learn things a specific way.
But it also gave you a lot of power.
And it's a very performant framework for what it is.
So I don't know.
I felt like a lot of things came together
to make the perfect sort of hybrid for teaching and for practicality.
DAVID MALAN: Nice.
Well, it makes sense.
Well, again, for those less familiar, I've
just pasted again into the chat window the URL of Colton's class
on edX if you'd like to take a look firsthand and re-implement something
like Mario the way it was meant to be, not just with ASCII art, as we
do in CS50 itself.
So let's start to take some questions.
Again, if you would like to ask a question yourself,
do go to cs50.ly/ask and submit the question there.
We won't be using the blue hands or the built-in chat window.
This way, take a look through the questions and know what to expect.
Our friend Ramon on CS50's team is kindly
going to help us pass the microphone around.
And we'd like to first call on Mohammed Shamek,
if you'd like to ask your question on video.
Mohammed?
AUDIENCE: Hey, everyone.
Am I audible?
DAVID MALAN: You are.
Where are you from, and what's your question?
AUDIENCE: I'm from Egypt.
So my name is Mohammed.
I'm 18 years old, and I am from Egypt.
And this question, it's--
well, it was kind of interesting to know the answer for.
So in week six, we start learning Python in the CS50 course.
And then what happened is I knew some Python before.
And apparently for computers, the beginning of time
is considered to be like Jan 1, 1970.
And so I wanted to ask why specifically?
DAVID MALAN: Yes.
It's a really good question.
The world has been around a lot longer, but so far as computers are concerned,
most computers do indeed think of the beginning of time,
as you say, as being January 1, 1970.
Brian, do you want to take us down memory lane?
BRIAN YU: Yeah, absolutely.
We can have a bit of a history lesson.
So this really goes back not just to Python, but even earlier
to the development of Unix, which was one of the first popular operating
systems and serves as the basis now for operating systems like Linux or Mac OS,
if you use them.
And at the time, when Unix--
Unix, the operating system, was first released in 1971.
So at the time, they just needed some way of representing time.
And they figured they just needed some number it was
going to count, second after second.
And they just sort of arbitrarily chose January 1, 1970
as the date that would be like time zero.
And you can count the number of seconds from that time.
And if you wanted to represent a time earlier than 1970,
you could do that, too.
They just said, all right, we'll use a negative number instead.
The interesting conversation now, though,
is the fact that when they made that decision at the time,
they were storing integers-- numbers--
in 32-bit integers, something you might be familiar with in CS50
in week 0 or week 1.
And if you remember from CS50, with a 32-bit integer,
you can count all the way from negative 2 billion all the way up
to positive 2 billion.
But anywhere beyond that, you start to run
into problems of integer overflow, which we talk about in week 1.
So you might ask the question of, all right, what is 2 billion seconds
from January 1, 1970?
And it turns out that will take you to the year 2038.
So our computers are OK up until 2038.
But after that point, we'll need to start
to switch to some bigger way of representing numbers,
like a 64-bit number, for example, which a lot of computers
are using nowadays here.
So, a very good question, and one that could become a problem
in just a couple of years if we're not too careful with our computers.
DAVID MALAN: Yeah.
Some of you might recall the so-called Y2K problem
around the turn of the Millennium.
And that, too, was the result of humans having
decided to use only a finite amount of memory that was not going
to be enough once the year got too big.
So thank you, Mohammed, for that question-- a really interesting one
at that.
Let's go next, Ramon, to Arman, if you'd like to say hello.
AUDIENCE: Oh, yeah.
Hi, there.
My name is Arman, and I'm from Armenia.
First of all, let me thank you for what you are doing.
Providing this level of education is really something
that you can't be thanked enough.
My question is about languages.
You know, I come--
I'm somebody who had some experience with Java
before I started the CS50 course.
And now, I am on week 4, I guess.
I'm currently working through the problem set.
My question is as somebody who had some experience with different languages,
but now, I'm trying to learn some of the more fundamental low-level stuff like
things like working with memory or the C language or C++--
things that are used in graphics, you know?
Colton, I think, will agree that graphics
use a lot of those low-level things.
What would you recommend to me to deepen my knowledge of C
and working with memory, but also juggling between other languages that
are not that low-level?
DAVID MALAN: Yeah, that sounds like a really good question for Colton,
who I think has tendency to like to do exactly what you're
describing with languages.
Colton?
COLTON OGDEN: Sure.
So yeah, it's an interesting perspective.
Going from higher-level languages to lower-level languages
is something I feel like I've been seeing more people doing these days.
I came more from the other side, where I learned C++ and C,
and then went to dynamic languages.
So my perspective on this may be a little different.
But I would say, I mean, the base rule, obviously,
is just do a lot of exercises.
Make a lot of stuff in those languages.
And you just kind of learn through absorption.
You learn if you're rigorously learning something, if you're reading books.
As it pertains to graphics, it's a little bit different
these days just because graphics, a lot of the time, is bundled to the GPU.
And things are done at the low level usually using shaders a lot
for a lot of the more fancy graphical stuff.
And that's a very--
it's its own universe on its own.
And it looks and reads a lot like C, but kind of an arcane version of C.
And in Unity, for example, it's also kind of C-like,
but even a completely different set from like if you were doing something
in C++.
But yeah, I would say get your mind wrapped around pointers and memory
blocks and using--
in C, we do a lot with malloc and free.
Those are the base functions in C. And you can use them in C++ as well,
but C++ has a different sort of model.
But yeah, just, honestly, do a lot of exercises.
And if you're interested in graphics, probably look at OpenGL,
which is a higher-level API, where you're still doing a little bit
of memory stuff, but it's not quite as low-level as maybe you might--
at the malloc and free level.
It's a little bit different in that sense, I would say.
DAVID MALAN: Well, thank you, Arman, for your question.
Let's go next to Nicole, if you'd like to say hello and where you're from.
Yes.
Now we can hear you.
AUDIENCE: I am from Seattle, and my name is Nicole.
So my question is I wanted to know what are some of the common traits or skills
that you notice in those programmers who are considered to be top programmers
or very skilled and advanced.
What's something that you see as a commonality they all maybe have
that you've noticed that may be something I can look
to see if I can incorporate for myself?
DAVID MALAN: Yeah, absolutely.
A couple of thoughts come to my mind.
Let me go to Brian first, though, for his, especially
since he's been teaching multiple classes this past semester.
BRIAN YU: Yeah, this is a great question.
I think with really skilled program records
and I've had the chance to interact with and work with,
I think some qualities they have are--
one is they're always trying to find the best way to solve a problem.
But oftentimes, when you're dealing with a computational problem
where there are lots of options you have for how to solve it,
I often find that I really admire people that are always
looking for the fastest to the most memory-efficient or just the most
elegant way to try to solve a problem.
And I also know that really skilled programmers
are good at anticipating possible edge cases.
Like when you're writing code, you have one sense
for what you expect the code to do.
But very skilled programmers will often be
able to think about what could possibly go wrong
and to try to be able to handle those situations.
Because otherwise, bugs may arise in your programs later on down the line.
DAVID MALAN: Yeah.
And the first thought that came to my mind was a good tendency,
I think, for a good programmer to have is a desire
to want to understand everything that's going on in their code,
even if they're using third-party libraries.
So case in point, one of CS50's own web applications
broke the other day when none of us had actually touched the code recently.
So it seemed a little strange.
So we thought maybe that one of the APIs we were using changed,
or one of the libraries ultimately changed.
And through trial and error, I realized that if I
downgraded one of the libraries we were using,
everything started working again.
And that was great.
And I could have just saved the code, pushed it to GitHub,
and called it a day.
But I was so determined to want to understand this that I dug in deeper.
I asked Brian for his second opinion.
And indeed, Brian chased down the issue to being a very small change
in this other library.
But it was so gratifying and, I think, enlightening for both of us,
certainly for me, to realize, oh, that's what happened.
And that's why the code broke.
And I think the opposite of that is a bad trait.
I think it's always disheartening when we see in some of our students
or even some of our teaching fellows a sort of attitude of like,
oh, I changed this line of code.
And I don't know how I fixed it, but it works now, and being content with that.
And I don't think you should be content with not understanding
lines of code that you wrote or even any of the dependencies
that you might be using.
So it's so frustrating, and it's so time-consuming
to go down these rabbit holes of understanding.
But I think it really will make you a better programmer, ultimately.
Well, thank you for that question.
Let's go next to Darren, if you'd like to say hello and where you're from.
AUDIENCE: Hello, can you hear me?
DAVID MALAN: We can.
AUDIENCE: Thank you.
Thanks for this.
Yeah, my name's Darren from just outside London in the UK.
I'm 45 years old, and that's probably the basis of my question, actually.
And this is going to be more focused to Colton.
I enjoy playing games since the age of gaming, my VIC-20 and Commodore
64 days.
I used to do some VB programming on the back of it.
But I started learning C through David and, of course, CS50 course.
But my question is, at the age of 45, we have two--
almost three kids, because the next one's due next week.
DAVID MALAN: Congrats.
AUDIENCE: Learning C, as you said, Colton, can be learned in hours.
I'm not sure about that.
But I hear it's not the hardest thing to learn.
But from the game-design point of view, from learning, say, coding in Unity,
do you think a commitment of eight to 10, maybe up to 15 hours a week,
is enough to be able to create your own games and get into the game design?
Or is that too much of a high expectation?
COLTON OGDEN: So I should clarify that.
The 30 minutes specifically was maybe if you knew several languages already.
But yeah, no, obviously, C from the very beginning, it's--
the hardest part, I think, is going from very little to no programming knowledge
to having the ability to solve problems in code.
That's language-agnostic, and that's just a fundamental thing
you have to learn as a new developer.
In terms of is it worth it or is it viable--
it's a combo question, I think, if I'm not mistaken.
So is it sustainable 10, 15 hours-ish a week to get into game design?
And I would say it depends on what you--
the games industry is very segmented.
It's a very diverse field.
There are a lot of avenues.
You can go into the realm of cutting-edge triple-A, like very
high graphics, high-capacity stuff.
I mean, at that point, you're usually using in-house engines.
But even things like Unity Engine or Unreal Engine
can take you in that direction.
Unity is really good these days as well.
But that takes a lot more commitment because you're
getting into a lot more detail as concerns things like shaders
and much more advanced systems if you're modeling
human interactions and kinematics and physics and all sorts of things, right?
But if you're doing something more indi-focused, where maybe your goal is
to make a 2D-game or a simpler game, or just exploring
new ideas that maybe aren't as crazy on the graphics or the physics,
then yeah, absolutely, you could certainly do that.
As concerns whether it's worth it, I would
say that that's a subjective thing.
It's a value measurement on your part.
If you're passionate about games, and you really like games,
and you want to spend the time, then absolutely, it's worth it.
But if you're looking at this strictly from
"I want to get into the games industry to make money,"
there's many other realms of programming where
you can make a lot more money with probably a little bit less
strain or, I'd say, a shorter learning period, certainly.
But yeah, no, if you love games--
I mean, games are extremely rewarding, in my opinion, in terms of development.
So I would say definitely pursue it if you love the process of doing it.
But yeah, it's not going to happen overnight.
It's not going to be maybe even a year.
It could take you a couple of years before you're
making games you're happy with.
But chase it if you love it.
But yeah, I would say just have realistic expectations
of the scope of the games that you might be able achieve as one person.
You could certainly lead a team in the future who can
let you accomplish those larger games.
But as a single developer, it's going to be a little bit--
you're going to be limited in terms of what you can actually accomplish.
DAVID MALAN: Nice.
Well, thank you, Darren, for that question.
And congratulations next week, especially.
Let's go next to Vicky, if you'd like to say hello to the world
and where you're from.
The floor is yours, Vicky.
AUDIENCE: Hello?
DAVID MALAN: Yes, we see you.
AUDIENCE: Hi.
My name is Vicky.
I'm from Canada.
I think I got a little overeager.
I asked two questions, and now I'm not sure which one you're referring to.
DAVID MALAN: I think you had a math question.
AUDIENCE: OK, yes.
So my question was a little desperately worded, but it was,
can you please promise me that all of these linear algebra and discrete math
and calculus classes will come in handy in my future career?
DAVID MALAN: Yeah, a common sentiment.
And for the group, this was asked essentially in all capital letters,
too.
So let me turn to Brian, who's studied these topics most recently
and also, I think, can speak to just how applicable they can be in some domains.
BRIAN YU: Sure.
Well, thank you for that question.
I definitely felt the same way when I was taking some of my linear algebra
and calculus classes.
I think ultimately whether or not it will
come in handy will depend in part on what your career path is.
But there are definitely areas within computer science
where calculus, linear algebra, discrete math-- where all of that
becomes relevant, especially in the world of artificial intelligence
and machine learning nowadays.
So as you think about using calculus, you're
doing it very abstractly to do things like how
do you find the maximum point of a function?
But you could translate that in a machine-learning setting
to how do you maximize the accuracy of your machine-learning system?
So a lot of the ideas that are taken from calculus and linear algebra
have a lot of application nowadays in terms
of modern machine-learning research.
Linear algebra in particular also has a lot of applications
to graphics-- so some of the stuff that Colton's just been talking about,
about games and game development.
A lot of graphics right now was ultimately based on linear algebra.
And a lot of what graphical processing units are doing
are just like pieces of hardware that are
designed to do these linear algebra operations very, very quickly.
So definitely, a lot of applications, depending
on where within computer science or other domains you're interested in,
but they do become important at some point.
DAVID MALAN: And I can say, too, I felt some
of the same frustrations taking math classes in college
and also in high school.
And I think it's in part because of how the classes I took were taught.
Many of the math classes I took were just so mechanical.
Like, it was just problem after problem after problem.
And I worry that a lot of classes lose sight
of the forest for the trees, so to speak,
which is they focus on a lot of the lower-level details
without appreciating that what's really important
is the higher-level concepts, like what a derivative is
or what an integral is in the world of calculus.
And frankly, in retrospect-- and I can say this with some confidence 20-plus
years later--
I really didn't need to know 12 different ways to take a derivative
or do an integral, especially now, when we have computers that
can help with some of those processes.
Hands-down, important to understand the applicability
of finding the min or the max and what problems
you can solve with those kinds of techniques, let alone
matrices and the like in the world of linear algebra.
But take some comfort in knowing that even though courses you're taking now
in math might be belaboring the point again and again,
the ideas are useful, even if you start to forget some of the mechanics
and don't get all of the answers right when trying to do things by hand.
Well, thank you for that, Vicky.
Hopefully that helps with future math studies for others as well.
Let's go to Ledor next.
Am I pronouncing your name correctly?
If you'd like to say hello and where you're from, too.
AUDIENCE: Yeah, sort of.
My name is Ledor.
I'm 21.
I'm from Israel.
And my question is I would love to know some more
information about how your walkthrough videos for various problems sets
are written.
Right now, I'm on problem set five.
And I'm kind of not sure about most of the questions there.
And I'm sure the walkthrough videos helped me
a lot to understand some of those basics and ideas of the code.
So generally, what are your considerations and/or inspirations
when making one of those videos?
And how do you decide what to include in them or what not to include?
DAVID MALAN: That's a really good question.
I can speak perhaps to some of the history,
and then have Brian elaborate on his particular approach to them.
So we've been doing these walkthrough videos
for CS50, which are these short YouTube videos that
are embedded into the homework assignments for CS50 itself,
for those unfamiliar, for probably 10-plus years now.
And different teaching fellows, or TFs, have led them over the years.
Marta Bralic was the first, some 10-plus years ago.
Tommy MacWilliam, after that, who you might remember from other CS50 videos.
And then Zamyla Chan, who held the title for probably
eight or so years while she was an undergraduate as well as a PhD student
at Harvard.
And she only just recently moved out into the real world.
In fact, as an aside, before I forget, if those of you
who know Zamyla from past years of CS50, I've just pasted into the chat window
a URL of her graduation speech that she gave upon receiving her PhD.
But the motivation for the walkthroughs early on
was really to start to answer a frequently asked question, or FAQ,
which was quite simply, where do I begin?
I'd hope we have fairly detailed specifications in the problem sets,
telling students what they ultimately need to do.
But they deliberately don't really tell the students how to do that.
And frankly, we have found through trial and error
that the longer, the longer, the longer the problem
sets' English language gets, the less, the less, the less the students
actually read it, even the native English speakers.
And so we wanted to use another media format to convey ideas and hints
for those students who might want the.
Additional guidance.
Early on, these walkthroughs were only in person.
We would hold them in a lecture hall on campus.
And students would come and attend these classes for help
with the current week's problem set.
And then over the years, we began to film those.
And then over the years further, we then got rid of the audience,
and we started to pre-produce the videos in a studio or in an office,
just so that we could get them just right.
We could alternate between text and code and the human speaking onscreen,
and then literally integrate them into the problem sets themselves.
In fact, it's a very deliberate, if subtle, design decision
that when Brian leads them and Zamyla leads them,
they're against this white backdrop because we really
want the human element to blend into the homework assignment itself.
And indeed, what was wonderful about Zamyla especially,
who really became the face of these walkthroughs for so many years,
students really began to identify with her-- really want to meet her,
really want to be her--
because she was literally the person there for them in their time of need
when they were struggling with homework assignments.
And so that's some of the history.
And Brian has now taken up the baton himself.
And Brian, do you want to elaborate on your approach?
BRIAN YU: Yeah, certainly.
I mean, I took a lot of inspiration from Zamyla's walkthrough videos
and watching the way that she did them as well.
But my general approach with the walkthroughs
is to first and foremost convey any background knowledge needed
to solve the problems-- that a lot of our problems
connect computer science to other domains.
So with the election problems, like from problem set three,
for example, I'll start the walkthrough just
by talking through how these elections work
so that you understand what the election even is before you
start worrying about the code.
Or likewise, with speller, trying to talk through
like how a hash table works to get an understanding of that
before you start writing the code.
And then the next step in the walkthrough videos
is I try to provide some ideas for how to start thinking about the problem
a little bit more methodically.
With a lot of these problems, I've been helping students
with them for five or so years now.
And I've started to see the way that some people try
to start to think about the problem.
And so part of the goal of the walkthroughs in my mind
is to provide some guidance and some hints
as to where to start your thinking in terms of how you can then translate
that into code, while still leaving the core of the problem up to you to solve.
Because we don't want to give the problem away in the walkthrough video,
but we do want to just give you that little first nudge
so that you have an idea of how you can begin writing up your own solution
and thinking about how you would go about solving any
of the problems in the problem sets.
DAVID MALAN: Nice.
Well, thanks for the question, and hope the walkthroughs
are indeed helpful for those taking CS50X online.
Next question-- can we go to Ivan, if you'd like to say hello
and where you're from?
AUDIENCE: Hello?
DAVID MALAN: Yes, hello.
AUDIENCE: [INAUDIBLE] the techniques used to detect bugs.
Well, in one of the first weeks from CS50 course,
David told us some of the techniques that can help us to detect bugs,
like the rubber duck describing thing.
Well, before I started to take the CS50 course, I knew some C++.
But when I started with C, I had some problems detecting bugs in my programs.
And I was wondering, how do you think that you can change
this type of thinking about your codes?
DAVID MALAN: So how do your debugging techniques
change based on the language you're trying to debug, it sounds?
Yeah, so I can say there's a few techniques that work,
no matter what language you're working with.
And simply using print or console.log or the equivalent of just a function that
displays information on the screen is probably
one of the oldest debugging techniques because it
allows us humans to see what's going on inside of the computer
by printing out text or variables whose values we might want to know.
Rubber duck debugging, for those unfamiliar,
is literally holding up a rubber duck on your hand or on your desk
and talking to that rubber duck, explaining to the duck
what you think your code is doing or what you want your code to do.
And invariably, in talking out your code, it's quite common for people
to realize, oh, that made no sense what I just
said to the duck, let alone the weird fact you're talking to the duck.
Or you realize, oh, no.
I should be thinking about this differently just in hearing yourself
talk.
A more social way to do that is to have a friend or a colleague
or someone on a video conference just to tell them about your code.
But in general, talking through problems can save significant amounts of time.
I can't tell you how many times I have spent minutes, hours, trying
to fix some bug in code I wrote.
And then I finally get up the nerve to reach out to Colton or to Brian
and start talking to them about the problem.
And even if they don't say something sometimes, do I realize, oh, that's it.
Goodbye.
And it's really a helpful constructive process
to have that approach to collaboration.
As for tools, I do think this varies.
And in fact, Colton, do you want to speak
to some of the different debugging techniques in various languages?
COLTON OGDEN: Sure.
So I'll echo what you said.
Amongst all languages, I typically do like--
and I know it's not super encouraged, but I
do like to use print statements because it's just an easy way
to dump a variable and its output to the console.
And you can just see, oh, my variable actually isn't getting a value.
Or it's 0, and it shouldn't be 0.
But if you're in a visual environment-- so I spend a lot of time
doing web dev these days.
And I've spent time in Unity as well.
Both of those are very visual environments.
And you have the chance to actually inspect a lot more than just variables
and memory.
You can actually look at a piece of the div.
If you're building a website, and you click on Chrome Developer Tools,
you can actually click on different pieces of what you're doing
and look whether your JavaScript is actually
affecting something or something else.
And Unity is kind of the same way, where you can at runtime actually inspect
all your variables.
But if you're doing something like C or C++,
and you don't have an engine to give yourself a visual environment to do
this, you can use GDB, which CS50 teaches to an extent.
And then that will allow you to actually examine your code
as it's running in a lot more detail.
But yeah, it just depends on the language,
depends on the tools for that language.
Python has PDB, Python Debugger, which you can use in Python as well.
So yeah, get familiar with a debugger of some kind.
I mean, also a big part of it, too, is intuition, honestly.
I think as you get more experienced, I think
you do start to see the common patterns crop up.
And when things don't behave in the way that you expect-- and this
is going environment-centric-- it can be easy to pick up
on things even subconsciously and look at the right variables
or the right function faster than early on, when you're not necessarily sure,
and it's kind of an unfamiliar territory.
I think just doing a lot of--
it's the baseline answer to a lot of questions in computer science.
It's just do more exercises, do more programs, and get familiar.
But with this specifically, also getting familiar with the tools
at your disposal for debugging can be very helpful as well.
DAVID MALAN: All right, well, thank you for that question.
And indeed, print should be the place you begin,
but not the place you end when it comes to debugging.
Using a proper debugger and learning how to use a proper debugger,
even if it takes you more time the first time around,
is absolutely a long-term solution as well.
Let's go next to Emily, if you'd like to say hello and where you're from
and what your question is.
AUDIENCE: Hi.
I'm Emily.
I'm from Mexico.
Can you guys hear me?
I think--
DAVID MALAN: We can, yes.
Welcome.
AUDIENCE: OK.
So against all odds with this COVID thing, I got my first job in marketing.
DAVID MALAN: [INAUDIBLE]
AUDIENCE: Thanks.
And the thing is the people that I work with don't know how to code
or don't know how to program.
So I was wondering if you could give me some ideas because I [AUDIO OUT]
want to incorporate computer science into what I do.
But I have no idea where to start.
And the people that I work with know a lot about marketing, but not
necessarily about computer science.
So what are some good ways that I could potentially
mix the two things, like computers and marketing?
I don't know if I made myself clear.
DAVID MALAN: You did.
You did.
And I think both Brian and I perhaps can respond to this.
One of my first jobs after college wasn't working in marketing,
but working in customer service, where my colleagues, too, really
didn't have any computer science background, no programming background.
And even my job was not to program and not to do CS per se.
It was just to support some of this company's customers
on the phone or email or the like.
But what I realized after getting to know my colleagues
and understanding their process every day of working at their own jobs
was there was a lot of opportunities to improve efficiency.
There was a lot of manual labor that they
were doing, whether with their computer or paper
or the like, that felt like, hey, I, as a computer science major,
could improve this.
I could speed this up and free them up to spend time
on more interesting things.
So I remember one of the first things I did
was write some kind of web application that
allowed all of the non-technical people to automatically email customers
the equivalent of form letters, I think it was-- so automatically generated
emails that were somewhat customized.
And after that, I became the customer services team in-house developer,
even though we had a development team.
And that's just one thought that's not specific to marketing.
But I think now that you're in a new world and with new people,
undoubtedly, you'll see a lot of inefficiencies or opportunities
to do things differently or better.
And you will become everyone's best friend
by knowing how to do those things technically.
So I would consider that kind of a watchful eye.
And Brian, your thoughts?
BRIAN YU: Yeah, I was also going to suggest
looking for areas where you can automate things or make things more efficient.
The other thing I might suggest is in a lot of industry,
and I'm sure marketing as well, your team probably
has access to a lot of data-- data about customers
and how effective your particular marketing campaigns have been.
And one thing that computer science is quite good at
is just data analysis-- that if you can write a script
to be able to look through some data and draw
some interesting or useful conclusions, that
can be an often interesting place to start and something
that could potentially produce very useful results.
So I might look for what data your team has access to
and thinking about what you could do with that data
by writing a computer program.
And see where that takes you.
And congratulations on the job, too.
DAVID MALAN: Indeed, congrats.
Let's go next to Taylor, if you'd like to say hello and where you're from.
AUDIENCE: Hi.
I am from Massachusetts, living in Somerville right now, not far
from Harvard.
My question is about summer courses in the Harvard Summer School.
I'm currently registered for E89, which is an intro deep-learning course,
though I'm considering that course or E80, the AI course with Brian.
I just took CS50 this spring.
And I'm curious which one you might recommend for who
and what students in each course might expect
to get out of the one versus the other.
DAVID MALAN: Yeah.
For those unfamiliar, in addition to the courses
that Brian and I teach and Colton teaches on edX,
Harvard also has an extension school, the Division
of Continuing Education, that offers courses for adults and younger students
generally for credit, for transcripts, and so forth.
There is tuition for those courses, but it
allows students to actually pursue degrees online,
unlike what you could do, for instance, via OpenCourseWare
or a platform like edX.
I do hear good things about E80.
And perhaps Brian could generalize the answer, too,
to be about not only E80 and E89 at the school,
but about AI and deep learning more generally.
BRIAN YU: Yeah, certainly.
So these terms come up a lot in terms of like artificial intelligence,
deep learning, machine learning.
And it's a good question as to how these things relate to each other
and what they all actually mean.
To be very general about it, I would consider artificial intelligence or AI
to be the superset of all of them, just to be generally referring to any time
we're talking about building systems that can do things
that we would consider to be intelligent,
so whether that means them doing something rational
or doing something that seems human-like.
Within artificial intelligence, a subfield within that
would be the field of machine learning, which is specifically
about how do you train a computer to be able to do a task that it wasn't
explicitly told how to do?
And within machine learning is an even smaller subfield
that is quite popular now which is that of deep learning.
And deep learning is a specific technique
within machine learning-- namely, the use of multi-layer neural networks
to be able to solve problems.
And it turns out, using neural networks has
been able to solve a really wide variety of different types of problems
within computer science and a whole bunch of different fields.
And so as a result, it's a very popular and interesting topic
within artificial intelligence nowadays.
So in general, if you're taking a deep-learning class,
it's going to focus very specifically on that one topic,
going much more in-depth into neural networks specifically.
Whereas artificial intelligence is going to be a little bit broader.
If you're taking an artificial intelligence class,
you'll probably spend some time on neural networks,
but also spend some time on other techniques
for how to design and build intelligent systems as well.
DAVID MALAN: Nice.
And while E89 is not freely available on edX,
allow me to paste the URL of Brian's AI class,
otherwise known as E80 at Harvard, which is indeed
freely available via that platform and YouTube and the like.
Well, best of luck with choosing, Taylor.
How about over next to Akash?
If you'd like to say hello and where you're from.
And I hope I'm pronouncing your name right, too.
AUDIENCE: Hey, David.
Hi.
I'm from India.
And I wanted to ask about systems reliant on architecture.
So I've been a software engineer for some time.
But I still don't get a lot of opportunities
to design a complete system.
And I want to get better at making decisions like which DB to use,
and from infrastructure to service stuff like load balancers
and servers [INAUDIBLE] So how can I get better and then get some hands-on?
DAVID MALAN: Yeah, it's a really good question--
how to go about getting better at the operations side of running web
applications or apps more generally.
It's very commonly the case that if you're working in software development,
especially in a large company, for those unfamiliar, that you
tend to be very focused on a pretty narrow piece of the puzzle.
Maybe it's the front end.
Maybe it's the back end.
Maybe it's the database stuff.
But it's not always the case that you have a complete picture of everything
and the responsibility for everything, for better or for worse.
But very increasingly common these days is
what's generally known as DevOps, which is
a conjunction of developments and operations,
where development means writing the code.
Operations means essentially running the code
or setting up the servers that are going to run the code,
setting up the firewalls that are going to protect the code, and so forth.
And perhaps the best way to get good or experienced with DevOps
is really to try to find some project of your own that you can take on,
even if it's just an application for fun.
Maybe it's some side project for work.
Maybe it's a gig that you're doing for pay on the side,
but something where you will have full control over the entire user
experience and the hosting thereof.
And I would encourage you, if you can, to try
using services like Amazon's Web Services or Microsoft Azure
or Google Compute Platform, each of which
allow you more fine-grained control over your servers, over your memory,
over your disk, over your firewalls, over everything.
Then do higher-level services like Heroku or DreamHost
or GoDaddy or higher platforms that hide all of those details for you.
The downside is it can be complicated, and it's
easy to break things when you're in charge of everything.
But I think if you can find a personal or professional project that
is yours to own and to figure out, it's the best way to learn.
And so for instance, me-- some 10 years ago now, when Amazon Web Services,
which is Amazon's cloud platform, was just coming into existence--
my own professional and personal goal was
to try to replicate a cluster of servers that we
had on campus at Harvard at the time, but move
it into the cloud because I wanted to figure out
how I could scale it to be bigger and handle more students,
how I could automate certain processes, how I could have route or administrator
access, which I didn't have on campus.
And because I had a goal that I cared about,
and it was going to solve a problem I had,
it truly motivated me to figure everything out.
And eventually, I figured out, wow, I don't want to run everything myself,
but I know now how to do it.
And I can have thoughtful discussions and design discussions
around how to do those same things.
So hope that helps.
And so in short, sign up for a free trial
account on Amazon or Google or Azure and see if that helps.
All right, well, let's next go to Mateen, if I'm saying it correctly.
If you'd like to say hello and where you're from?
AUDIENCE: Hi.
I'm actually Persian, but I'm calling from Texas.
DAVID MALAN: Nice to meet you.
AUDIENCE: I just signed up for both CS50 and the game development class
at the same time.
And I have some experience with C Sharp and Java,
that was like a few years ago.
And I'm just trying to get back to programming.
And also, I didn't see any due dates on the game development class,
so I'm assuming that it's like the CS50, and it's by the end of 2020.
So my question is, would you suggest that I solely focus on the CS50 class
first, try to finish that, and then move on to CS50G?
Or should I try to take them at the same time?
What are your suggestions?
DAVID MALAN: Sure.
Really good question.
Let's go straight to the source if, Colton, you'd like to advise?
COLTON OGDEN: Sure.
Personally, when people ask this question,
I usually like to say do CS50 first.
Now, since you said that you had some prior experience,
you might be in a position where you can actually do both of them concurrently.
But the games course is a lot of code by design, really,
because games are a lot of code.
And CS50 does ramp you up a bit.
It doesn't start with a ton of code per se,
although even the first few pieces are fairly intentionally a little bit
rigorous.
But yeah, I would say it would probably be a net positive for you
in the long term to do CS50 first.
Focus on that, rather than divert your attention between two at once or even
do more of the game stuff first, because I
think you'll have more questions than answers, especially early on.
And that might get frustrating, although I don't know how personally you
might deal with that.
Maybe that's totally fine because that's kind of how I am.
I just like to do whatever I feel like doing and get things done.
But practically speaking, I think the short answer is CS50 first
and then games would be what I recommend to most people.
DAVID MALAN: Nice.
Well, thanks for the question, Mateen.
Let's go next to Musadiq, if you'd like to say hello and where you're from.
And I hope I pronounce that right as well.
AUDIENCE: Hello, this is Musadiq from Pakistan.
Thank you.
And the question is about how would you recommend someone
who would just want to teach CS50 at the local schools, just in terms of content
and how to inculcate the students with interest to learn about computer
science and the things like this.
DAVID MALAN: Yeah.
Really good question, and thank you for the interest
in teaching CS50 in some form.
Let me paste a couple of resources here into the chat window.
For those unfamiliar, in addition to CS50 being freely available on edX,
we also have on harvard.edu our own version
of the same OpenCourseWare that has all of the course's
materials and a few others as well.
We do have this network of high school teachers and university
teachers and students and non-profits that wonderfully
have chosen to adopt or adapt CS50's curriculum in some form, such
that they teach the class locally.
And how you can do this can vary, really,
on what you think would work best for the students you have in mind.
For instance, some teachers have adopted CS50 outright, so to speak.
And they simply have their students watch the lectures online,
do the problem sets online, submit online, and so forth, and really use
the course as it exists on that URL I just pasted.
But what they then do locally is help students with the problem sets.
They hold the equivalent of office hours, not unlike these,
but much more code-centric and generally in-person.
And they might even hold what we at Harvard call sections.
Sections are smaller classes led by teaching assistants or teaching fellows
that guide students through additional examples,
answer questions about material that they might
have seen in the most recent lecture.
Other teachers, by contrast, choose to adapt the course
instead of adopting it outright.
And by that, I mean the teachers might watch the lectures that I gave.
They might read through the problem sets.
But then they adapt those resources.
They teach the class themselves, but maybe using some of the same examples--
maybe using my slides, but not my voice, using their own instead.
They might chop up larger problem sets into smaller pieces
so that they can spread it out, so that they
can work through things more slowly.
And they really do what they think is best for their own students.
What I can say next month, and we're in the midst of planning this now--
Brian, Ramon, and I, in fact, with CS50's team--
is a workshop that we hold annually for teachers
interested, like you, in adopting or adapting the course somehow.
I've just pasted an email address into the chat--
outreach@cs50.harvard.edu.
And Musadiq, if you want to follow up more personally with an email,
we can connect you with the team and help you think about what next steps
you might want to take.
And in fact, if anyone else out there is interested
not in taking CS50, as you might already be, but in teaching CS50,
allow me to paste the URL of the pre-registration form
here into the chat via which you can register for this workshop.
It would have been here at Harvard in June.
It's now going to be online via Zoom in June,
so many more people can participate.
Well, thank you for the interest and for the question itself.
Well, let's go next to Mithilesh, if you would like to say hello
and where you are from.
AUDIENCE: So I'm from India.
And first of all, I'd like to thank all of team members
for coming up with such a fantastic course CS50.
And I'm in [INAUDIBLE] My question is, what
is the next course in the pipeline from the [INAUDIBLE] team members?
DAVID MALAN: That's a really good question.
We have made no decisions yet.
We have been brainstorming.
And in fact, we would welcome from people in the chat
or via social media suggestions for what might be of most help to you.
Brian, do you want to perhaps share some of the things we've
been thinking about, even though we've made no decisions just yet?
BRIAN YU: Yeah, sure.
So upcoming in about a month is going to be a refreshed version of the web
programming class.
That's been around for about two years now,
but we've updated it to focus on some more modern web frameworks,
in particular, the latest version of Django, a web framework,
as well as React, a popular front-end framework developed by Facebook.
So that's something that's coming up later this year.
But beyond that, as David mentioned, we don't
have anything in particular in mind, but definitely
been exploring possible other topics within computer science,
thinking about anything from some of the more theoretical ideas in computer
science, like the discrete mathematics that was talked about
and the algorithm design, to other types of programming--
things like functional programming and logic programming
and different approaches to programming as well.
So certainly, feel free to let us know what things you would like to see
and what topics you are interested in.
But we don't currently have a definitive answer for what will be next.
DAVID MALAN: Yeah.
Stay tuned, indeed, for more.
Well, thank you for that.
Can we go next to Nathan, if you'd like to say hello and where you're from.
AUDIENCE: Hi.
I'm Nathan, 27, from London.
So my question really is if you are interested in pursuing computer
programming, say, as a career, should you
learn a broad aspect of all languages that you possibly can, really
focus down and become an expert on one language,
or just find out what programming languages are
relevant to the field you want to work in and have a good knowledge of all
of them?
DAVID MALAN: Yeah, that's a really good question.
Colton, how do you think about this?
COLTON OGDEN: So I like both approaches.
I think early on, it makes more sense to go deep into one area
because I think going too thin early on makes it hard
for you to be particularly competent enough to get a job, I think.
I think, because typically in a job, you're going to be doing--
usually using-- I mean, depends on where you're working.
But I think if you're going to work for, say, a web company,
usually you're dealing with a very small set of technologies.
Or if you're in games, your engine's in one or two languages, you know?
It's going to depend on the environment you work in.
But early on, I would say focus--
and especially because you gain more skill in deeper topics
by going deeper into one language.
And you learn a few more interesting ways to solve the same problem,
going beyond loops and if statements and stuff like that, which you learn.
And you can learn those easily amongst all different languages.
But every language has its own paradigm or way of thinking about things.
And you learn those things, and you learn the libraries for each language
if you're staying in one language and going a little bit deeper
in that language.
Now, that said, I think you get a more holistic appreciation for languages
and the pros and cons of using different languages and, therefore, a better
ability to choose a language, a framework, or an environment
once you have sampled a large set of the technologies out there.
And I think that, after you've got a couple of years experience,
actually makes you even more useful as a candidate--
having deep knowledge in one area, but also a very holistic understanding
of the landscape.
At least, to me, I feel like that would be more valuable than somebody who
only knows one thing or one language.
But yeah, I think it's going to also heavily depend
on the environment and the problems you're trying to solve.
DAVID MALAN: Indeed.
Well, thank you for that question.
And we're nearing the end of the hour.
And we want to be mindful of everyone's time and schedule.
Before we conclude in just a bit, we have
a tradition we've started now of taking a group photo via screenshots of Zoom.
So stay tuned for that in just a moment.
But we thought we'd take at least one more question here.
Indeed, our last question-- how about from Josh, if you'd like to say hello
and where you're from?
AUDIENCE: All right.
I'm Josh.
I'm 16, and I'm from the island of Guam.
So my question is when you guys were first learning programming a long time
ago, what kept you motivated?
And when did programming really click with you?
DAVID MALAN: Oh, that's a really good question.
So I think we can probably each answer this one.
For me, I think it was when I finally started finding personal projects that
were not academic in nature.
They weren't homework, but they were actual problems that I wanted to solve.
That's where I really got into programming and the excitement
clicked and my thirst for wanting to learn more and figure out
how to do things differently and better really clicked.
And in fact, the first thing I can think of--
I can paste this into the chat window.
This is from like literally 20 years ago in Harvard's newspaper
that I just googled.
I wrote this program at the time that was called Shuttle Boy.
And it was this command line program that you could run in a Unix
or in a Linux environment.
Before there was Webmail and Gmail, students at Harvard
use to check their email in a terminal window,
just like you might be compiling and running your C code or Python code.
And at the time, there was no GPS.
But we did have buses and automobiles.
And so Harvard had a lot of shuttle buses
that would drive around campus to take students from one location to another.
But the way you could figure out when the next schedule was you
picked up this old-school technology, printed paper,
and you could look up the time that the next shuttle could pick you up
from location A and take you to B. So for me, this seemed like an opportunity
to use some of the knowledge that I'd literally just picked up from CS50
and a follow-on class called CS51.
And I wanted to implement a program that would make this process much easier,
so students could check the schedule on their computer,
then go outside when they know there's going to be a bus there.
And it was just so gratifying.
I was lucky that this happened to solve problems,
not just for me, but for lots of other people on campus.
And I think several hundred, maybe a couple thousand students at Harvard,
ended up using this program.
And what was so cool about that was that it was never done--
the program.
I kept wanting to add more and more features to it, fix bugs and so forth.
So it really became a passion project.
And that, I think, for me is when it really clicked--
that I'm not just studying a topic in a class.
I'm not just learning something very mechanical.
Like, I'm learning something very empowering-- programming
that can genuinely solve problems that excite me and genuinely help others.
Brian, any thoughts come to you?
BRIAN YU: Yeah.
I think my general story is fairly similar--
that when I was first learning, the thing that really inspired me
was the different types of problems that I was able to solve.
And when things really started to click was
when I found a way that I could apply computer science in my life outside
of computer science to be able to do interesting things and solve problems.
The one that comes to mind is that in college, I
was a graphic designer for my college's newspaper.
And I would often have to late at night be designing
all of these charts and various different graphics
in a particular style to put up on our website or to put into print.
And very often, we're designing a very similar type of graphic again and again
and again.
And I remember one day just deciding to write a Python program that would just
create these graphics for me.
So I could just type in a few lines of code
and generate the graphics automatically.
And that alone just saved me hours that semester.
I spent maybe half an hour writing a program,
and immediately, it was making things easier
for me and for the people that I was working with.
So that, I think, it really helped it to click
for me-- being able to write a little bit of code that
helped us solve a bigger problem.
DAVID MALAN: Nice.
How about Colton?
What inspired you?
COLTON OGDEN: So I went into it with a goal
from the very beginning, which was I wanted to make games.
And that was since I was probably 10 or 11 years old.
But it started around the time I was in high school, so 14, 15.
And the first time I actually tried coding, it was from an old book
on the Torque game engine, which was popular in the early to mid-2000s.
And it used a custom language called TorqueScript,
which looked kind of like Perl or PHP, but a little bit weird.
It had its own syntax for some stuff.
And probably because of all the syntax and just the fact that it
wasn't formatted very well and it was black and white,
I just kind of got immediately almost repulsed by it, to be honest,
and didn't--
I had never seen code before, so I wasn't really familiar with it
or appreciated or know how it even worked or knew how to--
like, what games were even made of.
I just thought they were all like visual editor-based projects.
But the desire to make games didn't go away.
I still wanted to make games.
So I tried it again.
But this time, I decided I was going to learn something beyond TorqueScript.
I was going to go learn something like C or C++.
Those were the first two languages that I learned.
And learning from a more structured beginner-focused way,
doing simple exercises, learning the very basics--
you know, what's an if statement?
What's a variable?
What's a loop?
All of this stuff, I think, lit a fire within me--
the fact that I could actually make a computer do things
that I wanted to using what sort of felt almost English-y,
but it's like giving instructions in a way, right?
Using C or C++--
very imperative style.
That allured me in a way to where it wasn't just about making games anymore.
It became about coding because it was a craft
and because I thought it was interesting and because the landscape, honestly,
is just infinitely vast.
You can study your whole life and not know--
and this is the same with most sciences.
But you won't be able to know everything there is to know
about everything in computer science.
So you'll always be learning something new,
and it'll always be fascinating and interesting.
And that's what keeps me enjoying it to this day.
I can learn.
I can get a lot of enjoyment out of even small, little, new things that
optimize my workflow or let me think about programming in a different way.
So I don't know.
It's been a fun journey.
DAVID MALAN: Well, thank you so much for joining us for CS50's office hours.
We will email everyone when we know when the next one will be.
Thank you to Brian, to Colton, and CS50's whole team behind the scenes
and to all of you for your questions.
I hope you'll forgive if we didn't answer all of them.
But we'll definitely do this again soon.
All our best to you and your families and friends.
BRIAN YU: Good to see everyone today.
Thanks, everyone.
COLTON OGDEN: Thanks, everybody.
BRIAN YU: --see you next time.
COLTON OGDEN: See you.