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

[Scott Ellsworth]

[...]

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.

I have joined very few software teams whose programmers had a good grasp
of time, or progress towards the goal.

After one dreadful experience, I started to make 'what is the goal, and
how are we doing on getting there' a part of my toolkit. Not because I
love project management or project planning - I prefer writing code -
but because I saw teammates get their teeth into an interesting problem,
then burn cycles trying to optimize something only done once in a blue
moon.

The whole 'story points' or other agile bushwah at least gets the
programmers committed to shipping software that does something somebody
wants. Sure, that is what management is supposed to do, but a lot of
those managers have never been taught how to manage. Thus, a wise
developer finds ways to manage their own time, and ways to be clear
about what they need their manager to do to get the job done.

Story points is just one of many ways, and it works or it fails
depending on who does it, and how much their own management is listening.

[...]

"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."

Yep. I have used Agile and XP methodologies, along with waterfall, seat
of the pants, low hanging fruit, and hardest problem in sight. Each one
worked or failed depending on the team, the project, and the management.

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.

I sense bitterness.

Look, better, faster, cheaper, and useful all depend on the next word -
better than _what_. If an agile methodology means that your team
figures out that they have six months of work, and three months of
schedule sometime in month one, rather than in the last week of month
three, then it did its job. If it then lets you prove it to whoever is
setting the schedule, then you had a big win.

If it is just a set of buzzwords a manager uses, and that the team could
care less about, it is a waste of time. Like any other methodology.

It is not magic, it is not a mind control laser that will make your
management get clue it has lacked. It may, though, have the buzzwords
needed to get someone to listen. Very often, getting a dramatic change
requires evidence that someone else tried a similar change, and is still
employed.

Scott

 

[Scott Ellsworth]

From: Patricia Shanahan <[email protected]>
The full article should be available at any good scientific library, in
the 1978 volume of Biophysical Journal.

I don't have access to any such library, unless the San Jose public
library would have it (the new Martin Luther King library on campus of
San Jose State University).[/QUOTE]

I believe she is suggesting that you go to a good library, and see if
they have the paper journal in their stacks. Many university libraries
have their catalogs online, and most will allow you to go to the stacks
and xerox articles. If you are not a student, you usually do not have
borrowing privileges, but you are often allowed to go into the library.

Failing an online catalog, call their reference desk, and ask whether
they have this journal, and whether you would be allowed to go get a
copy of it.

Most good university libraries should carry Biophysical Journal.

Scott

 

[Alan Balmer]

I don't have access to any such library, unless the San Jose public
library would have it (the new Martin Luther King library on campus of
San Jose State University).

I believe she is suggesting that you go to a good library, and see if
they have the paper journal in their stacks. Many university libraries
have their catalogs online, and most will allow you to go to the stacks
and xerox articles. If you are not a student, you usually do not have
borrowing privileges, but you are often allowed to go into the library.

Failing an online catalog, call their reference desk, and ask whether
they have this journal, and whether you would be allowed to go get a
copy of it.

Most good university libraries should carry Biophysical Journal.

Scott[/QUOTE]

Many public libraries participate in inter-library programs and can
obtain such things on request.

 

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

From: (e-mail address removed) (".")

When you get the interview and the employer looks at you they are
going to wonder why you are talking about things that happened two
decades ago.

Your remark is based on a false premise. I don't intend to talk about
anything the interviewer doesn't ask about, and I don't think any
interviewer would ask me about anything more than 20 years ago.

A company will probably receive a few hundred resumes for a position.

More likely two thousand resumes for one position. That's the way
statistics have been during this recession. At a recent job fair, there
were only five employers, with probably one job each, yet several
thousand applicants came in person, lined up for hours just for their
brief moment inside the room with the five tables.

They will spend a minute (or less) looking at each one until they short
list it to 2 or 3 dozen resumes.

They won't look at any of the resumes at all (for that first
elimination round). A computer program will scan each resume for
buzzwords and any resumes that don't have the right buzzwords will be
eliminated before any human ever sets one glance at any of them. I
estimate 95% of the 2000 resumes are eliminated in that one scan,
leaving only one hundred resumes for some minimum-wage staff member to
scan to eliminate all but 20 resumes, before the actual hiring manager
spends five seconds on each of them.

I have no way to know whether my resume didn't have right buzz words so
got eliminated in the first round, or didn't look right to minimum-wage
staff member so got eliminated in second round, or didn't look right to
actual hiring manager so got eliminated during third round. I'm
thinking the only way to distinguish between pass/fail on first round
is to put something really threatening in the wording, whereby the
minimum-wage staff member will report me to the FBI if my resume is
even seen by a human, so if the FBI never visit me then I know I don't
have the right keywords.

You have two jobs when writing a resume. The first is not getting cut
from the short list. The second is getting an interview.

