Brain Log - Think it out. Write it down.

Today I found this image at NASA’s MODIS Gallery:

So I went and captured an image of the sea-floor bathymetry for approximately the same area:

These are fascinating to compare. I'm aware of work in shallow water in which wave structure is used to infer seafloor bathymetry. It seems it might be possible to do it in the deep ocean as well.

NASA is able to image shiptracks from space:

These are apparently caused by particulates and water vapor from their ship stacks.

A few years ago I was working on a project that collected copious amounts of data that many people were working up simultaneously. We weren’t communicating well and it was killing me. So I drafted up this email (I'm not sure I actually ever sent it.) and today I found it in my “drafts” folder. I think it’s good stuff so I'm reproducing it here. Take heed…

Ok, I have a Huge pet peeve that I need to rant about. Please buckle in.

If any of us do any data processing and produce things data products and or plots, we must PLEASE PLEASE document what we've done in the appropriate Data Processing Narrative. [There should be one for each field test and each desktop study.] 

If you don’t document what you've done your work is WORSE THAN USELESS to the rest of us. It is a colossal waste of time to have to reverse engineer someone else’s work. You must capture everything you've done. Where was the raw data? Where is your matlab or other script? Where did the plots go that were generated? Where have the results of your calculations been saved?. 

You need not document every detail of every step in the Narrative, PROVIDED, you have commented your scripts well and in meaningful ways. 

One should be able to read through the Narrative and see the exact state of our data processing for a particular test. If you think your processing pipeline is an offshoot of the main effort, it’s still good to document what you've done. Perhaps someone will read the narrative, find the results of your work and build on it in a way you hadn’t thought of. 

This is the essence of collaboration. It seems like it takes more work to work together. But we save 1000’s of times the effort by not having to throw out your work because no one understands it. I have met people who work with the ethos that obscurity equals job security. I hate this. It is counter to everything I know about efficiency, learning and progress. 

This problem is inherent in data archives, not just at CCOM but around the country. Data is being lost at an alarming rate, not because it’s actually removed off a disk, but because the people who know anything about it never wrote anything down and never captured the pieces of information necessary to understand how to process the data or what processing has been done. 

In short, you must document in this digital forum in the SAME WAY you've been taught to document in a Lab notebook. 

Thanks for listening.

-Val

Dale Chayes sent me a wonderful link: The Beginning Engineer’s Checklist

Here’s a few I like particularly:

Always understand that you may pick two of the following three, but not more:
It can be built well,
It can be built quickly,
It can be built cheaply.

Never underestimate the stupidity of the end user of your product. Make it fool and
idiot proof if possible. This is very hard to do. It takes infinite intelligence to
anticipate boundless stupidity. A [product] should follow the `Law of Least
Astonishment'. What is this law? It is simply that the [product] should always
respond to the user in the way that astonishes him least. -- "The Tao of
Programming"

Make things that people want to buy. Not use, play with, see, understand, etc... BUY

On Loren Shore’s blog Loren and the Art of MATLAB there is a fascinating post about embedding one image within another. Even more cool are a few animations in the post that illustrate some of the results. VERY Cool!!!