In practice it's been far easier for us to bring a mathematician up to
speed on good practices in our development environment (which is only
used in the semiconductor field...Grapheq anyone? CELLman?) than to
teach CS types how to analyze and solve problems...something the
math/eng has been learning all along. I suppose we may also be using
the term "software engineer" a bit differently. A lot of companies
throw around the term rather loosely when what they really mean is
developer or programmer. We're looking for people who can not only
design/develop but who also have a real tack toward engineering...the
best ones have a math/science major and either a minor or significant
coursework (i.e., much more than just a class in C/C++) in CS.
Don't misunderstand. I'm not bashing CS departments or students, and
for other specialized functions we do hire primarily those types (e.g.,
sys admins, dba). In our automation environment the major constraints
aren't physical (e.g., RAM, HD access, CPU availability, network
volume/speed) but logical. The CS types we've seen may be *great* at
taking an already solved problem and coming up with the best possible
implementation for it. We need folks who can solve the problem to begin
with.
[Note to Americans who are afraid of outsourcing and jobs moving
offshore: most of the Asian and Indian/Pakistani CS candidates have
been much better. Not cheaper. Better. But then, they already knew
calculus coming out of high school. The rest of the world really gets
math and physics...why's it so hard for us?]
On Sep 30, 2005, at 2:36 AM, Brad Hutchings wrote:
Wow, that is a real shame. I have to agree that far too much is
lumped into the CS major in many programs, and that it is entirely
possible to graduate with a degree in CS without being really good at
modeling and solving problems. I may be a little partial, but the
sharpest people I've known professionally in this field have had
Masters Degrees with specializations in algorithms and data
structures or the like. The key is then taking this textbook stuff
and finding ways to apply it to the real world. Many of the best
students go on to academic careers in the field and write esoteric
papers that will never have any practical consequence ever.
But really, if I were writing a database server or compiler, I would
want someone with some formal training in the field. Like before
messing with YACC and LEX, might it be easier to write a recursive
descent parser for the language at hand? Or knowing that disk access
is typically way more expensive than memory access. Those sorts of
insights can save man-years and yield workable systems. Too often, I
see good programmers without theoretical training completely clueless
about them ;-).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|