UW PMP, Patents, T-shape, Job ladders

I haven't blogged in a while. Given things in the news like generative AI you'd think I'd dive into thoughts there, especially interesting aspects like the use of probability, with my usual meanderings to related topics like Terrence Fine, Cornell, and formalists versus frequentists, etc. Or posts like https://www.cisa.gov/news-events/news/call-action-bolster-uefi-cybersecurity-now where I could possibly opine for another 900pp+ (like https://link.springer.com/book/10.1007/978-1-4842-6106-4).

Instead I was reminded of late 90's when reading https://www.quantamagazine.org/complexity-theorys-50-year-journey-to-the-limits-of-knowledge-20230817/#, specifically my time of the University of Washington (UW) in the UW PMP (Professional Masters Program) https://www.cs.washington.edu/academics/pmp. The PMP started in 1997 and I was accepted prior to the 2nd quarter having commenced, or the '2nd wave of inductees'). This was fortuitous for many reasons.  One, Intel was the largest recruiter from UW at the time, including donating a lot of equipment, and two, the other regional software companies hadn't flooded the application pool with talent form Microsoft, UW, Boeing, etc. If I had waited a few more quarters, the probability of acceptance as an 5-year-in-industy-EE-undergrad may have been tough going.  

Also, I had my first daughter during that last quarter. New tech job + around-the-clock-diaper-change + after-work-hours-studying-and-projects nearly killed me.

My 6-month-old little Husky didn't look so happy in her purple onesie on that hot day back in 1999.

Fast forward to 2023

My 6-month-old turned out to eschew the UW path, but her younger sister ended up choosing UW and is in her 3rd year

and my 2023 Husky next to her older sister

and a couple of my favorite things my UW daughter gave me include a box years ago

and then this coin when she entered UW

that I keep in the box.

As part of that program, the computer science department hosted a welcome event at the Pacific Science Center in downtown Seattle next to the Space Needle. There were many UW professors in attendance, included a newly minted graduate from Caltech named Chis Diorio who had worked with Carver Mead on hardware neural nets. Part of his research entailed work on multi-level cell storage, and Intel had a significant history and products around NOR storage at the time, so Chris asked if I could connect him with any other Intel folks. Diorio has done pretty well in the intervening years https://www.impinj.com/library/blog/impinj-named-a-finalist-in-two-categories-2023-geekwire-awards with Impinj, too.  My learning from this interaction is as follows: always assess if the value others see in the conversation with you are because of the 'person' or the 'platform'. In this case I suspect it was the 'platform', namely my employer.

Speaking of Carver Mead, it's interesting to see the wisdom of pioneers potentially resurface. Namely, reading https://www.techradar.com/pro/nvidia-beware-ibm-has-a-new-analog-ai-chip-that-could-give-the-h100-a-run-for-its-money made me think of https://www.amazon.com/gp/product/0201059924/. This is definitely a contrast to the digital state-of-the-art sort of read I found in https://www.amazon.com/Efficient-Processing-Deep-Neural-Networks/dp/168173835X, for example.

So after a couple paragraphs, how does this relate to the Quantum magazine article? Well, another professor was Richard Karp, viz., " In addition, the American complexity theorist Richard Karp proved that the universality property identified by Cook (and Levin, though Karp and Cook didn’t know of Levin’s work until years later) was itself all but universal".  More details on Karp can be found in https://en.wikipedia.org/wiki/Richard_M._Karp, including "Apart from a 4-year period as a professor at the University of Washington, he has remained at Berkeley. From 1988 to 1995 and 1999 to the present he has also been a research scientist at the International Computer Science Institute in Berkeley, where he currently leads the Algorithms Group."  And what was my interaction with this esteemed Turing Award winner?  After Karp introduced himself I replied, "ah, I guess you get to work on things like compilers and stuff." My learning from this interaction 20 years later is as follows:  always do your homework on the group with which you are interacting ahead of time.

