How much should I charge for fixed-price software contract?

[David Alex Lamb]

In principle you're right ... but it's rarely that simple.

I support testing and assertions wherever possible, including
intra-procedure if there is some meaningful test that can be done on a
partial result - but testing line by line is ridiculous. It may be
extremely difficult or quite impossible to figure out what would
happen if a particular line of code is wrong or missing. It's also
unwieldy because such tests frequently can't be batched but must be
executed in-line due to following code altering the test conditions.

You left out the important sentence in Phlip's original where he said "It's
not white box testing." From this I deduce he's talking about providing
inputs to the unit (method), not adding lines of code to what's being tested.

There remains the problem of "figuring out what would happen if a particular
line of code is wrong or missing". Once again I plead ignorance of TDD
(thankfully Phlip is kind to me when I make mistakes!), but it seems to me
that Phlip is talking about the simplest form of "test coverage" which gives
us two tests for "if A and B then S" -- one for if true, one for if false.
There are more complex forms of coverage such as checking all possible
combinations of truth values, and others which look at number of repetitions
of loops (somewhere I have an old reference to an article defining a hierarchy
of test coverage approaches, which I will try to find if anyone needs it). It
seems to me that the line-by-line approach would have to suffer from the same
limitations as test coverage: number of test cases grows exponentially as the
program gets longer and more complex. I suppose "small methods" helps limit
that problem, but isn't it still present?

 

[Robert Maas, see http://tinyurl.com/uh3t]

about setting yourself up for impossible expectations...

I have 22+ years experience writing computer software. I expect that
should be sufficient to qualify me for *some* job by now.

If you _really_ believed in this new idea, you would write it up,
give it away for free on the Java communities, and generate some buzz.

I am not Bill Gates. I don't have the power to decide upon my pet idea,
without consulting other leaders in industry, order my staff to install
my pet idea exactly as I conceived it, without any improvements that
might be obtained by consulting with other leaders in industry, make it
a bundled part of my operating system, and thereby force my albatross
across the neck of half the computer users in the world, as a de facto
standard everyone else must follow or die.

I'm just one bright guy among many. I get new ideas, which might be
really good, but require consultation with others to get a wider idea
of how to make it a best standard that really ought to be adopted
widely. So I'm looking to find a community of developers who get
feedback from many customers, to brainstorm with me to work out the
kinks in my idea before we start trying to standardize it.

Some of my ideas don't require standardization. I'm just providing an
end-user service, and I can just write the code my own particular way,
get it working, and install it as a CGI service for others to use. But
my proposal for a portable interval-arithmetic standard, that is
essentially the same in Java, Common Lisp, Scheme, Emacs Lisp, and any
other suitable languages, requires more than just one person saying how
it'll be.

Please let me know if you were thinking of some other idea of mine, not
interval arithmetic.

If you ever get near the negotiating step again, offer to pay per
"story point". (Look it up.)

What do you "again"? When, to your knowledge, do you allege that I was
ever in a situation where I could negotiate about anything in any way
related to employment?

I tried to look up "story point" in both Google Web and Google Groups.
Virtually all references were to literature (writing fiction). The only
useful references for what you might be talking about were in "extreme
programming", that IMO ridiculous programming system where all code has
to be duplicated by two different people on a team, and where the teams
are shuffled every day or even more often, and then I presume some sort
of regression is used to determine the individual output of each
employee:

I've been looking into using a use-case driven progress-tracking
appoach based on Robert Martin's 12/2003 SD article called The Bottom
Line. The idea is that you use weighted groups of requirements (e.g.,
stories or cohesive groups of use case steps) called story points to
find out just how many story points your team can complete within a
set amount of time.

Story points is an
interesting idea, I've started tagging stories/use cases as Easy,
Medium or Hard. Is this a similar thing? Or do story points translate
to some arbitrary time/effort expense?

Is that what you're talking about there?

Then you charge to the estimate, not the actual. Demand the _smallest_
possible line items - 2 to 9 hours each - to make them easy to estimate.

I can't demand anything. I'm lucky if they pay me any money at all for
the work I do for them. The most I can do is suggest that line
micro-items might be a good way to do the billing. Then I'll give them
exactly what they say they most want instead of a whole package of
stuff that is half what they wanted and half extra stuff I thought
they'd like but I was mistaken (or they really did need it and like it
but it was "invisible" so I never got credit for it because then never
looked at my code enough to see it in there). Then later when they
realize they need more, such as the stuff I would have just thrown in
as part of the bundle using the old system, they pay me more to do
more, and it ends up the same as the old system (same total software,
same total money) except they appreciate every little thing I did,
nothing "invisible".

The reticence at the "now I need funds to put you on this job" step
is because so many of your peers have destroyed your potential
customers' faith in programmers. Yes, they would rather hire an idiot
freshly graduated to use the latest buzzword-compliant crap, rather
than a senior who knows how to prevent bugs and stabilize development.

