Thinking of Honduras

Photo of Rus Rus Hospital and the Cessna 206 that is used as the Air Ambulance
Rus Rus Hospital and its ambulance

I recently got an email from the International Health Service of Minnesota, (IHS of MN) about their upcoming mission to Honduras. They are recruiting for this year’s mission in the last week of October and next year’s in the last two weeks of February. Unfortunately, I’m not able to go on either, this time, the message did motivate me to publish a short summary of the past trips my wife and I have supported.

I haven’t ventured out on many expeditions like the type IHS of MN runs, but I’ve seen enough large-scale deployments to know a well-run operation when I see one and IHS of MN runs a very tight ship. The dedication of their volunteers and their decades of their experience come together twice a year to provide an effective deployment of medical and dental services to people who would not otherwise receive them. While we aren’t able to go on the upcoming trips, we’re keeping in touch to be ready for the next opportunity.

With any luck, I’ll have edited and published all the photos and videos from the last two trips by then.

What I learned by building a project from scratch – Epilogue

v1.0 of my camera self-timer
v1.0 of my camera self-timer

My last two posts described a project that I took from conception to working prototype.

Post 1     Post 2

Finding it in my garage gave me the chance to reflect on the design process through the lens of historical recollection. While historical recollection isn’t the most accurate process, given how memory works (or doesn’t), the self-timer I found in the garage is really just an artifact to focus my reflection.


The first thing I realized was what I didn’t realize at the time. What I recall at the time was how each subsequent step (Idea, design, working demo, prototype, and beyond) seemed to require about an order of magnitude more effort.

  1. The idea? About 5 seconds.
  2. The sketch? 5 minutes.
  3. The design? 5-8 hours.
  4. The working demo? A couple of days.
  5. The prototype in the photo? About another week.

That ratio has been reinforced in my subsequent experience as a software developer and even as a writer. What I didn’t appreciate at the time (or for a long time after this project) is how often I would try to be convinced that this wasn’t going to the case in this project (whatever this project was at the time).

Only experience would reveal that.


Looking back on this project as a way to learn the lessons I listed in the earlier posts, I wonder if I could have learned those lessons at the time–while building the project. Maybe. What I realize now is that I didn’t recognize the significance of what I learned during the project.

Feature creep? Happens all the time and requires a constant vigilance and focus on the goal to avoid.

The illusion of a prototype/demo being the final project? Another element that has profound impact on the perception of the project–one that can work for or against you, depending on the circumstances.

“…but it looked good on paper…” Definitely a lesson on the importance of understanding how implementation details can pull the finished project away from the original design.

The problem with these lessons is that their impact is often felt long after the pivotal event. Feature creep? It always looks like a good idea when nothing costs anything (i.e. it’s just another line on the drawing or another bullet point in the spec). However, when release is delayed due to integration issues that result from the extra bullet point, the fingers point to implementation, testing, etc. everywhere but back to that moment in the conference room in which the bullet point was added–further masking its effect.

Agile methodologies

Since this project, I’ve learned a lot more about projects and project management. Looking back on this, now, gives me the perspective to appreciate how Agile methodologies do a lot to shorten the distance between events of each of the effects listed above and their effects.

Maybe that’s the lesson to take away from the reflection?

What I learned by building a project from scratch – Part 2

v1.0 of my camera self-timer
v1.0 of my camera self-timer

This post picks up where What I learned by building a project from scratch – Part 1 left off. In the last post, I had designed and tested my device and I was preparing to build a working prototype.

It looked good on paper

Yeah. I didn’t design it to look like this, but that’s what you learn by actually building something. The original design, for example, had put that big, ugly, black thing on the inside. The big, ugly, black thing is the beeper to indicate that it’s about to take a picture.

The inner workings
The inner workings

You can’t really see it from these photos, but I had reserved space for it on the inside. Well, not for the one in the photo, but for the smaller one I originally spec’d in the design. The bad news for my prototype, however, was that I could not get the part I spec’d. So I learned my next lesson:

You can have it now or you can have it good

Two of the three legs in the project management triangle: Fast, Good, Cheap; pick any two. I picked Fast and Cheap.

I had to decide, did I want it finished soon or looking good. Clearly, I picked the former.

All put together, it worked (quite well, actually), but it’s looks left something to be desired.

If I had it to do over again… I’d probably make the same decision. The goal of this prototype was to test the functionality. I could iterate and find a part that fits (or find more suppliers so as to not end up in the same bind on the next iteration), but I didn’t want to delay field-testing–something for which looks were secondary.

Clearly, if I had different goals for the prototype, I might have made a different decision. For example, if the goal was to impress others and raise funding, I would have approached the appearance of the project differently–learning yet another lesson…

Keep your goals clear and in front of you

That says it all.


The inner workings from the other side

The device worked quite well and I even used it for what it was designed a few times. While that’s an accomplishment in and of itself, the feature of the design that I didn’t (and couldn’t) appreciate until many years later was its durability–the durability of both the design and the implementation, in fact.

