CS> do so.  Do you have any experience hiring programmers?  If CS>
so, I'd appreciate any advice you may have.

 BC> 1. Hire people you've worked with before. Even if they have warts,
 BC> you  know EXACTLY what to expect. My experience with RECOMMENDING to
 BC> hire/not hire people: they turn out to be amazingly different than you
 BC> thought  during the interviews. In crisis times, it's almost better to
 BC> dispense  with any surprises & hire known quantities, although I've
 BC> seen  management hire people I thought were dogs only to find out they
 BC> were better programmers (and people) than me.

I often wonder if I've got some kind of objectivity problem whenever I
think about the quality of work I've seen other programmers do.  It just
seems like so many of them significantly underperform what I'd expect.  And
so few of them seem to be familier with OS/2.

Maybe I'm perfectionist, which can be good and bad.  It's good in the sense
that software with very few bugs is a nice thing to be producing, but bad
in the sense that it can take a lot longer than somebody who hacks together
a working piece of code quickly.  Then again, my experience has been that
hacked code is going to be a liability later when it comes time to make
changes and/or
strange bugs appear in the software that have to be fixed.

 BC> 2. Glowing recommendations don't mean diddly. The former employer may
 BC>  want to avoid a lawsuit, or the person may react strongly to their new
 BC>  environment and not perform as well as they did...this happens with
 BC> most of us when thrown into a sweatshop environment.

My thinking has been that getting a sample of source code that they've
written could yield a good idea of what kind of programmer they are. But I
suppose the problem is that I may not be able to be sure they wrote the
code. 
 And I also have to be sure they aren't showing me code to which they have
no legal rights.

 BC> 3. Older "experienced" programmers are hard to change,
have distinct
 BC> ideas about "how it should be done" and can be
insufferable about it

That sounds a bit like me.  I'm only 25, however.

 BC> rather than sticking to the old adage: "Never try and teach a pig to
 BC> sing- it wastes your time, and it annoys the pig" (which applies to
 BC> THEM as WELL as management). They also produce more good code/hr while
 BC> appearing to be extremely slothful compared to new programmers who
 BC> churn out stuff that needs to be redone 6 times.

I'd rather it be done right the first or second time than have to go round
and round on rewriting the same code.  Sometimes it is hard to know if an
idea is going to work until it is coded up and tried, so allowing the
benefit of the doubt on one rewrite of the initial version seems to me to
be OK.

Some things about OS/2 change so quickly or there are so many ways to
accomplish the same task with OS/2 that it makes me wonder what features
should be used for implementing certain functionality.  For example, I've
structured the project I'm developing as a set of clients and servers
communicating across named pipes.  Yet with DCE,SOM, DSOM, TCP/IP RPC, and
other options now available, I wonder if using named pipes was the best
choice.  So far I haven't wondered about it enough to rewrite anything,
though.

 BC> 4. New "young" programmers take direction better, code like a bat,
 BC> and  are quicker to pick up new constructs- helpful if the project
 BC> involves  all sorts of non-traditional stuff. OTOH, they have a low
 BC> experience  level, so you have to spell everything out. They won't
 BC> admit sometimes  that they don't know about some concept you or an
 BC> experienced coder  would take for granted. I 'bout fell off my chair

I think I'm more inclined to hire a newer, younger programmer.  Maybe part
of it is that I'm not sure about how an older experienced programmer would
take to some youngster age 25 being a supervisor. But I'm certain part of
that feeling is that I may be able to more easily train a newer programmer
to program the way I want him or her to program.

 BC> when my supervisor  laboriously explained integer fractional binary
 BC> arithmetic- NOTHING in  the CS texts I'd used (and I'm engineer, not
 BC> pgmr- predate "CS") EVER mentioned this, but out in
embedded control in
 BC> the late '70s, it was a standard tool. I felt like an idiot- but glad I
 BC> asked!!