The late 1990's had other great interactions. Having come up to Seattle from Houston, Texas, I couldn't but help to name my proposed Test Executive, or test framework for firmware, 'TEX", when working with Eric Hudnell. Or the spirited discussions with Andrew Fish in 1997 about ASIM (Advanced Server Information Modules), or a way to decompose our server firmware prior to the next of many, many 'modularization' initiatives, such as Intel Boot Initiative (IBI) and Davinci/Kittyhawk BIOS in 1998, EFI in 1999 Framework in 2000, ...... My retrospective learning: infrastructure evolution takes time. There are few 'short wins.'

A lot of those interactions above also entailed wisdom from others. I still recall a director who told me about the plan/clue matrix for engineers. Namely, you aspire to working with someone who has a 'Plan + Clue.'  They are effective and directed.  The 'Clue but no plan' are often visionaries/strategists in that they know where to go but not how. The 'Plan but no clue' are the scariest since they are akin to a bull in a china shop- they have a lot of kinetic energy to expel but perform the drunkard's random walk in plotting a path. Finally, the easiest to handle are the 'No plan and no clue' since they are largely inert/ignorable. Cook reminded me of this early 2000 wisdom in his posting https://www.johndcook.com/blog/2010/12/27/dumb-and-gets-things-done/. 

Speaking of wisdom, I was asked to give some patent training last week. One of the pieces of wisdom I always offer to folks on patents is to have a sense of urgency, especially with the normalization of invention primacy with 'first to file' and the American Inventors Act a few years back. I often put this urgency in the context of the industry, namely invoking Joy's Law "no matter who you are, most of the smartest people work for someone else,” https://en.wikipedia.org/wiki/Joy%27s_law_(management). What that means for inventors is that given similar problem statements and the frontiers of knowledge, others may come up with similar ideas. But what you have within a large company is perhaps earlier access to the problem and/or the frontier of knowledge since Fortune 100's like Intel often 'create' said knowledge. 

I also try to temper the patent presentation to put patenting in context. First the positive where I mention the ability to get patents as a software person in a hardware company (data also mentioned a year ago in http://vzimmer.blogspot.com/2022/09/new-milestones.html), viz.,

but then I remind the audience that patents are part of delivering value, not a means in-and-of-themselves (including quoting this blog from 10 years back http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html), viz.,

From the patent milestones you see the title "Fellow." This is one of the highest designations of a technical-track employee, as distinct from management-track, employee at Intel. Many tech companies have similar designations, and I culled a comparison of the Seattle area shops below https://www.levels.fyi/?compare=Amazon,Intel,Google,Microsoft&track=Software%20Engineer

NB
Someone might question why I continually show an image from a website that others can find themselves. I guess I have two answers. One, I learned that content on the web ages out or evolves, such as top inventor Wikipedia started to subset its listing. And two, for better or worse a colleague introduced me to the MS Windows 'snippet' tool and the barrier to image creation was significantly lowered for me :)

Speaking of old blogs in 2013, I should probably reprise http://vzimmer.blogspot.com/2013/03/a-technical-career-path.html since I discovered the T-shaped model https://collegeinfogeek.com/become-t-shaped-person/ and have used it a lot since in mentoring people. Then the other part of me notes that I also usually advise people that 3-7 years is optimal occupancy time in a grade level, say 9, prior to becoming a 10. Too short a time and you don't have time to generate sufficient evidence to prove you delivered at that last level, and too long you become stale and people ask 'why now?' As I roll into year 10 as a Senior Principal Engineer or grade 11, I am in the 'why now' camp where people can dismiss earlier accomplishments in the decade as not fresh or of insufficient merit since if they were, I would have been acknowledged then. As such, I challenge myself as to whether I am the right person to be dispensing 'career growth wisdom' if my career isn't growing. 

There are many great engineers in the Sr. PE community, including the two I mentioned in the last blog who retired, Sham and Kirk. And as the company matures, this cohort continues to grow in cardinality. But it does make me wonder if it's a terminal level, or sort of a tech elephant's graveyard

 

I couldn't help but use that metaphor since found the image arresting from reading Tarzan? or some such as a youth.