I recently found this prototype in a box hidden in the deep recesses of my garage (where things typically go to disappear). I opened it up and it looked like it did when I built it. The relay (shown in the photo above the battery) needed to have its return spring reattached, but other than that, once I added a battery, it worked just like it used to.

Unfortunately, it lasted decades longer than the camera for which it was designed. Nevertheless, the lessons I learned by building it are timeless.

What I learned by building a project from scratch – Part 1

v1.0 of my camera self-timer
v1.0 of my camera self-timer

It might not look impressive, but this device represents a considerable learning experience for me–an experience that I hope I’m able to pass on to my future students. The only problem, which I hope to rectify after the fact, is that I didn’t recognize the lessons I learned at the time and so I was condemned to relearn the several times later.

The project

It started off simple enough. I wanted to build a timer that would wait 10 seconds and then take a picture.  After thinking about the application, it occurred to me that the first picture might not come out well, so I added the ability to select how many photos it would take after waiting the first 10 seconds. Time to complete this step: about an hour.

Before I had even started, I was already learning a valuable, albeit at the time unrecognized, lesson.

Lesson 1 – Feature creep

Was the ability to take multiple pictures after waiting really needed? (Probably not.)

Was the cost of this change factored in the decision? (No, because I could do anything, cost was no object.)

The prototype

So with my [already revised] specification in hand, I set off to build a prototype. Being a hardware project meant collecting the necessary integrated circuits and other components and wiring them together on a breadboard. After designing the circuitry and ironing out the logic and state diagrams, committing all that to the breadboard was straightforward. With care and incremental testing, the design came together rather quickly. Time to complete this step: About a day–and I was about to learn my next lesson…

Lesson 2 – The prototype is not the product

It was very easy to get ahead of myself at this point. I had a working prototype. My design was validated. I was heading for home plate.

Not so fast. I was really just heading for first base. I was nowhere near having something I could put in my camera bag, let alone let anyone else use.

The real prototype

But wait! Didn’t I just finish the prototype? Nope. That was just the breadboard–more of a working demo.


The real prototype had to look like something I could actually use. In this step, I had to package it into something that not only functioned, but it had to function in the real world. I needed to give it the physical design some attention.

While it would be some time before I actually studied user-centered design, looking back, I had the right idea. I knew the audience (me) very well and I knew the application, so I laid out the user interface and set to make it happen. I was about to learn my next lesson…

Lesson 3 – A working demo is not a prototype

My breadboard project was really just a working demo. The prototype (as in a working example of the product in, more-or-less, product form) was another level of complexity.

At the speed of thought

Amy's_lentil_vegetable_soupI returned from a visit to my parents, recently. My parents live in another state–far enough away that it’s difficult to visit them more than once or twice a year.

My father has had Alzheimer’s for several years. For the past few visits, I have met a new father on each visit–the same person, of course, but, at the same time, a different one.

On this trip, I resisted the urge to look for the father from my last visit so I could get to know my new one. While I miss the father I knew, it was rewarding to get to know the one I have, now. He’s just as special to me as the person I saw the last time; but this one is special in his own way.

One evening, as he and I sat at the dinner table with my wife and my mother, he considered a bowl of vegetable soup for a moment before picking up his fork to eat it. This was a bit curious to me. As the soup ran between the tines of his fork with each bite, my mother tried, unsuccessfully, to convince him to use his spoon. My wife observed that the fork was actually the perfect utensil for the task he was trying to accomplish–he wanted to eat the vegetables first. After he ate all the vegetables, he picked up his spoon and finished his soup.

He knew what he was doing all along. Once we were able to move at the speed of his thought, things went much smoother for everyone.

I’m glad I had a chance to meet this father of mine. I’m still learning from him and I look forward to meeting the next one and what he’ll teach me.

Writing it down

WritingWithQuillI added another goal to my blog vision project, today: to post my online resume and portfolio. It’s a goal that’s been rattling around for a while, but I’ve never actually got around to writing it down.

That this goal has been rattling around for so long (maybe 6 years, or more if I’m really honest) illustrates the importance of making things visible.

Reflecting on why it took so long to materialize, I came up with the following tips to prevent the next goal from taking so long.

Clear and well-defined goals are easier to commit to

Not knowing how to accomplish the goal makes it hard to commit to. Sure, I could have started with something like “have a great portfolio” as a goal (which was where I was 6 or so years ago, by the way); however, at the time, I didn’t have a clear idea about how to make that happen. To commit then would have just been frustrating and defeated the goal of having goals–actually accomplishing something. It could have been an aspiration, perhaps, but it wasn’t ready to be a goal.

“Portfolio” was the complicating word, in this case. I couldn’t think of anything that I had for a portfolio. In the intervening years, I’ve talked to people who frequently review portfolios and my definition of portfolio started to evolve. Once I redefined portfolio to mean something more along the lines of an annotated resume, that opened up the possibilities to something I could envision and see a path towards. I had a goal I could commit to writing.

Do it if it’s important. Don’t do it if it’s not.

Priorities are important.

