Theoretically you could get a CS degree in one year, but the universities typically want you to take a certain amount of English, Math, History, Government, plus a certain amount of electives that aren't in your major.
They want you to be "well-rounded," and I think that most employers who are looking for degreed CS professionals want well-rounded people as well. People who just want the job done won't care if you have a degree in the first place.
But as you know, the work life is much more about interpersonal stuff and good politics and being responsible, etc, so there's probably not much a full degree can add to that.
And while you could CLEP out of some things, CLEPing just means you don't have to take the lower courses, so you take the same 3 hours, but at a higher level. So it really doesn't buy you anything.
Anyways, good luck. You might try some internet degrees, that way you can whiz through the history and focus on the CompSci side of things.
It seems to me that patterns, while occasionally useful, are especially useful in a specific domain. Lately a lot of the Java server-side design is accruing patterns that maximize Java and J2EE. While the standard patterns are always there, Singleton, Command, MVC, etc., it helps Java developers know where to expect to put a piece of code.
Obviously this is most useful for web-based projects (I'm not so sure about a giant project that some people have mentioned above), but the J2EE Patterns do a pretty good job of ensuring that there's not a ton of code that's duplicated, and that cut/pasting is minimized.
Even the Core PHP book has a section on patterns, so I think they're useful for any language.
Also, while I appreciate patterns, I try not to design too much on the front end (beyond functional requirements) because it's really only after implementing a solution that you figure out where you can refactor your code. The nice thing about patterns is that you can take them or leave them, and use them as you find them useful.
Obviously, patterns are especially useful when most/all of your developers are familiar with the basics and can recognize them. That way you can use abstraction together, and when you document "This is a singleton" people will know what you mean, as well as how it's implemented in a particular language.
Theoretically patterns should reduce the amount of surprise in a development project. Although if it's incorrectly implemented, and someone documents "this is pattern x" then that's when the real debugging starts.;-)
Slashdot Mirror
Theoretically you could get a CS degree in one year, but the universities typically want you to take a certain amount of English, Math, History, Government, plus a certain amount of electives that aren't in your major. They want you to be "well-rounded," and I think that most employers who are looking for degreed CS professionals want well-rounded people as well. People who just want the job done won't care if you have a degree in the first place. But as you know, the work life is much more about interpersonal stuff and good politics and being responsible, etc, so there's probably not much a full degree can add to that. And while you could CLEP out of some things, CLEPing just means you don't have to take the lower courses, so you take the same 3 hours, but at a higher level. So it really doesn't buy you anything. Anyways, good luck. You might try some internet degrees, that way you can whiz through the history and focus on the CompSci side of things.
It seems to me that patterns, while occasionally useful, are especially useful in a specific domain. Lately a lot of the Java server-side design is accruing patterns that maximize Java and J2EE. While the standard patterns are always there, Singleton, Command, MVC, etc., it helps Java developers know where to expect to put a piece of code. Obviously this is most useful for web-based projects (I'm not so sure about a giant project that some people have mentioned above), but the J2EE Patterns do a pretty good job of ensuring that there's not a ton of code that's duplicated, and that cut/pasting is minimized. Even the Core PHP book has a section on patterns, so I think they're useful for any language. Also, while I appreciate patterns, I try not to design too much on the front end (beyond functional requirements) because it's really only after implementing a solution that you figure out where you can refactor your code. The nice thing about patterns is that you can take them or leave them, and use them as you find them useful. Obviously, patterns are especially useful when most/all of your developers are familiar with the basics and can recognize them. That way you can use abstraction together, and when you document "This is a singleton" people will know what you mean, as well as how it's implemented in a particular language. Theoretically patterns should reduce the amount of surprise in a development project. Although if it's incorrectly implemented, and someone documents "this is pattern x" then that's when the real debugging starts. ;-)