How are the DIY and engineering communities meshing as prototyping and anlysis tools become more widely available? Chris and Jeff discuss the issue with a well-known inventor in this episode of The Engineering Commons podcast.
Since many engineering fields don’t require a license, there are few barriers to interested individuals learning and applying engineering theory.
Our guest for this episode is Steve Hoefer, a prolific inventor and maker, whose work is documented on the Grathio Labs website.
Steve was raised on a farm, so he learned problem-solving skills from an early age.
Although having a desire to write science-fiction, Steve minored in computer science while in college.
Steve’s first computer was a Texas Instruments TI-99, while Jeff was introduced to home computing on a Tandy TRS-80, nicknamed the “Trash-80.”
After deciding that the college scene wasn’t meeting his needs, Steve moved out to San Francisco to find a job building web sites.
Clients turn to Steve’s problem-solving skills when they’re uncertain as to whether a solution actually exists.
Being a generalist has provided Steve with useful “cross-pollination” skills and insights.
Steve references a chart about knowing what you know.
Makers can be limited by issues they don’t know that they don’t know.
On the other hand, engineers may be limited by a lack of application knowledge that makers possess.
Steve is of the opinion that the maker movement may produce more engineering jobs, rather than decreasing the need for traditionally trained engineers.
Portfolios are important in conveying your skills and excitement to others.
Steve finds Stack Overflow a useful resource for finding answers and discovering possible collaborators.
Listeners can follow Steve on Twitter as @grathio, or contact him by email via steve ..at.. grathio.com
Thanks to Steve Hoefer for permission to use his photo of a “Quick And Dirty IR Camera Remote.” Podcast theme music provided by Paul Stevenson
This week we talk to Ian Dees, software engineer at Tektronix focused on mid level software and ways to improve the longevity of electronics that use software over time.
Ian focuses mainly on C and C++ but also moves into higher level languages and other aspects of product design while working on oscilloscopes.
What makes things sustainable 10 years down the road?
Architectural changes (that’s “refactoring”, not “rewriting”) can really help short term changes.
Planning schedules can end up affecting longevity. However, making software (or hardware) too extensible can create paralysis analysis.
Software designers often have to deal with the evolution of languages as well, vs having similar concepts in electrical engineering and mechanical engineering over the years.
Reliability and longevity are the same thing over time.
Chris likes working on redesigns in order to learn about what not to do and how to design for the long term.
Jeff felt drawn towards different bits of software that would “solve problems” when in fact they’ll only solve one aspect and then create new ones.
Ian now works with a marketing person who doesn’t just wave off the difficulty of a task; there is trust between engineering and marketing to help get a better grasp on schedule estimation.
What would happen if engineers-in-training were subjected to a pile of code with no tests?
Jeff learned hands on with drilling and tapping threads into old mills and learning the warts in a realistic product.
Expected lifetime can also affect the longevity of a product. Should there be a planned obsolescence or maintenance schedule?
How are the DIY and engineering communities meshing as prototyping and anlysis tools become more widely available? Chris and Jeff discuss the issue with a well-known inventor in this episode of The Engineering Commons podcast.