In my experience, it is a gut feeling of how to get something done. CS majors tend to design for days while the self taught tends to get it done, tested and moves on to the next thing. This can be a problem with large code bases; although the CS major can also stumble here as well.
As someone who was in exactly your position a few years back I might have some insight into this.
First off I have a BS in physics with a minor in Mathematics and my physics department was HEAVY into computational physics. My grad work is in a different field altogether! As an undergrad, we coded for almost every class after our intro courses but we were never required to take programming classes; most all of us were self taught. I had started to code on a Commodore as kid (self taught) so I was comfortable with programming, but programming is not computer science!
A few years back I took a position at a software company as a developer (still there, still coding, although now a little more senior) and my tech lead was a computer scientist (versus a programmer or engineer). I had the good fortune to work with him for a few years and I quickly learned that programming is not computer science.
As others have pointed out, you may have missed good OOP design (talked a lot about but rarely done), design patterns and big O notation (I had a numerical analysis course in college so I had seen that before); these are easy to learn as needed (e.g. The Art of Computer Programming, Google, etc.). Perhaps the biggest thing I had to learn was the whole development process; customer requirements, functional specifications, technical specifications, QA cycle, learning to do what is needed versus what is requested, defensive coding, future anticipation coding, etc. Another thing that you might be missing is a fundamental understanding of why a computer does what it does (e.g. why you shouldn’t compare two doubles for equality, race conditions in parallel work, etc). Again, my physics program was computationally heavy so I covered some of this but your history may be different.
I’d say that should cover what you’d find you’re missing (for your first 2-3 years as a professional at least). I might add to this the fact you under estimate how little new code you actually get to write; meetings, documents, technical support, design and maintenance take up a lot of your time (both low level and senior developers).
I think the biggest help was coming to terms with the famous quote “Computer science is no more about computers than astronomy is about telescopes.” (Edsger Dijkstra).
Slashdot Mirror
Can the telephone system be turned off like that?
if your company will let you
Like I said, meetings, documents, technical support, etc will take up a lot of your time. :-)
In my experience, it is a gut feeling of how to get something done. CS majors tend to design for days while the self taught tends to get it done, tested and moves on to the next thing. This can be a problem with large code bases; although the CS major can also stumble here as well.
A balance between the two is nice!
As someone who was in exactly your position a few years back I might have some insight into this.
First off I have a BS in physics with a minor in Mathematics and my physics department was HEAVY into computational physics. My grad work is in a different field altogether! As an undergrad, we coded for almost every class after our intro courses but we were never required to take programming classes; most all of us were self taught. I had started to code on a Commodore as kid (self taught) so I was comfortable with programming, but programming is not computer science!
A few years back I took a position at a software company as a developer (still there, still coding, although now a little more senior) and my tech lead was a computer scientist (versus a programmer or engineer). I had the good fortune to work with him for a few years and I quickly learned that programming is not computer science.
As others have pointed out, you may have missed good OOP design (talked a lot about but rarely done), design patterns and big O notation (I had a numerical analysis course in college so I had seen that before); these are easy to learn as needed (e.g. The Art of Computer Programming, Google, etc.). Perhaps the biggest thing I had to learn was the whole development process; customer requirements, functional specifications, technical specifications, QA cycle, learning to do what is needed versus what is requested, defensive coding, future anticipation coding, etc. Another thing that you might be missing is a fundamental understanding of why a computer does what it does (e.g. why you shouldn’t compare two doubles for equality, race conditions in parallel work, etc). Again, my physics program was computationally heavy so I covered some of this but your history may be different.
I’d say that should cover what you’d find you’re missing (for your first 2-3 years as a professional at least). I might add to this the fact you under estimate how little new code you actually get to write; meetings, documents, technical support, design and maintenance take up a lot of your time (both low level and senior developers).
I think the biggest help was coming to terms with the famous quote “Computer science is no more about computers than astronomy is about telescopes.” (Edsger Dijkstra).