When I was a teenager, I wrote small C projects, then I discovered the world of OS development and set myself to write a minimal operating system from scratch. It was an amazing experience, with a lot of head-scratching, hours spent debugging weird hardware issues, reading other people's code and just churning out badly engineered (but working) code.
Now, 10 years after, after playing with Haskell, OCaml, Scheme, learning about best practices, variants, typeclasses, static vs dynamic typing and data structures, every time I set myself to write something more than 100 lines I just get stuck: which language is best for the job? How should I refactor this to be more clear and concise?
My programming life definitely got worse (as a C/Python programmer) after I discovered variants and the Option/Either monads.
As I said to him, ignorance is bliss.
def maybe(decorated):
def worker(*args):
if any(arg is None for arg in args):
return None
return decorated(*args)
# Standard decorator machinery
return worker
The post said to pick one area, research all of the shit right out of it, e.g., focus. Your list (and I assume it's abbreviated) is the opposite of that.
I agree you need to code (and a lot). I disagree (vehemently) that you need to fuck, then un-fuck, your code in order to progress.
The problem with reading a lot before coding is that you learn the knowledge ("what to do") without learning the wisdom ("when to do it). Even if you specialize in one area, there's a large body of practical knowledge that people do unconsciously when they're working on a problem, but don't think to write down in a book. Or if they do write it down in a book, you won't understand the context for it until you've been in several situaions where their advice has both worked and not worked. When I was studying this stuff in college, I read multiple books on each topic, it "clicked", I knew when to use each technique - but I didn't know when not to. As a result, my designs tended to be jam-packed with features. It takes experience to realize "Oh, metaclasses are really handy in this one situation...but most of the time, you are better off banning them because the cost in understanding your code is greater than the code simplification they give you."
Write code first. Write code until your programs collapse under their own weight. Then go out and read what the masters have written. You'll understand it much better when you have personally faced the problems that they were facing.