While I wanted to have a portfolio (of any kind) since I finished my MS degree (2009), it hasn’t always been the most important thing on the list of things to do. Over the past few years, I would take it from the shelf, review it, and, until recently, put it back on the shelf in deference to something more important or, at least, more urgent.

In Agile Development terms, it never made it off the backlog.

Yesterday, however, it was well defined and with a clear path to completion, and it was important, so it’s now a goal. Had I made it a goal any earlier, it would have resulted in a lot of wasted effort (non achievable) and likely resulted in more problems (by neglecting what was important at the time).

A goal without a plan is just wishful thinking

Having a goal without a plan is what happens between the times you decide on a goal and create the plan to accomplish it. During this period, wishful thinking is a good thing, as long as it motivates a plan and the action to accomplish it. Stopping at the wishful-thinking phase, however, won’t get it done.

So, it’s on the list and I have a plan. Now, to make it happen!

Unleash the initiative

This morning on Fareed Zakaria’s GPS (Fareed Zakaria GPS – Aug 30, 2015), U.S. Army General Stanley McChrystal (Ret.) was interviewed about leadership in the context of Gen. McChrystal’s recent book. His interview starts at [10:36:10], a little over halfway into the program.

I liked how Gen. McChrystal started by clearing up a misconception about leadership in the U.S. military–one that I’ve heard from people with no military background and summarized from the transcript here:

Zakaria: …[in] the U.S. Army, you give orders, people listen, your job is to appear imposing.

McChrystal: …everybody thinks that a sergeant tells you to do something and you immediately do it. … In combat, soldiers are much more frightened of the enemy than they are of the sergeant. So they do things for their leaders and their comrades. …so the ability to influence and persuade and build confidence in you as a leader and in what they’re doing becomes the key task.

Zakaria: So, when you looked at…successful examples of leadership, what you found…was a guy who really was able to win the trust of people?

McChrystal: You win the trust of people, and then you unleash their initiative…

Unleash their initiative.

That has a nice ring to it. He went on to describe how to accomplish this.

Zakaria: Somebody wants to be a leader in their organization, in life. What advice would you give?

McChrystal: One, it’s going to take personal discipline… The next thing is empathy. …those core, fundamental, almost value-like traits are the key.

It’s nice to hear that empathy is a core, fundamental, trait…even for an Army general.

Now, to go and unleash some initiative!

Day 1 with a motto

Look nice, but take some getting used to
Look nice, but take some getting used to

Still getting used to the idea. But, it seems to be working.

What does a motto do?

So far it’s helped me focus by organizing how I approach things. That’s something I didn’t quite expect. But, after trying it out, I kinda like how that works–a lot!


Well. Let’s consider each word.


It all starts from empathy. This is a new starting place for me, but I’m finding that it helps put things in perspective. I know my feelings, but that’s only one component in understanding a situation. It’s easy (too easy) to stop there. With empathy, I can include the feelings of others. With practice, I’ll be able to learn the source of those feelings to gain a much deeper and richer understanding of a situation. It’s been like turning on the lights in a dark room. (OK, maybe it’s more like turning on a night light, but it’s a start).


Empathy is great (I’m finding), but objective data still has a place. On the one hand it helps put empathy in perspective. Feelings and motives are important to understand, but they can vary over time. So having data helps separate spurious and transient feelings from more profound issues. Neither data nor empathy is more important than the other; instead, they work together to provide a clearer and more complete understanding.


As my motto was coming together, it started out as just: Empathy. Data. Success. But those shoes didn’t quite work (to stretch the metaphor). Something was missing. Initially I thought about Execution. But that seemed inappropriate for a lot of reasons. Even ignoring the multiple definitions of the term, simply “getting the job done,” or “processing the data” seemed necessary, but hardly sufficient to achieve success. There needed to be some sense of conviction to the process; hence, Enthusiasm.

If you’re going to do it, do it with vigor (while not ignoring the first two points, of course).


Finally, success. Does this mean riches? Maybe. But, maybe not. defines success as:

the favorable or prosperous termination of attempts or endeavors; the accomplishment of one’s goals.

That seems sufficient. A favorable or prosperous outcome seems sufficiently precise for the motto. Sure, the actual operationalization of  favorable or prosperous is going to vary from case to case, but in every case I can imagine, either one seems like a worthwhile goal.


And so begins day 1 with my new motto.

I have a motto

Today, I as reviewing the vision document and realized I didn’t have a motto. I’m fairly certain that I didn’t have one because I’ve found coming up with them to be quite a challenge. I honestly sympathize with my students when we’ve done the motto exercise in class.

But, today, I was feeling inspired and took advantage of the inspiration to come up with:

Empathy. Data. Enthusiasm. Success.

That seems like the right order and I like them because they seem representative of what I think are important aspects of life and work. To me they seem both inspirational and aspirational. Reflecting on them helps inspire focus and a certain amount of balance. That same reflection also reminds me of how much I have to learn about each–which suits my desire to constantly learn, grow, and improve.

I suppose the next step is the schwag (t-shirts, key chains, bumper stickers, and what not), but I’m still growing into them, so that might have to wait just a bit.