4 ms·

What differentiates a good programmer from a bad one? The good programmer will navigate the unknown on his own while the bad programmer will struggle. That's ab

What differentiates a good programmer from a bad one? The good programmer will navigate the unknown on his own while the bad programmer will struggle. That's about it. It does not matter what level of proficiency the programmer is at right now. It is a state of mind. The core of a personality. This translates to the whole career. Can you figure things out on your own or do you need someone to guide you, is what makes the ultimate difference.

cloogshicer 2y ago
I think you're on to something but I wouldn't call it a personality trait. It's something that can be learned, but it takes a ridiculous amount of time. I've been teaching programming to complete beginners now for a few years and there is always a point in time during their education where this clicks: they go from asking about everything to realizing that there are often no easy answers and start doing their own research and problem solving.
- robocat 2y ago
  > there is always a point in time during their education where this clicks Always? Or are you showing a selection bias? I call it "hitting your head against a brick wall". The tenacity to keep fighting until you win. Doesn't always work (can end up wasting time) but it is surprisingly effective against seemingly intratible problems. "Grit" is the marketing word. Workarounds is another form. I'm interested in how it can be taught. I force myself because I admire a certain level of "OCD" behaviours and try to emulate those I admire.
  - cloogshicer 2y ago
    No, unfortunately not always. Some people drop out before they learn it. I think it's best learnt through encouragement and support. If I have one takeaway for the last 5+ years of teaching, it's that most barriers to learning are emotional, not intellectual.
intromert 2y ago
This is spot on—a simple and precise explanation. As a programmer myself, I’ve seen developers dive into a 15-year-old codebase, independently work through it, and only ask questions once they’ve exhausted all other options.
- 000ooo000 2y ago
  >15 year old codebase Is this what people think of when they think of an old codebase? Must be nice :')
  - yurishimo 2y ago
    I think it also matters what happened during the intervening 15 years. If you built an app in 2004 and haven't touched it really since, then it should hopefully still be reasonably easy to follow along, even if the conventions might seem outdated. 15 years of active feature development on the other hand will likely be a major slog for any developer, regardless of experience. There's a lot that can happen in 15 years even if there were only 1-3 developers if they everyone takes the easy path since they know where all the gotchas are. It's only when new devs are added that the curtain comes down and the lazy abstractions (or lack thereof) are exposed.

cloogshicer 2y ago

I think you're on to something but I wouldn't call it a personality trait. It's something that can be learned, but it takes a ridiculous amount of time. I've been teaching programming to complete beginners now for a few years and there is always a point in time during their education where this clicks: they go from asking about everything to realizing that there are often no easy answers and start doing their own research and problem solving.

robocat 2y ago
> there is always a point in time during their education where this clicks Always? Or are you showing a selection bias? I call it "hitting your head against a brick wall". The tenacity to keep fighting until you win. Doesn't always work (can end up wasting time) but it is surprisingly effective against seemingly intratible problems. "Grit" is the marketing word. Workarounds is another form. I'm interested in how it can be taught. I force myself because I admire a certain level of "OCD" behaviours and try to emulate those I admire.
- cloogshicer 2y ago
  No, unfortunately not always. Some people drop out before they learn it. I think it's best learnt through encouragement and support. If I have one takeaway for the last 5+ years of teaching, it's that most barriers to learning are emotional, not intellectual.

intromert 2y ago

This is spot on—a simple and precise explanation. As a programmer myself, I’ve seen developers dive into a 15-year-old codebase, independently work through it, and only ask questions once they’ve exhausted all other options.

000ooo000 2y ago
>15 year old codebase Is this what people think of when they think of an old codebase? Must be nice :')
- yurishimo 2y ago
  I think it also matters what happened during the intervening 15 years. If you built an app in 2004 and haven't touched it really since, then it should hopefully still be reasonably easy to follow along, even if the conventions might seem outdated. 15 years of active feature development on the other hand will likely be a major slog for any developer, regardless of experience. There's a lot that can happen in 15 years even if there were only 1-3 developers if they everyone takes the easy path since they know where all the gotchas are. It's only when new devs are added that the curtain comes down and the lazy abstractions (or lack thereof) are exposed.