5 ms·

Play the long game when learning to code

13 points by kiyanwang 6y ago

auslegung 6y ago
I like the concept but felt the article was VERY light on facts, guidance, really anything other than “seek to fully understand a concept instead of getting just enough to get the job done right now “. So if you haven’t read the article yet, you might not need to, you just did.
- didibus 6y ago
  Hum, I'd kind of disagree with that advice actually. I find for me the Feynman technique works best for learning. Basically it says, assume you know everything needed to do the work or teach someone else about it, then go do the work or try to teach someone (by writing a blog post for example), and continue until you face a blocker where you actually don't know how to progress or don't know enough to teach that part, then go read just enough to get unblocked, rinse and repeat until you know it all. What I like about this is that it maximises the search space to spend your learning effort on what really matters. Otherwise it's easy to say... spend too much time on early chapters and not enough on later ones for example.
drewcoo 6y ago
Drew's Law: Whenever anyone presents only two choices either the problem is not real or the choices aren't.
- grej 6y ago
  I hadn’t heard of that before, but I like it! So many current situations where this applies...
notRobot 6y ago
> The best programmers embrace a “long game” mentality. They aren’t in a rush to memorize every bit of syntax, but instead, focus on real, sustainable progress. They know each programming concept builds off of another one and they don’t move on to another concept until they’ve understood the current one. Huh. I don't know any programmers (novice or otherwise) who spend time memorizing syntax. That said, IME, the best way to learn programming is by doing. Even if you know only the very basics, just start working on projects, and you'll learn more concepts and features as and when you need them, look them up, and implement them.
version 6y ago
I feel like a fraud sometimes. I routinely copy parts of various code projects, I’ve used before because Im too lazy to write it again. To the point where I don’t remember how it works anymore. Does anyone else do this? I feel like I’ve been coding for months sometimes when its been more half a decade. Suppose my advice to any coders looking for it or aspiring ones, is to keep it fresh and to always seek Something new, even if you’ve forgotten some ways you’ve built before. It may lead you to a door you haven’t traveled through before. To me that’s what this is all about. Starting somewhere and keep seeking doors.
burgerzzz 6y ago
I'm a senior engineer and had to push some changes to a repo for a team who's standards I wasn't fully aware of. I've never squashed my commits, so I had to ask the team full of other senior engineers (cream of the crop) how to squash my commits. And the four of us had a discussion on the best way, where no one was fully right in the end. I almost define senior engineers by their experience dealing with issues more than anything else.

13 points by kiyanwang 6y ago

I like the concept but felt the article was VERY light on facts, guidance, really anything other than “seek to fully understand a concept instead of getting just enough to get the job done right now “. So if you haven’t read the article yet, you might not need to, you just did.

didibus 6y ago
Hum, I'd kind of disagree with that advice actually. I find for me the Feynman technique works best for learning. Basically it says, assume you know everything needed to do the work or teach someone else about it, then go do the work or try to teach someone (by writing a blog post for example), and continue until you face a blocker where you actually don't know how to progress or don't know enough to teach that part, then go read just enough to get unblocked, rinse and repeat until you know it all. What I like about this is that it maximises the search space to spend your learning effort on what really matters. Otherwise it's easy to say... spend too much time on early chapters and not enough on later ones for example.

drewcoo 6y ago

Drew's Law: Whenever anyone presents only two choices either the problem is not real or the choices aren't.

grej 6y ago
I hadn’t heard of that before, but I like it! So many current situations where this applies...

notRobot 6y ago

> The best programmers embrace a “long game” mentality. They aren’t in a rush to memorize every bit of syntax, but instead, focus on real, sustainable progress. They know each programming concept builds off of another one and they don’t move on to another concept until they’ve understood the current one. Huh. I don't know any programmers (novice or otherwise) who spend time memorizing syntax. That said, IME, the best way to learn programming is by doing. Even if you know only the very basics, just start working on projects, and you'll learn more concepts and features as and when you need them, look them up, and implement them.

version 6y ago

I feel like a fraud sometimes. I routinely copy parts of various code projects, I’ve used before because Im too lazy to write it again. To the point where I don’t remember how it works anymore. Does anyone else do this? I feel like I’ve been coding for months sometimes when its been more half a decade. Suppose my advice to any coders looking for it or aspiring ones, is to keep it fresh and to always seek Something new, even if you’ve forgotten some ways you’ve built before. It may lead you to a door you haven’t traveled through before. To me that’s what this is all about. Starting somewhere and keep seeking doors.

burgerzzz 6y ago

I'm a senior engineer and had to push some changes to a repo for a team who's standards I wasn't fully aware of. I've never squashed my commits, so I had to ask the team full of other senior engineers (cream of the crop) how to squash my commits. And the four of us had a discussion on the best way, where no one was fully right in the end. I almost define senior engineers by their experience dealing with issues more than anything else.