I agree. In theory it's the buzzwords that make the pass/fail
difference for the first round of screening. Unfortunately, except for
my idea just above, I have no way to know whether I passed the buzzword
test or not, hence no idea what part of my resume needs the most work.

Don't assume you have to convince the person reading your resume. If
you give an example of where you used JDBC then I'd trust you.

You'd never see my resume, it'd be eliminated before any human ever
took one glance, even before the e-mail server passed it to anyone
human, if it didn't have all the right buzzwords in it.

How do I describe, via buzzwords, that I used JDBC to query a set of
linked tables that represented a tree structure, to allow the user to
select components for building a custom PC system or select some
appropriate standard system given choice of some individual components?
That I used JDBC to set up and maintain and query a set of linked
tables that represent a message system for taxicab dispatchers?

It would be during the interview that I would expect the details.

What happens at the interview is the least of my worries at this point.
I haven't had an actual interview (except for library page, in 1999,
which had 200 applicants for two positions) since mid-1994.

What have you done recently?

I set up a whole fucking set of Web pages to detail what I've been
doing the past several years, to answer exactly that question, after
several others asked it just as you did now. Didn't you take even one
glance at it?
Linkname: My recent specific accomplishments
URL: http://www.rawbw.com/~rem/WAP/SeekJobAccom.html
Yeah, it lists a very large number of accomplishments, because I've
been very busy, accomplishing a lot in recent years. Next time, RTFM
before asking a stupid question already answered.

I did some really impressive things int he 80s. I don't list them on
my resume because companies only care when the last time you did
something impressive.

How many impressive things did you do *after* the 1980s? From your
wording above it sounds like you've done only one impressive thing
since the 1980s, but I want to check if that was correct.

I've done lots of impressive things since the 1980s. Should I list only
the very last one of them, because that's the only one (1) that
companies care about?

the purpose of writing a resume is to get an interview.

I agree. My 1991 resume, which everyone hates, got me an interview for
CAD Lisp, data compression, data encryption, and information
classification. All of those were from direct ads, none via agencies.
My more recent resumes haven't gotten me even one interview since 1994.
I don't understand it, except if companies have totally stopped posting
direct ads, now posting only through agencies, and the agencies have
not been showing my resume to the employer. I don't know any way to get
my resume seen by an actual employer with an appropriate opening now.

The first few resumes will crash and burn. Learn from your mistakes.
Talk to the people who rejected it.

Everyone rejected it. I don't know how to talk to any of them, because
I don't know who any of them are. Just I see a job ad, send my resume
to the e-mail address or FAX number in the ad, and have no idea who
actually attends that address which is for resumes only, hence no way
to contact the person informally to ask a question.

Talk to people who hire but are not currently looking.

How would you propose that I meet such people?
In the absense of a newsgroup thread already started, what would I say
to a total stranger like that?

 

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

From: (e-mail address removed)

I have heard varying opinions on whether one should put something on
their resume that indicates their age, such as the year they graduated
from college.

I've decided to go with this advice:
http://www.quintcareers.com/resume_mistakes.html
don't provide the date of your college graduation if it was more than
about 10 years ago.

In some interviews I've had, questions were asked about things I'd
done in the 1980s that were pertinent to the work the company was
currently doing. In other interviews, no one cared about anything
that I'd done prior to the early 1990s. I think it behooves someone
to put things on their resume that are pertinent to the work the
company is doing, even if the work was done more than five or so
years ago.

There are two different issues here: Writing a single general resume to
post on a Web site, where you don't know who might look at it, and
writing a custom resume for just one individual job. Your advice
applies only to the latter, whereas the former is the topic we're
discussing here.

Here's a quote from a resume-advice Web site:
The rule of thumb for someone at the senior level is to list about 15
years worth of jobs.
I'm not sure how to apply that in my case.

 

[Andrew Thompson]

I've decided to go with this advice:

Robert, these groups are not your personal resume service.
Cease posting off-topic crap about you.

 

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

Up until the mid 70s, you could only count on one compile/run a day
per project.

Speak for yourself! As early as 1964 I was able to get more than one
compile/run per day, and often I would stay in the computer room late
at night to have the computer all to myself for hours. One night I was
there almost all night. When I got back to my car to drive home, and
turned on the car radio, all the radio stations were covering the
Crescent City tsunami from the Alaska earthquake, so you know one such
night down to the exact date!

Starting in 1970 I could get several compile/runs per hour on the PDP-10.

today's programs are so big, there is no way you could exhaustively
watch them over every code path.

