Idea to Market: Day 1 - Visiting KNH


Between 9th and 16th of February 2018, I attended a workshop whose theme was "Idea to Market". My initial plan was to blog about the workshop every single day after the sessions, but the sessions were intense and I was drained at the end of the day. So now that it's all over and I have a more relaxed schedule, I'll be doing a blog a day to review what each day was all about, starting today (though today there will be a bonus of two blogs 😉).

Day 1 was on Friday, 9th February 2018 and we were hosted at Kenyatta National Hospital - KNH. This was the first day of what was to be an intensive 5 day workshop. The workshop is centred around techniques that would enable the development of ideas surrounding Maternal, New Born and Child health, and later on actuating these ideas and taking them to market.

Personally, this training was of great interest to me because so many ideas tend to fall on the way side because we typically don't know how to transition our ideas at times into marketable products. 

The day we spent at KNH was kind of a preamble to the actual training, a way to give context to the training that would beginning in earnest the following week.

The training was conducted by two instructors from the Philips foundation, the instructors are based in the Netherlands. However, the training is a collaboration between Philips, KNH, Fablab Makerspace Nairobi, Gearbox, and UNICEF.

As we were being introduced to the facilitators of the workshop, one thing that was stated that really struck a chord with me was that, in providing this kind of training, the aim was to bring in individuals from fields that are not directly related to medicine early on in the problem solving process rather than only reaching out when need arose. These disciplines could include: engineering, business among others - and there were a lot of  engineers in the house, specifically from the electrical field, because we are AWESOME.

During the first day, the major exercise that we undertook was to take a tour of the hospital and observe how it operated. To achieve this, we were divided into two groups: one group went to the maternity ward, and another went to the New Born Unit - I got to go see the babies in the New Born Unit.

There were a couple of rules that had to be followed while at the New Born Unit since babies do require critical care. The first thing that you have to do as you get into the new born unit is you've got to sanitise yourself. There are disinfectant dispensers at the entrance that you have to use. Second, you are absolutely not allowed to go in with jackets or bags, even lab coats aren't allowed - I meant to ask why this was so but it slipped my mind.

In the new born unit, we got to see the kinds of machines that are used to care for babies who need extra care after birth. There was the incubator, which has a personal significance to me. My elder brother was born prematurely and thus he had to spend some time in the incubator, so I do have an appreciation for it.

Other machines that were available were like phototherapy units, respirators, resuscitaire among others. But basically our objective was to observe the working of the New Born Unit. How does the environment look like, how do the nurses interact with the space, how to the machines work and a whole load of other stuff.

Our visit at the New Born Unit had to be cut short though since it was approaching nursing time for the babies and we had to give the mothers their space.

We proceeded to reunite with the group that had gone to the maternity ward at the calibration centre.
The calibration centre is where all the calibration of the medical equipment used in the hospital is done and here we got to be given some insight into how all that happens.

After the calibration talk we proceeded back to the conference room that we'd had our introductions for a little brainstorming exercise. We were divided into groups of 3 and asked to discuss among ourselves what we had observed, and come up with three main issues. This was to be done on sticky notes. After some minutes of discussion, we presented our ideas to the facilitators and the group, and the ideas were stuck on a board and grouped. These ideas were what would be part of the discussion for the next week's training.

After that last exercise, the day was basically done. We were informed about the logistics for the next week, offered some lunch, and transport was provided back into the city.

Overall, it was a pretty good first day.

You Should Absolutely Document Your Projects


Documentation. The bane of many a project. From lab reports, to field trip reports, to hackathon reports, to work reports - documentation in any shape or form is a nightmare for most. Unless we aren't the ones coming up with the documentation 😉.

While documenting a project may not cause one to leap up in joy, it is a crucial part of a project.

From a personal use level, documentation can prove to be useful. When you are working through a project, you are learning and solving problems. In the process, you possibly learn new ways of doing things and sometimes you could even come up with an ingenious way of accomplishing a task. In that moment you are an expert of sorts. Unfortunately, you could lead yourself to believe that if you did it once, you could always do it again. But memory has a way of failing us. With enough passage of time, we tend to forget the details of what was once a vivid memory. So a couple of months later you may revisit your old project to possibly look something up that you need for a new project you are working on. If you made really good documentation, you could save yourself hours of having to figure it all out again.

Chances are, as you were working on your project, you had to look up information about how to accomplish a particular task. You know what you just did? You looked up someone else's documentation. Now the documentation could have been a datasheet, which you kind of expect from a manufacturer (but not always, some have reason to be secretive), or even a tutorial. Whatever it is, it's something that made your life easier. In future, someone could totally be trying to do whatever it is your project entails and your documentation could be used as a guide to learn the necessary techniques. So why not be the person who passes it forward by making it just a little bit easier for the next person.

Documentation is also important if you want a community to grow. This one is important for school based communities that are run by students. The leadership in these kinds of communities is very volatile since leaders tend to come and go very quickly. The only way to build upon ideas is to make sure all projects run by the community are properly documented so all subsequent members have a blueprint upon which to build upon.

And last but not least, the most fun part about documentation is that you get to have a body of work that you can show off to people. You can be at a conference and be like, oh I am an engineer and I have worked on a bunch of projects. Oh, you want to see what I have done, boom DOCUMENTATION. Now give me that contract.

The best way to get better at documentation is simply by doing a lot of documentation. It's only through practice that you'll be able to get the right flow of everything. You'll over time figure out what is important to state and what isn't. What's the best way to document this and what isn't.

The other thing is to do your documentation as you work. Memories tend to fade with time and we also tend to get lazy the further we move away from a project. But if you make documentation a part of your development process, it makes it easier to finally come out with documentation that actually adds value to the world.

So as you start new projects in the future, always remember, it may not be fun to document your project, but it is extremely important. How else will the world know about the awesome things that you do?

Learning to Learn


For the past couple of weeks I have been doing a lot of self learning. I describe self learning as learning outside of a formal school environment. It's a rather vague description, but let's just go with that for now.

How to Get Your HS420361K-32 4 Digit 7 Segment Display Working with an Arduino


Typically when I get new electronics components to play with, I just google the part number and lookup tutorials on how to get it working. This has been a pretty successful strategy more often than not. However, this wasn't the case when I needed to get the HS420361K-32 4 digit 7 segment display to work.

So You Bought Yourself a Raspberry Pi 3, Now What!


My second post when I started this blog was about my choice of a prototyping board to explore, and I started out with an Arduino. Back then, one of my arguments for choosing the Arduino over the Raspberry Pi was cost. While the cost factor hasn't changed all that much, I managed to get myself gifted a Raspberry Pi 3 (and that's how you bypass the cost factor lol).

So for the past couple of years I have been mildly exploring the Raspberry Pi 3 (emphasis on mildly), and what I'd like to go through is: "WHAT THE HELL DO YOU DO ONCE YOU GET A RASPBERRY PI?"