Because I've had to find ways to do tasks such as accurately plotting
300,000 data points across a window about 600 pixels wide, I've been using
ideas such as this one.  I'm using 32 bits on each side of the binary point
so as to try to maximize accuracy.  But I don't remember hearing about this
in any computer science classes.  As I recall, the first I heard about it
was in 1989 when learning OS/2 1.1 PM programming.  OS/2 uses some fixed
point numbers for certain PM operations.

 BC> 5. Good luck. For help, call (401).... Hope you don't have to make
 BC>  the cut on who to hire. Things in CT-RI axis are quite bleak, and I'm
 BC> too soft and sympathetic to make hard decisions about people. I'd want
 BC>  to hire them ALL!

I'd be happy to be able to hire just ONE additional programmer.  I'm a bit
tired of being the only programmer on this project most of the time.

 BC> 6. For one customer, I took over for a programmer who'd left 4500
 BC> lines  of uncommented C source behind. He used to sneer at how slow and

When I got involved with the project I'm developing, all the source code
had been written by programmers who appeared to have the idea that comments
were for identifying who wrote the code and to put arbitrary version
numbers on each file.  Obviously knowing that a file had been at version
0.2, and then 0.21, and then 0.25 is really useful information.  But
comments shouldn't be used for anything else. Certainly noting what each
function does should not be done, and identifying the purpose of parameters
and variables is obviously heresy.  It left me wondering why they stooped
to occasionally use intelligible variable names -- why not just put
everything in some cipher code.  Hey, to make it easy they could have
written a utility to take boring old commented C code with readable
variable and function names and strip the comments and all extra whitespace
and change everying but keywords (i.e., variable, parameter, and function
names) into random strings.

 BC> pokey  my coding was; took me 8 months, part time, to clean up that
 BC> code while  doing all the other stuff required, and the experience led
 BC> me to  consider using commercial off-the-shelf POPULAR libraries in
 BC> lieu of  even my beautiful, heavily commented code (the other
 BC> programmer now  uses lots more comments, I've noticed). Especially
 BC> those w/o royalties.  I've been reading some of the Ghostscript source

I'm really skeptical of using other people's tools.  Several times I've
wasted hours or days reading documentation and learning a new tool only to
discover that I can't use the tool on a project because it made some
assumptions about how a project should be done that would require a lot of
changes to code that was already completed and working well.

Recently I bought VisPro/C++ 1.0.  After realizing it wasn't generating
some required source code files due to what appears to be a conflict with
HPFS386 (or perhaps a bug in HPFS386) and changing back to HPFS to get rid
of that problem, I think it may be a useful tool. But I'm not used to it
yet and it doesn't write source code the way I'd like it to write source
code.  For instance, it uses /* */ style comments rather than // style
comments.  And it doesn't indent and name variables and classes the way I'd
like it to do.  Also it relies on the resource compiler more than I'd like.
 None of these things are individually significant problems, but together
they leave me with the feeling like it leaves the programmer with too
little control over stylistic choices.

 BC> It gets worse. It was a competitive bid with several heats. Software
 BC> had to be in a DOD-approved HLL. In 1982, those were FORTRAN IV, COBOL,
 BC> some AN/UYK-xx lingo, and Ada. Ironman or whatever had just finished,
 BC> and we  said: "They claim a 1st cut Ada compiler for our mini will be
 BC> ready by  the time 1st h/w is due- do you want us to code for that w/o
 BC> testing, or use FORTRAN?". They chose FORTRAN. We had a
"FORTRAN V"

I've heard from various people in the defense sector that many projects
will intentionally pick hardware/OS platforms for which there is no Ada
compiler available so they don't have to use Ada.  I've only done about 10
months of Ada programming, but the language didn't seem so bad.  The main
"problem" was that it was rather verbose and extremely strict
about type checking.  I think this means more typing and many more rounds
of fixing little things the compiler doesn't like before it will finally
compile a code module, but a better chance of the software actually
functioning correctly.

 BC> about 11 man-months for  naught. This was forgotten until GUIDELINES
 BC> chastized me the other  day about some long module label I'd used. Gad,
 BC> how far we've come in 12 years (and most of the *&^% radars are STILL
 BC> not installed)!  Comments about ICLUI .EXE size have me worried, but
 BC> GUIDELINES' imperfect .GUI translation on one module had me digging in
 BC> the .RC file (MIS_BREAK_SPARATOR??!) and I realized, "I don't like
 BC> this- it has no  intellectual satisfaction whatsoever".  Even if the
 BC> .EXE is 100K min.,  I'll take ICLUI or Guidelines over handwritten
 BC> APIs.

