rchiang
Kurose's book really does take the top-down approach from high level networking concepts through the application layer to the transport layer and downward. It provides just enough of the necessary details (here's a datagram with fields A and B) over a comprehensive list of all the details (here's every field, every field size, and a list of every field option).
See if this blog post helps out with sorting through the various CS subjects: https://tolerablecoder.blogspot.com/2022/03/a-short-list-of-...
There was a good run of Computer Chronicles, TechTV, and G4 for a while there. These days, This Week in Tech still exists in podcast form. G4 had a short revival as G4TV a few years back. There's nothing nearly as popular these days, but there's still lots of good ones like Waveform, SomeGadgetGuy, and AwesomeCast.
Patterson and Hennessy "Computer Organization and Design: The Hardware/Software Interface" has had 6 editions (1998, 2003, 2005, 2012, 2014, 2020) but various editions have had ARM, MIPS, and RISC-V specific editions.
- CJ Date: https://www.computerhistory.org/collections/catalog/10265816...
- Don Chamberlin: https://www.computerhistory.org/collections/catalog/10270211...
The Windows NT family of operating systems has always had the "Hardware Abstraction Layer" (aka HAL) which helped with porting the operating system to other architectures.
I don't expect any single article to cover all the details of a company that just passed it's 30th year. And even then, they're missing bits of lore, like the CEO playing ping pong as a teenager (see https://engineering.stanford.edu/news/jen-hsun-huang-nvidia-...).
This WIRED article from 2002 gives an interesting snapshot of the same company and CEO:
Meet Nvidia CEO Jen-Hsun Huang, the man who plans to make the CPU obsolete.
https://www.wired.com/2002/07/nvidia/
- Quote: "What we can do in the next five years is going to blow your mind. In 10 years, we should be bigger than Intel." (which took until July 2020)
Mercury News interview: Jen-Hsun Huang, co-founder of Nvidia
https://www.mercurynews.com/2009/10/09/mercury-news-interview-jen-hsun-huang-co-founder-of-nvidia/
I’m Prepared for Adversity. I Waited Tables.
https://archive.is/2iUbfIt's clear that just the investments that Xerox did have would have been huge had they just held on to them. That's ignoring what they could have done had cashed out less conservatively and reinvested in ongoing technology concerns the same way that Intel Capital or Google Ventures has.
Beyond that, it would have been beyond epic for Xerox to have had all the right pieces to replace a huge chunk of the high tech ecosystem by itself. Each of the successes that "should have belonged to PARC" involves VCs, hundreds or thousands of employees, business pivots, decades of existence, and plain luck and timing.
Hank Chesborough's (formerly of Harvard Business School, at Berkeley Haas School of Business last I checked) lists 35 companies that spun out of Xerox in "The Governance and Performance of Xerox's Technology Spin-Off Companies". Just that level of brain drain/distraction was bad enough at times for PARC's ongoing work.
And while SRI has had their impact in the computing industry, they also have other research labs that have very little to do with computing such as biomedical, education, and policy.
Along similar lines, while the original Ethernet was invented at PARC, Ethernet gained more popularity in industry through Silicon Valley companies like 3Com (with founder Bob Metcalfe, recent ACM Turing Award winner and ex-PARC researcher) and SynOptics Communications (with founders Andrew Ludwick and Ronald Schmidt, both ex-PARC employees).
Xerox's revenue has been slowly declining over that time (~$15B from 2002-2009, ~$20B 2010-2013, ~$10B 2014-2019, ~$7B 2020-2023). There's likely a few business-related reasons they are doing this donation now.
"As part of the donation, Xerox will enter into a preferred research agreement, called the Technology Exploration and Innovation Program, in which SRI will provide contracted research and development services to Xerox and its clients. Through the collaborative program, Xerox and SRI will identify topic areas relevant to Xerox’s core print, digital and IT Services business, with the final goal of creating proofs-of-concept and roadmaps to implementation. Xerox will also retain a branded Innovation Hub at PARC to host meetings, demonstrations and annual conferences for its clients."
It's unclear what the size of this revenue stream is compared to SRI's current revenues.
Also, while Apple did create their first chip (at least of their current families) in 2007, they did acquire 150 or so engineers when they bought PA Semi in 2008. So, that gave them a leg up compared to building a chip team completely from scratch.
I know I saw a video from around that time, but I couldn't find one online.
https://medium.com/airbnb-engineering/continuous-delivery-at-airbnb-6ac042bc7876
https://youtu.be/70luTZU-D3E?t=102
And it's easy to see that Huang and Nvidia put their money where their mouth was. The first GTC was 2009. That's 3 years before the famous AlexNet paper that's often credited with kicking off the current AI on GPUs trend.
I've always maintained that you really learn how to write code for a particular problem when you've done it three times. The first is usually to get working code, the second is to redesign it to improve some aspect (adding features, improving performance, code maintainability, etc.), and the third is when you really get it "right". Using this approach, it takes time and deliberate practice (borrowing the term from Geoff Colvin's "Talent is Overrated").
From my point of view, the core question that you're asking is "How do I get deliberate practice with coding?" There is no easy answer for this, but here are some ways to break things down so that you can come up with a plan for yourself.
1) "Clean Code"
This was brought up in another comment, but the book does an excellent job of covering many of the techniques for keeping a code base in good shape over time.
What can be trickier is 1) there are a lot of techniques, and 2) you may have a hard time taking the techniques from the book and applying them to your situation. While the examples in the book are universal, I think it's easy to get lost applying the technique to a more complex problem.
2) Applying One Technique to a Known Situation
Either start with a smaller piece of code or a medium piece of code that you know really well. Ideally, use some advanced piece of source code control that allows multiple branches. Then, start doing the practices from "Clean Code" one a time with a goal in mind, such as eliminated duplicated code, limiting scope, making functions more configurable via parameters, etc.
The real trick? Just do one of these improvement areas at a time. Do it a few times in different parts of the code. Eventually, the patterns start to emerge as to why it improves and where else it can be applied.
3) Recognizing Patterns
You may or may not have read articles/books about API design, coding style guidelines, etc. While many of those rules may seem arbitrary, as you get more practice, you'll start to see why such guidelines exist.
There will be similar patterns for how your code refactoring can improve modularity, debuggability, development time, testing, error handling, etc. Each code change may not improve all those things simultaneously, but you'll eventually start making improvements that cover more than one area of improvement.
4) Improving Your Learning Acceleration
There's a point you'll reach where you can keep refactoring, but you may not learn much more. At that point, try adding a feature. It can be a minor feature or a major one, but you'll start to see where the new feature forces your code to be refactored again. You can write a bunch of code or you can go through the "what do I need to change in the existing code base to add feature X?" as a mental exercise. In either case, you'll start to see what prior decisions may not have worked since they only considered one aspect of code improvement instead of three or four.
5) Putting All of the Above into Context
Another aspect of being a "Senior" engineer means that you recognize the problems really being solved by your software and what value it has. As you get more senior, you can answer all sorts of questions such as:
- How does the customer use this software? What pieces do they pay for? What features save them the most time/money/suffering? - What should the next features be? - What parts can be improved? Speed? Usability? Data Input? Connectivity/compatibility with other software? - What sort of documentation does the user need? - Is this software getting dated? What parts need replacing? Does there need to be a new solution (rewrite vs. continued refactoring)?
Not all of the above questions are applicable (e.g. tools used inside a company vs. a tool customers buy and use on their own computers), but being able to put the software usage into context (sort of the PM area you were talking about) and breaking down the technical context (the "senior" engineer role) are both useful skills.
You may need to go back and forth a bit between coding and reading books like "Clean Code" before the lessons really get internalized. Using the above guidelines and knowing what sort of learning process works best for yourself, hopefully you can start taking steps to improving in ways that help your career.