But you can protect every module from bad data coming in, and from bugs
that cause bad data going out, and from bugs that cause syntactically
bad intermediate results, merely by having asserts at those point. (Of
course a bug that produces syntactically valid but inappropriate output
can't be detected by that means.)

Because finding and fixing bugs is so easy, we tend to be more
careless about writing code in the first place.

Speak for yourself! I'm not like that. I try to get each line of code
working correctly before moving to the next, and each function working
in all reasonable cases before starting work on the next function.

Dr. Kennedy, the head of our computer science department bragged that
he had never had a compile error. He was a fanatical desk checker.

Too bad he didn't know about Lisp, whereby he could replace a lot of
that desk checking with live testing, which is much faster and more
complete in some ways, leaving the desk checking only for those few
cases where it's better than live testing.

 

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

You can only write tests before the code if you are very familiar
with what you want and have thought about it for hours/days/weeks.

I disagree with most of that.

When unit-testing single lines of code, the test consists of two parts,
the data going in, and the data going out. The data going in is already
there before I write that one line of code to deal with it. The data
going out is immediately checked by eye upon executing that one line of
code. No hours/days/weeks of prior thought are necessary to perform
that single-line unit test.

When unit-testing single functions, the input part is already there
before even the first line of code is written, which is long before the
function is put together. The output part is already there immediately
after the last line of code is tested, which is immediately before
putting the function together. That's for the first unit-test for that
function. Other unit tests are then constructed immediately after
running the first unit test. The whole bunch of them are finished a few
minutes after the function is put together. No hours/days/weeks of
prior thought are necessary to set up and perform those single-function
unit tests.

In the process of making the solution of a very tedious problem clear
to me, i can do a *lot* of throwing away of code and refactoring for
weeks at a time. The amount of extra churn from rewriting unit tests
would be hopeless.

I don't see it that way. I test just about every single line of code,
and every function, regardless of whether it's a brand-new function or
a refactoring of something. Unit testing is no burden, it's how I make
sure my code works before I move to writing the next part of my code.

Write code that works, then write unit tests to make sure it
keeps working.

So you don't test your code until after you're sure it's working?
How can you be sure it works when you havne't yet tested it??

 

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

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.

I disagree 99%. What I do most of the time is write one line of code,
then execute it to see if it did what I wanted it to. If it did, I
write the next line of code, which depends on the (already seen to be
correct) result from the first line of code, then I execute it to see
if it also did what I wanted it to. Repeat as many lines of code as
needed to finish the function these line will go into. By the time I am
ready to wrap a function declaration form around them, every line of
code works for that first test case, so I know for sure they are
connected properly, and testing additional boundary cases would then
make sure any decisions within my code, or any boundary cases of the
individual statements, are correct.

So what you do is write one line of code, then without checking whether
it works at all you go ahead to write another line that depends on it,
then another, then another, then another, etc., until you have enough a
complete function definition, at which point you wrap a function
definition form around the code and perform the very first test of all
that code as a whole unit, and if you have a bug you have to guess
which of those several lines of code, or which dependency between two
adjacent lines of code, might be the problem?? That sounds stupid
compared to how I do it.

I say 99% disagree, because once in a while I need to write a function
where every line of code is so trivial that I can write the whole bunch
of code faster than I can test each part individually. This hardly ever
happens with inline code. Usually it happens only with mapping
functions, whereby I treat the whole mapping operation as if it were a
single line of code. If the entire function has just that one "line" of
code, I might write the function wrapper immediately after the inner
code, and test the whole one-line-of-code function as a unit. But more
often the one "line" of code including the mapping call is not the
whole function, so I indeed test that "line" of code individually, and
other lines of code before/after it likewise, and only write the
function definition wrapper after all the lines of code are tested.

Here's an example of a mapping operation which is sufficiently complex
that I probably tested the innerds individually before putting the
pieces together into the mapc form:
(mapc
(function (lambda (ip)
(let ((ix (position ip iptable :test (function ipinrange))))
(cond (ix (cond (verbose (format t " ~D " ix))) (push ip revmatch))
(t (cond (verbose (format t " x "))) (push ip revmiss))
))
))
ip3nums)
This was written several years ago so I can't remember exactly how I
did it at the time, I'm just expressing what I probably would have done.

By comparison, here's an example where I probably wrote and tested the
entire function at one time (after the key function it calls had
already been fully unit-tested):
(defun one-nicid-find-eadrs (nicid res2)
(mapcan (function (lambda (rec2)
(one-nicid-one-rec2-maybe-eadr nicid rec2)))
res2))

It may be extremely difficult or quite impossible to figure out what
would happen if a particular line of code is wrong or missing.

That's a "red herring". If there is a setup followed by three lines of code:
;TestRig: (setq x0 '(sometestdata))
(setq x1 (dosomething x0)) ;first loc
(setq x2 (dosomethingelse x1)) ;middle "
(setq x3 (dosomethingdifferent x2)) ;last "
then it's obvious what happens if the middle line of code is missing:
The last line of code will encounter an unbound variable and signal
that error. How is that difficult or impossible to figure out?? If the
middle line of code is wrong because it can't accept the kind of data
in x1, then it'll signal an error when it's tested. If the middle line
of code is wrong because it produces wrong output, and you don't notice
it's wrong when testing it, surely when you run the last line of code
it'll signal an error or produce obviously wrong output. If no errors
are signalled, then you pay special attention to the final output from
the very last line of code intended to be in your function, and you'll
notice any bugs up to that point, and then looking back at the
intermediate results you can figure out where you went wrong. There's
no need to figure out, in advance, what would happen if a particular
line of code is wrong. You just try it and it's blatantly obvious
either immediately or very shortly that it was wrong.

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.

Line-by-line unit testing is done only during initial coding of each
new function, or when making a drastic refactoring that requires you to
check the function all over again from scratch. There's nothing
unwieldy about executing each line of code individually, assuming
you're using any decent live-interactive programming environment such
as Lisp read-eval-print or Java BeanShell.

On the other hand, assertions can be left in the code permanently, and
they aren't unwieldy in any case, regardless of programming
environment.

I didn't agree with this "line by line proof" approach in 1981 when
Gries proposed it in "The Science of Programming" and I don't agree
with it now. YMMV.

I haven't seen the writing by Gries. Is a summary online?
Google search gets:
http://www.springeronline.com/sgw/cda/frontpage/0,10735,4-40109-22-1332860-0,00.html
This is the very first book to discuss the theory and principles of
computer programming on the basis of the idea that a proof of
correctness and a program should be developed hand in hand. ...
Propositions
and predicate calculus are presented as a took [sic] for the programmer,
rather than simply an object of study.
This is something very different from line by line testing. Constructing
a formal proof of correctness it nothing at all like simply testing a
piece of code under a variety of typical situations, both valid and
invalid, to get a pretty good idea that indeed it's all working
correctly, producing good results with good data, and signalling a
clearly worded explanatory error if given bad data.

I use [sic] to do image processing in which the processing was a dependent
chain of fuzzy logic. All the possible answers were wrong in some
absolute sense - and the object was to find the answer that was least
wrong. If I missed a minor step or had a bug in a calculation
somewhere, the chances are I wouldn't be able to tell by looking at
the intermediate results.

It might be interesting to revisit that code, refactoring it to clearly
use a bottom-up tool-building design, whereby you can map the tiny
tools across contrived synthesized images, starting with clean
geometric images, then noisy geometric images, then clean fractally
generated landscapes, and finally noisy fractally generated landscapes,
to test whether they produce the expected outputs as inherent in the
synthesizer input. Also, natural images can be fed through the image
processing to create an abstract model, then that abstract model can be
fed back into the synthesizer to see if that synthetic image when
re-processed produces the same model gotten the first time around.

 

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

Its quite hard and maybe impossible to write unit tests for some
(new) things; OS bootloaders, device drivers, interrupt handlers, etc.

In some such cases I'd recommend putting the absolute minimum amount of
code into the device driver or interrupt handler itself, putting all
the complicated stuff in an application that invokes the low-level
driver directly. Things may run slowly that way, but it's relatively
easy to debug. Later when you get confidence that your application code
(emulating higher functions of device driver) is solid, you can try
miagrating it into the driver.

Unit tests are great, but they also have their limits.

I agree. I do application programming, where line-by-line and
each-function unit testing works great 99% of the time. That's the kind
of programming where I strongly recommend that method of program
development. In the case of tools used locally, exactly that method
(which I've described in more detail elsewhere, and which I teach to
absolute beginners) works all the way up to the very top level. In the
case of tools used via CGI applications, nearly all the tools can be
developed in a read-eval-print (Lisp or java/BeanShell), all but the
very toplevel application. That latter requires a slightly different
interaction:
- REP: Get test input, code&execute first line of code, use that
already existing data to execute second line of code, etc.
- CGI-toplevel: Write test rig to get test input, and print it, and
load WebPage to execute it. Add first line of code, and print
statement, re-load WebPage, which re-executes the get-test-input and
runs the first line of code for first time. Add second line of code,
and print statement, re-load WebPage, which re-executes get-test-input
and first-line and runs second line of code for the first time. Etc.
keep adding more lines of code and re-loading to re-do everything old
and first-time-do everything new. Since the test input usually comes
from a HTML FORM, it's trivial to test other input merely by changing
the contents of the form and re-submitting it. One nice thing about the
Web is that it's easy to jump to the end of the output, so you don't
have to worry about too much print statement output before the final
result, and if there's a problem you can then scroll back easily to see
the earlier print outputs.

(Remarks about CGI apply equally to JSP, PHP, etc., but not to Java
HttpServlets where you have to compile and install each new version
before you can run it, but even then the modular nature of Java and
automatic compile-only-what-changed and dynamic runtime loader makes it
not too horribly painful if you can compile directly to the runtime
directory and thereby avoid needing to run deploytool each time.)

 

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

I don't believe that unit testing eliminates debugging.

But would accept that comprehensive unit testing, to make sure every
tool does its job correctly before it's called from a higher-up tool,
reduces the needed amount of whole-system debugging by one or two
orders of magnitude?

We had a bug where an update to our library disabled some features of a
client program. After some investigating, it was determined that the
client program was doing this:
if (library_version == 3)
instead of this:
if (library_version >= 3)

It's obvious to me that the client program was never unit tested
properly. Since there was a line of code that checkd the library
version, there should have been a unit test whereby different library
versions were supplied by a test rig and the client program was checked
to make sure it performed correctly in all such cases. Testing boundary
cases would have sufficed for this line of code.

Our fix for this bug was to detect the client and report 3 for the
version if the client was the offending program, and otherwise report
the true version.

Given that the client program had a bug, it made more sense to fix that
bug rather than accomodate it by introducing a matching bug in another
module. What happens, per your "our fix", if somebody later adds new
code to the client to deal specially with library version 4, and that
code doesn't work, because the library is reporting 3 instead of 4?
Imagine how long it'll take to track down that bug, then it can't be
fixed without re-breaking the version 3 bug? The best immediate fix is
to document client as having a bug that makes it not work with any
version beyond 3, and roll back the library to version 3 on any system
used by that client until such time as somebody can fix the client,
meanwhile on any system with properly working clients they get a full
working version 4 of the library.

This is the sort of bug that gets caught in integration testing.

Only because complete unit testing of the client never occurred. With a
TDD-style of testing, although not necessary actual TDD (development),
each such line of code that tests a condition would be deliberately
disabled in various ways, and tests would be set up to signal
malfunctions whenever any line of code other than the correct one is in
that position. Perhaps having a contest between two teams would make
this practical: One team designs tests to signal malfunction whenever
the line of code is wrong. Other team contrives bogus lines of code to
try to fool the test. Rule is you can't make a super-complicated
perverse line of code such as:
if ((library_version == 3) || (library_version == 4) || (library_version > 7))
which would pass all boundary tests for versions 1,2,3,4, and also pass
far-beyond test such as 100, but fail at untested 5 or 6. The bogus
lines of code have to be approximately the same complexity as the
correct line of code. So the predicate could be == != > >= < <= or any
other test of a similar nature that might be in the programming
language, as well as stupid mistakes such as = or +=, and the constant
value can be any integer, and the variable name might be wrong. At some
point two different lines of code would be recognized as correct (with
< or <= for different adjacent constants), and a policy decision would
have to be made to reject one of the two in favor of the other, then
the game could continue with that restriction on the
bogus-loc-generator team until the tests are sufficient to make the
bogus-loc-generator team resign the game. However very early in the
game/contest the bogus line of code actually in the program would have
been signalled as malfunctionning by the test for version 4. (I admit
the test rig for this game, whereby various features are attempted and
a malfunction is signalled if some supposedly available feature turns
out not to be available, is a bit complex. But maybe the first team
would enjoy such a challenge?)

I can't think of any way that unit testing would have helped this
situation. I'd be very interested in hearing how this sort of bug
would be approached in the test-first "no debugging" philosophy.

Have my ideas about need to fully unit-test the client, and the
contest, helped you think of a way that unit testing the client could
have helped? I'm not saying that unit testing is guaranteed to help in
this case, because unit testing isn't perfect, and could possibly
overlook this particular case. I'm just saying that unit testing would
have a good chance of having found this bug already, and the better
quality the unit testing is the lower the chance of the bug slipping
through undetected. Like I said at the top: I don't claim unit testing
eliminates *all* bugs, merely that it eliminates 90-99% of potential
bugs already, depending on the quality/exhaustiveness of unit testing,
leaving just those very few remaining bugs to occur later.

 

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

From: (e-mail address removed) (".")

I, personally, write my resume so the company knows who I am

That phrase makes no sense to me. Who you are is you, exactly you, and
nothing else except you. To say that you are somebody other than
yourself is nonsense. It makes no sense to tell somebody who you are
because you are you and they already know you are you.

and what I can do for them.

This part makes more sense. Part of what you can do is just generally
the sorts of things you can do for anyone. Part of what you can do is
more specifically what you can do for that one company that would be
impossible to do for any other company, such as add features to a
product only this one company makes. Do I seem to understand that you
are referring to?

If they list requirements I will make it INCREDIBLY easy for them to
see that I meet or exceed their requirements. If the company uses
someone who just scans the resume for keywords then most likely they
are scanning the resume for keywords relating to the requirements for
the position.

You are obviously talking about writing custom resumes, a different
resume for each job you see advertised such that you respond to it. It
has been recommended that I apply for ten jobs per day, despite the
fact that I haven't seen even one job I qualify for in the past ten
years, and it takes a full workday of scanning job sites such as
CraigsList just to find one or two jobs where I only half qualify.

It takes weeks or months to compose a brand new resume from scratch
without any base resume as a starting point. At present I have a half
dozen general resumes and a half dozen specific-area resumes, any one
of which might serve as a starting point for editing to yield a custom
resume for a single job ad. Unfortunately general concensus is that
every last one of my existing resumes is total crap and not suitable
for using as a base for any custom resume. I don't believe adding a
bunch of custom keywords to a crap resume would get me an interview, do
you?

For example, if you apply for a job at IBM they have you do an online
application. The application will quiz you on your skill set and level of
experience. You will notice that all the technologies they quiz you about
are also listed in the job ad requirements.

IBM actively discriminates against disabled people such as myself in
their advertising of jobs available, so I'd just as soon not discuss
them any further here.

If the company is not going to put forth the effort to know assembler
and assembly-language are the same thing then why would I want to work
for them. I'm willing to put a great deal of effort into applying for a
job but I expect the employer to put some effort into it as well.

I'm desperate for a job. If it's a company such as IBM that makes it
impossible for disabled people to even see their job ads, then I
dismiss them as fucking shitheads who deserve to be bombed by the
military by "friendly fire" or boycotted by all organizations that help
disabled people or all their employee's cars being attacked with 2-by-4
sticks of wood to break windows and dent bodies by vigilantees who are
fed up with their anti-disabled-people attitude. But if the company's
only problem is that they didn't happen to think of all the synomyms
when configuring their resume-filtering software, I'd be glad to
include both synonyms just to make sure their little oversight doesn't
deprive me of a job. I would consider their Web being accessible to
disabled people, so we can at least see their job ads, to be sufficient
effort by the employer.

 

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

for development (i.e. not to be sold) purposes, you can get a free
copy of Oracle. The 10g version for Linux is quite nice.

This is the first I've ever heard of such. All the information I got
previously was that Oracle is the high-end commercial RDBS that hardly
anybody can afford and so there's no way they'd give it away for free.
If I ever can get the modem on my laptop working again, I might see
about downloading the free Oracle. Thanks for the clue, even though I
can't make any use of it at present.

Is there a free version that works on FreeBSD Unix?
If the whole things occupies less than ten megabytes, I could install
it on my personal shell account.

 

[Duane Bozarth]

....

It's obvious to me that the client program was never unit tested
properly. Since there was a line of code that checkd the library
version, there should have been a unit test whereby different library
versions were supplied by a test rig and the client program was checked
to make sure it performed correctly in all such cases. Testing boundary
cases would have sufficed for this line of code.

Except for the fact that at the point in time there was probably not
another libarary of the type to do the test...that is an oversight in
the design/specification stage, and more than likely would not have
reported an error on a test suite.

Unit testing won't uncover logic flaws in the design or even in the
testing scope/design.

Given that the client program had a bug, it made more sense to fix that
bug rather than accomodate it ...

Only because complete unit testing of the client never occurred. ...

No, because the client wasn't part of the unit under test...

 

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

Actually, these are far more interesting than a resume filled with
buzzwords, at least for me.

But if you were trying to fill a job at your company, you'd never see
my interesting resume, because you'd be required to file your job
opening with HR, which would hire an outside agency to screen tens of
thousands of resumes down to just ten or twenty, and my resume wouldn't
have the right buzzwords so it'd never get from agency to HR much less
to you personally.

These are too detailed to be in resume,
but you may be able to make a link from each item under
'MAJOR PROGRAMMING PROJECTS' in your online resume to a document
that fully explains what you did.

Ay, there's the rub! The agency wouldn't see any of those links, and if
the Sahara froze over and the agency passed my resume to HR it wouldn't
see links either, and you upon getting the printed resume from HR
wouldn't see them either. Should I list somewhere in the printed resume
where the online version with links is located (URL)? Should I put
square brackets around all the terms in the printed resume which
corresponding to HREFs in the online resume, so the person seeing the
printed resume would know whether the term he/she is interested in has
a link, hence whether it'd be worth the effort to look at the online
version?

I'm also thinking that the printed and online resume should look
exactly the same, as much as is possible knowing that the prited resume
is in one format whereas the online resume looks slightly different
depending on which browser was used. This is so that somebody who has
already gotten the printed resume, and marked all the places where
he/she wants to see the extra info, can then go online and see almost
exactly the same layout on-screen and therefore have no trouble finding
those same links and clicking on them. Agree? So maybe what I should do
is make a HTML resume, and then use lynx's print command to make a text
file containing what is on-screen (whole page, not just 20-line window
thereof), and then that lynx-printed image would be the printed resume
I send to people offline. (And of course I wouldn't have to maintain
two separate resumes, just one HTML and then re-do the lynx-print any
time I need to make the printed resume match the online resume.)

The main problem with that idea is that when I'm not online and I want
to edit my resume, currently I just go to my Mac and open the resume
file and edit locally, but under the new method I would have no way to
view the resume I've edited locally except to upload to my unix shell
account and then run lynx to view just one screen of it at a time, then
lynx-print then download back to my Mac to see the whole of my resume
with what I had changed, royal hassle just to make a tiny change!!

Being an all-around player actually put you in a difficult position.
Job market is not for such person. It may seem unreasonable that,
if one candidate can do everything so well, and another can do
just one thing so-so, and the company tends to hire the latter
when the one thing fits the job description.

What do you think of "playing dumb" on each customized resume, by
filling more than half the resume with just those particular things I
did specifically related to the current job ad, and condensing
everything else to an afterthought of no apparent significance? Or more
drastic: deleting *all* experience not closely related to the job,
flushing *all* my major accomplishments or anything else impressive,
because it's counter-productive when applying for any specific job in a
different area?

Jobs that require high skills are often filled by personal
referrals.

Nobody has offered me any such referrals since I got laid off from
Stanford. Previously, somebody I was working for at Stanford would hear
of another department that could use me as soon as the current project
was over, or the same department would tell me about a new project in
the same department that could overlap slightly with the tail end of my
current project. But when Stanford ran out of any money to hire me any
more, and the place I used to work was closed down due to founder
retiring, there was nobody remaining to tell me about any jobs and no
money for any such jobs in the first place.

So how does such an enemployed person ever hope to get back into that
personal-referral game??

I have been asked to find a good Lisp programmer, or even I myself
have looked for one to subcontract my own project.

If this occurred any time since mid-1992, why didn't you find me??
Have you been blind to the several times I posted my Lisp resume online
or mentionned that I had 10+ years Lisp experience and was looking for
employment doing same but now for industry instead of university?

http://groups.google.com/group/comp.lang.lisp/msg/623610bb8dd35943
Message-ID: <[email protected]> (1992.Jun, asking about industry Lisp job)

http://groups.google.com/group/ba.jobs.misc/msg/924ff4f7ff612059
Message-ID: <[email protected]> (1992.Oct, discussion mentions lisp resume)

http://groups.google.com/group/ba.jobs.resumes/msg/b251811c5fd5c948
Message-ID: <[email protected]>#1/1 (1998, general resume mentions lisp)

http://groups.google.com/group/misc.jobs.resumes/msg/0d1bcbe92ff280fa
Message-ID: <[email protected]> (1999, Lisp-specific resume)

http://groups.google.com/group/comp.lang.lisp/msg/662ae71b1e28748d
Message-ID: <[email protected]> (1999, Lisp-specific resume)

http://groups.google.com/group/comp.lang.lisp/msg/a25c5d5ca184628b
Message-ID: <[email protected]> (2003, Lisp-specific resume)

 

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

once you got many years of experience, you're expected to have enough
personal connections.

How is that possible? When I had a job, I was paid to write software,
not to socialize with co-workers thereby distracting them from the
work they were trying to do.

If you haven't got them, probably you should start from making
them...

That sounds like nice advice, but I have no idea how to succeed at
that. I've been trying to make contacts ever since I became unemployed
in 1991, but as far as I know I haven't acquired even one useful
contact yet. People in the same threads as me on newsgroups haven't
shown any interest in beocming my personal connections. People in
real-life have no common interests with me and have no interest in
arranging to see me again because they already have their own friends
with common interests and don't need somebody with no common interests
with them. Even the people in the computer-programming classes I was
taking 2003-05 already had enough friends and didn't need anybody new.

Why don't you join this forum:
http://groups.yahoo.com/group/helprobertmaasfindemployment/
and coach me toward obtaining personal connections?

 

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

The DiffAlg was only an abstract??

Only the abstract was published. The main paper was nicely printed but
not accepted by any publisher because of only about ten people in the
world who would be interested in details of such a specific result.

You could create or participate in an open-source project and mention that.

I already did that. Nobody cares.

Then mention some practical key examples that are appropriate to the job
you're applying to.

That's not possible in a single general-purpose resume that I post on
the net for everyone to see. In fact in customized resumes for single
jobs I already do what you suggest, and it doesn't get me any contact
back from the employer/agency that posted the ad. I suspect that the
customized resume is no good because it's based on the general resume
which you and everyone says is complete crap (except for Jennie and
Elizabeth at FFW who helped me work on the 2003 edit to the 1998 resume
and believe their handiwork is just perfect, and Blanche at DeAnza who
converted the format to MS-Word without making any major changes to the
information). I've gotten advice how to improve the latest general
resume, but the advice is contradictory, both to itself and to really
good advice on Web sites and from other good-advice sources.

If your unpaid work resulted in anything useful (that interests the
$COMPANY), just mention it.

I already do that in the case of customized resumes (see earlier above).

We know what you said they are. But we don't see lots of cool
applications that could have been written in that time.

A lot of my work was research, rather than practical applications, such
as my work on mathematical and board games, and fractals and base&digit
systems, and the paid work on English language interface for
instructable robot where I invented some new methods that might be
useful someday but the software I wrote up to the end of funding wasn't
itself of any immediate practical use, and my symbolic algebra package
for differential algebra.

A lot of my work was R&D, where I had to do a lot of trying different
approaches before I found the right way to do it. For example, for my
spam-reporting software I tried ad hoc semi-parsers, but then I
discovered cases where they produced the wrong IP number, a number
forged by the spammer rather than supplied by the SMTP server from the
TCP/IP source. At that point I decided I absolutely had to start from
scratch writing a true parser, only to discover that there were more
than a hundred different formats of Received lines in headers, causing
my work on the parser to take several weeks, but finally I had it fully
working and could replace the old semi-parser with the new genuine
parser and resume running the main program.

Did you actually look at the list of my major accomplishments which I
posted? Here's a quick one-[compound]-word-per-accomplishments
checklist for you to consider: SegMat, languagerecognizer,
flashcardsequencer, XGP, mathprint, calculusderivations, directories,
pcnet, compression, linrel, MaasInfo, SeekJobIndex, lineaments,
sourcesyntax, treeinfo, imageprocess, NMR, payroll, preregistration,
filecopy, cobolfixes, differentialalgebra. If that list doesn't look
familiar, then I presume you didn't even bother to read that list of
accomplishments before complaining that you don't see enough
accomplishments to represent 22 years of programming work. If that's
the case, you need to go back and look at where I posted a link to that
list of accomplishments which has been online for years sitting there
waiting for you to see it even before I posted the link again:
http://groups.google.com/group/comp.programming/msg/5aba4006df4e0f70
Message-ID: <[email protected]>
In any case, obviously some of those accomplishments aren't software
applications themselves, but most are, and the few that are something
else involved software work to make them possible. Also those (by
coincidence 22) accomplishments are just the major highlights of my 22
years of software work. So do you consider 22 major accomplishments,
each worth listing individually, and hundreds of lesser accomplishments
not listed there, would ordinarily be achieved by average programmers
in much less than 22 years of effort, so that you are justifieid in
basically calling me a liar to claim 22 years experience with such a
small amount of major accomplishments (appx. one per year)?

The message you wrote, basically calling me a liar, was written five
days after I posted that link to my list of accomplishments, which has
been sitting there ever since early 2001, more than five years ago, so
you had plenty of time to look at it. So I expect you to go through my
checklist and tell me which of those items refer to software you would
admit are "cool applications", which are not software applications at
all so they aren't to be considered here, and which are software
applications but you don't consider them "cool" so you need to explain
what's un-cool about each of them. Hint: One is not software, it's
math. One is not a software application, it's just data. One is not an
application, it's a callable utility package. Two aren't complete
programs, they're just fixes I made to somebody else's programs. One is
not a useful appliation, it's just a demo of a software technique I was
researching that turned out to have surprizingly good results. The
remaining sixteen (16) are useful software applications, and I expect
you to tell me which of those are not "cool" in your opinion, to
attempt to justify you basically accusing me of lying about my 22 years
software programming experience.

Also, you said "... we don't see ..." when you call me a liar, so
please tell me who else you're speaking for there. I would like that
other person to likewise state which of my 16 major practical software
application accomplishments are not "cool" in that person's opinion. If
you were speaking only for yourself, you owe me an apology for posting
a public message basically saying the you and other people all consider
me to be lying about my 22 years software experience. If you were in
fact speaking for more than just yourself, you owe me the name of the
other person you speak for who is with you calling me a liar.

 

[Andrew Thompson]

Re: Ulrich owes me an explanation (was: Resume questions, how convey?)

Just a note to clarify that Ulrich, like everbody else *here*,
as well as aahh.. yes,..

Newsgroups: comp.programming,comp.lang.java.programmer,comp.lang.lisp

c.p. and c.l.l.

Owes you exactly *nothing*!

Further, you are abusing these groups to chase your own personal
agenda and it is OFF-TOPIC for these groups.

Follow-Ups directed to alt.kook, which probably does not exist,
but should.

P*SS OFF!

 

[Andrew Thompson]

And another bloody one.. P*ss off, Robert.

 

[Guest]

Is there a free version that works on FreeBSD Unix?

There is a Linux version.

If the whole things occupies less than ten megabytes,

Around one gigabyte of space, from memory.
( It has been a few years since I used the free version )

I could install
it on my personal shell account.

Unlikely.
I think that you would need superuser access to install it.

--

Seek simplicity and mistrust it.
Alfred Whitehead

A witty saying proves nothing.
Voltaire