I haven't tried Guidelines.  For the last few months I've been coding using
ICLUI code written by hand.  Because the application has to take up the
whole screen yet I want it to be fairly independent of screen resolution,
I've been happy with classes such as ISetCanvas,ISplitCanvas, IViewPort,
and IMultiCellCanvas that can help
automatically adjust the size of position of controls to fit on a dialog or
window.  Dialog box painters that use the resource compiler get on my
nerves a bit as dialog boxes aren't flexible enough about resizing, but
with ICLUI handling size issues seems a lot more elegant.

As for EXE code size, turning off debugging output makes a huge difference.
 It seems like EXE and DLL files with debug hooks in them are at least 3-4
times larger.  Looking through the files it almost looks like half of the
headers for ICLUI get embedded inside each executable.

CS> The project I've been working on for the last couple of CS> years
has been unfortunate enough to have had severe
CS> personnel turnover problems,understaffing, and lots of
CS> requirements changes (some of them major).

 BC> Yikes! I hate it when that happens! Have you considered working for a
 BC>  quiet, relaxed, laid-back place -like NEXGEN ??

Well, I'm not looking for a new job at this point.  I'm hoping the current
one will turn out to be a good long term job.  Once we start delivering
some beta systems by year's end, the investors are pretty much stuck having
to follow through with release level systems and product improvements for
the next couple of years.  Thus I feel like there could be some good job
security here.

CS> However, in some
CS> ways this has been good for me personally as I'm the only CS> one
who has been around for nearly the entire project and CS> at this point
the investors and management seem to think CS> I'm worth trusting
because I haven't ripped them off and CS> haven't quit on them like the
other consultants have.

 BC> I sincerely hope you are getting $$$ for this! An OS/2-based project
 BC> (or even Windows these days) is in serious manpower trouble to begin
 BC> with;  tell management I said they need $$$$$ life insurance on you! If
 BC> it's  anything near as complex as it appears to be from ur various
 BC> messages on comm. programming, the time to come up to speed for new
 BC> folk should be  enourmous- an investment NOT to be lost by P-Oing the
 BC> help!!!

A few months ago I demanded a pay raise as I had been getting underpaid for
some time.  In December 1993 I graduated from UCSD but still hadn't gotten
a pay raise six months later.  They jumped on that issue right away and I
got a raise within about two to three days. After going through one
contractor (and about four or five programmers there) as well as two other
programmers they have hired, I think they realize how hard it is to get
somebody who is even moderately reliable and fair.

This project makes heavy use of multithreading, named pipes,semaphores
(mutex and event), DLL's, PM, multiple serial ports running at 38400 bps,
64-bit integer arithmetic (mainly addition and subtraction), and C++
features such as templates, exceptions, and multiple inheritance.  There's
even a bit of assembler code involved as it was the only way to efficiently
implement a few things that would have otherwise needed to use mutex
semaphores that would have a lot more overhead.  Overall I feel like I've
got a good handle on it,but there are enough different parts to the project
that after I've worked on one part for several weeks it takes me a few days
to get adjusted to working on another part I may not have touched for a
couple months.  Thus I'd be really happy to have some help as it might mean
I'd be able to concentrate more on core issues and leave some of the
simpler user interface work and testing and debugging to somebody else.


--- Maximus/2 2.01wb