More likely it's the other career advice I give folks, namely that getting promoted is a lot like real-estate opportunities, namely 'timing and location.' Since promotions are a meld of business impact, technical acumen, and leadership, not all role or organizations afford opportunities for the same, or that triple may not be as business relevant as the market moves or the exigencies of the employer change.

I like to stand outside of the phenomena and observe it sometimes. Thanks Marcus Aurelius and Seneca, too, for the classical doses of introspection and stoicism, respectively.

Maybe part of it is the reality expressed by Corey Quinn

Corey Quinn (@QuinnyPig) / X

Twitter

https://twitter.com › QuinnyPig

From what I can see, getting promoted at a big tech company is roughly four times
harder than getting that job at another company.

(I apologize for the rough copy-paste of a Google-search-of-a-Tweet).  The gist of the sentiment above is that the new company wants to believe in you and leans in, whereas your present employer knows all of the defects of an internal candidate and perhaps subconsciously over-indexes on them. Another area where I have seen Quinn's assertion in practice is that if things are not going well in a company, outsiders from successful companies are seen as more attractive since the internal candidates are the ones who 'contributed to the company and its ills' (i.e., why promote the arsonists?); of course this confuses correlation with causation on both internal and external candidates to a first order since rarely is a single individual responsible for the ills or gains of any large company. Finally, one reason that Quinn's logic holds is that as the business evolves, it is necessary to important new skills for the new business domains, as distinct for taking the time or risk of 'up-skilling' the present bench; I still recall in my early days why hiring was prolific that the 2nd line manager told us 'we need the exact skills. There is no slack in the schedule to train someone up over three months.' 

Or maybe it's related to the business cycle? Just as Ben Horowitz opined about 'wartime versus peacetime' CEO's https://www.linkedin.com/pulse/wartime-vs-peacetime-ceo-insights-from-hard-thing-things-pandey/, maybe there's a similar dynamic that applies down the stack, including technologists? The market dynamic might argue for loading the bench with more 'wartime'-minded folks? Or does the company need more 'referees' versus 'risk takers?'

So the magic bullet is job flipping employers then?  Maybe, or maybe not. I've always found the promotion-through-job-change risky in that the grass isn't always greener. You'll see from zoom in of above 

that my present job code overlaps with Microsoft 'Partner,' for example,  I recall one Partner Architect at Microsoft, now retired, telling me that at MS the title 'Partner' is also code for "throw the other Partner under the bus" job description. Namely, it's an understandably competitive peer group when total compensations can easily exceed $1million/year. Similar for my slight overlap with Amazon Sr. PE. I recall asking an Amazon executive what happened when someone was hired at too high a grade level. His glib reply was 'Oh, that?  We take care of those situations quickly.' Woof. 

So what's my parting advice on this blog postings sidetrack on careers? Enjoy the trip. Add business value. Learn. Appreciate contributing to and receiving wisdom from others. And promotions are a Faustian deal, too. As Goethe expressed in this epic, be careful what you wish for. namely the pursuit of power can entail a deal with the devil, etc. The $1million/year compensation isn't because the employer admires your bio and portrait as a 'new partner.' Instead, it represents an expectation of output against both business goals and your new peers commensurate with this compensation. And these days it's delivering value on 'internet time.' 

I've never worked in the high-flying world of silicon valley or startups either, but I suspect that there's no 'rest and vest' on a California tech building roof like https://silicon-valley.fandom.com/wiki/Big_Head in almost all cases. But if you enjoy the trip, moving up the tech job ladder can be awesome. You will be at a technical level aligned with Vice-President+'s of the management track and the role should provide more of an opportunity to make a dent in the universe as a technologist as you advocate for and drive insanely cool technical progress.

  

And the world keeps changing

 I'm a long-time fan on Twitter. I still recall merging onto I-5 years ago and listening to some tech podcast about this new 'micro-blogging service', namely Twitter. I still keep up with https://twitter.com/vincentzimmer and don't worry so much about the vagaries of ownership or management. But I was intrigued by the discussion of other services like https://mastodon.social/explore. As such I setup an account and posting some material akin to what I saw from another Twitter person regarding some personal metrics for 2022 https://mas.to/@vincentzimmer/109549960566794774, including a reply to myself with another random observation this week https://mas.to/@vincentzimmer/109550056099262201.

