Here are some lessons I learned by going to school that I find incredibly useful:
1. How to shut up and get some work done, even if I don't see the point to it.
2. How to shut up and get some work done, even if it isn't directly applicable or valuable to a job or something I want in the future.
3. How to take feedback and criticism from people who know better than me.
4. How to deal with someone I don't like but who has power over me.
5. Lots of other fascinating things that have nothing to do with my job but that learning about made me happy and appreciative of life.
6. A handful of things that are pertinent to my job, but I see this as added extras because I didn't go to school for the sole purpose of getting a job.
7. That a lot of people seem to think that the only things in life worth learning or paying for are those that will be useful at a job. This is a sad one.
I did not go to school for a CS degree, and that has not hampered me in any way when searching for a job in software.
All I learned in college was how to game the system of the institution itself, and that institutions like that are a societal racket and waste of time and money.
And this is going to sound weird if you're an engineer, but the 'real world' of commercial employment is 90% about gaming the system of an institution which is most likely also a social racket.
That's why kickass engineers get paid less than mediocre managers; because they spend all their time solving fun technical problems instead of gaming the system.
This is completely wrong. Universities are tremendously useful and do many great things for society and humanity. I'm not going to provide evidence because I think that any reasonable person will agree with me.
A school that provides merely the guise of education is a bad school. This does not mean all schools are bad.
Yeah, in theory someone can get a job without a CS degree. But it'll be a lot harder, and it's very likely that doors will be closed to you that you would prefer be open. It might be unfair, it might be an injustice, but it's still part of the equation. You might overcome it, but it is still a thing to be overcome that was taken on as an additional burden in exchange for losing a different burden (college).
I have no problem with people with passion and talent skipping college and going straight into the workforce. And it's very clear up front what they get out of it- they get an additional 4 years of professional life, and they never rack up student loans. I just object to people claiming that there's no cost to it.
There is a cost: maybe a negligible one, maybe just a little, or maybe a lot if it means you don't get to do the things you really want to do. Or if you never even find out about the stuff that you would have been incredibly passionate about because you were never exposed to it.
By not going to school, there is guaranteed to be a cost in missed opportunities. Maybe those shut doors and lost opportunities are all for things that the person didn't want to do anyway. The part that bites people is that when they are making the decision to skip school, they're probably in the 18-20 age range and most likely do not have the capacity to evaluate what those lost opportunities even are, and whether or not each one is OK to discard as a long term life decision.
I have a mediocre degree in an unrelated subject (History and Philosophy of Science) from a good school (Cambridge). I learned to program as a child by messing with 8-bit computers.
My first job was very much an apprenticeship, I found a small company that was willing to employ me based on some level of aptitude, a modicum of demonstrable programming ability, and a willingness to work for very little (£12k in 94)
Three years later, I was able to move to a more interesting, still not brilliantly paid (£23k in 97), job at a startup, which was acquired by MS a couple of years later. I spent 14 years at MS, and was a Principal Engineer by the time I left. My experience since then is that there are no doors closed to me.
There are two places where I got lucky, 1) finding a company that was willing to make a bet on me. 2) joining a top tier company through an acquisition.
but with regards to 1, over a 9 month period in 93-94, I applied to over 100 companies, and had three job offers in the end - so it was good luck to find a job based on my resumé at the time, but the jobs were out there
And with regards to 2, not everyone who joined through that acquisition was successful at MS, regardless of education. Some hated the idea of working for MS, others weren't suited to a large corporation, and many other reasons.
Comparing myself with peers, I find that their CS degrees possibly gave them a 3-5 year head start on me, they could go straight to better jobs, but the value of the apprenticeship type job, is that I was already pushing 10000 hours (or equivalent) by the time I was ready for the better job.
Getting a job is simply not what a CS degree is for. It was never declared to be for this purpose—nobody claims it's for this purpose (except maybe some schools for marketing purposes).
Yes, we all know that you can do a good job programming without a CS degree. Good job. Whoopdeedoo. Anyone who keeps repeating this point is a broken record. Anyone who tries to scientifically prove this is wasting their time. That's not what a CS degree tries to be. This isn't why I went to school, and it's not why many, many people go to school.
Moreover, I question whether or not each of your seven points are worth about $10k each, because a lot of students are paying that much.
I paid $180,000 to go to university and I think it was 100% worth it, regardless of my job or how much it helped my job. My selection of 7 points was mainly to make a point, that point being that I see a lot of value in university, many people do, and we should all stop trying to fit all of this into employment, because they have very little to do with each other.
And to think... I did took the more gruelling math and stat's courses to get out of doing comp sci labs that didn't interest me so I could work on problems I enjoyed.
I would only encourage people to make the choice based on a sober calculation of expected costs (including opportunity costs) and gains rather than because "it's the thing to do". Before I went to my school of choice I planned out the course sequence for my entire time there -- of course it ended up being different but not hugely so. Unexpected things will come up (#1 and #2 should have been learned by high school, what I didn't expect was that for me continuing the related path of "shut up and get BS work done" through college would result in burning out my tolerance for BS work in general and it's taken a long time to build that back up enough that I can perform ok in enterprisey roles) but that in itself is a useful thing to learn. If past me had future me as a mentor, I'd encourage past me to skip school and satiate his curiosity more directly, but not everyone has access to a mentor.
Folks, just use your brain. Observe, read, study, converse, imagine, think, analyze, hypothesize, apply, try, test, revise, repeat, carry on. Good general process regardless/before/after/outside school/college/job. You can spend either $100k and 4-6 years, or, $0 and N years -- you get to decide.
This is one of the reason some self-taught people often have more people skills than those who self-select to hide behind a keyboard most of their university years instead of getting out there, becoming more well rounded, and through it solving problems.
The ability to work in a group as you've mentioned is a critical and transferrable life skill that many people simply don't grasp. If you can't solve university group problems, guess what kind of co-workers you'll be stuck with in my 20's.
Having some structure in the start is important and valuable especially for those who don't have the discipline to do things that need to be done and instead jump from one shiny toy or problem to the next.
At the end of the day it's not just what your education (or lack of education) makes of you, but what you make of your ability to learn every day. Discipline is the master skill that most people at any age in or out of school in our 20's are missing.
They then enter an environment where the group isn't ad-hoc, meaning there's a hierarchy and people, especially new CS grads, get overruled. They're expected to comply with policies and processes that they had no input into. And they're expected to write code that doesn't just work, but is understandable and maintainable by every member of the team.
I find that most new grads are very able to come up to speed on the code and the structure of our project. This likely comes from having a very malleable mind and never having seen a well-organized codebase. But it takes a good two months of almost constant corrections before they're contributing to the team in the right way and many more years before the understand why that type of contribution is necessary. Teamwork is more than just not writing the entire project yourself and it feels like CS grads are never taught any of the skills necessary to collaborate in the real world.
I worked as a programmer long before the formal education, and the only thing I really learned is the only thing that is really needed to make it a worthwhile endeavor: a shallow but wide exposure to the body of knowledge out there. I accidentally reinvented poisson regression, I didn't realize that I had wasted a month of my life until going to college in my late 20s and finding out that somebody had already done the work (and a much better job).
Where is the money supposed to come from? If you're paying 50k or more for your education you might want to at least break even. If there is no ROI then it's just regular consumer debt which is both bad for you and the economy as a whole.
The vast majority of what a programmer does, forming good abstractions and avoiding complexity, is almost completely untouched by computer science curriculums.
That's the majority of what my CS degree covered, in several different programming paradigms. Even the idea that there are "programming paradigms" is something I learned at university, from a great course called Comparative Programming Languages. Granted, it's one thing to study it and another thing to gain years of experience doing it, but it was certainly a big focus. I took a whole course on design and structure of OO programs, which mainly at the time focused on C++, but also covered some alternative OO models and what pros/cons various people have claimed for this style of abstraction. And another one on design and structure of functional programs, which in the case of the one I took was mainly from the ML family perspective. These had some more "theoretical" content as well, especially the functional-programming one had quite a bit on type systems, but the overarching goal of the courses was abstraction and structuring (and even the type-theory stuff was introduced as a means to the end of useful programming abstractions).
When I read these kinds of summaries of computer-science degrees, I get the impression people went to some kind of program that was 100% algorithms courses, proving big-O running times and termination properties and that kind of thing. I thought I went to a pretty theoretical one (vs. one with more of a software-engineering bent), but it was maybe 20-25% algorithms. Where are people going where they are taking nothing but Algorithms 101 through Algorithms 1601 for four years?
I do agree that the standard tech company interview process seems to mainly test the algorithms part of the CS curriculum for some reason. I think tech interviewers love big-O notation tests more than actual CS academics do.
I can't speak for others, but knowing when to use an array vs. when to use a set feels pretty fundamental to me being able to do my job well.
I'm not sure why you assume that the only way to learn this knowledge is through a CS degree. These are things than can be quickly learned by reading a few articles online.
My friends in CS at Waterloo got to work with Scheme in the first year for their introductory programming course, when we were using C# and Java and the like. I was young, stupid and arrogant at the time, and made fun of them because I dismissed Scheme as some weird language nobody would ever use, but now I really envy the CS grads for their clearly much more well-rounded and better thought-out software curriculum.
The saving grace of the Computer Engineering degree at Waterloo is of course the 6 4-month co-op terms (internships) sprinkled throughout the 5 years program, where I gained valuable real-world work experience and finally acquired an appreciation for functional programming, but there's a large degree of variance in students' experience in the co-op program depending on the jobs they can find, so not everyone can be so lucky.
I did 2 papers on networking, a paper on computer security, and a paper on web development, and implemented an http client for Operating Systems.
There were some other math and logic-related courses with some proofs and such, but almost all of that was backed by writing software projects. I didn't write many papers in my computer science classes, but I did a lot of projects, both individually and in groups.
It's interesting to read how different other people's university experiences were.
- Any good CS curriculum is basically a calculus, statistics, linear algebra, real analysis, combinatorics, discrete mathematics course with a bunch of CS modules thrown in on the side
- All the computational intelligence stuff we did (particle swarm optimizers, neural networks, classification algorithms, data mining, ant colony optimization, genetic algorithms, etc.) these things were all cool but not really mainstream back then. It's all the rage right now. I'm really glad I have a good theoretical background in all of that now, it makes it so much easier to jump back into machine learning and analytics. The math I did makes it even easier still.
- I use a lot of "full-stack theoretical understanding" of operating systems, networking, compilers and distributed systems courses to reason about why things could possibly go wrong in production performance problems on large distributed enterprise applications, and how to isolate where the problem is. I do this on a daily basis and am amazed how many professional programmers don't understand what's going on "under the hood". It's almost a Dunning-Kruger effect situation where people don't even know what they don't know.
Then this doesn't even begin to mention things like formal methods, software architecture, computer graphics, database theory, etc. Oh, and the philosophy courses, which really went into logic and critical thinking.
A CS degree is completely mind-expanding if you get it from a good institution.
Anyways, all my research has gotten me very interested in all the topics you mentioned, also neuroevolution. I actually brought up neuroevolution and optimization problems to my professor to get his insight, but he wasn't able to help me out much.
I keep finding that people state computational intelligence was all the rage about 10 years ago, and can't find much work on what is going on with it now. Can you provide me with some more info in the field?
Up until recently, the vast majority of Computer Science programs were under the Mathematics department. For most colleges even to this day they are still under the Electrical Engineering department.
I think the problem is not with the students. The problem is that the companies expect you to be 100% ready to drop in and the only education you can put on your resume comes from a CS degree or previously having a job in the industry.
1. A highly theoretical CS foundation is still very useful. One of the hardest classes I've ever taken in all my studies was an upper-level proof-based algorithms course. Nowadays I can glance at an algorithm and give you it's runtime complexity. This is actually an important skill because it influences how you construct your own methods and such. There were quite a few times at my old employer where I'd be like, "If we just switched this out to a hashmap, we'd have a constant time solution instead of this polynomial one," or something of the sort. Furthermore, that algorithms course changed how I thought about computing (and life) forever. Computational complexity theory is simply wonderous. I'm in med school now, and I will tell you, learning about human biology through the lens of a computer scientist is a truly enriching experience. Computation is everywhere!
2. Your everyday programming jobs probably don't require that deep-cut CS coursework BUT there are plenty of specialized jobs that do. I can think of many sectors where you need to be fluent in something like graph theory and ways to traverse graphs, or statistical methods + machine learning. Not all jobs are full-stack dev jobs. Undergraduate CS is supposed to lay a solid foundation that you can build your career on. It's not vocational training. You have no idea where you'll end up! And honestly, I think there's plenty of hindsight bias going on here.
3. Man, oh, man, people in academia suck at software engineering (and not to mention, product design). This isn't their fault! They haven't worked on a large codebase before. They don't understand git-flow or continuous integration or test-driven development. Their products need to get A's, not sell to a consumer. I will say, coming from the industry into back an academic environment it has been a bit of culture shock. Tools used, architecture, even ways of speaking about the software are often completely outmoded.
All in all, I'd say both are very desirable. I'd recommend self-taught programmers take some classes on the more theoretical/mathy side of computer science. And I'd recommend that the academically-minded CS seniors FOR THE LOVE OF ALL THINGS GOOD take a year off and work in the industry before pursuing grad school.
I wonder how much of requiring a computer science degree is simply because the people hiring have computer science degrees. Seems like a self perpetuating insiders club.
It's interesting that this story appears at the same time that an article about how memory games designed to improve your intelligence only improve your memory with that memory game - not in broader contexts.
Chess masters are no better than beginners at memorizing chess boards with a more random arrangement of the same pieces.[0]
Expertise in humans seems to be highly specialized.
So then why do we expect algorithmic knowledge of a CS degree from people writing modern crud web apps?
It's ridiculous.
[0]https://psy.fsu.edu/faculty/ericsson/ericsson.mem.exp.html
In all seriousness, though, it's because the CS majors I've interviewed have (generally) been great at theory, crap at application. I once had a guy hold forth for 10 minutes about cardinality and then flop sweat when I asked him to explain the difference between "GROUP BY" and an "ORDER BY".
It's likely that the vast majority of programmers wish they were working on these interesting and difficult problems, but instead they are writing another yet another ETL transform for an ERP system (not that there's no value in that, but that was my job, and it was repetitive and dull)
So even if a Computer Science degree isn't necessary for the vast majority of programming jobs, without that degree, you can only do one of those vast majority of programming jobs, leaving the really interesting problems to those with advanced degrees (or special domain knowledge)
More than that it's all about how much of a self-learner someone is. This industry is so new and changes so rapidly that if you aren't feeling that itch to understand some new aspect of programming you're going to be left behind. The really good programmers I've seen have all been full-stack, not in frameworks, but in a complete understanding of how a system functions top to bottom.
Also quite a few CS people would do well to examine EE or a proper engineering track. I've always laughed at the title "Software Engineer". Very few are, most of what we do is just throwing something against a wall to see what sticks.
The most important things I got were: state machines, appreciation for high level math.
Oh and an intuitive understanding of modeling and translating fuzzy things into easily modelable things. That part is super important.
And an intuitive understanding of how tiny spec changes turn problems from computationally unsolvable to trivial.
But what have the Romans ever done for us?
Often, people take for granted how differently you approach problem solving coming from a CS perspective. If anything, I have gained mostly in the ability to break down problems into the smallest pieces possible that work together thus reducing complexity and shaping the problem case. I can isolate core problems and through algorithm design implementation evaluate best solutions. I therefore wholeheartedly disagree with the notion that CS does not teach how to reduce complexity. It does.
Above all, I have rid my decisions of emotion and solely focus on the problem at hand. It's brutal, rough and inconsiderate at times, but it produces the desired results.
Several careers have a more direct and tangible link degree-value, no one can be a cardiologist or a civil engineer without the degree.
I've a Software Engineering degree but I don't really know if it was worth it, I learned some valuable things but how can I say that I made a good choice with some degree of certainty?
Indeed, but I believe that having a solid foundation in theory is important. People have spent a lot of time coming up with ways to reason about common problems, and you don't need to reinvent the wheel.
Additionally, while many programmers can get by with skimping on theory, your mathematical knowledge tends to limit problems you can tackle. While you might be able to get away with making some CRUD application without applying any complicated math, you will have a hard time trying to write code to localize your robot with SLAM. Knowing theory only opens more doors to more interesting problems.
i can say for fairly certain that 90% of the engineering maths i did at uni will not be applicable to me in my career, and there's plenty of maths that would be applicable that i wasn't taught. considering that was a 6mo unit (and ignoring the fact that it was easily the one that burned me out fastest), that's a lot of wasted time.
But really, the engineering math curriculum has (or at least should have) three purposes. The first is to teach you logical reasoning and problem solving -- critical skills. The next is to provide you with a toolbox of techniques you can call upon to solve common problems in your field. Finally, the curriculum should provide you with the mathematical maturity to acquire the new mathematical tools that you need.
The last point directly relates to your second paragraph. I don't know very much about data analytics. If I (somehow) got hired into a big data role, the senior engineers will lack both the time and the desire to sit me down and give me the background on statistics, machine learning, etc. that I would need. However, because I have spent a lot of time studying other mathematical topics and have a background in linear algebra, probability, etc., they can point me at good sources and I can learn myself. If I came in just knowing single variable calculus from high school I would have a rough time.
Except that I think formal mathematics and proofs are attainable by informally-trained programmers... just perhaps not computer scientists.
To quote Friedrich Bauer:
"Software engineering is the part of computer science which is too difficult for the computer scientist."
I'm not sure how true that is. I don't have a computer science degree. I just have some interesting anecdotes from a colleague who is pursuing his Ph.D in computer science with a focus on developing a formal proof system. As a teachers' assistant he gets to run some classes. Most students tend to snore through formal methods I'm told. In order to wake them up he asked his students, who are working on their masters, to implement binary search. He gave them a specification for the algorithm and off they went in pairs. He used the PlusCal language from TLA+ to model around eight submissions in roughly two hours (I'm not sure what the exact number was). He found errors in 7 of them and was able to demonstrate what the inputs were and the steps the algorithm would take to reach the error state thanks to the model checker in the TLA+ toolbox. He got a few students hooked from that point.
In my case maths is exactly what I needed. I'd been working in distributed systems for years without an iota of training in formal methods. I'd read Leslie Lamport's papers on time, Paxos Made Simple, Raft, Bloom^L, etc. I have several common textbooks on distributed systems. I'd worked my way through many subjects in graph theory, "concrete" mathematics, discrete maths, etc. But as Nathan says what saved me most was experience and learning what abstractions to use and how to maintain a handle on complexity. If I just followed the code I could make things work. Except when the code wasn't a good enough abstraction (in the mathematical sense)... then things got hard (ie: race conditions, scheduling problems, etc). I used to just follow the code and suss out the problem using standard debugging tools and time-honored techniques but what started to really click for me was modelling my problem in TLA+. When I started leaning on maths I felt like I could start achieving more and solve problems before they became bigger problems.
I often talk about programming as a force-amplifier. If you're an actuary and you know how to program you will be a better actuary than your peers. Maths is the force-amplifier for programmers. You can learn formal mathematics and create a language for modelling computations that you can prove. Anything you can do from there will be better than what your peers can do.
... and yes I realize that not every piece of software needs to be accompanied by a proof. But for the hard problems it's a useful tool to have. And there are many other subjects where it's becoming necessary to understand different branches: graphics, AI, "big data" (ie: applied statistics), distributed systems (even your modern processor is a tiny distributed system), etc.
The biggest benefit for me was the complete understanding and model you get of the entire computer. How it works, what theories it is based on, why things are the way they are (in terms of the Turing model, the way microprocessors work, etc).
I don't believe this knowledge is helpful from a software engineering point, and I may have been a better programmer if I had spent those years learning more about how to work as a team and how to solve real-world problems. However, I do feel that it has allowed me to switch between different fields of programming without completely being thrown for a loop. It has allowed me to understand the issues that crop up when something goes wrong on a much deeper level, or why problems crop up on one part of "the stack" that I may not have understood had I focused merely on learning how to program. These are personally valuable to me, whether or not they may have been more valuable to my career.
I definitely think that understanding the lower levels helps me write better software, largely for the reasons you list.
Maybe what we actually need is a separate field, e.g. "practical computing". - which, I accept, would lend itself less well to University education which we have come to expect as a prerequisite for better paying jobs.
That said, anytime I've met one of the hard-working students who opted for a more math and theory heavy CS program instead of an SE program, that person has been able to software engineer and project manage circles around the people who specifically studied software engineering and project management.
1. Pick the three most important lines out of this 100 lines of code.
2. Explain why they're important to those who're not familiar with the problem at all.
3. Rename its functions and variables to achieve maximum consistency to you.
4. Optimize the code for maximum efficiency.
5. Optimize the same code for maximum maintainability. (assuming the code will be used for 30 years)
I can make an argument for even a "write to log" line as being extremely important when something goes wrong; I have no idea how I would pick three lines out of a hundred.
It sure tells SOMETHING.Ofcourse there are better ways to evaluate a person as a programmer but I hate it when people claim something without basis.
The problem is that there is no good formalized educational standard for software development training. So instead Computer Science gets shoehorned in as a substitute. This leads both to sub-standard Computer Science degree programs from a pure CS perspective (because they are primarily just trade school educations in disguise) which are even worse as regards to training for Software Engineering. CS is very algorithm and data structure focused, which is good in moderation for dev training, but they usually delve into realms that are not useful even in the "well it's good to have a broad knowledge base" sense. Moreover, CS doesn't typically touch at all on the many practical skills, and their fundamentals, needed to be a good dev, ranging from development cycles and styles to QA and testing fundamentals to source control use and management to proper composition and componentization of software to refactoring and dealing with legacy code to deployment strategies and techniques and then on to familiarity with actual operational systems related to all of these things. Each of those topics has sufficient depth to be an entire course or series of courses, yet they are frequently only barely touched on in CS programs, and sometimes they are ignored entirely.
I've been in hiring loops numerous times, and one of the quickest things I learned about hiring in tech is that a CS degree on a resume means basically nothing, there is almost no correlation between having studied CS in college and being able to code at even the most basic level. Unfortunately, I don't foresee much change in the future on this problem. CS is still a prestige degree (a 4-year degree in one of the coveted STEM fields) and I have a hard time seeing a legitimate Software Development education fitting in the mold of either an arts or sciences degree program at a liberal arts college.
Sure, most computer scientists become programmers, and CS degrees don't necessarily translate into programming skills. However, getting a "computer science" degree is not the same as getting a "programming" degree and I don't think that its "usefulness" should be determined by the skill someone has as a programmer after getting the degree.
The reason getting a CS degree does not make someone a good programmer is simple: * A large percentage of the courses you will take will be general education (about 20% in my colleges case) * Another large chunk will be in mathematics (say another 20%) * One more sizable chunk will be "lost" to CS theory and "row-based" information (remember writing round-robin schedules by hand, or verbally explaining parts of TCP in class)?
Leaving us with maybe 40% of classes having some sort of programming lab. And if your like me you'll specialize in machine learning, will will allow for even less exposure to things like the gang of 4 patterns.
However, the flexibility of a CS education is much much greater than if I had just been programming for those 4 years. If I decide I'm more interested in a career in IT security or data science, my courses will have useful. I think that someone who had instead just been programming Java and Rails web apps for 4 years (like I do now) would have a much harder time transitioning into those (potentially higher paying) fields as the market evolves.
Also it's important not to discredit general education. Being a strong writer, speaker will always help you. Knowing some history and geography will keep you from sounding like an idiot when you talk to people from other countries.
A college education is not the same thing as a trade school and shouldn't be compared to one.
1. Success in tech industry depends as much on your peers as much it would depend on your IQ. Knowing bright, well established people in tech industry is invaluable. Such connections are often built when you go to schools like Stanford, MIT etc. or even a reasonably good college.
2. Having a good college name on your resume is going to open many doors for you. You will realize that as a MIT grad when you talk to investors about cutting edge research in a specific field would be far more credible.
3. CS degree will not teach you a lot about how to code, build great products. Not more than a passionate coder writing code in his basement. I admit that.
I feel like in the course of working on large projects such as a parsing, lexing, compiling program, a student inevitably touches on these topics. And certainly when working with template code (such as in an Intro to CS class), they can see how nicely it was structured for them.
However, I agree with the sentiment that it seems like these topics are not directly addressed by most curriculums. At the same time, from my experience it seems like these ideas are applied very differently in different contexts (such as different platforms and languages), so a college class would be more abstract in teaching them. Perhaps it would be effective if they did some examples while teaching these ideas.
The part I question is, the percentage of programmers that will work at a "hard tech" company is so small that, unless the company you're working at is a hard tech company, then there is no relevance to onboarding someone with CS skills. It does not diversify the team. Diversification in a team is of high value. Most engineers want to hire others engineers so that they have something to talk about. But that's a comfort thing.
Long story short, soft tech companies should only have one or two hard tech engineers on their team especially in the early days and only test at the skill level required when onboarding.
If you live somewhere that you can get a job in the field directly out of High School, that's all well and good, but it's alot harder for a variety of reasons than someone who has finished a degree. Which is one reason why so many people go that route.
that is key; there is a strong argument in favor of jumping right to a programming job if you have the opportunity... it's what I did. but I got lucky on a bunch of fronts. (parents in the industry, timing, etc) - I mean, if you have a programming job right there it's hard to argue that you should go to school instead. And in my case, the job was available in large part due to timing; it would have been way harder to get a job in 2001 than it was in 1997, even if I had gotten a degree meanwhile.
I guess the other thing to consider is how hard it is for you to go to school later. I mean, if the parents are willing to foot the bill for your education now and won't be willing a few years from now? that's a pretty big thing. I'm slowly working on getting myself into college now, and it's harder in some ways, because the typical application process was not designed for me, but easier in others, because things like money aren't a huge problem anymore, and I am so much more self-disciplined.
I'm too early in the process to tell you if it's easier or not (I've got either 9 credits, or 0, depending on how you count) - but it's certainly different. It is... difficult to pay people to
But, in general, if you have the opportunity to get a coding job right out of high school, and nobody is paying for your college, take the job. If someone is paying for your college and you don't have the opportunity to get a coding job out of high school, go to college. The optimal course of action gets foggy if you have both opportunities or neither.
What I got out of my CS program was... discovering that figuring out how systems and things worked was interesting to me. I also found the prospect of something closer to engineering was a better path to me than academia, teaching, law or some other path.
In terms of the relevance of specific coursework, I can't say that I spend a lot of time with advanced math or some of the other topics, but I learned my way around a UNIX system, got my first taste of large scale networking, and a bunch of other things.
What I learned most about in school was me.
(1) it usually, but not always, implies that the candidate has at least some coding knowledge; and,
(2) [most important] it is a good proxy for logical/mathematical intelligence.
As long as IQ tests for employment remain a legal grey area, employers will continue using STEM degrees as a filter.
The claim that (2) is the most important is anecdotal, being based on my own experience: I have a degree in mathematics, which doesn't really imply (1) to nearly the same extent as CS, and I have never felt it made it more difficult to get job interviews.
Fun times trying to distract them from their own arrogance.
> Whether someone can or cannot solve some cute algorithm problem in a high-pressure situation tells you nothing about that person's ability to write solid, clean, well-structured programs in normal working conditions. This practice is akin to hiring pilots based on how they do on an aeronautical engineering exam. That knowledge is relevant and useful but tells you little about the skill that person has for the job.
There's a lot of talk and debate about whiteboard interviews and this, for me, succinctly sums it up
It's also almost completely ignored in the typical programming job interview. Which is why when I interview people now I'm most interested in looking at code they've already written, and asking them to break down an application description into a set of data & interface abstractions.
It mustn't be forgotten that a theoretical curriculum teaches discipline to learn just about anything--if you can learn complexity theory and algorithmic proofs, chances are you can learn to create a CRUD API.
I thought, I would have nailed this problem when I was looking for my first developer role, when I knew precisely how python regexps worked. Now of course I just look them up when I need them, which is never.
My employer wants to pay me to get a bachelors in ee or cs (have half of one, but dropped out when it was clear I couldn't afford to finish), followed by a masters/phd, but it's only tangentially about the 'education'. It's all about networking and being able to wave around credentials.
If someone wants to learn coding or programming - screw the CS degree, there are better options. I know CS degree holders who can't code more than a few lines or can't debug a large program. And there are better programmers who don't have a CS degree. YouTube will teach better programming than a CS degree class.
Apart from programming, if one "also" wants to learn the mathematical aspect of CS and want to work on core-stuff, go for a CS degree. And those skills do not come easy from some tutorials - a academic rigor is probably the best way to earn it. But if you use the O-notation at some jobs - you could become an outcast in the team.
When I got into a top college for a CS degree, I had high hopes from it. For the first 1.5 years, I wanted to quit, quit and just quit. It was hopeless - they were teaching few subjects that I was way better at. But for some reason they would not allow me to just give exams and get promoted. I already knew programming, patterns, electronics and even dealt with basic robotics before I joined college. For one example - when they started teaching operating-systems, my expectation was that they will at least give a hands-on on writing a pretty basic OS. No - they were just doing theories. Ultimately, I ended up writing a pretty simple version of a custom OS without any mentoring (and used Google) - because the professors had never even written a boot-loader to start with. I also ended up helping weaker students get upto the mark. In one of the semester assignment evaluations, I was told by a senior professor " you copied programs from the internet - how come they are so well written". I lost trust in them.
I did learn some stuff in the later years and came to peace. While I knew programming, I did not have a strong math background - stuff like probabilities, numerical methods, theoretical computer science and bit of advanced algorithms were the things I learnt and explored further. The most important thing was getting introduced to AI which turned out to be a huge area of interest for me.
However, all of that bad experience has turned me sour towards academia in general and I do not recommend spending a lot of money and more-important-time learning "used-less" things - unless you are expecting more than programming in CS. And when it comes to CS, the learning never stops.
Where does the concept of regular expressions come from? Can you explain why you can't use regular expressions as an all-purpose HTML parser?
I took 1 1/2 semesters on critical sections, race conditions and such. I deal with these problems all the time, and have seen much code where people either never learned about it, or didn't learn it properly.
I had the idea once to hash a short list of small numbers as a Goedel number. Looking around I see the idea was not original (in other places I use triangular numbers etc.) I would never have known about those without CS.
Yes you have to keep learning more. It is a good foundation to start from though.
God it's refreshing to see someone actually put that as one of the primary, principal activities of software development.
Figuring out how to do a hard thing in a simple way is not simple, it's actually really hard!
