
I Compiled NASA‘s Workmanship Standards into a Single PDF - muunbo
https://archive.org/details/nasa-workmanship-standards
======
vladTheInhaler
Wow this gives me flashbacks. I interned there one summer, working on a
project that was in absolute crunch mode with no budget left for the fiscal
year.

I and some other interns got press-ganged into helping assemble a prototype
device ahead of a visit from some higher-ups at (I think) JSC, and I ended
doing a lot of soldering - something I had only a little experience with
before that summer. As I was learning, I spent a lot of time with one of the
electrical engineers scrutinizing my practice pieces under microscope for tiny
scratches in the conductor and little burn marks. I also distinctly remember
burning my fingers over and over using the thermal wire-stripper, since it
tended to made the conductor extremely hot.

I ultimately ended up having very little confidence in my workmanship, and
when I found out that the thing we were working on might end up flying on the
ISS, I became terrified that I would read about a fire on the station someday
and not know if it was because of something I had messed up. That was also the
summer I got my first gray hair.

~~~
fzil
that's an incredible experience, thanks for sharing!

if you don't mind me asking how long ago was this?

~~~
vladTheInhaler
It was summer of 2014, so I'm not some old graybeard if that's what you're
thinking.

Yeah, it was incredible - very stressful, but I learned an enormous amount in
just a few months. And I was surrounded by a ton of extremely smart, motivated
(though sometimes rather dysfunctional) people. I just wish I had the
knowledge then that I have now. In retrospect, the project I worked on really
touched on almost every single aspect of mechanical engineering, and it was
really what steered me in that direction. I wish I could talk more about it.
It's not classified or anything, but it's very specific, and I'd rather not
dox myself by accident.

------
nosmokewhereiam
This goes well with [https://llis.nasa.gov/](https://llis.nasa.gov/)

"The NASA Lessons Learned system provides access to official, reviewed lessons
learned from NASA programs and projects. These lessons have been made
available to the public by the NASA Office of the Chief Engineer and the NASA
Engineering Network. Each lesson describes the original driving event and
provides recommendations that feed into NASA’s continual improvement via
training, best practices, policies, and procedures."

~~~
bumby
This lessons learned database is often met with a sigh and eye roll in
industry unfortunately

~~~
CamperBob2
Why is that? Is NASA drawing questionable conclusions from the incidents, or
what?

~~~
bumby
No, in general the search-ability is considered lacking. The findings are
often quite good. It’s often just difficult to find relevant results. Finding
a needle in a needle stack. Think of poorly managed orgs that just throw
everything on SharePoint.

On top of that, there’s often so much schedule pressure that project managers
may only do a cursory look (if any at all) and unlikely to add anything of
their own

------
m0zg
TIL that most of my electronics work is well represented in the "bad" sections
of the NASA manual. Then again, I'm not launching it to Mars, so it's OK.

~~~
muunbo
Haha! It’s helpful regardless for non-space projects. For e.g. I made “rave
skates” (colour shifting LEDs on ice skates) and the connections on it have to
be robust to abrupt movements and forces.

~~~
m0zg
I do intend to read the manual cover to cover. A lot of the advice in it isn't
difficult or labor intensive to apply, and a lot of it makes sense outside
aerospace. I do want an "excimer laser wire stripper" now though.

------
s_gourichon
Interesting, thanks for sharing! It would be even nicer with some kind of
table of contents: named chapters and the like, especially in the PDF
structure so that PDF viewers can show and provide direct access.

How did you create this compilation?

Also, pages seem out of order, with blank pages, but I guess that's to print
that to leaflets?

~~~
muunbo
There have been a lot of requests for the table of contents. It’s on my todo
list; I’ll post again when it’s ready :)

------
bumby
If anyone is interested, the IPC J standard is often followed for flight
hardware. Advantage being you can get a certification in this standard.

[https://www.ipc.org/ContentPage.aspx?pageid=J-STD-001](https://www.ipc.org/ContentPage.aspx?pageid=J-STD-001)

~~~
Ccecil
Most of the time you learn the IPC-A-610 stuff first...then J-standard is an
addition.

One thing to remember though is often Mil spec or custom builds actually
require better quality than IPC or J-std gives. IPC/J-std are "Minimum
acceptability requirements"...meaning "How bad can it be before I am required
to fix/scrap the part?" Every time you rework a board you damage it (they are
actually being damaged every time they are heated) so you only want to rework
if absolutely required.

