The fact is that most of the things on the list are just trivial, but a nuisance to do because it is the boring, not glamorous part of the programming job.
For me, the really difficult part of the language is understanding the core concepts, like what is a monad? or a functor? or a lambda, or a map, or an S-expression, a pointer, automatic reference counting,ip stack, neural network and so many more.
Each of those concepts isolated can take more than a week to deeply understand.
What this man calls "The hard part of learning a language" is quite simple and easy to do with the right method.
The method I use is:
- Take a notebook and write down a checklist with all the things you need to do.
-Set an alarm clock to alert you after an hour of work.
-Start following the steps on the checklist, mark them when finished and write notes of what you did.
-When the alarm alerts you, stop working.
Now rinse and repeat every day as a routine, doing other (fun) things so you don't emotionally link learning a new language as something terrible or bad.
Instead of trying to do all the boring stuff one single day(and burning myself out) I split it.
Learning different approaches to programming will pay off over time. It compounds and makes solving problems so easy in the middle and long term. But you are not entitled to improving.
The fact is that nobody cares if you stop learning. They will just pick someone better solving problems and not making mistakes than you(because they continue improving).
I've also found a timer-based approach to drudgery very helpful. Your technique is reminiscent of the "Pomodoro Method"; you should check it out if you're not familiar with it already.
> For me, the really difficult part of the language is understanding the core concepts
Well, it might be difficult in an absolute sense, but it's exactly the difficulty that you're motivated to overcome. You started learning the language in order to understand new concepts/techniques. And so it's the "easy" difficulty, because in some sense it's fun.
It's the difference between climbing a mountain (difficult, but rewarding) and climbing a mountain with holes in your boots, no food, and a broken strap on your pack (difficult and annoying).
> I prefer to just get started by building something.
I think you're missing the point (of the original article). That's pretty much the issue here, some languages have such complicated ecosystems that you can't "just" build something.
To go from "ok I've written some code" to "it runs", sometimes it takes hours of wrestling with complicated tools and reading poorly written docs. It's infuriating.
For me, the really difficult part of the language is understanding the core concepts, like what is a monad? or a functor? or a lambda, or a map, or an S-expression, a pointer, automatic reference counting,ip stack, neural network and so many more.
Each of those concepts isolated can take more than a week to deeply understand.
What this man calls "The hard part of learning a language" is quite simple and easy to do with the right method.
The method I use is:
- Take a notebook and write down a checklist with all the things you need to do.
-Set an alarm clock to alert you after an hour of work.
-Start following the steps on the checklist, mark them when finished and write notes of what you did.
-When the alarm alerts you, stop working.
Now rinse and repeat every day as a routine, doing other (fun) things so you don't emotionally link learning a new language as something terrible or bad.
Instead of trying to do all the boring stuff one single day(and burning myself out) I split it.
Learning different approaches to programming will pay off over time. It compounds and makes solving problems so easy in the middle and long term. But you are not entitled to improving.
The fact is that nobody cares if you stop learning. They will just pick someone better solving problems and not making mistakes than you(because they continue improving).