DigiComp I was a plastic, hand-cranked, 3-bit state machine, with some restrictions on the allowed state transitions.
You programmed it by pushing little plastic tubes on to little plastic tabs.
I had one when I was 9 or 10 years old.
I've been a hacker ever since.

I figured this out twenty-mumble years ago.
I was doing data analysis in spreadsheets, and realized that I had no way to audit them.
The data and the analysis were all just...there...in the spreadsheet.

As soon as I got a grip on my data, I changed over to C programs that I could test, and document, and validate, and run at any time to demonstrate that input X generated output Y.

I heard an interview with Torvalds where they asked him why there was no kernel ABI.
He explained that the reason people want ABIs is so they can link object code into the kernel w/o releasing the sources,
and then that code breaks, and he ends up having to debug kernels with incomplete sources.
And he doesn't want to do that.
So no kernel ABI.

I don't know that I'd call that arrogant. Selfish, maybe...

The good news is that because the Linux kernel has no ABIs,
the sources are all necessarily available,
which means that you can get the sources, and fork them, and add ABIs, and create a binary driver compatibility layer,
so that people can link in drivers w/o sources,
and then you'll be running a kernel with incomplete sources,
and then....ummm....wait....what was the good news again?

My reading speed moves up and down to maintain a constant information density.
In a low-density text, like, ummm, Slashdot comments, I skim.
In a medium-density text, like a novel, I read every word.
In a high-density text, like a math book, I *study* every word.

And it's not something that I have to think about either: it happens automatically.
My subjective experience is that I'm managing a tradeoff between boredom (too slow) and incomprehension (too fast).

I'm Pappy. I'm not dead, but my kids have been hearing me bitch about Microsoft as long as they can remember. At this point, they probably think of it like a fixture of the landscape: the old man doesn't like Microsoft.

So my oldest finally graduates college, and gets his first real job. He's an engineer; industrial controls. The vendors only write drivers for Windows, so everyone uses Windows, and no one cares. He's provisioning servers in plants, and doing Windows installs, and running VMs, and trying to automate things. And it's all done in Windows Power Shell.

After a few months, I start getting calls from him. He's astonished: "This thing really sucks!" he tells me. It kind of a broken, crippled, over-engineered, badly implemented shell. It's always in his way. Everything is a needless problem. He talks about what a relief it is to go home on weekends, and work on his own systems, in Linux, running bash, and being able to work on the actual problem, instead of spending all his time fighting with the system and the tools. And every time he calls, it's the same refrain with more exclamation points: "This thing really sucks!!!"

So, yeah, he learned it from me, but then he learned it for himself.

I've seen this assertion in two comments now.
How do local variables cause stack overflow?

If you aren't using recursion, then total stack space requirements can be computed from static code analysis.
If you are using recursion, then you can overflow the stack with return addresses alone.

BTW, I did read most of the expert testimony, and some of the expert report.
The suspect software is catastrophically bad.

http://world.std.com/~swmcd/st...

I threw a monkey wrench into the engine of my car, and it ran slower. Maybe if throw something different into it, it will run faster

They wouldn't let him board a flight from Boston to Washington, so he was stuck in Boston for a few days until someone removed his name. Then he flew to Washington.

I was very disappointed by this. I was hoping that he would stay camped out at Logan airport, and pledge not to fly until the government created a procedure for people who aren't United States senators to get their names off of the list.

If you are a contractor, and "there's plenty of jobs you can take", then you really don't have a problem here. Let's take it by cases.

1. You just don't want to deal with this app/code base/company/assignment
Then leave for one of those other jobs. That's part of what being a contractor is all about: being able to drop clients that you don't want to deal with.

You don't have to be rude or snarky about it. Give notice, complete whatever term or notice period is specified in your contract, and move on. If they ask why, tell them simply and honestly. Providing such information (if asked) is part of your service to them.

2. You are willing and able to do the work
Great! You've got a good gig, and from the sound of it, it could keep you in peanut butter and iPhones for a long time.

If the code base is a horrid mess--that's their problem, not yours.
If everything takes 2, or 5, or 10 times a long as it "should"--that's their problem, not yours.
If every time you fix a bug, the app breaks in two other places--that's their problem, not yours.

If they ask for schedules, give them your best estimates, based on what you know about the code base.
If they demand to know why everything takes so long, give them your best (diplomatic) explanation of the problems with the app. Speak only in terms of the code as it stands. The history of who wrote it and how it got that way is irrelevant.
If they decide you are incompetent and dismiss you, then you are back to case 1, above.
If they decide to cancel the whole project and terminate your contract, then you are back to case 1, above.

Part of what a company gets when they hire contractors is the ability to dump scut work on them (so that the "well respected" people don't have to do it), and the ability to dismiss them when circumstances change (w/o paying unemployment, etc.) If you're OK with that deal--the work, the scut, being low man on the totem pole, no job security--then give them the best 8 hours of your working day, cash their checks, and sleep soundly. The day you're not OK with it--the day you wake up thinking, "I *just* *can't* do this any more"--that's the day you give notice and move on.

Along about 3rd grade, most schools offer musical instruction for a semester or a year.
The kids come home one day carrying a flute or a trumpet or a drum kit,
and they go to band practice once or twice a week and learn to make some noise\b\b\b\b\bmusic.

Some have no interest and no aptitude and drop it pretty quickly.
Some have some interest and aptitude and stay with it until they find other interests.
Some go on to become musicians.

I'd offer programming instruction on the same basis.
But I'd put it off until age 12 to 14 (when the capacity for abstract thought develops).

Most of the code that I see exhibits what I can only describe as a kind of aggressive indifference.
It's not just that they don't care.
They *totally* don't care.
And they're going to make sure you know it.
And suffer for it.

After a while, dealing with this stuff is just depressing.
Especially if you do care.

Or maybe they both stood their ground.
Or something.

And this is what we want, right?
Half the country in the morgue, and the other half in prison, because, because...stand your ground!
Or something...

some kind of 6502 assembly code in the Terminator's red overlay

I knew a guy (Hi, Tom!) who identified the code as coming from the Apple ][ ROMs (which were 6502)
He said he recognized some of the code comments.

You already have your algorithm running in electronic hardware, right?
Your current gate count is the sum of
  * the gate count of your CPU
  * the gate count of your RAM
  * the gate count of your program ROM

So that's an upper bound on the gate count.
If that number is too big for your manufacturing partner,
then you have an optimization problem.

Optimization is a hard problem...