Welcome to the first office hours.
Peter and I are going to be answering your questions.
Well, Peter will be answering the question. I'll be asking the questions every week.
We're going to take the questions that you ask in the forums.
So far we've seen a lot of really good stuff, so I hope in the weeks to come
you guys keep coming to the forums and keep asking such great questions.
The first question comes from Prajeet, and he's a high school student
who actually lives in the Silicon Valley area.
He wants to know when you're about to tackle a new problem
how much research do you do?
Do you look for methods that have already been written
or do you generally just write these tools yourself?
And how do you balance that trade off of research time versus time spent writing?
That's a great question Prajeet.
An important part of being a programmer is knowing what you should do yourself
and what you should take advantage of what other people have already done.
I like to think of at two levels.
One is the low level tools--the built-in functions and data types like strings and sets
and dictionaries that are part of Python.
There you've just got to learn what's available and keep on learning and reminding yourself
of exactly what all the functionality is.
The core functionality, how you access the nth element of a list,
that you're going to know by heart pretty soon.
But there's lots of individual methods,
like how you count up how many items are in a list and so on.
You may not remember all those, so you'll be looking at the documentation constantly,
looking things up, and saying what methods are available on this type.
And then the second part is for much larger pieces of code.
Say you want a web server or you want to be able to parse and respond to email.
Those are the types of things where you expect, hey, somebody else has done that before.
That's a big job. I probably don't have to do it.
Then you start research, and you find the right module that implements what you need.
Programming is always this combination of what you have to do yourself
and what do you find that people have already done that you can incorporate into your solution.
Mark Sanders asks the next question.
He had some concerns with the difficulty level of the class,
particularly in the solution videos.
Often he'll write some code that maybe solved it one way
and he finds that your solution maybe involves functions that he's never seen before.
What do you have to say to students who are experiencing this kind of thing.
Mark, thanks for that question, and I know other people in the forums had
similar types of questions and what I want to say to you is
everyone chill out. You've all got this.
If you've made it through CS101, you know everything you need to know
to answer all the problems in this class.
Now, I think that there's this misperception that--
and maybe this is sort of the way school has traditionally been done--
that students think that there is one correct answer,
and you're measured by how close you come to the teacher's answer.
In this class, that's not the way things work at all.
In this class, what I'm trying to get you to do is to grapple with a problem,
come up with a solution and then analyze alternatives for how it might be done differently.
If you have the problem and you come up with a solution and it solves the problem,
then you've got it. That's 100% correct. Pat yourself on the back.
Don't worry about how anybody else solved it.
You did the job, and I know you can do it.
You've got all the background you need--full stop.
Now, after you've done, now it's time to introspect a little.
I'll talk about the way I did it, and my way of doing it might be different than yours.
If you think my way is interesting or has something novel to show that you didn't think of before,
then you could say, hah, maybe next time I'll do it that way.
But that doesn't take away from your solution.
Your solution is still fine,
but now you've learned a new trick, a new tool to add to your arsenal
that maybe next time you can use.
I'll let you in on a secret.
Every advanced feature that's in a programming language
is there because somebody suffered in the past.
Somebody tried to write it out the long way, and it took a really long time,
and they said, gee, there's got to be a better way, and then we put the better way into the language.
You've got to understand why this is in the language.
Now, if I just told you ahead of time,
"Here's a new feature. This is part of the language,"
you wouldn't get it to the degree you would if you see why it's there because you suffered without it.
That's the way this course works, and I know it might be different
from what you were used to before where you're spoon fed
everything you need to know ahead of time.
Maybe that's how school works in some cases, but it's not how the real world works.
So don't get frustrated. That's the way the class is supposed to work.
If you have a solution that works, no matter how you did it, then that's fine.
That's perfect. That's 100% correct solution.
Then after that you can start learning about alternative ways to do it.
Thanks. Serge had a question about how to value, I guess,
the clarity of a certain solution or the beauty of a certain solution.
How do you, when you're presented with two choices for code,
both equally correct and even equally efficient,
how do you evaluate which one is better than the other?
Great question, Serge. You're right.
The first thing you want to think about is have I solved the problem?
Do I have it correct?
Once you do, then efficiency is another issue.
Sometimes efficiency is important.
For a lot of the types of problems that we're dealing with efficiency is not important,
because all the solutions will be fast enough,
but I think that's a minor part of the conversation.
The more important part of the conversation is the one you're having with programmers.
That's other programmers who are reading your code and with yourself
as you start developing and working with your code over time.
You want to hold up your end of the conversation.
You want to have it be clear, express exactly what you mean to say,
and have that all work out.
One of the the rules I use is we're all good and communicating in English,
or in our native language whatever it is,
so if the code can look like that then we know we're going to be successful in our communication.
We talk about what's the best poker hand.
Well, the best poker hand is the one that's the maximum according to the hand rank.
To the extent in which I can write my code to sound exactly like that English sentence,
then I think that that code is clear.
There's a one-to-one mapping between the English description and the code description.
Now, Serge, you mentioned length.
The length of a conversation can help clarity of communication or it can hurt it.
If I go on and talk and talk and talk and talk, and you start to get bored,
then I failed in my communication.
Having a program that's too long can be a problem.
Similarly, if you ask me a complicated question, and I give you a two-word answer,
I may have failed to communicate then.
I may not have given you enough context so that you understand my answer,
even if my answer was technically correct.
A program can fail to communicate because it's too short as well.
You've got to learn to have good taste, to say, yes, for my audience
this is the right length, this speaks to them and tells them all they need to know
with just the right amount of context to get it right.
Clair Dunn had a question, and she is interested in this top-down
problem solving approach that we used in unit one.
What I mean by that is we're often defining functions, even pretending to use, functions that don't exist.
When you defined the poker function, you referenced the hand-rank function,
even though we haven't written that yet.
What can you say about the advantages of this approach to problem-solving
versus the bottom-up approach where we would first build up all the pieces
and then use those pieces in the poker function.
We know when we're finished with our program we've got a complete structure.
It's got a top and a bottom.
There's a top level function that you call, and then that's going to call subroutines.
That's why they're called subroutines, because they're below.
They've all got to work in order for your program to work.
Now the question is in what order do you address them?
I think a lot of that depends on the domain
and depends on where you're clear and where you're uncertainty is.
If we have a description of the domain that we understand,
then it makes a lot of sense to start from the top.
I gave the example of saying what's the best poker hand.
It's the one that has the maximum hand rank, and that's a high level statement.
It assumes that we know how to rank a hand.
I think that's quite a reasonable assumption.
If you don't understand what's going on, then sometimes it makes more sense
just to start down at the bottom and build your way up,
to say what are the pieces of the domain and how do they fit together?
Let me play with them a little bit, and then I'll think of a good way to put them together.
You can go in both directions, top down and bottom up.
It depends on your current state of understanding, but I think the key here--
maybe that Clair wasn't used to--is never be afraid to engage in wishful thinking,
to say if only I had a function that did the right thing.
Then I could proceed. You should always be willing to proceed that way.
One last question. You were once a student of computer science yourself.
I'm sure there were methods that were helpful for you in learning how to code.
What kind of advice can you give to current students of computer science?
I should I think you guys are doing great,
and it's so much easier for you than it was for me when I was learning.
Part of the reason for is that so much is more accessible now.
I started before there was an internet, so you couldn't just do a Google search and find results.
Secondly, I didn't own a computer.
Those were big, expensive things that individuals didn't own.
So you had to go to the computer center and use the machines that were there.
It was just inconvenient and hard to do that.
Now, one of the good advantages of doing that was that meant I was in the same room with other people.
You got a chance to talk with your colleagues and friends and learn from them.
I would encourage you to keep doing that, to keep finding other people
to bounce ideas off of and learning from them.
But then you're in such a great position now to learn so much more quickly.
>From what I've seen from briefly observing 101
and from what I've seen in this class, you guys are off to a great start.
It took me years to get to the level where you guys are just starting out. Keep it up.
Thanks for the answer, and thank you all for the great questions. We'll see you again next week.