Subj : SW-design more important than jargon-memory (was: Software Job Market Myths)
To   : comp.programming,comp.software-eng
From : rem642b
Date : Sun Aug 21 2005 04:36 pm

> From: g...@best.cut.here.com
> >... If it were me doing
> >the hiring, I would be looking for people who can learn and adapt
> >quickly, not people who already know the popular
> >buzzword-of-the-week.

> Throughout most of my sw eng career in the 1980s and 1990s, the above
> was considered more important and valuable to an employer than the
> ability to remember bits of trivia.

"an employer", like just one employer you happened to encounter? It
certainly wasn't important to the vast majority of employers who
advertised jobs and never even considered me because I didn't have 3-5
years commercial shrink-wrapped experience with some specific
requirement they thought they absolutely needed.

The only employer I ever encountered with our view on this was Stanford
University, and not the university as a whole, not any of the major
departments, only a few of the small research labs:

I knew a little about NMR (Nuclear Magnetic Resonance), but nothing
about T1 or T2 relaxation, or NOE, and I had only a little bit of
Fortran-IV experience, and I had vaguely heard of spherical harmonics
but had never done any of the math, yet the NMR lab hired me to write
Fortran-IV software to perform calculations of T1/T2/NOE using
spherical harmonics to approximate motion of side-chains in
hydrocarbons. I not only wrote the software (by converting formulas
from a journal article they supplied) to graph each parameter against
NMR chamber frequency, but I also invented a new technique, a simple
application of high-school analytic geometry, namely parametric graphs,
to provide a much better characteristization of NMR relaxation
behaviour than their pure one-parameter-against-frequency graphs had
provided, allowing the scientist to take one glance at the graph and
immediately tell whether it showed freely-rotating side-chain or
side-chain only wobbling between two barriers.

I had done graphics hacks, and had seen Floyd-Steinberg
error-diffusion, but had never written any significant image-processing
software, but the department of Applied Earth Sciences hired me to
enhance their image-processing software. I not only did what they asked
me to do, but I recognized their pattern-dither images as utter crap
compared to what error-diffusion could do, so I added an
error-diffusion mode to their image-rendering/printing feature, and
suddenly the Printronix printouts actually showed the subtle textures
of the land and glaciers instead of being dominated by the blocky
texture of the pattern dither. (The wavy-dotted-diagonal patterns that
occur in error diffusion images were only a faint marring to the
otherwise perfect output, nothing that detracted from visually
understanding the actual geographic textures.)

And I never had any experience in Lisp implementation or CAI software
before IMSSS hired me to help port SL and their CAI-symbolic-logic
program, and I didn't have any serious experience designing any CAI
program before IMSSS hired me to work on the CAI-Calculus program I've
already mentionned recently.

> Things like specific language features, user-level commands, and
> protocol parameters were referenced from books and man pages, not
> memorized.

I agree, but if you don't have at least 3-5 years paid commercial
shrink-wrap experience at ten different technologies, and you're too
honest to fabricate such experience on your resume, your resume gets
tossed in the trash by any of today's employers before the actual
hiring manager even skim-reads it.

> It was more important to be able to design an appropriate solution to
> the problem first, then implement the solution.

IMO, and IYO, but not according to all the potential employers nowadays.
Do you have any proposal how to enlighten them to convert to our opinion?

Per what you say there, I'm just about the best candidate for a large
number of present-day job openings. I have a challenge to some employer
or recruiter reading this thread: Please specify five general ideas for
a new program, not saying how it'd be accomplished, not even reciting
the use cases, but just describing the general idea of what the program
must do. For example, for a class this past Spring, the task was to
design a system, using a relational database to maintain all data in
realtime, the control program for letting several taxicab dispatchers
in a large taxicab company sent short text messages (up to 60
characters each) to one or more individual taxicabs, and let the
dispatchers view listings of all recent mesages (from all dispatchers,
not just from self) to any given taxicab, and statistics about how many
messages the various taxicabs received or various dispatchers sent. So
I had to write the use cases (guessing what the employer would want, we
weren't allowed the normal channel of proposing use cases and
brainstorming with customer to get them just right before starting to
code, because there was only one very busy instructor for twenty
students each working independently), and design a set of database
tables, and then code the whole things and give a live demo for the
instructor. So would you (for any employer/recruiter value of "you")
please write a couple lines of description of each of five such (no
taxicab, please) applications, so I can give my ideas about what
facilities (hardware in general, software/API tools more specifically)
might be needed and generally how I might design software to implement
solutions to each of the problems/tasks you presented? Consider this an
aptitude test not for having memorized various jargon or for being able
to draw flowcharts for a pre-specified algorithm, but for the more
important (IMO/IYO) skill of overall problem-solving software-design.

.