[Tfug] OT - WAS Re: Cyber War -oh noes | Now H1B Visa Rant

[Bexley Hall]

Hi, Cara,

--- On Sat, 1/10/09, cara <pinkgranite at gmail.com> wrote:

> ... as a matter of fact, I love your comments. But, I'm currently
> seeing programmers paid in the 6 figures who can't architect
> their way out of a paper bag. This means, architect anything
> beyond the app/algorithm/glue_script they are currently working 
> on. Follow a customer required specification for a system
> design? You can freakin' forget it.

There's nothing new, there.  And, it isn't unique to "programming".
How many MBA's never actually "make a decision" in their career?
Or, rely on "concensus"?  (then what do we need *you* for?  to
"tally the votes???")

> Their managers, who are just as clueless, keep things going

"Peter Principle"  :>

Top be fair, it is had enough as a "droid" trying to keep up
with everything that *might* be pertinent to an industry.
Can you imagine the burden this places on managers?  They
(*ideally*) would not only have to keep up with what is
*current* but, also, keep an eye at the horizon for things
that *might* be pertinent to their businesses down-the-road.

> ... but for how long? Everyone thinks they have a maintainable
> system, they think they do 'software' ... and well, I've seen

Learn a key distinction:  Programmers vs. Software Engineers
vs. System Engineers.  Figure out where in that totem pole
you want to be working.  The skills you need are different in
each.  And, your *value* to the organization is likewise!

> so little competence in the field that I have struggled to
> find a good mentor. Yeah, SOA is somewhat like CORBA is
> somewhat like just plain doing nice modular oo code ...
> But, yeah, good programmers who can design, see the big
> picture, write something scalable, write something 
> maintainable and put the real business goals in perspective
> ... over and above, "I whipped out this cool python
> GoogleEarth plugin today." ... are rare ... I swear, they 

Look at how folks approach *testing* as an insight into their
overall skillset.  If it is treated as an "extra" job (chore?),
then you have an idea of their commitment to producing a
good product.  The same is true of documentation.

I see *so* many FOSS projects that have *no* documentation.
"What's the structure of the code?  What are the underlying
algorithms used?  Hell, what's the layout of the source
distribution???!  (where is main() so *I* can start looking
through the code?)"

This is how I evaluate which FOSS projects I want to get
involved with and/or incorporate into my own designs.  If
those that came before me think so little of their efforts
as to NOT codify test sets, documentation, etc. then it
probably means they didn't write very robust/good code.

> are rare. Basic programming skills can be had for less 
> money. And, if simple programming skills go from a
> salary of $90K+ a year to whatever they make in other parts
> of the world, then things seem to be working correctly to me.

You will also see different cultural emphasis in the
appearance, reliability, etc. of code.  I have complained
for many years about "japanese code" that assumes the
world is perfect and barely does what it *should* (failing
completely when something imperfect happens in The World).

You can also get a feel for how committed a company (either
the firm doing the work *or* the firm selling the product)
is to doing a good job by some of the more visible parts
of their product.  E.g., does the user manual read like
"good english"?  Or, like a sloppy translation from some
other language?  (japanese electronic devices are notorious
for describing all potentiometers as "volume controls"...
"Um, what's this 'volume control' doing in the high voltage
power supply control loop?  Can I make the high voltage
LOUDER???")

[N.B. I don't mean to be picking on The Japanese; these are
just some historic references that were easy to conjure up]

--don