writing skills Re: [Beowulf] Re: about clusters in high schools

[Jim Lux]

At 10:26 PM 1/29/2006, Andrew Piskorski wrote:
>On Sun, Jan 29, 2006 at 04:01:08PM -0800, Jim Lux wrote:
>
> > I'd even go so far as to say, many engineers SHOULD BE PROHIBITED from
> > programming in their professional career (unless they're in the software
> > development business).  Better they should learn how to write effective
>
>An interesting thought, and I think I agree - in the context of
>programming fundamental to their engineering responsibilities.  (E.g.,
>"design this widget", "calculate the parameters of this process".)
>But the ones who should be banned from such programming are the ones
>who took a good programming class and didn't get it.  If at all
>possible ALL engineers should be exposed to it.

In the same sense that all engineers should have to take metal shop, and 
even machine their hearts out at home, but not be allowed to machine the 
production item.


>And remember, a lot of work - and computer programming - engineers do
>is NOT fundamental to their responsibilities - it just makes day to
>day tasks, problem solving, and friction fighting a hell of a lot
>easier.  More on that below.
>
> > specifications and test cases so that someone else can do it better.  Yes,
> > being an engineer means you're, by nature, a jack of all trades, and we're
> > justly proud of it, BUT, from a business standpoint, machinists should
> > machine, artists should art, and engineers should engineer.
>
>Except that I have heard plenty of stories of an engineer not being
>allowed to just go in and spend an hour machining some damn one-off
>part he needs, because the union rules say, "Only machinists are
>allowed to machine, nobody else."  Instead, write up a work order,
>then wait for two weeks.  And the engineer who DOES know at least the
>basics of machining has an advantage, and in many cases is simply a
>better engineer because of it.

That's not uncommon, but the two week wait is an institutional problem, and 
the fix is not necessarily to have the engineer go in and machine their own 
stuff.  The fix is to make the system so that it can handle the fast turn, 
one-off jobs quickly. I've worked in both big and small shops, with and 
without machinists, and the all around best is the big shop with machinists 
who can work from "paper napkin sketches".  I like to think that my own 
machining skills help me draw a better napkin, but, frankly, the end 
product will be much better if the machinist does it, and, during the time 
they're toiling, I can be off doing something else productive.


>Computer programming is analogous - but more so, because computing is
>much more widely applicable than machining...
>
> > All should know what the other one can do and how they do it(and
> > should have done a bit, so they understand WHY they shouldn't be
> > doing it).
>
>Yes, absolutely.  But when it comes to computer programming, most of
>the working engineers I met did not even reach that basic level of,
>"Know enough of the basics to know when and how to call in an expert."
>
> > >> Learning effective use of one or more higher level languages, on the
> > >> other hand, would serve them EXTREMELY well.  A scripting language
> > >> like Tcl, Perl, or Python would certainly be useful, but a math or
> > >> statistically oriented language like Octave or R probably has better
> > >> synergies with the rest of the engineering curriculum.
> >
> > I'd be happy if engineering students all learned english grammar and
> > spelling and could write an effective 2 page essay.
>
>Except that's not properly part of an engineering education at all, it
>is a PRE-REQUISITE for an engineering education (or for any university
>level education at all for that matter).  If an engineering program
>must teach how to write an effective two page essay, it's engaging in
>remedial education because grades 1 to 12 have completely dropped the
>ball.

Not necessarily.  A decent liberal arts basis in K-12 might give you the 
ability string together sentences and paragraphs for a couple pages (and 
most high school graduates CAN actually do this reasonably well).  It's 
that this skill needs regular practice, and it needs refinement for the 
engineering idiom.  What we are NOT talking about here is cranking out 
"journal paper"-like things, which a number of college programs do just 
fine with.  It's the 2-3 page memo cranked out in a couple hours 
describing: here's the problem, here's what were doing, and here's why we 
think it's a decent idea.  Summarization and distillation is the key.  I 
get plenty of 30 page reports filled with gory detail, but that's not 
something I can send to a half dozen people and get their quick comments on it.



>But we weren't talking about that, we're talking about teach computer
>programming to engineernig students, and about the wisdom of DROPPING
>computer programming entirely in order to make room for instruction on
>"teamwork" and "presentation skills".

Hmm.. that's an interesting tradeoff.  Traditionally, one would have 
learned teamwork in elementary school ("plays/works well with others") and 
presentation skills would be acquired in some sort of debate or theater 
arts class (or, at least, the ability to get up in front of a group and 
speak intelligently and coherently).


>If that is in fact actually occuring at some university somewhere (no
>specific examples have been given, only generalities), then I suggest
>that it has absolutely nothing to do with better teaching engineers
>what they really need to learn, and everything to do with lowering
>standards and dumbing down the curriculum.

I don't see it as dumbing down, per se.  Good teamwork and good 
presentation skills are just as difficult as good engineering.  It's just a 
realignment, or, perhaps a recognition that more skills are needed to be a 
success than you can reasonably teach in 4 years?  Part of the problem is 
that industry, in general, is less willing to do "on the job training" for 
such generic skills.  In today's lean&mean efficient organizations, every 
worker body needs to be actively contributing to the bottom line, 
today.  Not building skills for some future time, when, gods forbid, 
they'll be working for another company anyway.


>Open source is the friend of education in ways that closed source code
>simply can't be, therefore educatuion should be somewhat biased in
>favor of selecting open source programming langauges and other tools,
>where feasible.

I'll go for that, providing that closed source is available where 
needed.  Actually, most closed source vendors provide their tools on very 
attractive terms to education, which creates a problem when all the 
students come out used to using the $100k/seat tools.
These are all tasks that someone with programming skills is much
>better equipped to attack than someone without.

Sure, but maybe that's peculiar to the particular job.. and for that job, 
programming skills are needed.  On the other hand, another engineer might 
be designing piping to bring the process chemistry in and out, and for that 
engineer, programming skills might not be necessary.  And yet another 
engineer might be liason to the marketing folks, and for that role, 
teaching skills might be most useful.




Jim