andamu

When I was diagnosed with Type II Diabetes, I had to start testing my blood glucose levels twice a day. My glucose meter stores these results (the most recent 100 entries, I think) and then I have to transcribe them. I am supposed to bring my results along to my doctor, my diabetician and my endocrinologist, so they can track my progress (or lack thereof).

So I entered the values in a spreadsheet, and created some charts.

• I plotted all the values on a bar chart, I split out the values by morning and evening, fasting and non-fasting, and drew line charts plotted against the date, with the target zone indicated.
• I created trendlines to spot well, trends.
• I zoomed in on the last month, and I showed the greater picture with charts running over several months.
• I created pie charts to represent the ranges of readings.

In short, I visually represented absolutely every possible aspect of the data, clearly showing both progress and areas of concern.

And how did they respond? Every single one of them looked at the charts (some incomprehendingly) for a few moments and said: "Oh. No, but where is the list of numbers?"
::
In hospitals there are "pain scales" posted on the walls - a bar gradually changing from green at level 0 through yellow, amber to red at level 10.

I have tried multiple times in the ER to answer a doctor's request to describe the pain with a verbal representation of an xy chart with the pain scale on the y axis, and time on the x. Somehow they just don't seem to understand "a mostly constant 5 with intermittent spikes to 6, 7 and occasionally 8, until the constant level is elevated to 7 and the spikes reach 9......"
::
I guess not all pictures are worth the same to everyone.

Chrysalis in a comment below paints a pretty bleak picture of an engineer's job today.
While everything he says is true, it is not entirely complete. There are still parts of the job that excite as much as other parts bore. And after all, he is a manager, and I am just an "individual contributor," which distinction affects the constitution of our daily tasks.

So exactly what does an R&D (Research and Development) Engineer do all day is the question that is uppermost in everyone's minds. (Yes, I have now become a mind-reader as well.)
So, just for you, I have created the following extract from one part of my job.

Workflow:

1. We design experiments.
2. We create software and hardware to conduct the experiments.
3. We tweak the experiments. When we are satisfied that they do what we intended,
4. We create software to capture the data.
5. And more software to automate the loading of data to a database.
6. Then we create queries to extract the data in meaningful ways.
7. Next we write software to analyse the data from every side.
8. Finally we create the powerpoint presentations to show the managers what we had been doing, to
9. Win approval for the next level of experiments - at which time
10. We start all over again.

Well, you did ask. Or sort-of-asked at least.

I don't know why, but I frequently find myself writing volumes as a comment to someone else's blog. I've turned some of them into blog posts here - if there was any way that I could tenuously work it in.
Recently it struck me that I can post a comment as a blog post straight out over here, when it is a comment to a comment that has been made to one of my posts. (Is that confusing enough yet?)
::
Em wondered about "programmers" and "engineers," and specifically the prevalence of the latter on this side of the pond in his comment to this post.
And it is true, everyone seems to have engineer appended these days, from Domestic Engineer for people who focus on housekeeping and parenting tasks to Sanitation Engineer for the guys who pick up trash.
Engineering and engine do have the same root, and most likely the concept has evolved originally from someone concerned primarily with engines to that today of "A person who is trained in and uses technological and scientific knowledge to solve practical problems."
The variety of areas of specialization, from Electrical, Mechanical, Civil, Chemical, Aeronautical, Computer, and Industrial Engineering, illustrates how much technological development has taken place.
::
Most programmers here would have a job title of "Software Engineer." I would classify a programmer as someone who writes code for applications that will be sold as such: Microsoft Word, Movable Type, Oracle etc. At least half of all programmers would have Computer Science qualifications.
Given the high-tech nature of our world, many engineers (and certainly those in R&D) need to be able to code to at least some level of proficiency. Here however the code is not aimed at market, but rather used as tools to make hardware do something (when working on prototypes of products) or to collect and/or manipulate data from experiments conducted on hardware (by running code that puts said hardware through its paces). We code mostly in a scripting language (Python in our case) for ease of modification and accessibility, whereas programmers would use compiled languages for speed and security (among other things).
In my case, seven of my team mates are Mechanical Engineers, and one is a physicist, but all of them jump in at times and modify code, or even generate new code, to accomplish their goals.
I am the lone Computer Engineer, and so I do a disproportionate amount of the coding, by virtue of the fact that I have "computer" in my degree title, although I have some "proper engineering" work as well.
As Computer Engineering is a relatively new degree a word of clarification: In most instances, the curriculum for Computer Engineering is the same as that of Electrical Engineering for the first two years. For the final two years there are a number of required subjects in Electrical Engineering, some in Computer Science, and some in Computer Engineering proper (computer architecture, logic design and the like.) Technical electives can be chosen in any of these three fields to construct a specialty.
By training I would be about 60% engineer, 15% mathematician, and 25% computer scientist.
By job function, my coding is all direct-use data and hardware oriented, aimed at allowing us to fulfil our engineering functions. I think that makes me an engineer who happens to code. But I guess the definition would depend on your perspective :-)

Yesterday I broke a tooth.

Yes. Ouch!

Not that that is an event limited to engineers, certainly. Nor is the piercing pain I experienced as a result.

But then I found myself trying to describe (to myself) the pain as resonating, and I found myself particularly intolerant to the whines and buzzes of the various pieces of machinery around the lab, and so I postulated a theory and constructed a small DOE to test its validity.

And so I found myself wandering around various parts of the lab, lingering at individual spots, and estimating the position on the pain scale. I exited the lab, separated by a double set of doors from the noise, and noted the response. I pressed hands and objects against the cheek and jaw, and again noted the response.

And came to the conclusion that my theory was valid; that in fact one of the frequencies (possibly the 18KHz) was resonating through the bone and the exposed nerve endings, and aggravating the pain.
::
For those who just need to know: Yes, the dentist said it would need to come out. However, I need to go back for the extraction - this visit after all was only an evaluation, you know.

Finally!

I have been putting in sixteen/seventeen hour-days this past week, trying to finish a set of experiments before a major meeting.

Part of the joys of being in Research & Development, is conducting lots of experiments, and those on prototypes and testbeds that by their very nature have, shall we say, challenges associated with them; after all, if everything worked perfectly we could stop fiddling with them and start selling them, couldn't we?

Every glitch that gets ironed out reveals another behind it, but at long last I am done, every last bit properly slotted and categorized, ready for the big evaluation, scrutiny and categorization to start next week.

And tomorrow is a big day - a fellow blogger is visiting the area and we're meeting for breakfast and a bit of a natter; we might even squeeze in some sightseeing.