realbasic-nug
[Top] [All Lists]

Re: "You're not going to learn how to program in BASIC any

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: "You're not going to learn how to program in BASIC any
From: Alex Lindsay <alindsay at mac dot com>
Date: Fri, 30 Sep 2005 11:15:56 -0500
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <20050930093630 dot 6FB35DDC41B at lists dot realsoftware dot com> <3e805c2cfba48e8b37576bec65a1ec15 at cox dot net>
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.

I agree. In my experience an true engineering degree has almost always yielded candidates that are better prepared for software architectural issues. But them I am biased, as my degree was in Electrical Engineering.

[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?]

Have you seen the crap that many high schools are using for textbooks in the US? When my daughters were in HS, it seemed more important to have story problems about the politically correct issue of the day than to actually teach theory and promote a true understanding..... I have two brothers teaching in HS, and one sister teaching in a community college so I have seen both sides.

Thank you,

Alex Lindsay
On Sep 30, 2005, at 10:35 AM, Ethan Rutter wrote:

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>


_______________________________________________
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>

<Prev in Thread] Current Thread [Next in Thread>