cool book

Bought :)

A friend came back with this:

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

It is. I got it a while back, after I heard the authors on the Amp Hour:

In electronics, beauty is seldom something that can be photographed.

RL

Waveform photos can be beautiful too.

I like to x-ray parts.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Even less so with software. Even if a descriptive representation was available, most folks aren't competent enough to realize elegance.

When your peers call you an "artist", take heed! :>

There's a big perceived difference between the "tradesman" ethos and the "craftman" ethos, gender-neutral here "tradespeople"and "craftspeople", there's a big perceived difference between those who clock-in to clock-out and those who clock-in to clock-in.

The usual notion of "intellectual property" is defined in terms of "prior art" and those "knowledgeable in the field".

Science: it's an art.

Thousands of lines of code, dominated by puncuation marks, will never have the instant beauty of a color photograph.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

I think it is more than "work ethic" and "skillset".

Hardware and mechanical designs are inherently visual. You can "see" the entire (?) design and its interrelationships.

Too many people think of software as a "serial enterprise": "this, then that and then something else". For them, it would be like trying to photograph a bird call.

If, instead, they approach it as a set of cooperating

Instead of just "a long list of instructions" whose relationships to each other are strictly linear/sequential.

I suspect (good) chefs don't see their preparations as lists of ingredients and steps (i.e., a "recipe") but, rather, as a collection of tastes, temperatures, textures, etc. By contrast, most folks who cook are just doing "this, then that and then something else"... as dictated by the recipe.

Next time someone describes a piece of music, meal, mechanism, hardware or software design, listen to HOW they present it as an indication of how they THINK about it. Can you *visualize* what they are describing?

Thanks for writing - something to think about.

The "holistic" view or "systems" view, that "process is, itself, a process", sort of like how it's so easy to automate tests and so hard to automate spec.

A couple pieces of thin wide sourdough with a thick slice of ham and a thin slice of tomato, a bit of Italian blue cheese to melt and hold it goether, then lightly buttered and pan-fried on medium-low about ten minutes a side, then covered with weak horseradish root.

"Making do with what you have" is a usual account of pragmatism.

The old adage "you'll be happy if you love what you do", includes that for some people it's getting off work, for others it's getting on.

Posing and answering "the question words", ....

There is a test I give people: close your eyes and imagine an apple floating in front of your face. Can you see it? Can you rotate it?

Some people can't.

I had a visit last week from a person who has an English degree and is now back at school to become an engineer. I thougt that was interesting.

We got to discussing visualizations. What happens when people, deaf from birth, read? They can't hear the words in their heads. She said that some deaf people see the words as images, of apples or whatever.

My wife works with people who have communication problems. She had one old guy who could only commmunicate in Morse code.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

I don't know. I think people genuinely think of things differently. Not even considering there are "other ways". What is unfortunate is when their view *imposes*, unnecessarily, on the use of a device.

I see devices (regardless of their eventual implementation) as a set of "actors" each providing a particular functionality. Or, "mechanisms", if you don't want to anthropomorphize.

Then, "design" is just the scripting of those interactions. Placing ONLY the constraints that the problem mandates on those interactions (ever encounter an electronic form-interface that REQUIRES you to complete line 1 before line 2??)

Tests have a preexisting specification to enforce/verify/validate. Specifications, OTOH, rely on how well you can organize your thoughts (notion of what a device should do or be).

SWMBO is always surprised by the "concoctions" that I come up with for meals, desserts, etc. Without having previously tasted them (yet confident enough to *rely* on them for "tonight's sustenance").

Some folks need the structure that work offers -- and, the direction that an employer/client provides. Others can provide those things for themselves, giving additional degrees of freedom to those efforts.

In those cases, is it really "work"?

Vanilla ice cream with a splash of lemon juice and balsamic vinegar.

Whipped cream is an idyll, though it's a heart attack.

A design engineer is a sort of unicorn, who with a pencil and paper, and resources of a capital industry, makes flying machines.

I got a lot out of "Electronics 1-7", Mileaf.

I make my own ice cream. My "standby" (to gift to others) is butter pecan -- heavy cream, melted butter, sugar and lightly salted pecans sauteed in butter.

It is very rich and, as such, "self-limiting" in terms of how much one can eat before "overdosing".

Personally, I prefer almond ice cream with almonds and chocolate chips. There, the utter *sweetness* is the limiting factor.