This is my first post to mastodon: 

"Interesting 2022. First journal pub https://www.mdpi.com/2410-387X/6/4/48 although waiting for red box on https://dblp.uni-trier.de/pid/34/5641.html. I also had oppty to collaborate on an IEEE conference http://www.ieee-smart-world.org/2022/uic/index.php mentioned in http://www.ieee-smart-world.org/2022/uic/uic-2022.htm. Then a couple of unrefereed items https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://eprint.iacr.org/2022/1049. Then 2 books https://link.springer.com/book/10.1007/978-1-4842-7939-7 and https://link.springer.com/book/10.1007/978-1-4842-7974-8. A podcast https://www.youtube.com/watch?v=wqcUWAEHcVg. 6 US patent filings and 7 issued.  Whew."

and

"Speaking of https://eprint.iacr.org/2022/1724, it was referenced by https://eprint.iacr.org/2022/1724. 

Latter doesn't read in on PQC aspects of SPDM but provides a formal verification of extant SPDM protocol using a theorem prover https://github.com/tamarin-prover/tamarin-prover with public proofs https://github.com/AnalysisSPDM/FormalModel. Perhaps this is a use-case to leverage for achieving a long-held ambition, namely axiomatize and 'prove' some tricky parts of UEFI, viz https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html?highlight=authenticated#setvariable and EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS?"

I try to be pragmatic about formal. I recall reading once that even in the days of the Orange books with A-level certification requiring 'formal proof' it was hard to achieve, but the attempt at least 'provided better documentation.' And at a professional level I've always mutated the 'culture trumps strategy' aphorism to be 'implementation trumps architecture.' A painful reminder of this dichotomy is having studied https://www.cl.cam.ac.uk/~lp15/papers/Auth/tls.pdf back in the day and then meeting Marsh Ray and learning of his work https://troopers.de/events/troopers10/242_history_of_the_tls_authentication_gap_bug/. Networking has been close to my heart for a couple decades as I helped grow our EFI network stack from its nascent PXE equivalent in 1999 through IPV6 https://www.rfc-editor.org/rfc/rfc5970.html and into HTTP and TLS (e.g., HTTP-S boot). I still recall reading the Rescorla book on SSL/TLS while waiting for my older daughter to be born in 1999 at the University of Washington hospital.

Perhaps if I have the opportunity in the future to use my sabbatical

I can do some thinning of the archives. Rescorla and Rudin have aged well, but I suspect I can sunset the Java duo of Aglets and JavaOS. On the other hand, though, I'm a fan of keeping around some documents of 'old tech' since there is often wisdom to be gleaned from the past.  Hmm. Decisions, decision.

Well, to close on formal, specifications, and networking, I should tie off that thought at least with a re-invocation of as always, there is no 'silver bullet.' 

These mastodon posts feel like my usual terse blog posts. Perhaps my posts are 2xM or 3xM (i.e., 2 or 3 times the text length of a Mastodon post).

This blog is usually pretty low traffic, too. The sources of eyes are either google searches or link via https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A (which included the blog links) or blogroll like https://blogs.coreboot.org/. 

With the removal of the former, I suspect there will be less traffic. That should be fine. I don't do sponsored ads or other revenue-generating activities here. It's more of a personal set of footprints in the sand to chronicle the journey.  

And luckily https://en.wikipedia.org/wiki/List_of_prolific_inventors has been curated to just the top 100, so watching my slow descent down the leader board, such as http://vzimmer.blogspot.com/2022/09/new-milestones.html and its earlier ilk, are no long a nagging distraction.

Ah well, so much for a mastodon experiment and clone+amplification to my OG blog. Back to work. Need to figure out how to add an abstraction service to code I wrote 20 years ago before 9am tomorrow....

Cheers

Feedback, tech talks, 23 or Anniversary.Next^8

This covers my 8th blog aligned with my work anniversary, a successor to https://vzimmer.blogspot.com/2019/02/tiano-147-and-22-or-anniversarynext7.html.  I've now passed the 23 year milestone.

