I agree, there are a lot of options in industry with a BS in ChE, but not so much in Chemistry. You're pretty much expected to get at least a Masters...
I wonder why this is so different in CS, where it's much more feasible to get a senior highly-technical job without formal credentials. What's the source of this cultural difference?
(Note: I have assumed you mean CS as in programming)
Because programming is not science. In fact its not even an engineering discipline from what I can see.
The process is not rigorous enough and few programmers can even hope to attempt something like formally proving that their code works. We need less people writing code, not more. And those fewer people should be held to a much higher standard than 'Bob's cousin once read a book on sharepoint so go ask him if he can create a cake ordering website for you'
I think the exact opposite is true: Programming is more scientific than most science. A biologist often spends months experimenting before invalidating a hypothesis. A programmer's hypotheses are proven wrong dozens of times a day. By failing so quickly and often, we build mental models of code that closely correspond to reality.[1]
Also, our experimental apparati are more powerful than anything in the analog world. We have debuggers that can stop time and examine every aspect of a running process. No other field gets such tools. In fact, I'm not sure I'd feel safe if other fields had debuggers. The chemistry-equivalent of a debugger is molecular nanotech. The physics-equivalent is omnipotence.
1. A side note: I have a hunch that this perpetual feedback loop of failure messes with our heads. There's a certain je ne sais quois about many who write code. It's not just programmers who notice it. A few months ago, I overheard two finance people talking about me. One said, "Geoff's kind of a weird guy, don't you think?" To which the other replied, "You haven't met many programmers, have you?"
I think there has to be something seriously wrong with you in order to do this work. A normal person, once they’ve looked into the abyss, will say, “I’m done. This is stupid. I’m going to do something else.” But not us, ‘cause there’s something really wrong with us.
>By failing so quickly and often, we build mental models of code that correspond closely to reality.
Okay, but those mental models are not close to reality since in 'reality' all those models consistently break in production use. We write code to work on platforms which run on top of other platforms, etc and each of those platforms breaks in weird inconsistent ways. The cargo-cult mantras like 'ship often' , 'move fast, break things' that people love to blog about are all useless here. (Note that I don't care much for the business aspect. For me, shipping reliable software is infinitely more valuable than making money shipping junk) I propose we don't ship _at all_ unless the software can be 'certified' to run for atleast a year.
>We have debuggers that can stop time and examine every aspect of a running process.
Its okay if you find that impressive. As someone who ships multithreaded embedded/systems code which has to run for months/years without crashing I find most tools to be rubbish for helping me catch the really hard to find bugs. It does not matter (from my customers POV) that the bug was in the OS or hardware or whatever.
Maybe that is an 'impossible' standard to hold someone to, but that is exactly what I'm proposing.
There are specific sub-fields of programming (embedded systems, real-time operating systems, etc.) that focus more on provably-correct programs and shipping non broken code.
> What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.
Not sure why this is down-voted. I wouldn't necessarily agree with the comment, but it's definitely arguable.
I think we should be trying to boost developer productivity with better tools and less of the accidental complexity that turns "this should take a few hours" into a 3-week yak shave, even if this means developers need to learn some slightly more difficult tools and techniques at first (the 'tricycle vs. bicycle' principle mentioned here: http://worrydream.com/refs/Vannevar%20Bush%20Symposium%20-%2...). This might mean that individual projects could be completed by fewer developers, with lower communication overheads and a higher level of professionalism, and this would be a good thing.
My suspicion is that this would not lead to there being fewer developers overall, because quantity of good developers is still a constraint on growth - if we had more good developers, more projects would get funded/approved. However, rather than trying to persuade more marginally-skilled people into the industry we might do better by enhancing the productivity of the people we've already got.
Certainly we need better tools, but we also need a better process. I think many people who haven't been exposed to rigorous engineering processes that exist in manufacturing world to build durable products that keep on working year after year or even things like building bridges that have to really hold up to their specifications.
As people from the manufacturing world (some of whom are quite unaware of the buggyness of software) attempt to integrate more software into things - the so called 'internet of things' - we're in for a big surprise when most of this stuff ends up breaking. Software people have all too easily have accepted in their mind this 'inevitability' of having to run on the update/patch treadmill to make things work that should never have been shipped in the first place.
You're right that programming isn't science, but parts of it are complicated in a way similar to math, with many intricate components that interact in complex ways. People with only a BS (or no degree) regularly get jobs writing this complex code. I'm thinking of things like browsers, databases, and video codecs.
Personal view: because CS programs are highly variable (which, to be fair, is unsurprising in such a young field). Someone with a master's in CS might be great, or might have a lot of theoretical knowledge but be unable to apply it in practice, or have a deep understanding of the state of the art as it was at the time which is nevertheless borderline-irrelevant now. So we look to other filters.
I expect the same issues are present in a field like organic synthesis. It takes cleverness and skill to develop synthesis procedures, and I'm sure a lot of people graduate with PhDs who aren't particulalry great at it.
Hmm, maybe it has something to do with the fact that the resources needed to learn CS are very accessible, but this isn't the case with other fields. So self-taught experts are much rarer in other fields, but CS stands out since it's accessible to anyone with a computer and the interest.
"maybe it has something to do with the fact that the resources needed to learn CS are very accessible"
This is a great leveler. If you need to play with expensive toys, and those are only open to specific few, you may likely end up with a type of distorted "merit" system.
Jobs are in big organizations, and you have expensive multi-year projects which might be your first project, and highly conservative funding/approvals boards.
(Chem Eng and industrial chemistry seem fine with an SB, and maybe an employer-provided SM, but that's not research.)