~~~
bumby
I can only speak for my personal experience, but we started with the J std but
that may be just because the nature of the work was almost exclusively
spaceflight.

As far as “minimum requirements” I completely agree. As with all specs, they
define the lowest level of acceptable characteristics. Especially if done by
contractors this will be the aim since they rarely make additional money going
above and beyond minimum standards, but can often lose money doing so

------
Commodore_64
Quite impressive. Good job dude!

------
gjvnq
Not to sound too harsh, but ~ 300 MB seems a bit too much. Maybe you forgot to
enable image compression.

I did some poking around and discovered that the problem is that all those
drawings are incredibly detailed vector art. The "proper solution" is to open
each page with Inkscape and convert those vector art drawings into regular
bitmap images, probably encoded in JPEG to save space.

Alternatively, you can get a reasonable quality DJVU file for under 50 MB
with:

pdf2djvu --dpi=900 --verbatim-metadata -j4 "NASA Workmanship Standards.pdf" -o
"NASA Workmanship Standards.djvu"

~~~
CamperBob2
The proper solution is to get a bigger hard drive.

~~~
LargoLasskhyfv
Imagine carrying it around on your smartphone/phablet to have it available at
all times. Given a MicroSD with 512GB capacity that is more than half of total
capacity for a single file.

~~~
bigiain
You’ve slipped three orders of magnitude there.

300MB is 0.06% of 512GB.

~~~
LargoLasskhyfv
Lol. Sorry. Just got up :)

------
supernova87a
If only these existed for blocks of code.

~~~
ishcheklein
They have this famous one -
[http://spinroot.com/gerard/pdf/P10.pdf](http://spinroot.com/gerard/pdf/P10.pdf)
([https://dev.to/xowap/10-rules-to-code-like-nasa-applied-
to-i...](https://dev.to/xowap/10-rules-to-code-like-nasa-applied-to-
interpreted-languages-40dd))

~~~
jkaptur
I was nodding along to this, but this gave me pause:

> Assertions must always be side-effect free and should be defined as Boolean
> tests. When an assertion fails, an explicit recovery action must be taken,
> e.g., by returning an error condition

> ... Because assertions are side-effect free, they can be selectively
> disabled after testing in performance-critical code.

Why would you put in recovery logic in if you're just going to disable it?

For example, let's say that I've got a new algorithm for calculating the
cosine. Just to be safe, I add an assertion that the return value is in [-1,
1], and return an error if it isn't.

Now the clients of my code (say, the guidance computer) deal with the error
somehow: if cos(x) returns an error, show an error to the pilot and maintain
course or something.

If that assertion were stripped out in production code, then there was no
point in writing the recovery logic. I've never written safety-critical code -
am I missing something?

~~~
jedimastert
> For example, let's say that I've got a new algorithm for calculating the
> cosine. Just to be safe, I add an assertion that the return value is in [-1,
> 1], and return an error if it isn't.

I believe the idea here is that, if you've tested your code correctly, the
assertions are never triggered and therefore your constraints are met and you
don't need the checks anymore.

Somewhat interestingly, the Chromium code base does something similar. There
are `DCHECK` macros everywhere that are assertions that crash if the condition
is false (for instance if a variable is null or some such) but they're
disabled in production builds

~~~
stjohnswarts
Are you sure they aren't turned off for performance reasons?

~~~
jedimastert
Also yes

------
fallingmeat
How do these compare to the IPC standards? Redundant?

~~~
muunbo
Hmm I have no idea! Are the IPC standards publicly available for me to check
out?

~~~
Ccecil
Yes but the book isn't free. IPC-A-610 is a good place to start. I just
briefly browsed the page but it seems to be very close to IPC standards with
the J-Standard addition (which is mission critical/Space typically)

Source: I was IPC trained for QA/technician at one point (as well as soldering
and assembly)

------
sebastien_b
Having worked on SMT stuff years ago, I (kinda) fondly remember the specs of
what's acceptable/unacceptable in this guide (starting around page 125).

------
emsign
...and I didn't even know laser stripping was a thing.

