NICOLE: 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 the commonality they all
have that you've noticed?
That may be something I can look to
see if I can incorporate for myself.
SPEAKER: Absolutely.
A couple 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: Yeah, this is a great question.
I think, with really skilled
programmers that 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, ehrn you're dealing
with a computational problem,
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.
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.
SPEAKER: 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 sort of 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 it 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.
