"Hello, World!" A Short Recap of Thoughts on Industry...

Long time no chat 😜

Surprisingly, I am *not* dead (although did I come close during one particularly bad China trip). A lot has happened since undergrad - got my masters, industry-ed for ~3 years, shipped millions, went blonde, etc. Regretfully (or maybe luckily hahaha) most of that can't be shared due to friendly Silicon Valley NDAs :)

As a sort of time capsule exercise, here are a couple of personal realizations amassed thus far.

1. Life expectancy in the US is about 75-80 years. 
• Given that I'm in my mid to late twenties while writing this, I have about ~50 years of life left. In which case, 5 year increments are about 10% of my remaining life. 
2. Industry is almost entirely dominated by the manufacturing machine. 
• The manufacturing machine feeds on optimization. This in turns means low-risk, high volume, high reliability, fast turnaround. However, this also means that often enough:
• Priorities are placed on "what" and "how much", less so on "why" and "how come". 
• Novelly creative designs aren't highly valued (since it may be more risky, slower to manufacture, harder to plan out/around, etc). New ideas are often met with skepticism, but this is understandable. 
• Nonetheless, make sure you've the right spec/figure of merit priority before heading down any single execution path. Challenge yourself - always think of at least 3 different implementations before settling with any single one. Sometimes your first idea isn't the best.
• Don't become enamored with one implementation style. "If all you have is a hammer, everything looks like a nail." 
• The adage "all models are wrong, some are useful" is forever true. People often (accidentally) mislead with data. Always keep a watchful eye out... Double check everyone's data / model / assumptions (including your own!!!) 
• Don't assume that people understand what you're saying (and don't assume you understand what they mean!). Give your instructions / suggestions / comments, and then ask the person to reiterate what *they think you meant*. Do the same for when you're given task! Most communication problems stem from small misunderstandings.
• Budget enough time for rigorous analysis beforehand. Problems will haunt you if you don't. 
• While I understand that *certain* product cycles may not have enough time for full simulations/mock-ups, this "we don't engineer, we make a ton of configs at the build" technique only works for companies with more money than time... 
• Also the whole "million different configs" method forever involves drama. Limited build quantities means everyone has to share. The worst result is people not getting the right data (either too little or too messy). Other stressful consequences range from overly long builds to overly chaotic build matrices - all with a huge dollop of engineering drama. (Whose units can we use for this config, when are they going to be inputed, who gets the final allocation, is this going to disrupt Reliability's quantities, etc.)
• No one is above Murphy's Law. 
• You'll almost always end up regretting shortcuts. The worst shortcuts are the forgotten ones. Those are a nightmare to debug. 
• People like to say root-cause matters, but often completely forget its importance once there's a tight enough tourniquet around the wound (note: horrible mindset to adopt). 
• As matter of personal principle, *always* nip failure modes in the bud. What might be a 3-off or 5-off in the first build rapidly grows to become a fail rate of 10%, 30%, 50%, etc in subsequent builds. Early problems often have relatively easy solutions - had you implemented the fix a few builds ago! Never skip your debug/analysis chores. 
• Occam's razor is sharp. Before going after some crazy, complicated theory, always cover all your basics. Check the obvious things you assume *must* be working. Systems can be majorly screwed from the simplest things. 
• Divide and conquer. Split your debug tactics logically. Try to check SW then HW then branch down into a decision tree until you know if the issue is either completely SW or completely HW (or somehow tangled in both, although that's extremely rare). Once you've understanding of the true root-cause, *then* brainstorm solutions. Always take the SW fix if you can (then you can avoid waiting for another expensive build, reliability testing, etc)
• Large scale debug typically consists of data correlations, odd distributions, and borderline rude emails asking why distributions look so bad. 
• *Always* do the correlation study first. It's cheap (no need for physical hardware, can be done anywhere at any time), relatively fast, and can give you a lot of insight. When starting, just plot everything. True, correlation doesn't mean causation, but sometimes bizarre things end up correlating in ways that do make sense (ex: a high PMU temp correlating to large decreases in battery SOC). Go overboard first, then fine tune. 
• A few choice CDF plots can save your product.  
• Your work must be useful to the company/product (this should be self-evident). The only way to get projects you want is to sell them in terms of company/product benefit. This will place artificial limits on what you do with your time. 
• You wear a lot of hats. Sometimes you'll have to play program manager, test engineer, build lead, statistician, salesman, psychiatric counselor, and lastly electrical engineer all in one day. 
• Some people genuinely love all of this. Although I may never understand why/how they do, I've come to accept that people exist on axes orthogonal to my own.
3. Visceral technology consists of improvements in the following: 1) Energy, 2) Time, 3) Space, 4) Mind:Mind Interface, 5) Mind:Machine Interface.
• If your technology (*cough cough consumer electronic*) doesn't either 1) improve one of those 5 significantly, or else 2) improve at least two of those decently, then it's not going to make much of an impact. At best, it'll be regarded as some weird Silicon Valley toy. 
4. Having all the money in the world doesn't matter if you don't have time to spend with your friends and family. 
5. Understand your personal motivations and agenda. Remember, you are not an open-loop system! If you can re-identify your personal motivations and agenda again, you can always negative feedback back. Also, just as the input signal can vary with time, so can you! Don't beat yourself up if your goals have changed/evolved since years and years ago. Just be the very best closed-loop system you can! 

Anyway, I'm planning to blog again because I miss the virtual ether of the internet. 

See you all soon! 😊