A quick DB query and the variance was substantial. A couple of people had over a hundred. About 10 had 2. For the year. The ramp up was slow, average was 8 to 10 a year.

Dig a little deeper. Those at the top were 'group leads' not only did they do IC work, they also got stuck with all 'paperwork' on the problem work packages. They had 'power', so they could override various things. So, they were doing a lot of work, and taking care of things. Good signal, matches what one would expect.

Those at the bottom. One of them had effectively been a 'systems engineer'; all of their time was working on requirements with the customer, making powerpoint, etc. Important work, so that signal was inverse of what it originally showed.

A couple were in the middle that had great reputations for technical expertise. They were spending almost full time in training / mentoring / very hard problems mode. Highly valuable, but not shown by looking at these numbers.

All the rest? 80% of the work was being done by 20% of the people. We could have dropped about 12 heads and barely noticed.

The problem is, you could not take action on this measure. It gave you a place to start, but you needed to know more about what was going on day to day.

(buy a VAX, get a library. oh, and a computer too.)

the 6 months after the first screen editor was installed was constant questions and answers bouncing across the room on how to do things.

Which has a good track record of being right, most of the time.

I agree!

very confusing that the computer thinks it knows what i want; when i can push the power button to turn it on, or /sbin/shutdown -h now when i want it off.

image a computer display made up of 1000 line segments. that is what you would get. it was possible to buy these with an output that was not raster, rather it drew on the CRT with vector segments. incredible light points to simulate night landings.

eventually, the company would call that a 'system design and mechanization report', which would document the math and equations needed to correctly simulate a small part of an aircraft.

note the marking "link division of general precision". the computer was made by General Precision, of which the Link aviation company was the biggest customer. i had always been told that Link purchased General Precision, but perhaps it was the other way around.

i worked in this industry for about 35 years. this stuff was ancient and forgotten about when I started.

you used to have a thing called preliminary design (i think is specified in 2167A).

with ada, you write all the specs. so, all of the packages procedures / functions and visible variables are declared.

Feed this to the compiler. Does it compile? If yes, then your design is complete.

Implement the bodies during detail design.

Late 1990's I was contacted via e-mail by someone that was looking for a JOVIAL manual. So, cool, I asked him which one? Hughes Aircraft? Boeing? Boeing J3B2?

in the 1980/1990's i was a dumb kid. problems of large systems were not in my mind. having to type begin/end instead of {} was, i thought, a valid complaint.

with experience, education, and hindsight, most of the advantages of the ada language were not understood by the masses. if ada came out today, it would have taken off just like rust.

not that it was their responsibility to provide a free compiler to the masses.

same is true today. the spec/body separation made for an actual delineation between design and implementation.

'performance stuff'. i try to solve it in C for a bunch of reasons; others readability is one. almost never need to do more than a short macro of assembly embedded in C.

the actual most use of have for assembly is "what is happening here.." and need to ask the debugger for the assembly for some deeper understanding.

Some years, did these things 5 times, so maybe 20 hours. Other years, never.

As far as "sit down and write some assembly to solve problem X", the answer is never. (except when X is right in the middle of the above items)

responsive. everything dealing with user interaction is fast. sure, reading a 1 MB document took time, but 'up 4 lines' was bam!.

linux ought to be this good, but the I/O subsystem slows down responsiveness. it should be possible to copy a file to a USB drive, and not impact good response from typing, but it is not. real time patches used to improve it.

windows has always been terrible.

what is my point? well, i think a web stack ran under an RTOS (and sized appropriately) might be a much more pleasurable experience. Get rid of all those lags, and intermittent hangs and calls for more GB of memory.

QNX is also a good example of an RTOS that can be used as a desktop. Although an example with a lot of political and business problems.

what we don't know is what is the blocker? it maybe that LM is running at 10% capacity, with a lot of material in stock. a purchase order shows up, and they start a night shift next week.

may or may not be a dire situation. unless, as you mentioned, we need them next month.

We don't know what the pacing item of the manufacturing is. It could be sub-assemblies from another company, raw materials, final assembly workers, facilities for final assembly, or a lack of capital to address these shortcomings.

Double the price you are willing to pay, and I bet the rate goes up a lot. You can build a new building in 6 months. In 90 days you can hire and train enough new workers for a third shift.

At the current demand, and the current sales price, and the current planned procurement's, that is all LM can make....

Until I spent some time in a country whose predominate language (and signage) was not english.

Maybe those pictorial signs are a good idea after all.

I am not saying he is crazy, or will always be so. But thinking that you have 'teleportation' skills directly implies you have some (brain) processing issues.

As an added benefit, enlisted air crew have no restrictions on mustache length or on professional wear of the uniform.