Picture Your Success

Talking about documentation is probably something you enjoy about as much as sticking your hand down the garbage disposal with the latter having the advantage of being far less boring. But if you don’t document, you’re in a lot of trouble.

A good drawing is like a good friend. Sure it requires a bit of work upfront. You have to tend to the relationship, find the things you have in common, or in this case slave over an overworked computer yelling at your CAD program for why it doesn’t recognize the table you just inserted five minutes ago and won’t let you add a new row to it. But in the end an assembly drawing is priceless.

When that guy is on vacation (or in a coma) was the only one who knew what that fitting was correctly torqued to or what generic part you ended up using when the machined one wouldn’t fit you’ll thank yourself for keeping good records.

Start with a good assembly drawing. It should be everything a technician needs without your supervision to assemble everything. A good parts list lets that technician know what grommet he’s supposed to use in one place and which way the coupler goes in at another. You probably already needed detailed drawings to get the parts built, but don’t neglect the assembly drawing. And don’t forget to redline it when you change something or use a substitution, especially in a test program, because once you get to the real thing it’ll be that technician who’s gone and doesn’t remember what crushed washer he substituted and nobody tracked it.

So when’s documentation saved your ass? When have you decided to go with shoddy paperwork instead and have you regretted it later?

5 responses to “Picture Your Success”

  1. Miss MSE

    As my parents always taught me, comment your code.

    I regularly have to use code someone else has written, and frequently that someone else is no longer a member of my research group. I am therefore incredibly thankful when things are commented. Uncommented code, especially when several people are working on it, has led to disasters, particularly when two different sections of the code are using the same variable name for two completely unrelated things.

    Well commented code I can use. Uncommented or poorly commented code? It’s often faster to just rewrite it.

  2. Max Loki Kingsbury

    If I don’t comment my code then I’ll never be disposable!

    All jokes aside, employers know that employees who share knowledge create a more efficient organization. “Lone wolf” engineers may congratulate themselves on their individual production, but they are the weak links in their cohort.

  3. Em

    I do a lot of work with old (5-40yrs old) mechanical drawings. When shop redlines don’t get updated by engineering, not only do the same mistakes get made on subsequent systems, but when we are asked to perform retrofits, we end up losing oodles of money on warranty for retrofits because the new components don’t fit (because we assumed that the drawings we had on hand were correct).

    I’ve also been caught not updating my own documentation at the end of a project – it was very embarrassing to get called out when it was discovered.

    Company culture has a lot to do with good record keeping. It has to be budgeted for (in the schedule as well as the budget), and recognized as being valued work. If those two factors aren’t present, then it gets shuffled to the “low priority” list, and eventually no-one even does the redlines because they know they won’t be input.

    I try to set aside a half-day every week or two to deal with updates, filing, and other administrative details that aren’t necessarily enjoyable, but make lives easier in the long run. I also use comments and hidden text rather heavily in my files to provide extra context that we don’t necessarily want the customer to see, as much for my own reference as for others (I have a terrible memory).

  4. Wulf The Engineer

    Over the years I’ve gained more and more appreciation for good documentation and documentation practices. It did not come naturally. I first met an engineer when I was a young punk who had about 30 years of experience and was one of the best I’ve known. He had notebook after notebook of well documented reports all with dates and subjects. Often when someone would bring him a problem to work on he would pull one down photocopy an appropriate starting point report, review it and start on his way. I photocopied a couple of his reports (he was very generous with information) and realized that most important information for engineers is never found in textbooks, it’s developed while you practice engineering. Without documentation it’s ephemeral. I modeled my report creating after him and it has served me well. I have all my reports in electronic form now and working as a consultant I never know which of them will be needed, but they are there ready to help.

    What I’ve also begun to appreciate is the small things in documentation. I only recently started using the International Dating Convention ISO 8601:


    Today is 2011-05-03

    Little did I realize how nice it would be for sorting computer files of my reports and such. I would like to see the US adopt it, but like the metric system, I suspect it will take something catastrophic to change us. Documentation is our personal engineering memory, without it we have amnesia and must start over each time. Engineering drawings are also legal documents of a type, they spell out what is expected of fabricators and vendors. Poor documentation leads to misunderstandings and lost time and the question of who is going to pay for the scrap.

    Frautech has brought up a very important subject. But a further question is: “What is documentation in the age of computers?” is a solidworks file good documentation for an engineer 15 years from now who wants to look over a design?–AutoCAD?–a PDF? How on earth do we document for the long term now? Paper, still works over fairly long periods, but even that has limitations. For those who are interested in this I recommend the book “A Splendor of Letters”—The Permanence of Books in an Impermanent World by Nicholas Basbanes. If you had to read Vergil’s Aeneid in College, you read the one from the 1400s as it has been copied and re-copied and the originals from Roman times no longer exist. We don’t have the original “documentation” This book examines the struggles librarians and others face to preserve information. It’s worth a read.

  5. Weekend Journal -- Starting an Engineering Job | Engineer Blogs

    […] — Knowing how to find information is a big task when starting a job. Either navigating a document control system at a large company or knowing where to find theory of operation documents (even if the solution is […]