- learning many technologies, even the ones I'll never use
- learning 100% of the syntax (10x what I'll ever need)
- being able to solve the same problem 5 different ways
- learning slick stuff I'll never need
- being able to scale to levels I'll never encounter
- winning brogrammer arguments in on-line forums
then, yes, I'm missing my foundation.
If, OTOH, foundation means:
- seeking solutions for problems, not problems for solutions
- being able to learn whatever I need
- being able to solve most problems with few tools
- favoring action over status
- living in the real world, using academia as a resource
- having learned what really does and does not work
- having raving customers who don't care what's under the hood
- satisfying 100% of customers with 75% solutions
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.
Another classic example of "what is good for the individual is not necessarily good for the group" (the exact name of the economic theory escapes me).
Sure, for you, the cost/benefit scenario might not work out. You seem to be doing quite fine. However what about the people that created the languages you use? Those who built the processors you work on?
A lot of people will never need the things they teach in a standard CS curriculum. I doubt most programmers even know how to spell "automata". But then again, most programmers aren't doing anything new or ground breaking. Most programmers are simply rehashing solutions to problems already solved somewhere, or simply making small iterative steps. I have found that my own work seemed very "small minded" before I began my formal studies.
Even beyond that, I am now equipped to do most anything I choose involving this discipline. I've always wanted to create my own language, and now the only barrier is simply the time and effort I need to put in. I have all the requisite knowledge and background, and my solid foundation will allow me to easily (comparatively) pick up any new concept I might encounter.
The average programmer might never desire to create their own language, but for this field to continue to grow we need people to push the limit and innovate beyond our current limitations. To do this you need to have a deep comprehension of what you are working with.
However even beyond all of that, I wasn't content with not knowing the intricacies of computation. Maybe I'm just a naturally curious person (and possibly biased), but in my opinion the world of Computer Science is one of the most fascinating fields to have ever studied.
One last point... why not? Knowledge is power.
Edit: After reading some of the replies posted while I was typing, I'll agree there are outliers. You will always have those people who are able to become masters of their field with no formal training, but then again, those are a select few.
What about being able to analyze efficiency (Big O), understanding compilers, full understanding of computer architecture, realizing how the CPU executes code, knowledge of advanced algorithms, knowledge of the OS workings, and AI fundamentals? That's generally what I see self-taught people lacking, i.e., deep understanding of anything outside of languages.
You realize these pet topics are only 5 university courses. It would be a intense 4 month semester, but it's workable.
1. full understanding of computer architecture, realizing how the CPU executes code
2. analyze efficiency (Big O) (a few hours), knowledge of advanced algorithms
3. understanding compilers
4. knowledge of the OS workings (often self taught out of necessity)
5. AI fundamentals (Admittedly a specialized topic)
I wholeheartedly disagree. First because I'm a self-taught developer (if such a thing is actually possibly), and second, because I often find myself studying deeply into things outside of the languages I use. A self-taught programmer isn't any less (or more) motivated to study Comp Sci topics than a CS student and most school's curriculum are wide open for anyone to inspect. Most self-taught developers I know are actually mostly the same, deeply passionate, driven, insightful, and knowledgable in a wide range of Comp Sci topics. But as the saying goes, birds of a feather flock together. I suppose I wouldn't necessarily engage with self-taught programmers who don't exhibit any kind of depth any more than I would a University CS graduate who lacked depth. Having said that, none of us are experts in all things Comp Sci related.
The difference between a self-taught programmer and a college CS education is that the self-taught studies what he wants to. If a self-taught person dives into the CS pool, they often learn much more than a B.S. CS person because they are learning what they want to.
However, some self-taught people have conditioned themselves to hate CS due to constantly needing to prove to companies that they are qualified for a job despite not having a CS degree. These people place little value in understanding CS and because of that they are worse off because they weren't forced to learn it.
It all depends on what kind of person the developer is, and I am glad that you are the first kind. I'm getting tired of HN bashing any article that suggests that perhaps a developer doesn't know everything.
I'm a self-taught engineer, and I first picked up Big-O when I was 16. (That was almost 20 years ago). I've written a linux kernel patch (rejected), toy compilers, and the two big no-nos of software development ( 1: Writing your own lock-free code, and 2: Writing a string library, both of which went successfully into production ). I've built my own microprocessor from NAND gates, and wrote the microcode instruction set to go with it. I've studied VLSI (ages ago), but I've never dug into AI topics.
There is one way in which I feel handicapped compared to my colleagues, which is that I find it generally hard to grab a book on a programming topic and read it cover-to-cover (The same goes for taking classes). I've got to get a development environment up, see how I can break the 'examples', and generally abandon the book to doing my own thing before I get more than a third of the way through.
On the other hand, every time I've worked with more classically trained developers on real projects (and all the cruft that goes with it), I always find that there are corners of the code base that none of them understand, and no one ventures in to find out what's wrong.
Myself, I need to understand how a system works in order to work on it, so I always dig, and tweak here, or tweak there, and so I tend to learn full systems much quicker than my colleagues.
In the end, it's a trade-off, but it's how I work, so I guess I'm stuck with it.
As someone who had started out as a self-taught programmer and only after a couple of years went back to school to get a degree, I can confirm that. I think the only thing from your list that I had been familiar with from my self-studies was the Big O notation and some algorithms and data structures. I first went back to get the degree mostly for the piece of paper with better job security and salary prospects in mind, but I actually enjoyed hearing about most of these things. I would add two things to your list which were great fun: automata/languages (I had known how to use regular expressions before, but I had no idea where they came from and how they fit a bigger picture) and heuristic algorithms (like simulated annealing and what not).
In all honesty, I can't say I know for a fact that knowing these things made me a better developer. It's hard to quantify. In your day-to-day life you don't generally use such knowledge. It's entirely possible that it didn't make any difference to my actual work. I certainly did use it during job interviews and lunch-time conversations with my coworkers.
That's generally what I see self-taught people lacing, i.e., deep understanding of anything outside of languages.
What a shame. There are lots of very accomplished self-taught people who know much of this stuff and are busy changing the world. I sincerely hope you get a chance to meet many of them.
It's remarkable how many of these are self-fulfilling prophecies. You'll never use technologies that you have no idea how to use. You'll never need slick stuff you don't know because you won't get into situations where you would end up using it. And so on.
Prioritization is fine, but always be careful about rationalizing your own continuing ignorance of things that a lot of people claim to find useful.
(I actually ran into a min-cut problem in the wild today. I'm glad I recognized it as such, because it was kind of important, and I wouldn't have been able to solve it if I hadn't heard of graph flows and cuts. Hell, I might even have congratulated myself for having avoided spending time learning something so useless....)
Comments
If "foundation" means:
then, yes, I'm missing my foundation.If, OTOH, foundation means:
Then, yes, I think I'm just fine.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.
Another classic example of "what is good for the individual is not necessarily good for the group" (the exact name of the economic theory escapes me).
Sure, for you, the cost/benefit scenario might not work out. You seem to be doing quite fine. However what about the people that created the languages you use? Those who built the processors you work on?
A lot of people will never need the things they teach in a standard CS curriculum. I doubt most programmers even know how to spell "automata". But then again, most programmers aren't doing anything new or ground breaking. Most programmers are simply rehashing solutions to problems already solved somewhere, or simply making small iterative steps. I have found that my own work seemed very "small minded" before I began my formal studies.
Even beyond that, I am now equipped to do most anything I choose involving this discipline. I've always wanted to create my own language, and now the only barrier is simply the time and effort I need to put in. I have all the requisite knowledge and background, and my solid foundation will allow me to easily (comparatively) pick up any new concept I might encounter.
The average programmer might never desire to create their own language, but for this field to continue to grow we need people to push the limit and innovate beyond our current limitations. To do this you need to have a deep comprehension of what you are working with.
However even beyond all of that, I wasn't content with not knowing the intricacies of computation. Maybe I'm just a naturally curious person (and possibly biased), but in my opinion the world of Computer Science is one of the most fascinating fields to have ever studied.
One last point... why not? Knowledge is power.
Edit: After reading some of the replies posted while I was typing, I'll agree there are outliers. You will always have those people who are able to become masters of their field with no formal training, but then again, those are a select few.
I think the theory you're referring to is called the Tragedy of the Commons.
Exactly, thank you
What about being able to analyze efficiency (Big O), understanding compilers, full understanding of computer architecture, realizing how the CPU executes code, knowledge of advanced algorithms, knowledge of the OS workings, and AI fundamentals? That's generally what I see self-taught people lacking, i.e., deep understanding of anything outside of languages.
You realize these pet topics are only 5 university courses. It would be a intense 4 month semester, but it's workable.
I wholeheartedly disagree. First because I'm a self-taught developer (if such a thing is actually possibly), and second, because I often find myself studying deeply into things outside of the languages I use. A self-taught programmer isn't any less (or more) motivated to study Comp Sci topics than a CS student and most school's curriculum are wide open for anyone to inspect. Most self-taught developers I know are actually mostly the same, deeply passionate, driven, insightful, and knowledgable in a wide range of Comp Sci topics. But as the saying goes, birds of a feather flock together. I suppose I wouldn't necessarily engage with self-taught programmers who don't exhibit any kind of depth any more than I would a University CS graduate who lacked depth. Having said that, none of us are experts in all things Comp Sci related.
The difference between a self-taught programmer and a college CS education is that the self-taught studies what he wants to. If a self-taught person dives into the CS pool, they often learn much more than a B.S. CS person because they are learning what they want to.
However, some self-taught people have conditioned themselves to hate CS due to constantly needing to prove to companies that they are qualified for a job despite not having a CS degree. These people place little value in understanding CS and because of that they are worse off because they weren't forced to learn it.
It all depends on what kind of person the developer is, and I am glad that you are the first kind. I'm getting tired of HN bashing any article that suggests that perhaps a developer doesn't know everything.
I'm a self-taught engineer, and I first picked up Big-O when I was 16. (That was almost 20 years ago). I've written a linux kernel patch (rejected), toy compilers, and the two big no-nos of software development ( 1: Writing your own lock-free code, and 2: Writing a string library, both of which went successfully into production ). I've built my own microprocessor from NAND gates, and wrote the microcode instruction set to go with it. I've studied VLSI (ages ago), but I've never dug into AI topics.
There is one way in which I feel handicapped compared to my colleagues, which is that I find it generally hard to grab a book on a programming topic and read it cover-to-cover (The same goes for taking classes). I've got to get a development environment up, see how I can break the 'examples', and generally abandon the book to doing my own thing before I get more than a third of the way through.
On the other hand, every time I've worked with more classically trained developers on real projects (and all the cruft that goes with it), I always find that there are corners of the code base that none of them understand, and no one ventures in to find out what's wrong.
Myself, I need to understand how a system works in order to work on it, so I always dig, and tweak here, or tweak there, and so I tend to learn full systems much quicker than my colleagues.
In the end, it's a trade-off, but it's how I work, so I guess I'm stuck with it.
As someone who had started out as a self-taught programmer and only after a couple of years went back to school to get a degree, I can confirm that. I think the only thing from your list that I had been familiar with from my self-studies was the Big O notation and some algorithms and data structures. I first went back to get the degree mostly for the piece of paper with better job security and salary prospects in mind, but I actually enjoyed hearing about most of these things. I would add two things to your list which were great fun: automata/languages (I had known how to use regular expressions before, but I had no idea where they came from and how they fit a bigger picture) and heuristic algorithms (like simulated annealing and what not).
In all honesty, I can't say I know for a fact that knowing these things made me a better developer. It's hard to quantify. In your day-to-day life you don't generally use such knowledge. It's entirely possible that it didn't make any difference to my actual work. I certainly did use it during job interviews and lunch-time conversations with my coworkers.
That's generally what I see self-taught people lacing, i.e., deep understanding of anything outside of languages.
What a shame. There are lots of very accomplished self-taught people who know much of this stuff and are busy changing the world. I sincerely hope you get a chance to meet many of them.
It's remarkable how many of these are self-fulfilling prophecies. You'll never use technologies that you have no idea how to use. You'll never need slick stuff you don't know because you won't get into situations where you would end up using it. And so on.
Prioritization is fine, but always be careful about rationalizing your own continuing ignorance of things that a lot of people claim to find useful.
(I actually ran into a min-cut problem in the wild today. I'm glad I recognized it as such, because it was kind of important, and I wouldn't have been able to solve it if I hadn't heard of graph flows and cuts. Hell, I might even have congratulated myself for having avoided spending time learning something so useless....)
"- learning slick stuff I'll never need"
You never forgave that algebra teacher, did you?