I try to land this blog posting on the anniversary day. Regrettably I'm a few weeks late this year (OK a couple of months at think point). Thanks to Lee F. for reminding me about me dilatory blogging practices so that I can bump this out of my drafts folder.

The important thing about the trip is to pushing things forward. I hearken back to a quote from Joel Spolsky https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ "Fire and Advance." Keep pushing. Don't duck and cover. This includes engaging with theoretical debates about tech with people, esp since folks who have the time to 'debate' and not spending enough time 'doing' (e.g., firing, advancing).

One thing about the trip is that there is always criticism. Sometimes the insight is insightful, such as the FSP-S critique in https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/changes/28/36328/5/Documentation/fsp/fsp-s_discussion.md. At other times is can be a bit tougher, such as the  https://media.giphy.com/media/z9AUvhAEiXOqA/giphy.gif that Topher had as the image for https://uefi.info/.

Feedback can include specification size https://twitter.com/bcantrill/status/1219085364737888256. I am sympathetic to this approach. For example, in the PI specification we originally posted as five volumes http://www.uefi.org/sites/default/files/resources/PI%201.5.zip as late as PI 1.5 but are moving to a monolithic https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.pdf
document in PI1.7. The rationale for the smaller books is that if you were doing something like the Intel FSP, you might just want to learn about generic software objects like HOB's and Firmware Volume headers (e.g., Volume 3).

As always happens to me when I haven't blogged in a while I collect more random observations. Technology seems to run in cycles, namely the I/O Controllers (IOC's) on mainframes to abortive attempts to standardize a couple of decades ago such as I2O https://en.wikipedia.org/wiki/I2O (which could be a blog on its own where I2O apportioned the work wrong with respect to data movement) to today's Smart NIC's, safe OS's such as the 432's Ada Imax OS https://en.wikipedia.org/wiki/IMAX_432 and today's Rust-based Tock OS on Open Titan https://github.com/google/tock-on-titan. Or 'computer' companies like Honeywell going from 16-bit https://en.wikipedia.org/wiki/Honeywell_316 to quantum https://techcrunch.com/2020/03/03/honeywell-says-it-will-soon-launch-the-worlds-most-powerful-quantum-computer/.

Another interesting observation this blogging cycle... Although my patenting career has mostly gone to sleep, I was interested to see the reformulated web page https://en.wikipedia.org/wiki/List_of_prolific_inventors with company names added. I observed Intel twice - myself and Bellevue Intel neighbor Mike Rothman. Although this list not complete since it's missing Intel's Robert Chau

 (nearly 500) https://venturebeat.com/2020/01/07/a-bright-future-for-moores-law/. Other notable tech companies mentioned in the list: IBM 51 times, 4 for Broadcom, 2 Qualcomm, 1 AMD and 15 for Intellectual Ventures (just a few miles away from the office @ 405/i-90) here in Bellevue. No MS or Faang companies?  Maybe latter are too young? At the time of this posting I'm #90, but the ineluctable march of the forces of IBM will bump me out of the top 100 before the end of the year, I suspect (or edits to address omissions like I mentioned above).

Speaking of Bellevue/Seattle area, prior to the recent health quarantines, there were some pretty interesting local talks, including one from Flowers in SODO on refactoring , and any code in your source tree without tests is 'legacy code.'  --  https://martinfowler.com/books/refactoring.html

Since EDKII just upstreamed a unit test framework https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg w/ 2 tests (Safe Int Lib and reset system), I'd say it's now more on the 'legacy' side of the ledger. It was a bit saddening since the talk was hosted an office next to my former Seattle Intel office.

Although it did find the Pac NW variant of Stonehenge, it would appear.

Another good talk was in SLU for the Rust meetup,

including a Wasm talk by a Google engineer
https://docs.google.com/presentation/d/1eOaVK3b5Ye13ZF92viWETq7F8wZdBOOY_yT37JNjAPs/edit#slide=id.p with always interesting propaganda posted at their new office.

These days, though, the in-person meetups are mostly replaced by conference calls, including but not limited to Zoom, GoToMeeting, BlueJeans, Skype, Hangouts, and MS Teams.

