We catch up with Sam Feller (who previously joined us in Episode 70), discussing his interests, projects, and latest entrepreneurial ventures.
Having left industry to pursue an academic career, Jeff isn’t chomping at the bit to move back into the entrepreneurial world.
Our guest for this episode is Sam Feller, a mechanical engineer who may be better known to our listeners as the “Awkward Engineer” from Episode 70.
Sam continues to run his Awkward Engineer website as a side project, selling widgets and gadgets that are designed to fascinate and entertain the engineering mind.
More recently, Sam has been working with WrightGrid in designing and producing solar-powered charging stations.
Skills acquired from pursuing his hobbies have helped Sam in his more recent entrepreneurial efforts.
Having “fried” his BeagleBone, Sam has been developing his bus stop sign using the Particle device platform.
The Python package Beautiful Soup is handy for parsing HTML and XML feeds.
Sam accesses bus arrival times using the NextBus API.
Our guest was kind enough to spend time with us in the middle of his family vacation near Cape Canaveral, Florida.
Those interested in learning to program micro-controllers will find a lot of online support for the Arduino platform, says Sam.
Adam, Brian, Carmen and Jeff discuss theoretical and practical aspects of the design process, as well as the emotional states they experience when engaged in design activities.
Carmen is starting to gain confidence in his design abilities.
Jeff notes that a lot of his colleagues wanted to be design engineers, but the number of available positions for such work was rather limited.
Carmen and Jeff agree that the design process was not discussed in any great detail during their college years.
A wide variety of meanings have been attached to the word “design.” Additionally, the word can be used as either a verb or a noun.
A lot of design work goes on outside the realm of product design, notes Carmen.
Xerox PARC scientists decided that design activities “moved minds,” while engineering activities “moved atoms.”
In the Rational Design Model, constraints and objectives are known in advance, allowing optimal designs to be created in accordance with a predetermined plan that follows discrete stages.
In the Action-Centric Design Model, creativity and emotion guide design decisions along an improvised path in which no predetermined structure is evident.
Brian mentions using the Phase-Gate Model of project management in previous design work.
Young engineers are warned by Brian to avoid “custom firmware.”
Jeff mentions a video that attempts to explain the Engineering Design Process to children.
Brian, Carmen and Jeff discuss the role of details in engineering projects, and how one goes about evaluating, managing, sharing, and documenting critical minutia.
In the introduction, Jeff misses the detail that this podcast is published in November, not October.
Carmen doesn’t mind sweating the details, but reviewing documentation for typographical errors is not his favorite task.
We continue to look for guest and topic suggestions from our listeners, so feel free to send us a note with your ideas.
A previous guest, James Trevelyan, has written about the value of engineers, and how uncertainty reduction is an important contribution of the engineering profession.
Brian relates a recent situation in which he burned through many hours trying to uncover a programming detail buried in the documentation.
Electronic circuits can behave badly in “high EMI” environments, where EMI stands for “electromagnetic interference.”
Jeff justifies his “pi multiplier” concept (see this podcast’s first episode) with the “cone of uncertainty” used by software developers.
It’s Brian’s opinion that engineers often fail to utilize the formal methods found in other professions when managing a multitude of critical details.
Jeff claims that engineering standards ease the burden of dealing with frequently encountered details.
Of course, as Carmen observes, the problem sometimes lies in choosing the “right” standard.
Searching a large solution space for potential design details can be a frustratingly slow process, says Jeff.
Brian always tries to have a backup plan, so he is not “checkmated” by a single detail.
The amount of documentation appropriate for each detail seems related to the detail’s expected and potential costs.
Creating a documentation hierarchy can provide needed information without overwhelming customers, notes Carmen.
Humans quickly become inured to a surplus of details (or warnings).
Brian has found modularization (it’s really a word!) to be a good means for keeping details from interfering with one another during the development process.
We catch up with Sam Feller (who previously joined us in Episode 70), discussing his interests, projects, and latest entrepreneurial ventures. 
