The Integration Engineer
When it just has to work.

Have a plan of what you want the reader to understand.

When you start taking notes, you won’t have this plan, and that is okay.  Notes are mostly for yourself.  But by the time you start to create a document that you want someone else to read and understand, you will need to have a plan on what the reader will take away from the document.  Ask yourself, “Is this a ‘how to’, or a ‘how works’ document?”

There is some overlap and subcategories for these two general types, but in basic if you are documenting how to start the system, or documenting how the parts of the system work together, you will use a different approach.  There will be some examples in the ‘how works’ document that will be like the ‘how to’  and any good ‘how to’ explains some of ‘how works’ that is inherent in the doing.  But these two approaches produce documents that look very differently. (more…)

Keeping a copy of all of the documentation you create is a pretty general benefit.  It helps you in three major ways;

1. Having a personal copy means that if the systems that have the public copies become unavailable, you will still have access to them.
2. Some times projects that get shelved, lose their documentation.  If you have a personal copy, when the project comes back to life, you will not be starting over.
3. And you never know what future project you will be working on that will spark the memory, “Hey we solved a problem like this on this other project…”  And having the documentation for it will help you.

I have never regretted keeping a personal copy of documentation.  But I have always regretted knowing that I didn’t keep one when I could have used it.

Greetings. I gave a presentation yesterday on an introduction to market research. Not the normal topic for this blog. Well if you are looking for it, you can find it here.

Be sure to sign up to be notified when the video of the complete presentation becomes available.

(more…)

I google people.

If I had said this a decade ago, you would have thought that I was confessing to something akin to being a peeping tom or voyeur.  But today, everyone reading this knows that I am telling you that I look people up on google to see what the internet says about them.  If you have ever done or said anything on-line, (or if anyone has done or said anything that references you on-line) it can be found.  And it will be by someone at some time.  Don’t let this on-line first impression be random or worse, in someone else’s control.

(more…)

One of the things that I advocate is keeping a copy of the documentation you produce, and the documentation that you encounter and use.  Over a short period of time, this can become a large amount of stuff.  If you are just throwing it all in your MyDocuments folder, it can quickly get out of hand.  To help out in this ongoing task and fight against the chaos, I am going to share some basic approaches that can help keep the sanity and utility in your documentation collection. (more…)

One of the things that Integration Engineers are asked to do is create documentation.  But as we all know, many times documentation is the last and poorest part of a project.  Developers and programmers don’t generally like writing documentation, and are generally considered the most qualified.

In comes the Integration Engineer to make the system work.  Producing effective documentation at this point is important.  We want to make the system work, and then hand if off to the team that will support it.  If we don’t create effective documentation, this last step can never happen, and we will be unable to undertake new integration work because we are still supporting the first one.  And if we are a contractor, we need this even more. (more…)