Let's wrap up with interesting companies in the news. I mentioned oxide in http://vzimmer.blogspot.com/2019/12/rust-oxide-corrosion.html and was happy to receive some of their swag https://twitter.com/vincentzimmer/status/1233847629928452096. I also had a chance to catch https://oxide.computer/blog/on-the-metal-3-ron-minnich/ interview with Ron. Ron wrote the introduction to https://www.apress.com/us/book/9781484200711 and it's always great to hear Ron provide history and insights into technology. When we finished this book co-author Marc Jones said 'we should do one on servers.' As always in tech, it takes a little time https://www.opencompute.org/projects/open-system-firmware. Speaking of Oxide, beyond their podcast series Bryan Cantrill has also done a nice talk as part of Stanford's ee380 https://www.youtube.com/watch?v=vvZA9n3e5pc&list=PLoROMvodv4rMWw6rRoeSpkiseTHzWj6vu.  Good stuff.

300, networking, FSP, books, and good-byes

It was October of 2012 when I posted http://vzimmer.blogspot.com/2012/10/250.html.  Over a year and a half later I have finally hit 300 issued US patents 300 issued. In later posts I talked about innovation and invention http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html, so I don't have much to add.

Probably closer to my mind includes recent events. Since my last posting I had the opportunity to talk with the industry about UEFI and testing. With Ricard Neri from Intel's Open Source Technology Center I spoke at the UEFI Plugfest in Seattle last month. Our presentation and video of the same on "Open Source Test Tools for UEFI” are located at http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and https://www.youtube.com/watch?v=aV1DSF4cwGw, respectively. I will pick up on some of the topics of open source security and tools at the upcoming ToorCamp, too http://toorcamp.toorcon.net/talks/#16.

Other events that have occurred since my last posting include publication of the UEFI 2.4 specification. Items of note there include removal of the need to time stamp each UEFI network packet and manage volatile variables for the network stack. This is important because the former entails a call to the real-time clock (RTC), which is an expensive I/O operation on some systems and may entail a system management mode interrupt (SMI) trap, which has non-zero overhead to effect the world switch. Similarly on the volatile variables. Many implementations of UEFI implement all of the variables in SMM in order to protect authenticated variables, thus even an update to a volatile variable in the performance path of the network stack can entail significant overhead. My colleagues posted a paper on these issues of PXE performance at https://uefidk.com/sites/default/files/Intel_UEFI_PXE_Boot_Performance_Analysis.pdf.

Speaking of UEFIDK.COM site, I have been encouraged to blog there, but I have yet to wean myself off of this site. Hopefully my next blogs on UEFI will migrate to that location. From that site I'd also like to note the existence of

Intel® Firmware Support Package (Intel® FSP) For MinnowBoard

·         "Wrappers" and Instructions for using Intel® FSP with MinnowBoard

·         Intel® FSP is Available from the Intel® Embedded Design Center
(Intel® Atom™ processor E6xx series with Intel® Platform Controller Hub EG20T )

- See more at: http://www.uefidk.com/content/minnowboard-uefi-firmware-download#sthash.X6BoqM8T.dpuf

under http://www.uefidk.com/content/minnowboard-uefi-firmware.  This shows how to adapt the Intel Firmware Support Package, or 'consume' that binary, into an edk2 http://edk2.sourceforge.net tree. Similar infrastructure code in the coreboot upstream at http://www.coreboot.org can be found to do similar integration, or how to 'consume' the FSP http://review.coreboot.org/#/c/4018/.  These are two examples of workflows of open source firmware ecosystems that allow for building platforms with the FSP.

To provide guidance around the FSP construction, on both the 'producer' and 'consumer' side, the Firmware Support Package (FSP) External Architecture Specification (EAS) has been posted to the location

http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/fsp-architecture-spec.html. This helps to lock down the interfaces so that the above listed firmware ecosystems can align their 'consumer' source infrastructure codes.

Why FSP?  Even UEFI/Edk2 stalwarts like my good friend Tim Lewis, CTO at Insyde Software, have expressed thoughts on using edk2 for embedded, including anecdotal commentary such as http://uefi.blogspot.com/2014/04/the-tale-of-three-conferences.html