I can't prevent *all* bugs by my all-levels unit testing, occasionally
a design oversight leaks through and I have to track down which module
is misbehaving and fix it. But one bug per month of programming, and
one day to track it down and fix it and re-test everything programmed
to date, IMO isn't a bad bug-rate for a one-person project with not
even one other person to give feedback about design or to help
unit-test large modules. Agree?

Anyway, in general I like your suggestion of charging per estimate
(standard for all contract work AFAIK) but making that charging based
on micro-features written&debugged rather than just a bulk price for a
poorly-specified overall system. It seems more likely that I can get
the customer pinned down on exactly what use cases are to be installed
if each is priced separately. (There would be two kinds of use cases in
this kind of micro-billing system: Middle-level capability, which is
apparent only in test rigs, and top-level user-application cases, which
show up in actual product. I'd make it clear which middle-level
capability is being programmed, and how it might enable a more general
class of user-application cases in the future, in addition to its need
as a foundation for the current user-application case. That should
avoid the client telling me to write totally unstructured code where
everything is inline at the topmost level with not a single reusable
mid-level utility, to reduce the number of items I bill for by a
cheapskate customer.)

Example (I'm talking to my client): You said you wanted a way for users
to log in and log out. I propose a mid-level utility which keeps track
of logged-in users in a table in a relational database. This will
support all of the following use cases easily:
- User logs in the normal way via the Web.
- User logs out the normal way via the Web.
- User loses his/her net connection, and tries to log in again while
already logged in. Option of killing old login first, or attaching to
old login and simply continuing where left off.
- User forgets to log out and leaves login hanging. Sysadmin needs to
bring down system to do backup, and therefore needs to log out all such
hanging logins first.
- User is misbehaving. Sysadmin needs to lock that user out.

At this time, I'd bill for the mid-level utility, and the first two use
cases, leaving the rest as easy options if you ever need them, OK?

You have no Win32?

That's correct. I have no access to any Windows system whatsoever,
except at the public library which allows only IE, no other program
whatsoever, not even Note Pad.

You really need to work on the positive thinking angle!!!

Lying to myself to convince myself things are better than they really
are, has never been my strong suit.

I have, however, been tricked many times, when things seemed like they
were getting better, and I actually believed they were getting better,
until I realized I had been mistaken. For example, a few times I
thought a woman loved me, only to find out that wasn't true. One time I
got a permanent job, only to be fired five months later because my
employer discovered I was disabled. Several more such examples.

No. It's to get them hooked and then charge for the upgrades. Nobody said
you couldn't start charging if someone starts using your code, then needs a
new feature. Do you think the GNU license prevents you from charging for
that?

Except the people who don't have money for software in the first place,
who therefore are forced to use free software (freeware, and open
source), are unlikely to be willing to pay for upgrades. It would be a
very small market for those tiny fraction of people not willing to pay
for the software in the first place but then willing to pay for
upgrades, like probably less than one percent of the total free users,
and even so they wouldn't be willing to pay for a new feature that cost
thirty hours of my time (a thousand dollars) unless there are at least
ten others who want exactly the same feature to share the cost.
Something general like Linux, I can see a million customers, with one
thousand of them willing to pay for an extra feature, but only ten of
them agree on exactly which new feature, and that's right at the
threshold for sharing cost $100 per customer. But I don't expect to
have a million users for some specialized tool I write. The main tools
used by millions (Linux, RDBMS, spreadsheet, WebBrowser,
mail&newsgroups, wordProcessor, incomeTaxFiling, etc.) have already
been written so there's no way I could get into those markets. I doubt
there'd be a million customers for an XML/RSS-based utility for
consolidating and prioritizing watches on various sources (newsgroup
threads, Yahoo! Groups, e-mail accounts, news wire topics, blogs,
etc.), but I might be able to attract a hundred users, in which case a
centralized server-side consolidator/prioritizer with freeware
client-side alerter would support charging for CGI directly after an
introductory free period.

So how can I find anyone in the local area (Sunnyvale, CA) willing to
purchase my services on a line-item basis, or anyone anywhere on the
net willing to brainstorm with me on a new interval-arithmetic
standard, or willing to try my various specialized utilities and give
me feedback?

(Missing word "mean", exercise for reader where it belongs.)

 

[Andrew Thompson]

On Fri, 26 Aug 2005 21:45:07 -0700, Robert Maas, .. wrote:

X-Post to: comp.programming,comp.lang.java.programmer,comp.lang.lisp

Isn't it about time you stopped abusing these 3 groups
for your personal whining and bitching, Robert?

It got quite boring, around 5-10 threads ago.

[ F'Ups to this post set to c.l.j.p. only ]

 

[Randy Howard]

Robert Maas, see http://tinyurl.com/uh3t wrote

I have 22+ years experience writing computer software. I expect that
should be sufficient to qualify me for *some* job by now.

McDonald's is hiring. I know, it's not funny. But, if you were
carrying a foreign passport, you'd probably be hired instantly.
Or, you could move to a foreign country to work for US countries
that want to outsource. Yeah, real enticing isn't it?

So how can I find anyone in the local area (Sunnyvale, CA) willing to
purchase my services on a line-item basis, or anyone anywhere on the
net willing to brainstorm with me on a new interval-arithmetic
standard, or willing to try my various specialized utilities and give
me feedback?

Put an ad in the paper? Knock on small business doors and ask
them if they need help, and offer to do something they need done
/today/ for no charge to show your abilities. IOW, work for it,
instead of sitting around on Usenet whining about why people
aren't hiring you. If you have time for this despite being
unemployed, then you have time to working on some commercial
software product that you can sell, even if it's 9.95 a copy
shareware on download.com.

 

[Robert Maas, see http://tinyurl.com/uh3t]

From: (e-mail address removed) (Michael Sullivan)

... instead of looking for exactly and precisely the kind of work
that you have done in the distant past, ...

You're displaying a serious misconception. I'm available for any legal
work where I'd be doing something actually useful so that it would be
worth paying me to do it. It's the employers who refuse to even
consider people who haven't done exactly the same kind of work before.

Go work at McDonalds

I tried that, when I had less than one year work experience. The
manager at the McDonalds on El Monte near El Camino Real told me that
because I have a college degree he won't consider me for employment
because he'd waste two months training me and then I'd find a better
job elsewhere and he'd be out the expense of training. Later that year
I got a job at Round Table Pizza on University in Palo Alto, where a
ditzy redhead Mrs. Masinter wasn't watching where she was going and
collided with my car and then freaked out seeing the car parts strewn
on the pavement, apologizing, exchanging insurance info, then she drove
off before giving me a chance to inspect the damage and see that all
the damage was to *her* car, not mine. Anyway, Round Table fired me
because I suffer a learning disability, unable to memorize the prices
on the menu. A year or two later I was sitting at a terminal at the
A.I. lab doing my usual work for free, and occasionally running FINGER
to see who else was around, when I saw Larry Masinter logged in, so I
wwnt over and asked if he was in any way related to that ditzy driver,
and indeed that was his former wife. He showed me Lisp for the first
time, impressed me, and after Hans Moravec explained the REP loop to me
I was forever going strong with Lisp.

or a factory

That's not a good idea. I have very poor muscle coordination, can't
write legibly, can't do sports at all, take ten times as long as anyone
else to do a simple mechanical task in metal/wood shop in school and
still the result is cruddy, need extra space on both sides of car when
I'm driving because I can't judge distance between car and parket cars,
break almost anything physical I try to work on, did I tell you about
the disaster when I tried to do work on my car (tune-up, and lubricate
the air-duct wire-in-sleeve control cables)?

a lot more brainpower goes into defining the problems that explicitly
than into the actual coding,

Much of my work at Stanford was like that. Unfortunately there's no way
to express that with buzzwords on a resume, so you're not aware of that
from reading my resumes.

and once you've done that part -- Indians and Chinese can and will

I'd be glad to design the software, farm it out to I&C, then check what
comes back to make sure it does the job that was required. Do you know
any such software-design jobs available now? I've never seen any such
jobs advertised anywhere, ever in all the years since I started
programming.

 

[Robert Maas, see http://tinyurl.com/uh3t]

there is a world of difference between "brag and brag and brag
incessantly" and making it clear to the world that you are looking,

How do I let potential employers know I'm looking, and able to start
work immediately, without letting them know I'm currently umemployed? I
got castigated by some people in this thred just because the very first
resume I wrote in 1991 happened to mention that I was currently
unemployed (3 months at the time) and available to start work
immediately. I'm not the kind of person to jump jobs, quit a job before
the project is completed, and while they still need me, just because I
found a better job at another company, and I don't want any potential
employer to think I'm that kind of person.

and bringing certain skills to the party.

I have no idea how to express my qualities of work in buzzwords that
the junior staff member filtering resumes into trash can would
recognize as a reason to select mine to stay out of the can. Do you
have any ideas to help me, or do you just like kicking people while
they are down and I shouldn't expect you to offer any useful ideas?

When I used to have a car and be on the mailing list, I used to attend
the BOF meetings at Shorline Park in Mountain View, but I haven't been
able to find any announcements of them in recent years, so I haven't
been able to attend any, and since late 2003 I haven't had a car to get
to them anyway. But back when I did attend, there was no opportunity to
talk with other attendees about anything that would help me get a job.

Many years ago I went to Macintosh UG meetings, no chance to talk about
anything there either.

Last year my Java instructor told me about a Java puzzles meeting in
the Oak room near Wolfe and Pruneridge, and I did good at solving the
puzzles, but the only chance to talk with anyone was just one
conversation that lingered afterward and then had to be moved outside
so the building could be locked, and none of the conversation was of
any use toward employment or inside contacts. I haven't heard of any
other Java meeting in this area since then.

Lisp UG meetings in this area seem to be secret, no way to find out
about them until after the fact.

 

[Andrew Thompson]

...You're displaying a serious misconception.

We care about your incessant, whining ramblings?

[ F'Ups set to c.l.j.p. only. ]

 

[Andrew Thompson]

On Fri, 26 Aug 2005 23:22:45 -0700, Robert Maas, ...wrote:

...& wrote and wrote and wrote.

You probably cannot get work becasue you bore
people to death. Go away Robert.

[ Follow-ups set to c.l.j.p. only ]

 

[Robert Maas, see http://tinyurl.com/uh3t]

The good is the enemy of the best.

A half-truth is a lie.
A bicycle with only one wheel isn't useful.
Yin without yang isn't useful.
A glass half full but not half empty, or vice versa, is not the whole
picture.
For nearly every cliche there's an opposite which is equally valid in
different circumances.

Please choose which of the following activities you would most and
least like to participate in:
(1) Have bamboo shoots driven up under your fingernails.
(2) Undergo Chinese water torture.
(3) Be trapped in a large tank with one (1) pihrana.

 

[Andrew Thompson]

A half-truth is a lie.

You have written enough to have covered many full-truths.
Now give it a rest, *please*.

[ F-Ups set as usual. ]

 

[Guest]

I tried to look up "story point" in both Google Web and Google Groups.
Virtually all references were to literature (writing fiction).

Then you need to learn to do a search.

A search on ' "story point" programming' brought up several documents
that discuss story points and how many story points a pair programming
team can handle each week.

--

Seek simplicity and mistrust it.
Alfred Whitehead

A witty saying proves nothing.
Voltaire

 

[Randy Howard]

(e-mail address removed) wrote

Then you need to learn to do a search.

Why bother?

A search on ' "story point" programming' brought up several documents
that discuss story points and how many story points a pair programming
team can handle each week.

Anytime you are worrying about counting story points, or lines
of code per delta_t, or 'programmer activity units' or any other
made-for-the-slideshow gibberish, you are working to make some
micromanager happy, not to write code. Programmers don't give a
hoot about 'story points', they care about meeting (and
hopefully exceeding) their project requirements and schedule
without compromising quality.

Spending 6 months out of every 12 memorizing a new set of
made-up terms to describe some supposedly novel way to write
software may be interesting for project planners, and keep them
going to nice seminars adjacent to interesting golf courses, but
for everyone else it is a colossal waste of time.

(It does of course open up a financial bonanza for the evil
folks that descend on these new buzzword festivals with training
materials, certification programs, books, self-paced CD study
kits, t-shirts, motivational posters and of course, special
high-$$ software to track all the new buzzwords as the lemmings
meander through the new labyrinth now created for them.
Here's an example of the mind-numbing stupidity expressed in the
latest incarnation, 'story points' from google searching...

"Managing estimation and keeping with deadlines is always a art
than a science."

Let's pretend like that is a well-written sentence and keep
going.

"... But it doesn't mean we can not utilize the science at all
for project management."

I knew this was BS for managers and planners.

"... Robert Martin suggests us two charts that can be very
useful hanging on wall -"

The author is functionally illiterate, but we finally get to
something...

"... 'Velocity Chart' - illustrating, week by week, how much
work is actually getting done?"

Hmm, sounds like something a project planner would keep track
of, but is basically irrelevant to programming. What needs to
be tracked is how much is remaining. Since development isn't
linear, like walking at nn miles per hour, you can't really
measure that all that well either unless the person doing the
measuring is extremely experienced, knows all of the project
details, and has worked with all the team members long enough to
be an accurate predictor of their likely forward progress rate
given the remaining problems.

"... 'Story Points Chart' - week by week, how much work remains
to be done in the project."

Ahh, there we are. A story points chart, doesn't that sound
lovely? Well guess what. It's a dated to do list, although
when created by people that buy into lingo instead of action,
it's probably not as informative.

And here we have an open admission of what I was saying
earlier...

http://www.sdmagazine.com/documents/s=8958/sdm0312f/sdm0312f.html


"Well, here¹s the bottom line: Agile methods are merely a
technique for managing software projects. Their purpose is to
provide managers with the data they need to make timely
management decisions. And this should be good news for those
project managers who know that managing a software project often
involves more prayer than science."

So there is the smoking gun, it is to make managers happy. Note
that it doesn't say anything about better, faster, cheaper, or
anything that might actually be useful, but gives them better
charts for their powerpoint presentations to the next layer of
morons in the meeting next Tuesday. Don't pretend like "make
timely management decisions" means anything valuable. It means,
"should I ask them to work late and slide a pizza under the lab
door before I knock off early to bang my secretary?".

 

[=?iso-8859-1?Q?Tiarn=E1n_=D3_Corr=E1in?=]

and that's after fighting off the feral koalas and dislodging
the redbacks from the keyboard

And dodging the drop-bears. *shudder*

 

[Joan]

I have 22+ years experience writing computer software. I expect
that
should be sufficient to qualify me for *some* job by now.

<snip>


Can you say "welcome to wallmart"
Can you say "bye bye"

 

[Joan]

You're displaying a serious misconception. I'm available for
any legal
work where I'd be doing something actually useful so that it
would be
worth paying me to do it. It's the employers who refuse to even
consider people who haven't done exactly the same kind of work
before.

<snip>
Most places that I've worked at don't do something actually
useful.
They try to make it interesting sometimes. But they cancel most
of
the good projects.

 

[Greg Menke]

The define "legacy" as "requires debugging".
Bizarre.



This sounds like the code went through an emulation phase and then a real
thing phase.

Nope- went through breadboard designs of the hardware using inputs &
outputs first from emulation hardware and eventually from the real
hardware. The breadboard designs are used to work up hardware and
software designs and implementations, feeding back changes & bugfixes,
etc into the evolving specs. Ideally, the working software meets the
working hardware later on in the project. Low fidelity emulation is
pretty handy for easier classes of bugs early on; mismatched or unpacked
structs, endian stuff, etc.. But race conditions and pathological i/o
states (the harder problems) often depend on the real hardware in the
real operating environment (maybe interrupt timing changes because
capacitors & clocks drift when the system goes below freezing, for
example).

Ideally, I would configure one button on my editor to run all tests against
the emulator, then run all possible tests against the hardware. If the code
fails in the hardware I would trivially attempt to upgrade the emulator to
match the fault, so the code also fails with the emulator. But this is
speculation, and of course it won't prevent the need to debug against the
hardware.

Neat. Who's going to pay for the emulator (build it & prove that it
matches the hardware- and keep it matching) when we also have to do the
real system?

Now one place that emulators are really handy are for working up smaller
subsystem elements; ie logic in a single fpga or related fpga's- then
excercising the i/o is a bit easier.

Realistically, you are apparently relentlessly testing, and admittedly in a
"legacy" situation that prevents you from using tests to make the hardware
more bug resistant. Carry on!

We don't get many opportunites to make hardware more bug resistant. If
software discovers a discrepancy in the documented interface we can
sometimes get fixes back into hardware, but it has to be well proven.
Early in the hardware lifecycle its easier to get changes to the
interface specs, but later on the software people pretty much have to
lump it.

Gregm

 

[Phlip]

Bizarre.

Then define "foo" as "frequent punitive open-ended debugging causing
occassional schedule risk". Some teams use "legacy" as a casual shorthand
way to say "foo". Please substitute my definition for "foo" wherever I wrote
"legacy", so we can address the actual points raised.

Nope- went through breadboard designs of the hardware using inputs &
outputs first from emulation hardware and eventually from the real
hardware. The breadboard designs are used to work up hardware and
software designs and implementations, feeding back changes & bugfixes,
etc into the evolving specs. Ideally, the working software meets the
working hardware later on in the project.

Sorry to interrupt; why is that "ideal"? Does the software match up even
later sometimes?

Low fidelity emulation is
pretty handy for easier classes of bugs early on; mismatched or unpacked
structs, endian stuff, etc.. But race conditions and pathological i/o
states (the harder problems) often depend on the real hardware in the
real operating environment (maybe interrupt timing changes because
capacitors & clocks drift when the system goes below freezing, for
example).

As you stated before, in that space you often must research the nature of
faults, and that research will occupy significant development time.

Neat. Who's going to pay for the emulator (build it & prove that it
matches the hardware- and keep it matching) when we also have to do the
real system?

In my experience, many teams are too busy doing "foo" because they did not
carefully plan a development environment that reduces the odds of "foo". I
suspect your team does have a good development environment, so we may be
talking past each other now.

But that's no reason to stop!

 

[David]

Hello Robert,

Sorry for the delay. I've been away from home for a few days.

Which kinds of categories? Various programming languages? Various
platforms? Various application areas?

A general list of languages, platforms, and so on doesn't give
me much of an idea about what you're capable of, or if you would
match my employment needs, when other parts of your resume or CV
do not indicate that information.

I understand you've been rewriting again and my view of your
resume is what was posted a week ago, I don't have time to find
it again and see what might have changed. I'll address my
previous comments where I can recall about them.

My first interest was in C++ and was related to work. You've
since indicated you had a course in C++ and that is why it was
listed. Since my immediate need is for people who would be up
to speed on my design and productive quickly, that doesn't
sound realistic even when the C++ skills I think that are needed
are fairly minimal. I also know of others that need various
Java or PDA applications written. This is new to me, so I'm not
entirely ready to help out after my normal day ends. Similarly,
just listing operating systems or development environments doesn't
give me much to go on.

Many years ago during the first five to ten years of my experience
I did list the 40 languages I knew and was productive in (not just
could read) and so on. That really wasn't helpful to the people I
submitted my resume even when I put in experience levels. I also
had a terrible time with the automated systems and headhunters of
the day looking for unrelated keywords that meant something to them.
In my case AS/400, RPG, COBOL, and similar experience was forcing
the people who really needed to fill boring $100K business positions
to contact me. Nowhere on my resume did it say these technologoies
were used together. Yes, I knew the AS/400 very well... but it was
all internals knowledge useful only to IBM. Adding a few well
chosen "Objectives" and dropping the experience that I could live
without mentioning helped my add room for other more useful
information.

It is good to have specialized resumes, but don't show them all
to a prospective employer. They just get confused. Have a general
one that whets there appetite to learn more aobut you and contact
you. Use more specified versions that are customized for a
particular position when you are ready to contact them. For
instance, just sending me a resume with your C++ or Java work
isn't helpful until you can address why it is helpful to my core
product development needs. That may take a little research to
find.

What indication would you like in each category? Years experience?
Specific major software I've written?

Given what I've read from you over the years and what I've had to
review from prospective candidates, I prefer people that give an
accurate objective statement, some indication of familiar technologies
and an accurate indication of expertise, but mostly this information
comes in the form of desciptions about past experience. It helps
me get to know what you've done to help others and what you might
to for me. I also do a phone interview with those that seem worth
learning more about. It is a huge turn off for me if the person
indicated some level of expertise in a couple subjects and can't
answer simple questions or say anything more than the resume already
did. At every level you want to whet their appetite for utilizing
your skills and not dissapoint them.

A good description is quite enough. What your responsibility was,
perhaps the major technologies, and what you accomplished for the
employer. I know you don't feel employed. Tell people what you
did for others.

As for any of your handicaps, they can be pluses if you sell them
properly. They need not be mentioned. Some people call this
arrogance but many people can be honest about their abilities and
find much more work. For instance, you've mentioned remote work
and about 20 hours per week maximum as part of the things you want
in a job. Okay then, find employers able to use that. Part of that
might be smaller projects that can't justify full time help. If you
want to work remotely, don't worry about the skills the employer
needs and instead listen to what they need and find a way to help
them if you are a reasonable match. Grow repeat customers. This
cannot be acoomplished with mass mailings, specialized resumes, and
classic big-company-methods. Learn to sell yourself. If you want,
you might explore teaming up with a good salesman that can help you
find the work. That keep each of you busy doing what you might do
best.

I'm not sure what you mean by the "info" category.

You listed C++ exactly once on the multipage resume you published
a web link to. I was unable to find any further information about
what you knew or had used the language for. I did find other
language categories though. It was pretty much trial and error
finding what your recent activities and accomplishments were.

I list C++ on my very latest (2005.June) resume because I took a
beginning C++ class this past Winter. Naturally it wouldn't be listed
on any resume prior to this year, including the most recently uploaded
resume which is the 2003 rearrangement of the 1998 resume and the 2004
MicroSoft Word formattings of that rearrangement.

I'd suggest listing C++ only if you could be useful to an employer
in that language. You could probably sight read anything and be
fairly useful.

A recent applicant claimed to be a C++ expert and could only list
six years experience using computers. Perhaps his definition of
expert and mine differ. I've used C++ since about 1989 and have
seen many compilers, tools, and language definitions. I tend to
rate myself mid-to-high but not an expert. Anyway the applicant
couldn't complete "strcpy" given the function definition and
asking him not to use any other functions. There wasn't a need
to ask any more detail about his experience. Sadly he couldn't
tell me much about his career so even as a junior developer he
wouldn't have been worth pursuing. I don't mind growing team
members. I just hate wading through the muck when a great leader
is what I'm after.

The only version of the 2005.June resume, other than customized
versions I posted the other day, is the one I'm in the middle of
editing right now. There's no backup for it. Do you want to see it
mid-edit?

I'll take a look at some point.

You're conflating two concepts here: How much general experience and
expertise I have at programming in general, and what I've done in each
of the many particular langauges I've used. In the case of Java, I have
many years of experience in Lisp that can be converted rather easily to
Java ability, but only a little work I've done specifically in Java. So
would refuse to hire me for Java programming, even though I have all
those years of experience in a pre-Java langauge almost directly
applicable to Java, and I find Java almost natural and easy to program
in that way, just because that pre-Java language wasn't exactly Java?

Mentioning the right buzzwords just lets the reader know a bit about
the tools used. So tell the employer what you did for someone else.
If you can work in that you didn't know Java but picked it up to complete
a project that shows effort on your part.

Your English is escaping me there. Could you please re-phrase it so I
might understand it?

You mention many languages, operating systems, and abilities. An
employer doesn't care that you know all that -- at least not yet. It
would be very helpful if you told the employer what it is you wanted
to do for them. If you know so many languages, perhaps the language
isn't important and you can focus on what you want to do. I've read
that you have opinions on user interfaces, design, and development.
If you've read what an employer is looking for, write a good objective
statement to let them know how you can help them. Then complete the
resume for them with supporting information -- just not too much.
You want them to contact you, not make a decision on what they've
read thus far.

I'm in a dilemma. If I don't include all the buzzwords the junion staff
member is looking for when screening resumes, nobody who knows the
slightest thing about software will ever get a chance to see my resume.
But the list of buzzwords (posted in alphabetical order earlier this
evening) is very long, and I don't know how to avoid it seeming like
overkill without taking a chance the very word the junior staff member
absolutely needs to see might be missing. How can I guess which
keywords will be needed and which won't, so that I can include only the
former?

Just as an employer doesn't care about not-hiring every best candidate,
you shouldn't be concerned about getting past every screening step that
all of the potential employers have to use to address the influx of far
too many resumes.

If you must list a bunch of languages/OSes/etc I'd prefer the list
to be ordered in your preference for using them or experience level.
Somewhere else you mentioned the various spellings, such as FORTRAN
vs. Fortran, and what you felt was correct. There is no such thing.
Each employer has their preference and which you choose may make a
difference.

As I stated earlier, I think that you would find much better
employement opportunities by determining what you want to do and
address specific employers one-by-one. That doesn't mean that you
won't also approach totally different employers needs with someone
else. Keeping your resume focused also helps keep your image
focused. When you present too much information it is then up
to the screener to figure out why they should keep looking at
your resume and contact you. They probably aren't looking for
a generalist yet, so don't try to be one. Just try to address the
needs you think they have.

Cold calling or appying to jobs that don't exist can work in
your favor too. Say that you want a part-time job in Java/web and
are willing to do as much of the project as the employer will let
you. Sending that to prospective clients that don't likely have
development departments can open up opportunities just for you.
This can even be done local to you and when personal contact is
required, you ask them to come to you. Tailor your career to
what you want to do and offer them.

David

 

[Robert Maas, see http://tinyurl.com/uh3t]

... zimmer frame!

I have no idea what you're talking about.

How could you not know where something you wrote was published?

How would I find out that information? I tried searching online but I
haven't been able to find the right free database where it'd show up.

All the papers I've had published required be to do things like sign
off copyright or sign a statement that the work was mine etc etc.

I don't remember anything like that happening. In any case, my boss
asking me to sign something like that still doesn't tell me where the
paper would actually end up when published.

Surely you had to submit the paper to a journal/publisher?

No, my boss handled all that, except for the abstract I submitted
myself behind the back of the supervising professor who didn't think it
was a good idea. As best I remember, that abstract was in the 1970.Oct
issue of Notices of the AMS. My copy burned up in a warehouse fire in
1972, so I can't easily look it up to verify if my memory is correct.

In that case, my original full paper was submitted, by my supervising
professor, to various journals that dealt with differential algebra,
such as Annals of Math, but no journal would accept it because it was a
specific result in a field where there were only about ten people in
the whole world working in that field who might like to see the result,
so the math department made photocopies of the manuscript and mailed
them to those ten people.

In the case of the NMR research, the paper was by my boss, whose name I
don't remember, but based on a recent online search I believe it might
have been Olav Jardetsky. I contributed my description, which his
secretary re-wrote, or somesuch. I never saw the final copy of the
paper. I was promised a re-print, but never got any. I have no idea
what journal it might have been in.

In the case of the instructable robot research, the journal was one I
never heard of before and can't remember now.

For the rest of my work, I have no idea whether my boss published any
of my work or not.

Were you the sole author of these papers

Good suggestion. Here's the info:
NMR - contributing author
Robot - primary author
DiffAlg abstract - sole author
Others - unknown if any paper or not

Its the only explination I can think of why you wold not know where
your paper was published.

What if my supervisor did all the publishing arrangement?
Can you think of that?

That may be relevant if you had worked recently on different
plaforms. However, your experience is so outdated its not worth
cluttering up and possibly distracting from points the employer may be
very interested in.

Which of the following computer systems/platforms, which I listed in my
resume (Unix/Linux shell, MicroSoft Windows, Macintosh, CGI) are so
grossly obsolete that no current employer would want to know whether I
had ever used such a system to develop software or not?

Note that I didn't include any of the following on my latest resume:
WAITS, ITS, Tenex

What do you mean "Not true"

Lots of Web servers don't allow CGI, or allow only Perl for CGI, not
arbitrary programs. Having CGI that allows arbitrary Unix runnables
(both native binaries and scripts that use native binaries) is
different from Perl-only WebServers such as Tripod, and
no-CGI-whatsoever WebServers such as Geocities.

they shallow level of description you have made me think you had next
to no database experience at all.

And what kind of description would fit on one or two lines of a
one-page resume that would convince you I had enough experience to do a
job you wanted me to do?

Or just forget the 1-2 line restriction. Let's say half my page is
stuff about relational databases. What could I reveal in half a page
to convince a skeptic that I really know how to write JDBC software?

MS Access is barely a database in the terms of what employers think
of when talking about a database.

MS ACCESS is the only DB available via JDBC at De Anza college.
Oracle was available, but only manually via keyboard/SQL interface,
with no way to make tables or find out what tables were already in the
database it connected to, hence no way to play with it either manually
or via JDBC.

Get yourself an instance of postgres to learn with ...

If you require me to do that, you'll have to provide the money to buy
it for my Macintosh with only 17 megabytes unused disk space, or for my
laptop with no working modem or diskette drive or CD-Rom drive, hence
no way to install it without first fixing the modem.

If you won't provide the money to do what you want me to do, then don't
order me what to do.

stop referring to ove 20 years experience. You don't have over 20
years experience

That's a fucking lie! I do too have 22+ years experience at writing
computer software.

the only experience that counts is paid employment experiences.

**** you! Most of my best work was unpaid.

your skills don't match those of someone who has been doing it full
time for 20 years.

You don't even know what my skills are! The total time I've spent
writing computer software is at least equivalent to 22 years fulltime.

If it was "the best" on the net during that period, then some of us
who have been here for a while should remember it

If you were reading PACS-L in 1991, you'd be well aware of it.

what was it called?

The two files were MaasInfo.TopIndex and MaasInfo.DocIndex.
The first was a list of various indexes/lists that were around at that
time, and the second was a list of important documentation about the
InterNet that was around at that time, in both cases telling the exact
FTP site and filename etc. where to find each such.

Just for interest, what web server was it being used with back in
1991?

It was on a server in Taiwan, in Texas, and in Tasmania, all FTP
servers except the Texas one also had e-mail fetch commands.

Also, if it was the first, the techniques used to build the
index must have been pretty impressive - how did you do it?

I did it all manually, using a text editor to build the text and
assemble the FTP data. Most of the raw data was posted to PACS-L, where
every few weeks somebody would announce they had found such-and-such
list or index and tell where to find it. I merely collected all these
pointers into my master index so that there'd be a single place
everyone could go to find all the important lists/indexes and
documents. I did a search just now, and I see that after I had been
passing word privately to various people, I still wasn't ready for a
full public announcement but I cited my index in response to a need
1991.Oct.12:
http://groups.google.com/group/comp.sys.mac.digest/msg/cb0a1875451e5c1e
Message-ID: <[email protected]>
then somebody else included reference to my index in her posting of
various useful resources 1991.Nov.04:
http://groups.google.com/group/alt.education.distance/msg/8529d3bc37d05a98
Message-ID: <[email protected]>
then when I felt comfortable the index was in good enough shape my
first formal public announcement on PACS-L was 1992.Jan.03:
http://groups.google.com/group/bit.listserv.pacs-l/msg/d03e8a6c6b9fc3eb
Message-ID: <PACS-L%[email protected]>
See also announcements of multiple FTP locations 1994.Feb.22:
http://groups.google.com/group/bit.listserv.pacs-l/msg/eb83631e99f8f06e
Message-ID: <[email protected]>
and 1994.Apr.07:
http://groups.google.com/group/bit.listserv.pacs-l/msg/365b52adc8dc453d
Message-ID: <[email protected]>
also 1994.Nov.21:
http://groups.google.com/group/bit.listserv.pacs-l/msg/fdca6ca2c0219ebd
Message-ID: <[email protected]>
also for e-mail access, 1995.Jan.03:
http://groups.google.com/group/bit.listserv.pacs-l/msg/cfe4d9b87298e44a

Of course they are methodologies - but you cannot claim experience or
proficiency with a methodology unless you have used it in real world
situations (as opposed to contrived learning environments).

Spam is a real-world problem costing more than 50% of the total e-mail
resources in recent years, therefore fighting spam is a real-world
application. Not having control over a SMTP server, and not having
access to the court for suing spammers for $1000 per spam per
California law, my only active option was automating the process of
collecting CTW (Complain To Whom) data and validating it, and using it
to automatically complain about each new incoming spam just a few
seconds after it was noticed by my program that checked my inbox once
per minute. In that way the ISP, if it cared to reduce its outgoing
spam, could catch the spammer in the act.

Lots of people used my computerized pseudo-typesetting (precursor to
desktop publishing) software before Knuth did his TeX. This was
a real-world task for people who had no other practical way to
edit their manuscripts that had complicated mathematical formulas.
(Even after TeX, some people preferred my software because with
Gosper's macros it automatically converted MacSyma output to nicely
formatted output, something TeX can't do.)

Do you want more examples of my software solving real-world problems
(college payroll, college class assignments, for example), or have I
made my point with those first two?

applying the methodology to something other than trivial problems.

I've written software to solve a large number of non-trivial problems,
not all as real-world practical as described above, but still not
trivial in any way. How about if I describe the purpose of five of my
nontrivial problems, and you see if you can write software to solve all
five of them in less than one day of effort? I bet you can't do them
all in even a month of effort, but if they were trivial as you claim
you'd be able to do all five of them in 24 hours. With such a wide gap
between my claim and your claim, it should be easy to see if they are
trivial (maybe it takes you two days because you were busy one of the
days), or very very non-trivial as I claim (it'll probably take you a
full month or two just to do *one* of them completely, but taking even
half a month to get the first completed would show for sure I am
correct and you are wrong).

I said I could not tell what job type/class/catagory they were
"customized" for. If I couldn't determine that, its unlikely any
employer would see anthing which would get their attention.

An employer looking to fill a particular job, and getting resumes
labeled for that particular job, already knows which job the resume is
for, and merely has to check whether it is or is not suitable. He
doesn't have to guess, from the thousands of jobs offered by hundreds
of companies, what job each resume might be for. So your failure to do
a very difficult guessing task is no proof the employer wouldn't be
able to do that much easier task of noticing that I have a lot of
different qualifications including the ones needed for the job.

 

[Robert Maas, see http://tinyurl.com/uh3t]

"Ranked 5th in the US: Putnam maths competition(undergraduate)"

No, that's not correct. I might have placed first, or second, etc.,
there's no way to know, because the top five are bundled together with
the individual scores deleted from the record. Those top five are then
candidates for the one-year fellowship to Harvard.