You seem to equate "foundation" with knowledge that's not immediately applicable. There's some truth to that, but I think it misses the forest for the trees. Knowledge is just the tip of the iceberg when it comes to excellence in software development.
Think of programming like writing an essay. Clearly some knowledge is required; you need to include some information in the essay or it's completely pointless. But the difference between a good essay, one that persuades the reader, and a poor essay isn't in the information it contains. It's in the flow of ideas, the juxtaposition of opposites, the emotional connotation of a well-chosen word, the ruthless elimination of extraneous words. The quality of a good essay comes from the skillful presentation of ideas as much as the ideas themselves.
Programming is similar. It's hard. Doing it well requires more than just knowledge of syntax or data structures or algorithms. It requires identifying the essential elements of the problem at hand, extracting their essence and crystallizing it as code. It means writing code that so simple that it seems so obvious and unremarkable that anyone could have done it. It means being able to move up and down the tower of abstraction, from bits flying around in memory to the concepts and language of the business domain, and from individual lines of code up to architecture and processes. It's a skill, like writing or pottery or motorcycle maintenance.
Now from your "I'm fine" list it sounds like maybe you're not interested in excellence in programming per se, just in the business value you can create by programming well enough to solve your customers' problems. That's a perfectly reasonable. That's how I approach design.
But if you want to be a good programmer, to really master the skill, then you need a bit more than a few tools that can solve most problems, and being able to learn new skills just in time. Which is not to say that an academic education is necessary. But it does mean you'll have to learn things that aren't immediately applicable.
Knowing how to solve a problem 5 different ways means you can choose the best way for the current situation, knowing that the other 4 solutions will probably be called-for another time. I've been in situations where "slick stuff" was absolutely appropriate. (For example, I once solved some tricky timing issues in multithreaded code by using continuations. Another time I used parser combinators to drastically reduce the size and complexity of a family of parsers, and eliminated a lot of bugs.)
I'm self-taught too, so I get it. But I wouldn't be so quick to dismiss the idea of building up a good foundation for your skills, if you're interested in developing them.
Comments
You seem to equate "foundation" with knowledge that's not immediately applicable. There's some truth to that, but I think it misses the forest for the trees. Knowledge is just the tip of the iceberg when it comes to excellence in software development.
Think of programming like writing an essay. Clearly some knowledge is required; you need to include some information in the essay or it's completely pointless. But the difference between a good essay, one that persuades the reader, and a poor essay isn't in the information it contains. It's in the flow of ideas, the juxtaposition of opposites, the emotional connotation of a well-chosen word, the ruthless elimination of extraneous words. The quality of a good essay comes from the skillful presentation of ideas as much as the ideas themselves.
Programming is similar. It's hard. Doing it well requires more than just knowledge of syntax or data structures or algorithms. It requires identifying the essential elements of the problem at hand, extracting their essence and crystallizing it as code. It means writing code that so simple that it seems so obvious and unremarkable that anyone could have done it. It means being able to move up and down the tower of abstraction, from bits flying around in memory to the concepts and language of the business domain, and from individual lines of code up to architecture and processes. It's a skill, like writing or pottery or motorcycle maintenance.
Now from your "I'm fine" list it sounds like maybe you're not interested in excellence in programming per se, just in the business value you can create by programming well enough to solve your customers' problems. That's a perfectly reasonable. That's how I approach design.
But if you want to be a good programmer, to really master the skill, then you need a bit more than a few tools that can solve most problems, and being able to learn new skills just in time. Which is not to say that an academic education is necessary. But it does mean you'll have to learn things that aren't immediately applicable.
Knowing how to solve a problem 5 different ways means you can choose the best way for the current situation, knowing that the other 4 solutions will probably be called-for another time. I've been in situations where "slick stuff" was absolutely appropriate. (For example, I once solved some tricky timing issues in multithreaded code by using continuations. Another time I used parser combinators to drastically reduce the size and complexity of a family of parsers, and eliminated a lot of bugs.)
I'm self-taught too, so I get it. But I wouldn't be so quick to dismiss the idea of building up a good foundation for your skills, if you're interested in developing them.