Many discussions around UEFI have to do with complexity. And there is something to these discussions, since the very power and flexibility of UEFI has led to implementations (like that on tianocore.org) which are broken into hundreds of pieces, where assembling the right one requires the right recipes. Most embedded vendors don't need their firmware distribution to be as complicated as their Linux distribution (see yoctoproject.org).

So you can think of FSP + EDK2 as one 'recipe', among many, to ease the embedded workflow in various open source firmware ecosystems. FSP helps preserve the boundary of critical silicon initialization code, with some examples found in PI Silicon Init. This doesn't describe the only mechanism, of course. But given the end goal of booting an operating system, Mille viae ducunt homines per saecula Romam.

So enough of UEFI and FSP, an additional thought on this 'milestone day' of 300 include a mention of a book that I enjoyed reading over the last few weeks, namely Ben Horowitz's The Hard Thing About Hard Things  http://www.amazon.com/Hard-Thing-About-Things-Building-ebook/dp/B00DQ845EA/. Ben was a leader at Netscape during the startup days, and his book ranks among Andy Grove's High Output Management and Only the Paranoid Survive as more proactive business books, or managing a business in a crisis. Specifically, Horowitz speaks of the distinction between the "Wartime" versus "Peacetime" CEO. He notes how Eric Schmidt was a peacetime CEO of Google, with features like the 20% time, versus Larry Paige becoming a wartime CEO, and the more narrow but aggressive product focus.

After reading Ben's book, the question I would pose is if the same analogy works for engineers, or more generally, the employees. Namely, are some employees better at peacetime, with the less stress and ability to explore more things, than in wartime, with the enhanced focus?  I personally find constraints help with focus, and Paige's 'Scarcity brings Clarity' comes to mind. Food for thought.

Speaking of thoughts, I'll close with thoughts on co-workers who have departed. Over the last day I learned about a manager with whom I worked since the last 90's has passed away. I learned a lot from his mentoring, and I especially recall a quote he made about project development at a technology company: "If upper management knew the true cost of an R&D project, they would never fund it." Fare well, Doug.

A couple of additional thoughts are for technical colleagues still with the world, but who have recently retired from Intel. One is a Senior PE from Folsom on the CPU development team. I learned many things from Steve about the trade-off between hardware and software, especially disabusing me of the fact that 'the other guy's job is easier.' I relent and the CPU microarchitects win for complexity. Talking to Steve was like reading Colwell's tale http://www.amazon.com/Pentium-Chronicles-Politics-Landmark-Practitioners-ebook/dp/B001CBCRCA/. A parting quote from Steve that sticks with me is “You will not have all the answers, but in working with the right people, you can find them.“  So true. And thanks to the 'right people' who still answer my emails, pick up the phone, and look up from their monitors when I invade their cubicle.

