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.