The balmy days of summer have made me reflect upon the past. And colleagues leaving of late make me more thoughtful. This is sort of a twist on the earlier career development talk, but with advice on how to pivot and react to the world. Of course the discourse includes a long-winded blog format that also treats on various aspects of life in tech and the human condition.
To begin, I work at a remote site (aka 'Siberia' of West Coast), so a long period of time can pass between seeing most colleagues. Even in the age of video conferencing, few parties use that class of tool, and I keep my camera covered with a yellow sticky note for other reasons.... In fact, I can work with some colleagues for years and only communicate on the phone or e-mail. When I finally do meet one of those long-distance collaborators in person, I often want to blurt out "you sounded much taller/shorter/fatter/older.... on the phone." But there really isn't an appropriate response. At one point I had mistakenly thought a collaborator was the Office Space stapler guy while remotely collaborating, and when we did finally meet, I sat stunned for the first ten minutes when I realized that I had mistaken this gentleman for an erstwhile cryptographer. The stapler guy image and the tan, fit person sitting across from me in the conference room didn't quite align.
On the other side of the coin, I do see certain people aperiodically over the course of the years, say at internal conferences or face-to-face mission meetings. In the early days of my tenure we would beat our chests and opine about all-night coding sessions, weight lifting, and other antics of youth, all with shiny, fresh cherubic faces.
Fast forward 10-15 years, and I note the weariness on faces w/ lines reflecting hours of ennui in meetings, bodies thicker around the middle from those days of eating lunch while on con-calls + fast-food while working late + more meetings + poor eyesight from poring over code and docs.... There is an occasional spark in an eye recounting the past, but mostly there are discussions that entail children and who is promoted or working at company XYZ.
But the advantage of wisdom includes having a network of collaborators and a more senior role to effect change. And that position is important, because the one thing that is constant over this span of time is change, especially in the technology industry. And when it comes to disruptive trends and change in our industry, I like to think of these trends as the four horseman of the apocalypse. When a disruptive trend is afoot, you can be in one of the three places: in front of the trend (and get trampled), behind the horses (and do clean-up duty), or riding one of the horses. Given my simplified view of things, you can imagine my predilection, namely riding one of the horses and being that agent of change.
As part of riding that course and driving change, one of the trends I observe has been the movement to open ecosystems, open source, including the move from PC/AT style BIOS to firmware environments like UEFI and its edk2 based development on tianocore.org. The salient portion of system software work, whether operating systems like Linux or edk2, includes openness and ecosystems. That's where open source can help. Marc Andreesen rightly noted that software is eating the world http://online.wsj.com/news/articles/SB10001424053111903480904576512250915629460, and now open source software is eating software http://readwrite.com/2013/12/12/open-source-innovation#awesm=~oIwdZdqu0YdTo8.
This tend of open source source helps inform innovation paths, too. Whether the discussion includes the minimal features to exemplify a capability, such as a micro-hypervisor using hardware virtualization https://github.com/udosteinberg/NOVA, or showing how a full UEFI edk2 implementation on Quark (1MByte image) can scale down to a 64-kbyte solution with "TinyQuark" http://firmware.intel.com/sites/default/files/Intel_Galileo_TinyQuark_64K.zip for https://firmware.intel.com/projects/get-started-intel-galileo-development-board. Why zips for the latter and not checked into an upstream open source IA firmware ecosystem? That's a discussion for another day. These small examples prove an innovation direction ahead of broad product execution that may embrace some of the design precepts demonstrated therein.
Another example of openness and innovation is network boot. Recall my description of IPV6 network booting at http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html. I'm a big fan of pre-OS networking https://www.researchgate.net/publication/258834396_A_Quick_History_of_UEFI_Networking and I chair that subteam, along with security, in the UEFI forum.
Since that discussion the options at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml have been expanded by my friend at HP Samer El-Haj-Mahmoud http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf. The essence of these new options is to allow the UEFI machine to express that it has the ability to boot using a TCP-based, or connection-oriented protocol like HTTP, versus today's TFTP-based PXE wire protocol. This allows for more robust and scalable deployments without the need for retries and timeouts that afflict the UDP-based TFTP deployments.
Regarding this exchange, the technologist doesn't want to break the cathedral's feature since both parties often work for the same company. But the technologist does observe these business facts to his colleagues, namely that the bazaar has the potential to power this disruption. Given that potential, why not disrupt yourself? I use the analogy of driving down I-5 to Portland. I can mind the fuel gauge and re-fuel when necessary. This entails diligence in observing the physical reality of an automobile. Or I can ignore reality and run out of gas in the middle of the interstate. The fuel constraint is like the competitive technology, you should only ignore at your own peril and 'control' the phenomena as best you can.
In the thick disruption and openness, being open also helps solve the outside-in problem. Sometimes a technologist in the cathedral wants to drive something that the other priests in the cathedral are loathe to support. So the 'outside-in' strategy can include getting customers (i.e,. the 'outside') excited and pulling the internal team (i.e., the 'inside') to respond. This is the less-kind version of http://knowledge.wharton.upenn.edu/article/outside-in-strategy-for-the-c-suite-put-your-customers-ahead-of-your-capabilities/ since recalcitrant priests may be caught flat-footed to respond to the customer request once the outside-in push accelerates. But by enjoining the outside with open source ecosystems, there is a ready substrate to help the cathedral meet the incoming business request. Essentially the bazaar is the join point and shared infrastructure to evolve technology between partners, such as common open source code into which the cathedral can accrete its features.
The other fact I have realized over time is that everyone has their own cognitive frame and history. This is where the humanities http://blogs.scientificamerican.com/cross-check/2013/06/20/why-study-humanities-what-i-tell-engineering-freshmen/ still have a place in engineering. The arts teach 'how' to think and embrace change. Whether its the questioning of all premises in the spirit of Socrates, realizing the arbitrary language games of many conversations via Wittgenstein, or treating the world with skepticism that is resolved via Popper-like proofs and refutations. Take these words with a grain of salt, of course, as my bachelors degree is in electrical engineering and my masters in computer science. Thus you're reading the advocacy of an autodidact in the humanities, not a lettered representative therein.
And sometimes you just need time to be alone with your thoughts.
And you have to leave your ego at the door. The best advice I received on this point came from Andrew Fish, who once confided in me his secret, namely when you are in the thick of a debate and you realize that you are in the wrong, do the 'flip', or embrace the interlocutor's position. There is no shame in evolving your position in light of additional data. The flip should be done with due care and consideration lest you become a relativist or perceived as wishy-washy, but you must observe the truth when you see it. Part of leaving your ego at the door also includes taking criticism and feedback. You will often be incorrect, or not everyone will love you or your ideas, especially if you are on the wave front of a disruption. And the more you disrupt, the more ire you might draw from your peers and the incumbents. And following Rumsfeld, "Learn to say `I don't know.' If used when appropriate, it will be used often."
And you must also always tell the truth. My best advice in this vein comes from Mike Richmond: "Never lie, but don't always tell everything." Telling the truth and being genuine eases the burden of having different stories for different parties and having to compartmentalize yourself. You will ultimately succeed on being transparent and delivering value, not on dissimulation and currying favor.
Another piece of advice includes finding the true root cause of an issue. It's quite easy to 'blame' other people, or the ad hominem attack, since the targets are nearly inexhaustible, with the last number I heard pinning the figure at a world population of over seven billion people in 2013. This class of attack sows enmity and reduces your credibility since a barbed tongue replaces truth. But the technique goes pretty far, especially within companies. Only when existential realities like external market forces or internal resources enter the fray does this technique lose its potency.
Also, I observe that technologists who were most successful in the last disruption have difficulties in adapting to the next trend. I analogize this to the armies in the wake of World War I (WWI). In that conflict, trench warfare prevailed and the best defense devised for future conflicts by the French was the Maginot Line, or an armored variant of a trench covering their border. When World War II occurred, airplanes flew over the line. The quote that is often related to this historical event includes: "generals always fight the last war, especially if they have won it."
In the technology industry, you can imagine the parallels to the Maginot Line. Specifically, the technologist who drove the last disruption may be loathe or unable to address the next one. To me, you should always acts as the challenger, or a recent colleague graduate, with something to prove. The technology industry doesn't respect tenure. It instead demands results. And as Heraclitus said (now we're going pre-Socratic), "you can never step in the same place of a river twice." In the river of technology, that has never been more true than today.
But spotting trends is tough. I recall the exuberance of Gilder's Telecosm. This hasn't aged as well as Grove's or Christensen's books, I fear. It turns out that the fiber of the Telecosm became the conduit for the web and data traffic that drove the new businesses, such as Google.
And having a network doesn't just include your co-workers. Your network should span other industries and companies - see advice on same at http://www.forbes.com/sites/ricksmith/2014/07/02/5-career-mistakes-you-will-regret-in-10-years/. I still remember my first trek to the Intel Developer Forum where I presented in 2003. The then-CTO of Sun Greg Papadopoulos said in his keynote "All of the smartest people don't necessarily work for your company." Your company does have the smartest people who are both dialed into the road map, strategy and capabilities of that enterprise, though, so I believe the advantage still goes to the company - necessary for success, but typically not sufficient (i.e., the 'if' but no the 'iff'). To close the sufficiency argument (and get to 'iff'), alternate views and help of others, especially in open ecosystems I've described in this posting, are key. As evidence of same, just throughout these recent blog entries you'll find reference to colleagues both within and outside of my company from whom I have had the honor to learn and collaborate over the years.
So you might not always guess right, but by enjoining the community with openness, listening, and reacting to the customer and acclimate market needs, you'll do fine. The tactics might include a pivot, flip, or re-plan, and through all of those actions remain genuine, honest, and work hard.
Speaking of working hard, time to get back into the melee and cease by blog graffiti on the wall of the internet.
To begin, I work at a remote site (aka 'Siberia' of West Coast), so a long period of time can pass between seeing most colleagues. Even in the age of video conferencing, few parties use that class of tool, and I keep my camera covered with a yellow sticky note for other reasons.... In fact, I can work with some colleagues for years and only communicate on the phone or e-mail. When I finally do meet one of those long-distance collaborators in person, I often want to blurt out "you sounded much taller/shorter/fatter/older.... on the phone." But there really isn't an appropriate response. At one point I had mistakenly thought a collaborator was the Office Space stapler guy while remotely collaborating, and when we did finally meet, I sat stunned for the first ten minutes when I realized that I had mistaken this gentleman for an erstwhile cryptographer. The stapler guy image and the tan, fit person sitting across from me in the conference room didn't quite align.
On the other side of the coin, I do see certain people aperiodically over the course of the years, say at internal conferences or face-to-face mission meetings. In the early days of my tenure we would beat our chests and opine about all-night coding sessions, weight lifting, and other antics of youth, all with shiny, fresh cherubic faces.
Fast forward 10-15 years, and I note the weariness on faces w/ lines reflecting hours of ennui in meetings, bodies thicker around the middle from those days of eating lunch while on con-calls + fast-food while working late + more meetings + poor eyesight from poring over code and docs.... There is an occasional spark in an eye recounting the past, but mostly there are discussions that entail children and who is promoted or working at company XYZ.
But the advantage of wisdom includes having a network of collaborators and a more senior role to effect change. And that position is important, because the one thing that is constant over this span of time is change, especially in the technology industry. And when it comes to disruptive trends and change in our industry, I like to think of these trends as the four horseman of the apocalypse. When a disruptive trend is afoot, you can be in one of the three places: in front of the trend (and get trampled), behind the horses (and do clean-up duty), or riding one of the horses. Given my simplified view of things, you can imagine my predilection, namely riding one of the horses and being that agent of change.
As part of riding that course and driving change, one of the trends I observe has been the movement to open ecosystems, open source, including the move from PC/AT style BIOS to firmware environments like UEFI and its edk2 based development on tianocore.org. The salient portion of system software work, whether operating systems like Linux or edk2, includes openness and ecosystems. That's where open source can help. Marc Andreesen rightly noted that software is eating the world http://online.wsj.com/news/articles/SB10001424053111903480904576512250915629460, and now open source software is eating software http://readwrite.com/2013/12/12/open-source-innovation#awesm=~oIwdZdqu0YdTo8.
This tend of open source source helps inform innovation paths, too. Whether the discussion includes the minimal features to exemplify a capability, such as a micro-hypervisor using hardware virtualization https://github.com/udosteinberg/NOVA, or showing how a full UEFI edk2 implementation on Quark (1MByte image) can scale down to a 64-kbyte solution with "TinyQuark" http://firmware.intel.com/sites/default/files/Intel_Galileo_TinyQuark_64K.zip for https://firmware.intel.com/projects/get-started-intel-galileo-development-board. Why zips for the latter and not checked into an upstream open source IA firmware ecosystem? That's a discussion for another day. These small examples prove an innovation direction ahead of broad product execution that may embrace some of the design precepts demonstrated therein.
Another example of openness and innovation is network boot. Recall my description of IPV6 network booting at http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html. I'm a big fan of pre-OS networking https://www.researchgate.net/publication/258834396_A_Quick_History_of_UEFI_Networking and I chair that subteam, along with security, in the UEFI forum.
Since that discussion the options at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml have been expanded by my friend at HP Samer El-Haj-Mahmoud http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf. The essence of these new options is to allow the UEFI machine to express that it has the ability to boot using a TCP-based, or connection-oriented protocol like HTTP, versus today's TFTP-based PXE wire protocol. This allows for more robust and scalable deployments without the need for retries and timeouts that afflict the UDP-based TFTP deployments.
Processor Architecture Types
- Registration Procedure(s)
Expert Review
- Expert(s)
Vincent Zimmer
- Reference
- [RFC5970]
- Available Formats
CSV
Type  | Architecture Name | Reference |
|---|---|---|
| 0x00 0x00 | x86 BIOS | [RFC5970][RFC4578] |
| 0x00 0x01 | NEC/PC98 (DEPRECATED) | [RFC5970][RFC4578] |
| 0x00 0x02 | Itanium | [RFC5970][RFC4578] |
| 0x00 0x03 | DEC Alpha (DEPRECATED) | [RFC5970][RFC4578] |
| 0x00 0x04 | Arc x86 (DEPRECATED) | [RFC5970][RFC4578] |
| 0x00 0x05 | Intel Lean Client (DEPRECATED) | [RFC5970][RFC4578] |
| 0x00 0x06 | x86 UEFI | [RFC5970][RFC4578] |
| 0x00 0x07 | x64 UEFI | [RFC5970][RFC4578] |
| 0x00 0x08 | EFI Xscale (DEPRECATED) | [RFC5970][RFC4578] |
| 0x00 0x09 | EBC | [RFC5970][RFC4578] |
| 0x00 0x0a | ARM 32-bit UEFI | [RFC5970] |
| 0x00 0x0b | ARM 64-bit UEFI | [RFC5970] |
| 0x00 0x0c | PowerPC Open Firmware | [Thomas_Huth] |
| 0x00 0x0d | PowerPC ePAPR | [Thomas_Huth] |
| 0x00 0x0e | POWER OPAL v3 | [Jeremy_Kerr] |
| 0x00 0x0f | x86 uefi boot from http | [Samer_El-Haj-Mahmoud] |
| 0x00 0x10 | x64 uefi boot from http | [Samer_El-Haj-Mahmoud] |
| 0x00 0x11 | ebc boot from http | [Samer_El-Haj-Mahmoud] |
| 0x00 0x12 | arm 32 boot from http | [Samer_El-Haj-Mahmoud] |
| 0x00 0x13 | arm 64 boot from http | [Samer_El-Haj-Mahmoud] |
| 0x00 0x14 | pc/at bios boot from http | [Samer_El-Haj-Mahmoud] |
| 0x00 0x15-0xff 0xff | Unassigned |
These tags as part of the wire protocol for DHCP, along with the URI device path node from the UEFI 2.4 specification, errata B, allow for negotiating this download and informing the network boot program from where it was loaded, respectively. Good stuff. And I look forward to booting UEFI on the Skynet.
Openness and ecosystems also allow for bringing people along in the journey. I was shocked and pleased when one of my overseas colleagues mentioned how to escape from the 'Cathedral', namely a reference to Eric Raymond's book http://www.catb.org/esr/writings/cathedral-bazaar/ on the same. The meme infects technologists regardless of experience or culture, as exemplified by our Friedman'esque Flat World http://www.amazon.com/The-World-Is-Flat-Twenty-first/dp/0374292884.
And you have to innovate. I cannot recall the number of conversations I've had over the years which evolve roughly as follows (I'm the 'technologist' here):
[technologist] 'You can do this feature with open technology.'
[incumbent] 'Don't do that, you'll compete w/ my value proposition.'
Which is sometimes met by
[incumbent's marketing] 'It's easy to pass someone by when they are standing still.'
Exactly.Regarding this exchange, the technologist doesn't want to break the cathedral's feature since both parties often work for the same company. But the technologist does observe these business facts to his colleagues, namely that the bazaar has the potential to power this disruption. Given that potential, why not disrupt yourself? I use the analogy of driving down I-5 to Portland. I can mind the fuel gauge and re-fuel when necessary. This entails diligence in observing the physical reality of an automobile. Or I can ignore reality and run out of gas in the middle of the interstate. The fuel constraint is like the competitive technology, you should only ignore at your own peril and 'control' the phenomena as best you can.
In the thick disruption and openness, being open also helps solve the outside-in problem. Sometimes a technologist in the cathedral wants to drive something that the other priests in the cathedral are loathe to support. So the 'outside-in' strategy can include getting customers (i.e,. the 'outside') excited and pulling the internal team (i.e., the 'inside') to respond. This is the less-kind version of http://knowledge.wharton.upenn.edu/article/outside-in-strategy-for-the-c-suite-put-your-customers-ahead-of-your-capabilities/ since recalcitrant priests may be caught flat-footed to respond to the customer request once the outside-in push accelerates. But by enjoining the outside with open source ecosystems, there is a ready substrate to help the cathedral meet the incoming business request. Essentially the bazaar is the join point and shared infrastructure to evolve technology between partners, such as common open source code into which the cathedral can accrete its features.
The other fact I have realized over time is that everyone has their own cognitive frame and history. This is where the humanities http://blogs.scientificamerican.com/cross-check/2013/06/20/why-study-humanities-what-i-tell-engineering-freshmen/ still have a place in engineering. The arts teach 'how' to think and embrace change. Whether its the questioning of all premises in the spirit of Socrates, realizing the arbitrary language games of many conversations via Wittgenstein, or treating the world with skepticism that is resolved via Popper-like proofs and refutations. Take these words with a grain of salt, of course, as my bachelors degree is in electrical engineering and my masters in computer science. Thus you're reading the advocacy of an autodidact in the humanities, not a lettered representative therein.
And sometimes you just need time to be alone with your thoughts.
And you have to leave your ego at the door. The best advice I received on this point came from Andrew Fish, who once confided in me his secret, namely when you are in the thick of a debate and you realize that you are in the wrong, do the 'flip', or embrace the interlocutor's position. There is no shame in evolving your position in light of additional data. The flip should be done with due care and consideration lest you become a relativist or perceived as wishy-washy, but you must observe the truth when you see it. Part of leaving your ego at the door also includes taking criticism and feedback. You will often be incorrect, or not everyone will love you or your ideas, especially if you are on the wave front of a disruption. And the more you disrupt, the more ire you might draw from your peers and the incumbents. And following Rumsfeld, "Learn to say `I don't know.' If used when appropriate, it will be used often."
And you must also always tell the truth. My best advice in this vein comes from Mike Richmond: "Never lie, but don't always tell everything." Telling the truth and being genuine eases the burden of having different stories for different parties and having to compartmentalize yourself. You will ultimately succeed on being transparent and delivering value, not on dissimulation and currying favor.
Another piece of advice includes finding the true root cause of an issue. It's quite easy to 'blame' other people, or the ad hominem attack, since the targets are nearly inexhaustible, with the last number I heard pinning the figure at a world population of over seven billion people in 2013. This class of attack sows enmity and reduces your credibility since a barbed tongue replaces truth. But the technique goes pretty far, especially within companies. Only when existential realities like external market forces or internal resources enter the fray does this technique lose its potency.
Also, I observe that technologists who were most successful in the last disruption have difficulties in adapting to the next trend. I analogize this to the armies in the wake of World War I (WWI). In that conflict, trench warfare prevailed and the best defense devised for future conflicts by the French was the Maginot Line, or an armored variant of a trench covering their border. When World War II occurred, airplanes flew over the line. The quote that is often related to this historical event includes: "generals always fight the last war, especially if they have won it."
In the technology industry, you can imagine the parallels to the Maginot Line. Specifically, the technologist who drove the last disruption may be loathe or unable to address the next one. To me, you should always acts as the challenger, or a recent colleague graduate, with something to prove. The technology industry doesn't respect tenure. It instead demands results. And as Heraclitus said (now we're going pre-Socratic), "you can never step in the same place of a river twice." In the river of technology, that has never been more true than today.
But spotting trends is tough. I recall the exuberance of Gilder's Telecosm. This hasn't aged as well as Grove's or Christensen's books, I fear. It turns out that the fiber of the Telecosm became the conduit for the web and data traffic that drove the new businesses, such as Google.
And having a network doesn't just include your co-workers. Your network should span other industries and companies - see advice on same at http://www.forbes.com/sites/ricksmith/2014/07/02/5-career-mistakes-you-will-regret-in-10-years/. I still remember my first trek to the Intel Developer Forum where I presented in 2003. The then-CTO of Sun Greg Papadopoulos said in his keynote "All of the smartest people don't necessarily work for your company." Your company does have the smartest people who are both dialed into the road map, strategy and capabilities of that enterprise, though, so I believe the advantage still goes to the company - necessary for success, but typically not sufficient (i.e., the 'if' but no the 'iff'). To close the sufficiency argument (and get to 'iff'), alternate views and help of others, especially in open ecosystems I've described in this posting, are key. As evidence of same, just throughout these recent blog entries you'll find reference to colleagues both within and outside of my company from whom I have had the honor to learn and collaborate over the years.
So you might not always guess right, but by enjoining the community with openness, listening, and reacting to the customer and acclimate market needs, you'll do fine. The tactics might include a pivot, flip, or re-plan, and through all of those actions remain genuine, honest, and work hard.
Speaking of working hard, time to get back into the melee and cease by blog graffiti on the wall of the internet.