And last but not least, I have to comment on the retirement of George Cox. George had a rich Intel career, including setting up the first intel.com website, CDSA, iWARP, the Intel 432, and one of his last achievements, the digital random number generator (DRNG) http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0. On the latter I still recall George quoting John von Neumann, in Geoge's distinct West Texas accent: 'Anyone who uses software to produce random numbers is in a ``state of sin''' when discussing the DRNG work with me over lunch.  That work, and the 432 http://en.wikipedia.org/wiki/Intel_iAPX_432, count as epic events in just one career, and I'm still a fan of hardware capabilities http://www.google.com/patents/US8312509, especially as it's tough for 'software to protect software.' We all need a little help from our hardware friends.

Since I started the thread with patents, I'll end with patents. Intel has been a great place to work. I joked on my Google+ channel that this is the closest I'll ever get to the C-suite in response to the patent award photo at https://plus.google.com/+VincentZimmer/posts/R764RmhX7tg. In reality, though, Intel has offered me an opportunity to work with some of the smartest people in the industry and learn from them. I only hope that I can contribute back a small percentage of what they have provided to me over the years.

And with that, off to work.

Invention and Innovation

I recently returned from Shanghai. I was greeted by the following when I boarded the plan from LAX to SH, though.

There was little hyperbole in that headline, I'm afraid. Since my first trip to the Shanghai to work with our team members at the Cao He Jing site in 2001, and then Shanghai Mart in the early 2000's, and finally the Zizhu campus, the pollution and traffic have increased.

But what has also increased is the team's experience and capabilities. The energy of the Intel team always recharges me, and this trip was no exception.

These trips include working sessions, open forums, talks, and other instances of collaboration. One talk I always offer to the site is patent training, for an engineer's perspective. I want to make sure that the audience doesn't believe that I can provide legal advice, but what I can do is to provide guidance on the process within the company.

Since the process by engineers capture and idea and propose it for inclusion in a potential patent filing varies per company, what I'll discuss below entails more of a higher level view of how I think about the process, and innovation in general.

For me I see a serial relationship between Invention and Innovation, as follows:

•INVENTION

•Company feeds $’s into Engineer + Engineer’s insight in response to a Problem Statement

•Results == Patents

•INNOVATION

•Patents + Engineering + Marketing leads to product development

•Company sells products

•Results == earnings of $$$$’s (or RMB, YEN, Euro...)

-- Repeat this loop of INVENTION -> INNOVATION

So this frames the action of Invention versus the broader goals of the company, such as creating products which delight and fulfill end customer needs.  The process begins with invention, using a small 'i'. Therein an engineer is faced with a problem presently, or potentially in the future, faced by the market. The engineer devises a solution, and if it is 'novel' or distinct from other practice, it may be a candidate for formally pursuing a patent, or Invention with the capital 'I.' Of course most of our engineering problem solving is invention, but it is important to note the creation of patents because of the present nature of cross-licensing, company investment preservation in its Research and Development (R&D) spend, etc. These means the evolution of the small 'i' to the big 'I,' namely transforming invention into Invention and the associated patent applications for the latter.

With invention in hand, whether small 'i' or 'I', the long path of Innovation, or working with a team within, across, and possibly beyond the company, to deliver product. If the engineering concept was truly born of a problem statement enjoyed by the market and the team can execute on the associated reduction of the design to a shipping product, and the timing of the market is right, and....including many other factors such as the phase of the moon, resultant revenue should be borne of the activity. And as each company reinvests some revenue into R&D from whence invention is incubated, the virtuous cycle continues.

And note the emphasis on 'problem statement.' For me a good problem statement that is relevant to the business can be the source of unbounded invention, and hopefully, resultant innovation.

So invention is the idea pump that can inform product design, but Innovation is the mapping of invention into the creation of products that you ship to customers and for which you get paid.

This is how I think of invention in the context of business-driven-innovation ("BDI," oh not another acronym.....). It is perhaps a bit narrow minded and parochial, but just as I cannot see myself studying theoretical physics or maths, I feel most comfortable operating in a space where the business imperatives are manifest. Sort of like how after the Cultural Revolution in China I heard that all maths were "Maoist Mathematics", such as to support manufacturing and civil engineer, not pure maths. Maybe that explains why the Alma mater of many of my Shanghai colleagues, Shanhai Jiao Tong University, literally translates to "Traffic School" (or at least that's what they've told me)? To my mother's chagrin this is also the reason that my CV doesn't include the PhD moniker, too.

The cycle between Invention and Innovation at a large company is often tempered by the role of "Exit Champions," as well defined in the Harvard Business Review article http://hbr.org/2003/02/why-bad-projects-are-so-hard-to-kill/. It continually proves a delicate balancing act to ensure that Invention and Innovation are congruent with the business exigencies, especially given the finite resources for R&D budet allocation. But with our ever-changing market and internet-time pressure, I always feel the need to co-equally role model the 'entrance champion,' or party who delivers Invention+Innovation, as much as providing the guard rails of the 'exit champion.'

Given my love of business-driven-innovation, maybe I'll miss the next Kuhn-style paradigm shift and scientific revolution http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions, but this is where I feel I fit into the flow on this dynamic.  Enough said for Sunday blogging. And thanks for reading if you made it this far.