I work in programming, and I agree with just about everything you said and I want to put my biggest, boldest circle of agreement around this. I don’t think I started getting into what seems like a more advanced style of programming knowledge until I received a large enough stack of tedium that I had to automate through.
The other key step was realizing something was tedious. If you’ve only worked on a few things related to a system, then everything seems novel, but if you do the same type of thing over and over again, you’ll frequently see a tedious pattern and then you can automate THAT tedium.
A word of caution: It is possible to get so caught up in automating and other meta-work that you lose focus on the object-level goal. I know this because I’ve done it.
“Oh, I could probably automate this with a script...you know, I should really optimize my vim setup for script-hacking...you know, I really need a way to keep track of my vim plugins...I could probably tweak these plugins to work better with what I’m used to...”
A lot of these time investments end up paying off (e.g. you really should use vundle to manage your vim plugins), but every now and then you should push through at least a bit of tedium to make sure you have a good idea of the problem, how much pain it’s causing you, the scope of similar-enough problems which are likely to have the same solution, and exactly what you need to do to solve it.
A word of caution: It is possible to get so caught up in automating and other meta-work that you lose focus on the object-level goal. I know this because I’ve done it.
It depends what you want to learn. If you want to learn programming then spending time on automating stuff is useful practice.
I work in programming, and I agree with just about everything you said and I want to put my biggest, boldest circle of agreement around this. I don’t think I started getting into what seems like a more advanced style of programming knowledge until I received a large enough stack of tedium that I had to automate through.
The other key step was realizing something was tedious. If you’ve only worked on a few things related to a system, then everything seems novel, but if you do the same type of thing over and over again, you’ll frequently see a tedious pattern and then you can automate THAT tedium.
A word of caution: It is possible to get so caught up in automating and other meta-work that you lose focus on the object-level goal. I know this because I’ve done it.
“Oh, I could probably automate this with a script...you know, I should really optimize my vim setup for script-hacking...you know, I really need a way to keep track of my vim plugins...I could probably tweak these plugins to work better with what I’m used to...”
A lot of these time investments end up paying off (e.g. you really should use vundle to manage your vim plugins), but every now and then you should push through at least a bit of tedium to make sure you have a good idea of the problem, how much pain it’s causing you, the scope of similar-enough problems which are likely to have the same solution, and exactly what you need to do to solve it.
It depends what you want to learn. If you want to learn programming then spending time on automating stuff is useful practice.