[2006-present] Products my team designed at Impinj
[2010-2015] Sourdough Snapshot main page
[2010-2015] Sourdough Snapshot available on Amazon
[2010-2015] Some fun with the backstory at Sourdough Snapshot
[2000-2007] Ph.D. Research as published in the IEEE Journal of Solid-State Circuits no subscription? try the [Unformatted draft]
My philosophy reflects my experiences and guides how I approach projects. I appreciate others that contemplate design philosophy.
This topic takes more than a page and is continually under revision.
Hardware
Every new project starts off as a log jam ● Make reasonable assumptions and press forward knowing you will need to go in reverse ● Napkin math, although not emotionally comforting, is surprisingly accurate ● Distinguish between non-negotiable specifications, negotiable specifications, and best-effort specifications. Iterate as much and fast as possible on “negotiable specifications” ● As specifications iterate into equilibrium, try to get the numbers to move in the direction of “hard to meet” to “easy to meet” so clients of the specification do not have to rework ● Despite the reality that development does not move linearly (“2 steps forward 1 step back”), hardware development should still follow some kind of methodology with milestones, group evaluation, and checklists ● The cost of a bug in the next milestone is 3 to10 times more expensive to fix – geometric pain ● Hardware should be deliberately designed, not just “it works in the lab”
Team
Ask others to show their work and answer questions ● Expect others to ask you to show your work and answer questions ● Scheduling is hard, especially when a schedule includes R&D ● Let people make controlled mistakes and learn from those mistakes ● A clearly-stated personal commitment motivates better than a unilateral order ● Innovation does not occur in a vacuum ● Dogfood your product ● "Play nice with the locals": embrace the community style guide, community tools, and documentation conventions ● Fail-fast in code, fail-fast in the system, but have patience with the market ● Good leaders make decisions, make adjustments, and do their unfair share of the bad stuff ● Individual contributors are not faultless when the team takes on misguided tasks, speak up ● Be scrappy about working around roadblocks ● Nihilism and progress seem to travel together. You need to tear things down a bit to move forward sometimes ● Be positive but honest and realistic ● We all have strengths and weaknesses
Software
I have watched software projects with 20-40 man years get beat by a different team that required less than 6 man months. This spiraling phenomenon is scary, cautionary, and fascinating – I have opinions on why these “tar pits” happen – or rather we can all agree to read Joel Spolsky or Fredrick Brooks or an equivalently inspired book/blog ● I gravitate to people who read code and delete code, more than to people who write code (is the developer listening and watching?) ● Try to stitch large pieces of unfamiliar code together without slipping into the abyss of a rewrite ● Even in a complex program, each single line of code can be simple. A distracted human brain should easily follow the instruction pointer ● Try new software tools ● Software projects should usually start from the bottom knowing rewrites are inevitable. Build a partially working solution. Learn. Delete. Then try mid-term and system planning.
Chris Diorio, CEO, Impinj
Todd Humes, SVP Hardware, Impinj
Marc Yun, Engineering Manager, Facebook
Jay Iyer, System Engineer, SpaceX
Cameron Charles, Program Engineer, Amazon
Chris Gray, Principal Software Developer, Microsoft
Andrew Houck, Professor, Princeton University
Contact me via linkedin here.
