'standard' NDA

• Good thing that you can ignore SOX.

Small claims courts in the US have basically no ability to enforce judgments when the client is out of state. Nobody is going out across state lines to arrest them if they just ignore a summons entirely, or repo their assets to pay off a summary judgment for being a no-show.

About the "best" that might happen is a blip shows up sometime down the road when the company or client tries to get credit that they have a bench warrant attached to them. but spending time and paying money out of my pocket for "revenge" unwitnessed is a lousy use of my money and time IMO.

I think the up-front fee for NDA-processing is a better idea I will consider.

• Small claims court is cheap and covers that. Maybe include a covering statement, and if possible an up-front NDA fee to cover E&O insurance.

Ya, doing a project for a new client who's sort of an unknown without setting regular milestones is bad idea.

Posting bids somewhat higher than the ask doesn't hurt much either. It encourages the non-serious to bail.

The only "investor" I have to please at the moment is myself and it would please me if flakes and scam-artists just went away forever ASAP, they can keep their money.

• Small claims courts usually are good to K; if you anticipate problems like that, try breaking the project into logical sub-sections and make those desperate contract projects. Also look into E&O insurance that THEY pay for, proceeds to you when they mess up.

My favorite customers don't have in-house electronic design teams. A lot of aerospace outfits used to design their own stuff, but when the guys retired they didn't replace them.

If we do compete against an in-house team, we usually use. They have management's ear, and they can make extravagent claims about how cheap stuff will be to make.

Nobody teaches control theory in college any more? I guess the software guys don't learn things like that. I'm not sure what they do learn.

I just had to explain to a guy at a biggish aircraft outfit how synchros and resolvers and LVDTs work. He had no idea.

Econ courses present a classic sales-vs-price curve. In reality, there is a long tail on the high end. If you double your price, some people will still go for it. May as well.

software engineering and electrical engineering have diverged very far over time to the point that outside a basic circuits class some students take. They're both extremely broad disciplines there's hardly time to even touch on all the fundamentals of just modern "computer science" (well, at the undergraduate level this means programming, not what the term computer science means at the graduate/research level) much less go into control theory.

Back end web developers and game-algorithm writers don't encounter things like heaters and motors much in their day to day work, but sometimes the day comes when they try to write something like: if (measurementTooLow) { ++controlVar; } else if {measurementTooHigh) {

--controlVar; } and become curious why their state variable never seems to end up where they want it to be despite this code being pretty elegant and self-documenting.

making "affordable" products is sometimes a thankless job, put a $5 monochrome LCD display in a product costing $250 and reviewers may gripe about the display, put the same screen in a $2500 product and reviewers may say "wow! it even has a display!"

Or at the most mention the cheapness of the display but qualify it with "at this price point buyers are true connoisseurs who understand the limitations"

Hence why BMW still exists

And Maserati, and Cadillac, and...

Thanks John, Ughh that's a lot of legal-ease. I think statement 3 is the only one I need, stuff in the public domain can not be confidential. Since most of my circuits come from AoE, spec sheets, app notes or circuit's shown on SED, it's all public.

I'm working on a response, it includes a summary of my long and rather sordid history with my ex-boss. Maybe sharing it is not a good idea? But I'd like my colleagues and co-workers to know I'm not a complete a-hole.

I was reading about Henry Briggs, the guy to make the first logarithm tables.

The last line about probity struck me.

George H.

they

Not in my experience--I sometimes get sent ones like that, and if they insi st on it, I walk. (I've had to walk as many as three times in an ultimately

-successful negotiation.)

I do a lot of NDAs, and it's onerous having to remember who owns what chunk of my brain.

Cheers

Phil Hobbs

They should teach EE students the fundamentals, as always. Physics, electromagnetics, circuit theory, EDA (engineering unit concepts), signals+systems, control theory. Without that background, anything more "advanced" is useless.

I have no idea what software engineering is. I should buy a textbook. I did buy a sociology textbook; it was hilarious.

Can anybody recommend a good (or at least popular) undergrad intro textbook in software engineering?

I asked the dean of a big CS depertment what sort of programming they teach nowadays. She handed me my head. "We don't teach programming!"

Oh. Sorry.

We did a fan control loop like that recently. It just slews slowly up or down around the temperature setpoint. That avoids audible drama.

It doesn't have your second IF. Once a second, it jogs up or down a fixed amount.

You can buy a mechanical wristwatch for $60K. A $20 quartz watch works better.

Some restaurant near here discovered that the more they charged for a bottle of wine, the more people ordered it. They peaked out around $3K.

Thanks John.

For those who cannot read DOC files, here is a free DOC to HTML converter:

It's not unusual for some academics and aspiring ones to get miffed when asked pedestrian questions, like that time I made the mistake of asking a TA in a literature class working on a novella "what's it about?" HOW COULD YOU PRESUME ME TO SUMMARIZE MY _ART_?

I tend to think academics who can't negotiate pedestrian questions and smoothly re-direct, if she really feels saying they prefer to focus on the science aspect rather than the coding is something she needs to say, is a bad academic. Or at least an out-of-touch one.

I took some CS classes in the mid 1990s and at the time I do recall the professors liked sink-or-swimming students to dive into high-concept aspects of CS ASAP and were little interested in like, "coding" or the mechanics of actually writing understandable, repeatable code that worked properly. Or at least viewed this as a task to be farmed out to TAs who weren't much better.

In essence your success in a CS program of that type was predicated on you already being a good programmer before you came.