One of the basic tenets of homemade ice cream is that there is no such thing as a "bad" batch!

My heart attack meal is baked shrimp (5 per pound) stuffed with crab meat and served with hot, melted butter. Again, self-limiting; there's only so much you can eat before the richness causes you to beg off.

I increasingly move functionality into software and drive hardware complexity to nil. With processors so fast, small and capable, there are so many things that can be done in software (which is changeable) that binding a particular solution to a hardware implementation seems foolish.

This has the added benefit of making the hardware easier to troubleshoot and repair as the things it is called on to do are simple -- the complexity buried in the software driving them.

I like marinating mild fish (Ono, Cod, etc.) in a honey (or agave nectar) and soy sauce marinade. Then, serving with something having a stronger flavor (to offset the smooth/salty flavor of the marinade and texture of the fish). So, each bite is slightly different than the prior.

Absolutely.

But I still like to treat my code as a work of art. There is a beauty in well structured design and implementation. Compact and concise modules. Clean interfaces. Neatly and consistently laid out. Well documented.

Not something that can be appreciated by a layman, like a photograph can, but when I look at software projects sometimes I see skill and beauty, other times I see an unstructured mess.

Of course none of this matters to the compiler, so to some it's a waste of time and effort. "As long as it works". Luckily I'm not paid by LOC/hour, and we consider the "itys" (supportability, maintainability, reliability, testability, ...) to be important qualities.

(I also like well structured schematics, and hate those that are just a "tangle of gates" (usually from synthesis tools), or "parts libraries" (pages of components with no connecting lines, just net names on the pins). And HDLs have their place, but it's too easy to forget that you're defining hardware, not programming a CPU.)

I see much of that as just a reflection of the skill, experience and mindset of the developer. They are things that we all "know" to be the "Right" way to write code.

For me, the beauty lies in the design choices on which the code relies.

I like to build models that consist of interacting agents so they can adapt to changing circumstances instead of naively relying on assumptions made in the design stage.

E.g., my irrigation system consists of N identical instances of a "zone process" where each has a reference to an irrigation valve (and ONLY that valve), irrigation history (for that valve), environmental history (sun exposure, temperatures, precipitation, etc.) for the plantings served by that zone, the species of plants in that zone, a water supply service (from which to requisition irrigation water), etc.

So, a process can look at:

- the expected needs of the plantings it serves (by consulting a database for each explicit species named in that zone)

- the way those needs have been met in the past (irrigation history)

- the environment that they have been exposed to (weather)

- predictions for how that environment will likely be in the near term (forecasts)

- the availability of irrigation water (actual *costed* supplies as well as current demands being placed on them)

- the relative goals of the owner in maintaining those plantings (valuation) and make a decision as to whether or not it should activate the valve for that zone "now" and how much water to dispense.

This decomposes the problem to one that can more adequately be addressed beyond a naive "turn on the valve for zone N for 10 minutes every 3 days" (which is how traditional irrigation controllers tackle the problem)

It also makes it relatively easy to add additional capabilities and constraints without having to wind them through the entire design (e.g., if you have harvested water available, it ONLY affects water availability and can be hidden from the rest of the design)

You can visualize how these agents interact AS IF they were entities competing and cooperating to address the problem. Their behaviors feel intuitive. And deliberate.

Instead of a bunch of spaghetti code that was patched together over time (model 1 became model 2 which became model 3 etc.)

A lot of that comes from accepting ownership of the codebase. Employees often just want to get PAST the code (and are often implicitly motivated to do so by Manglement). After all, those might end up being someone ELSE's problems, not theirs!

I always provided "lifetime free bugfixes" to clients. This made it worth the effort to front-load the design to avoid having to revisit the codebase at a later date (when I had moved on to some other project and could ill-afford a distraction!)

You've never known the joy of a 300 sheet, machine drawn schematic! <frown>

A CPU is just hardware. And it's single-threaded, which means that it isn't all that interesting.

The thing about schematics is that you can mostly impose a left-to-right and a bottom-to-top order on the signal flow, which can make them more intelligible.

Heirachical schematics can let you do that for quite complicated stuff. .

Vanilla bean ice cream with a tablespoon of rum.

Do you want to live in a world without whipped cream?

I use an immersion blender and a beaker.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Mo's favorite meal is panko-crusted fried shrimp on hawaiian buns, with tater tots and beer.

The world is still analog, and uPs don't work in kilovolts or amps or picoseconds.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics