Writing Documentation That Doesn't Suck

I've often had to write manuals for the products I've developed. The Technical/Maintenance manual is easiest (because the audience is technical), and the User/Operations Manual is by far the hardest (anyone can be a user).

Like many engineers, I took the minimum number of required writing classes.  So it was not a huge surprise that my initial attempts at product documentation were terrible.  Over time I finally became "not horrible" at documentation, and the main path to success was to avoid saying too much!

There are many technical writing guidelines online, but I find most are too narrowly focused to be of general use. A few simple guidelines are generally enough to avoid documentation disaster.

Here are some guidelines that have served me well:

• "Don't write so that you can be understood, write so that you can't be misunderstood." William Howard Taft

This is partly about getting inside your reader's head, and partly about getting out of your own. It is all too easy to write for people who are near-clones of yourself, and forget the wide range of other folks on the planet.

It's about making your writing as "simple and obvious" as possible. Avoid long-winded explanations when a couple short, carefully-crafted sentences will do the job. That said, always use however many words are needed to make each point clearly and concisely.

Important things may need to be said more than once. What I typically do is "say it once", then show an illustration, then explain the illustration, and finally summarize what was just done (what success looks like).

• Have some "fresh eyes" available.

Given that we can't understand all possible readers, we must remember that we only truly care about the first-time reader. That means at least some of the folks who review our work must also be as close to a first-time reader as possible.

In particular, this means it must be simple and easy for actual users to provide feedback on the manual itself. Encourage each customer to print and mark-up the instructions, and tell them how to get their input back to you (email, forum, etc.).

• Include a glossary.

It is way too easy to use too many technical terms, and too hard to get rid of them. Having a glossary and always keeping it current is a great way to track specialty terms and language.

• Don't get tied down to a Table of Contents: Make it the last thing you generate.

Too many folks start with a Table of Contents as the plan for the document. This is backwards! The document should have whatever organization and structure it needs to get its job done, and the flow is expected to change with time.

That said, it is important to have a "ToDo List" for the document, a detailed set of goals for what must be included and not left out.

Of course, organization is needed, but primarily at the lower levels:
o What is the purpose of this step?
o What tools and parts are needed to accomplish this step?
o What things must I do?
o How can I verify that I did it correctly?

• There is no such thing as too many good illustrations.

However, there is such a thing as too many bad illustrations! The old saying "A picture is worth a thousand words" isn't totally wrong, but having a picture doesn't mean words aren't necessary. Illustrations should add context and meaning to words, not replace them.

For something like kit assembly, there are going to be situations that words can't express in an understandable way. This is when illustrations matter most, so take the time to create lots of candidates and choose the best. Try to avoid the "one and done" attitude to images or drawings.

• Layout matters! But not until close to the end.

One important goal is to not force the reader to have to flip back and forth between pages to understand what's going on. Text mixed with images? Images and text in separate columns? Size? Pagination? These are all important to the reader, but not unless and until the needed information is already present in the document.

• Documentation is really about "teaching", not "telling".

The user has goals, and the documentation must ensure the user will meet those goals with minimal confusion, and minimal need to ask for help. For kit assembly, the initial steps should train the user to become a good assembler, not merely get things put together.

Not all of us learn in the same way, and there are a number of ways by which we learn. These ways are called "learning modalities" (or "learning styles"), and while we all have access to all them, some work much better than others, and which ones do best will vary between individuals.

It is often necessary to say a thing in different ways (words, pictures) in order to engage multiple modalities. It is also important to help the user sharpen the modalities that will be most useful, and that's where training comes in. Take time at the start to build the skills the user will need before making use of them. Even the fundamentals matter:
o What is an "M4 screw"? Is a screw different than a bolt?
o What does it mean to "tighten a screw"? How tight is tight enough? How tight is too tight?
o What does it mean to "crimp a connection"? How can I tell if I did it right?

SexyCyborg: Causing Continual Cultural Conflict

I want to talk a bit about Naomi Wu, a Shenzhen freelance programmer, a Maker, a model and a vlogger, who added an enormous pair of 800 ml breast implants to her already abundant good looks and then established her YouTube persona as SexyCyborg.

When appearing in public, she often wears the tiniest of nano-shorts and a crop-top revealing a slice of under-boob.  At pool parties, her bikini consists of little more than strings.

Naomi is intentionally stirring the interfaces between Makers, engineers, culture, sexism and more.  She has many goals in her life, but the one that fascinates me most is her goal to level the playing field for everyone, female and male, young and old, newbie and expert, both as Makers and in life in general.

I support her on Patreon, and I want to be clear about the reasons why.

1. She's a female Maker pushing her way into a global phenomenon still dominated by white Western sexist male culture.
   
2. She's a talented self-taught Maker who works in multiple areas, from software, to 3D design and printing, to wearables, to work tables and shelves.
   
3. She's a Maker on the inside of the Great Chinese Firewall.

Certainly, the above characteristics alone are worthy of support.  The fact that Naomi is also the SexyCyborg really has relevance to only two items in the above list: Maker sex discrimination and her wearables.

There is one enormously important item missing the above list:

4. Inspiring Makers of all ages, especially female Makers, to pursue their interests despite gender-based or age-based resistance.

This is actually what I most want to support, and would most like to see succeed on a global basis.

---

I'm making it sound like it's all about Naomi Wu, SexyCyborg.  It isn't.  It's also about me.  It's about how I view Makers and how I view women, and how confused I used to get when both appeared in a single package.

I always thought of myself as an unbiased person, free from common prejudice.  But Naomi arrived like a stick in my eye, jumbling my perceptions, causing me to uncomfortably flip between "Wow, cool Maker" and "Wow, hot woman" as if they were two different things.

I can't count the times Naomi has made very clear the differences between how people in Shenzhen respond to her appearance compared to Western males.  The charming videos with kids and "Aunties" were one thing, but the lack of drooling, leering looks from Shenzhen males when she walked in public finally made the point clear to me.  The only leering looks I can recall in any of her videos came primarily from the Western expats at her pool party modeling gigs.

So, what's the difference between Shenzhen men and Western men?  Is there a difference I can find, understand, learn from, and put to good use?  Well, I'm far from Shenzhen, and don't speak either Mandarin or Cantonese, so direct research is difficult.  I started by rewatching Naomi's videos, and well as videos by other Asian vloggers, both locals and expats.

I was most impressed with the videos by Western expats who had chosen to live in China long-term; had built a career; had married a local; had started a family.  How their videos changed from the earliest to the most recent.  And how they and their spouses reacted during trips to the West.

Then I viewed Naomi's videos again, especially her 360 videos, where I could look at all the folks around her.  I noticed how she got about as many looks from Chinese women as she did from Chinese men, and for about the same brief length of time, with no major facial reaction other than, at most, a small smile, never a frown.  Many of the expats had the same behavior, though there were several very obvious exceptions who stared and leered, turning their bodies when their necks reached a limit.

After a while I finally started to understand something. Perhaps it's not the full picture, but I think Chinese and Americans view beauty, especially female beauty, in very different ways.  It may come down to the perception of beauty itself.

For example, to a Westerner, a beautiful building, a beautiful garden, a beautiful song, and a beautiful woman are likely thought of as representing distinctly different kinds of beauty.  To the Chinese, I believe they are seen as parts of a continuous whole, free of sharp distinctions, sharing more commonality than differences.

Western males judge women according to their perceived beauty, attributing to them attributes that are unrelated to appearance, such as personality or intelligence.  Western women are not immune to similar judgments concerning each other and men.

I believe the Chinese view physical attributes as simply a means to recognize someone from a distance, and not as a representation of who they "are".  The Chinese also view identity a bit differently, not residing entirely within the individual, but also being diffused into family, friends, associates and even society.  To get to know someone in China I believe it must be just as important to spend time with others who know them in addition to individual time.

I believe it does come down to identity, both its definition and perception, particularly in how and when appearance becomes a factor.  And, perhaps, how there is an intentional Chinese cultural emphasis on similarities over differences.

China is a communist country, a "People's Republic", that has been undergoing great social and economic upheavals over the past 40 years, causing stresses that, after a period of easing, now push the government to become more authoritarian, with increasingly invasive public and private monitoring.  The underlying ethos was and is: "we are all in this together, and must work for the common good".

China is also a region with a long dynastic history massively dominated by the Han culture and race.  In China, all of the non-Han taken together are a surprisingly small part of the population (under 10% of the total), with explicit government policies having the goal to absorb and diffuse formerly separate races and cultures into the Han-dominated society.  An example of this is the ongoing government-supported Han migration into Tibet.

Taken together, these factors provide a context that encourages specific social traits, especially among the overwhelming Han majority.  While Westerners may view some some of these traits with disdain, the simple fact is that equality is much more a default assumption within China, particularly among the Han.  And I'm saying "more equal", not "totally equal": China still has many cultural stereotypes related to sex, age, and particularly race, but they are much less noticeable than the equivalent Western traits.

I believe this Chinese equality particularly extends to sexism and judgments based on appearance.  For example, personal style is both accepted and appreciated in China, but not judged by its absence or extremeness. My perception is that fashion and style are much more about expression and entertainment rather than anything about identity.

A Western comparison may be our taste in music:  We sometimes want to listen to Jazz, other times Pop, but our favorite may be Country.  We seldom judge people by what they are listening to in the moment or by their general music tastes, at least not in any way close to how we judge people based on their appearance.

So, I've chosen to try to view the external physical beauty of people more like how I suspect the Chinese do, more like a beautiful song or flower, rather than something that should inflame my hormones.

And it's working!

But I must admit I did have a bit of a head start:  Decades ago I was a semi-pro photographer (which means I took gigs only when I wanted a new piece of equipment).  As a photographer, I saw whatever was in the viewfinder as part of the picture, something to be properly framed, lighted, and composed.  This applied equally to people, places and objects.  I was photographing beautiful things, but it was more about the beauty they shared, and abstract beauty.  I took particular joy in revealing the beauty in things often not thought of as beautiful.

I gave up photography because I had let the camera isolate me from life on the other side of the lens.  I had become increasingly shy in social situations.  Things get quite bad before I realized there was a problem, getting to the point where I rarely when anywhere without my camera.  I quit cold-turkey, which helped immediately, but only decades later did I realize I had also given up the equality of the viewfinder.

The more I try to see "beauty as beauty", the more I see the world as potential photographs.

When I see images of Naomi in minimal clothes, I find I now look first to see if a Maker project is also in the image.  Because that is who Naomi is to me.  See the list at the beginning of this post.

Don't get me wrong: I don't appreciate Naomi's physical beauty any less than I did before!  I now appreciate it as part of the beauty of the greater whole; the Maker, the programmer, the model, and the many other attributes of Naomi Wu, SexyCyborg.

I also view those around me differently.  I like having less of a Pavlovian response to attractive women, less being shy and tongue-tied in their presence, more interested in the rest of who they are.  Most notably, this affects how I interact with female bar and restaurant staff, whom I now seem to adopt as sisters independent of their attractiveness.

And, finally, I must admit to the changes being ongoing and incomplete.  For example, I have come to fully understand just how rude it is to openly stare at people.  So I now do it covertly, behind sunglasses, from the corner of my eye, with my nose pointed straight ahead, with my face neutral.

My journey may not yet be complete, but I can at least try to act as though I'm further along the path.  As most Shenzhen folks do.

One day, one step, one person at a time.

Cybersecurity *IS* "Defense in Depth".

I'm not any kind of security expert.  I'm just a real-time/embedded instrumentation developer who needs, from a security perspective, to Lock Shit Down.

No matter how much you know about your hardware and software, you really know very little of use until you get down to "Formal Proofs of Correctness" for all parts of the system.  Which are scarce, to say the least, presently limited to academic exercises or special-case military-type implementations.

When I came across anything that could use a network to affect the boot process, I'd ask IT to firewall it in our routers (in case the on-system configuration of that capability failed or was overridden), and write a test to show that the firewall was at least trivially working to meet that need (which the customer would also run to help ensure system security).

Then we came across firewall vendors who explicitly prevented closing such channels, or didn't explicitly show they were open.  We needed to assume our external firewalls would lie to us.

So I started preparing for "Defense in Depth", to have a series of simple firewalls present at every opportunity that wouldn't destroy latency or throughput (such as within network interface hardware and drivers). This worked well enough when on a wired interface, but proved inadequate when our systems started supporting wireless interfaces.

I finally had to move my embedded applications into VMs (at a significant increase in platform hardware cost), and implement firewalls at every opportunity both within the VM and between the VM and the host OS/hypervisor.

All these firewalls primarily concerned blocking traffic that wasn't related to the instrument functionality itself, traffic that was out-of-band relative to the application.  To keep things small and fast, we avoided stateful firewalls.

As the platform hardware capabilities grew (to multicore ARM), we shifted from tiny "secure" RTOSes to Embedded Linux, which meant we also needed to address hundreds of CVEs on our platform if we wanted to sell into certain markets.  This pushed us to consider using stateful firewalls.  Not to detect traffic related to a CVE, but instead to block everything that wasn't valid application traffic.

From a black-box perspective, our system eventually became immune to all know attacks, including fuzzing.  What it took to finally get us there was a formal, provable specification of ONLY our instrumentation application protocol.  This specification took the form of a lightly modified version of the firewall rule syntax: Our specification was executable!  We used it not just to initialize the firewall, but also to generate the application interface code.  A completely separate version of the specification was used for testing and validation.

Best of all, this made the instrument interface-agnostic and also agnostic to higher-level protocols: We no longer cared where the application traffic was coming from, wired or wireless LAN, even including everything from serial interfaces to cellular gateways (including SMS!).

Bottom line:  1) Use simple firewalls to block all-but-application traffic from the platform.  2) Use stateful application protocol firewall(s) to permit only valid application traffic.

Unfortunately, while this works well for "simple" M2M instrumentation interfaces, it is extraordinarily difficult to scale to more complex and versatile environments, such as a web browser on a PC (or even a Raspberry Pi).

However, it SHOULD scale well to the IoT world.  But it MUST do so in a way that consumers will accept, which means keeping security holes small in both number and duration, especially for conveniences like DHCP and semi-automated WiFi configuration.

To do this, the common internet protocols relevant to IoT must be recast in minimal forms that will support the required IoT functionality and nothing more, and sets of stateful firewall rules must be generated for these protocols.  Then every IoT device must include internal stateful firewalls to execute them.

To do so with any hope of both system-level and application-level security, the IoT application itself  must run in a VM. Which means only processors capable of VM support will be useful for "Secure IoT".  At present this rules out the tremendously popular ARM Mx family of embedded processors, but there is hope that upcoming members of this family will inherit the VM capabilities of their larger brothers.

About the James Damore screed...

Many have read or at least heard about the 10-page paper by James Damore and his subsequent firing by Google.

What most have failed to note is simply that the workplace performance differences attributable to sex are of the same magnitude as, or smaller than, those attributable to other group classifiers such as age, race, education, economic history, and so on.  There are quantifiable differences everywhere you look.  Few are relevant to anything.

Damore seems to argue that because such differences exist and are measurable, they impose a burden or create negative impact.  Nothing could be further from the truth.  Damore is literally using his numbers backwards.

First, the differences between individuals easily overwhelm the differences between sub-groups, especially in tech, and particularly in software development.  So anything that may appear to be relevant at some level of classification fails miserably when applied to individuals.

Second, Damore conveniently ignores the evidence that diversity (of all types, not just sex) is a net positive in technical environments.  Working with people different from ourselves can literally make the best even better.

I prefer to think of our differences as the aggregate in the concrete that binds us together as a team, making it far stronger than the cement alone.

Personally, I've done some of my best work while part of diverse teams.  In particular, design and code reviews in a diverse environment are much more dynamic, creative and productive.

I've seen the petty passive-aggressive discrimination some express, such as consistently claiming they can't understand a coworker's accent, when in fact they understand just fine.  Or by snubbing others at social team or group activities.  Or by making snide comments behind their back.  Or by doing that fakey "Hello..." subtly sexist greeting.

Most of this is done by folks who look like me, a white male.  But some is also done by members of other various minorities trying to "fit in", which perhaps is the greatest tragedy of all.

This makes me both angry and sad.  My anger keeps me vigilant, always willing to redirect or defuse a situation, and to take more direct action in private.  My sadness keeps me open and sensitive, seeking out my quieter colleagues, looking for signs of exclusion.

I need all my colleagues.  I work best as a member of a team.  Yes, I do have my individual "rockstar" moments, and I treasure them, but they don't happen every day.  My team is what happens every day.  It is what enables my best moments.

Damore simply doesn't get that.  I can only wonder how well he works on any team, much less a diverse team.

BuildOne $99 3D Printer on Public Pre-order!

Just got the word that the Build One 3D Printer with Automatic Bed Leveling is now available for public pre-order, with delivery in 2017.

I got in on the Kickstarter for this printer, with mine expected to arrive in September.  The Creator of this printer has had many prior successful crowdfunding campaigns, so I have no doubt he will deliver, and do so very close to his stated schedule (something relatively few tech campaigns manage to do).

This printer costs only $30 more than the 101Hero I backed last year, and is a massively better piece of hardware, with printing speeds 7x to 10x faster than my 101Hero!

Now, I'm very glad to have my 101Hero, mainly because it is a Delta printer and has been a fantastic learning experience.  But it's time for me to do some real printing without breaking the budget.

What a life!

This is a retrospective describing how fortunate I've been since first arriving in San Diego in 1975, focusing primarily on the technical aspects of my career.  I'll try to make this more of a time-line, with just enough detail to stand on its own.  I can always add more detailed posts later, if needed.

After graduating High School in the Midwest in 1974, I had no burning desire to immediately start college.  There were many issues involved, but the main one was my having no idea of what long-term career I wanted.  I needed an income, so I got some typical low-wage jobs suitable for folks without a degree, and within months decided I needed something more.

I joined the US Navy in February 1975, enlisting under the Nuclear Power Program (NPP).  At that time, four enlisted ratings (job categories) existed in the NPP: Electronics Technician (ET), Interior Communications Electrician (IC), Electrician's Mate (EM) and Machinist's Mate (MM).  My oldest brother was a HAM radio operator and had been an ET in the Navy, and I very much wanted to learn electronics.  Though I had qualified for ET, the most technically advanced of the four ratings, I was told that I would not be assigned to a rating until after I started boot camp.

I was assigned to the IC rating, which was initially a severe disappointment.  However, two factors about the IC rating combined to ease my disappointment:  First, the IC rating was responsible for equipment located throughout the ship, in literally every single part of it, covering a wide range of technologies.  Perhaps none were at the level ETs worked on, but the scope and breadth was very intriguing.  Second, IC school was in San Diego, a place of fables this Midwestern boy had never seen.

I arrived in San Diego in the spring of 1975, seeing my first palm trees as I exited the airport terminal.  I sailed through the IC coursework and totally fell in love not only with electronics, but also with electromechanical systems and the technologies of sensors and actuators.

A few months later I was sent to Vallejo, California for 6 months to attend Nuclear Power School (NPS) at the Mare Island Naval Shipyard (MINSY).  Here I fell in love with applied physics, especially nuclear physics, thermodynamics and hydrodynamics.

After that came 6 months attending Nuclear Prototype at the Idaho National Energy Laboratory reservation (INEL) west of Idaho Falls.  I was assigned to the S5G prototype, the newest one there, and also the most technically interesting.  Unfortunately, the continuous intense effort required exhausted me just before the end, and I was unable to meet graduation requirements.

As my friends and classmates moved on to their new duty stations, I stayed behind while a place in the regular (non-nuclear) fleet was found for me.  During this time I learned about non-destructive testing (NDT) and the differences between quality assurance (QA) and quality control (QC).

I was overjoyed when my first choice of duty station, San Diego, was granted.  Unfortunately, the ship I was assigned to, the USS Blue Ridge (LCC-19), was on deployment in the western Pacific at the time, and I wouldn't get back to San Diego for several months.  This was not a bad thing!  I flew out to meet the ship in Japan, and had lots of shipboard time underway without the distraction of trying to have a life ashore.  This let me focus on quickly learning my new responsibilities.

I also had the opportunity to learn about many of the ship's other ratings and their equipment.  The Blue Ridge was a command ship, and had a large computing suite that was exceeded only by those on aircraft carriers.  I learned hands-on programming of the CP-642B mainframe system, and I instantly knew I wanted my future professional career to include computers.

At the time, the IC rating seemed more like a "catch all" rating for equipment that doesn't quite fit within the responsibilities of other ratings.  Two critical pieces of equipment we were responsible for were the ship's gyrocompasses.  Our current gyro technician was scheduled to leave the ship, and since a replacement was not readily available, I was selected to attend Gyrocompass "C" school, exposing me to yet more theory and its application.

While at gyro school, I learned about the Gas Turbine Controls school, which was training technicians to maintain and operate the Spruance class of jet-powered destroyers (the same technology used today in the Arleigh Burke and Ticonderoga classes of ships).  I applied to change over to the "Gas Turbine Systems Technician (Electrical)" (GSE) rating.

I was selected, and I was exposed to yet more new technologies.  I did very well, and was selected to the pre-commissioning crew of a brand new destroyer that would be based in San Diego.  Getting a new ship from the shipyard into active service is very demanding, and by the time all of our shakedown trials and refits and updates had been completed it was late 1979, and I had only about a year left on my 6-year enlistment.

The Navy had been exceedingly good to me, and I seriously considered becoming a "lifer", staying in until retirement at 20-30 years of service.  However, I had advanced through the ranks very quickly, and my next promotion would have been to Chief Petty Officer, a paygrade focused more on managerial, administrative and training duties, than hands-on equipment operation and maintenance.

I really enjoyed being a hands-on technician and operator, and didn't want to give it up.

Since I had the GI Bill available to me, along with some savings I had accumulated over the years, I decided to let my enlistment expire, so I could take a closer look at my future civilian career path.  I would stay in the Navy Reserves, so I could easily return to active duty should I choose to do so.

During this last year of active duty, I bought my first PC, an Apple ][+ complete with the 48K Language Card and UCSD Pascal, a massive $2000 investment in 1980 dollars (about $6000 in 2017 dollars).  Most of my programming was done in BASIC: I was impressed with UCSD Pascal, but was having problems learning it on my own.

Being in San Diego, and with the University of California at San Diego (UCSD) right here, I immediately decided that, should I choose to go to college, UCSD would get my first application.

I left the Navy and within months was soon making use of my nuclear and electronics training working at General Atomics performing factory calibration of radiation detection systems used in many commercial nuclear power plants.  I was soon working on debugging new prototype instrumentation, and soon after that I became an R&D (research and development) technician assigned to work with the division's chief researcher, who had a PhD.

Working shoulder-to-shoulder with a PhD made one thing very clear to me:  We were both equally smart, but his education permitted him to work at an amazing higher level.  I immediately submitted applications to 6 of the top engineering universities (Cal Tech, UC Berkeley, UC San Diego, Carnegie Mellon, MIT, Champaign-Urbana) and by mid-summer I had been accepted by all but one of them.  Most importantly I was accepted by UCSD, and that's the offer I accepted.

I majored in Computer Engineering, an overloaded degree program that included all of a Computer Science (CS) degree along with the digital half of an Electrical Engineering (EE) degree.  Needless to say, I soon knew I was on the "5 year plan".

I continued to work at General Atomics (GA) during school: Full-time during summers and breaks, but also part-time when classes permitted.  GA was extremely supportive: Every time I learned something useful, they'd find ways to let me use it, simultaneously give me a promotion.

I graduated from college wealthier than when I started!  This was thanks primarily to the combination of the GI Bill, the Navy Reserves, and General Atomics.  And also to UCSD, who gave me opportunities to be a paid tutor and lab proctor for lower-level Physics courses.

Leading up to my graduation in 1986, I was eagerly recruited by several top tech companies, receiving some great job offers.  Fortunately, the best offer by far was also the only one that would keep me in San Diego:  My offer from General Atomics was generous to the point of embarrassment, 30% higher than my next highest offer (which was also very generous).  GA management repeatedly assured me they felt they were getting a bargain. So of course I accepted their offer.

I continued to design and implement radiation detection instruments, and even got to get into the Navy side of things by working on the reactor control and monitoring systems for the Navy's next-generation nuclear attack submarine.

During this time I tried to get involved in work being done in San Diego by other parts of GA.  The San Diego Super Computer Center (SDSCC) was created just as I graduated, and for the next year I tried to get a position there to help bring up their new Cray XMP.  In late 1990 GA's expertise in fusion technologies lead to San Diego becoming the first home for the ITER (International Tokamak Experimental Reactor) project, and again I tried hard to join their early staff, without success.

Then our division's top-level management started making changes that made my job much more difficult.  Perhaps I had been spoiled by having "too much fun" in my career, but I decided to move on.  I first tried to transfer to another division within GA, but there were few openings at the time, so I decided to leave GA for another company that had been started by GA veterans: SAIC (Science Applications International Corporation, now Leidos).

There my radiation instrumentation experience was leveraged to build inspection systems using X-Ray and neutron beams.  In particular, I got to work on bleeding-edge technology for real-time automated video inspection systems.

By 1991 SAIC was "strongly encouraging" (pushing) me to move into technical management. I gave it a try and did well at it, but it gave me little joy. The experience convinced me I was happiest when doing engineering myself, rather than enabling others to do it.  However, having successfully entered the ranks of management, SAIC was reluctant to let me switch back to being an engineer.

Given my wide and deep experience, I decided to become an independent contractor.  I was soon working with yet more technologies and targets for embedded systems, including satellites, cable boxes, and security systems.

I was doing well, but I soon realized I sucked at marketing myself: 100% of my contracts came from referrals.  Within four years I started to encounter significant gaps without a contract.  I took some work through temp agencies to fill these gaps, but just before deciding to throw in the contracting towel and return to a "regular" job, in 1998 the "dotcom bubble" came to my rescue.

While the primary heat was up in Silicon Valley, San Diego became known as "Silicon Beach".  Our relaxed atmosphere and diverse tech community attracted many startups, and I got to help a few of them, working on an ever-increasing array of new technologies.  By late 2000 it was clear the bubble had popped, and my career as an independent contractor evaporated.

One boom I missed was San Diego's biotech explosion. Another boom I missed was the explosion in digital cellular phone technology centered around San Diego's Qualcomm.  But I did catch another important wave: High-speed digital photography.

I became part of a team designing a digital video camera capable of 100,000 frames per second.  I had two different areas of responsibility:  Color processing and the low-level camera command interface.  Both of which exposed me to yet more new theory, technology and applications.

Immediately after releasing our new camera, the company was purchased and relocated to Arizona.  I chose to stay in San Diego and was soon working for an aircraft instrument company.  While the underlying technologies were not new to me, the process of getting an instrument through FAA certification certainly was.  My prior experience in nuclear systems was primarily focused on industrial and operator safety.  Now I was directly affecting human safety: If my instruments malfunctioned, people could easily die.

A few years later I was asked to help a startup making a new radiation detection system for Homeland Security applications, so I left the aircraft instrument company.  Unfortunately, the startup folded 6 months later.

I next worked at a maker of surveillance equipment, most of whose customers were government agencies known as "TLAs" (Three-Letter Agencies, such as the FBI).  Here I got my first exposure working with digital radios, and helped design and implement a broadband point-to-point communication system for smaller UAVs, giving them the ability to handle the same sensors as the "big boys" (such as the Predator and Global Hawk), and do so without need for expensive satellite uplinks.

Since then I've gone back into contracting, both for myself and through temp agencies, and have worked in areas as diverse as cybersecurity and underwater navigation.

All this was done within San Diego, actually within a 30-minute commute from my home.  That's not a bad lifestyle!  I'm also a triathlete (San Diego is the birthplace of the modern triathlon), a volunteer swim instructor, a wanna-be musician, a volunteer supporter of local live theater, and an inveterate hacker on my home automation system and 3D printer.

If you want to find that precious intersection of a fulfilling and diverse technical career with a rich and abundant lifestyle, San Diego is tough to beat!

101Hero - Now Less Bendy!

As I experimented with increasing print speed and acceleration, my 101Hero would noticeably shake, twist and flex.

I looked at some of the stiffening and support solutions tried by other 101Hero owners, and to me they all felt like overkill in engineering and/or cost.

I imposed some restrictions on my solution:

1. It must not require modifying the 101Hero itself.  No new holes, no glue, no bolts.  The solution must be completely removable.
2. Cheap.  Like the 101Hero.
3. It must be truly rigid, and not require fussing to make the printer geometry correct.

My solution was simple and provided the extra benefit of also serving as most of an enclosure: Clear Acrylic panels slid in the outer grooves between the pillars/pylons.

My Setup

The Acrylic

The Printer

The acrylic panels had to be about 3 mm thick to be strong enough not to bend and actually add rigidity to the printer.  That's also about all that will fit against the pylons and still leave room for the slides to travel freely.  But the groove width was only about 1.5 mm away from the ends.

So I made three 304.8 mm x 18.5 mm panels from 3 mm acrylic.  Then I reduced the edge thickness to 1.5 mm, and added a 60° bevel on each long edge.

The above pictured aren't very good (need a macro attachment for my phone), but they should get the point across.

The printer is now amazingly rigid!

You'll also notice the $5 Walmart fan up against the pillar: It provides less cooling than it did before adding the panels, but it seems to be enough.