Lessons from David Patterson

Lessons from David Patterson

David Patterson co-invented the RISC architecture, which permanently changed how microprocessors are built. He later helped develop RAID storage, the open-source RISC-V instruction set, and Google's Tensor Processing Unit. This collection organizes his advice on hardware engineering, academic research, and career strategy.

Part 1: Academic Research & Mentorship

1. On Initiative: "Show initiative, for fortune favors the bold. Don't wait for professors to tell you what to do; if we were good managers, we probably wouldn't be faculty." — Source: [How to Have a Bad Career in Research]
2. On Responsibility: "Professors offer opportunities, but it is what the student does with those opportunities that makes or breaks their career." — Source: [Advice to Graduate Students]
3. On Reverse Mentorship: "Students should teach their professors about what they are working on, including what they have learned outside of the classroom." — Source: [Penn State Research Notes]
4. On Early Involvement: "Get involved in a research project as an undergraduate student. A classic thing to do is do well in a class and talk to your professor afterwards about whether there are things that you can be involved in." — Source: [Medium Reflections on Academia]
5. On Selecting Problems: "Avoid choosing issues that are too narrow or lack real-world impact; pick something where the solution actually changes behavior." — Source: [How to Have a Bad Career in Research]
6. On Ignoring Constraints: "Academic research should intentionally ignore the legacy constraints that product companies are forced to maintain, in order to find the actual optimum." — Source: [Computer History Museum Oral History]
7. On Building Teams: "The best academic research comes from small, highly motivated teams of graduate students trying to prove the entire industry wrong." — Source: [Computer History Museum Oral History]
8. On Grades vs. Research: "Focusing strictly on a 4.0 GPA at the expense of early research involvement is a mistake if your goal is to be a creator of new knowledge." — Source: [Wisconsin CS Seminar]
9. On the Role of Universities: "The university is the ideal place to build prototypes that fail, because the only consequence of failure is a learning experience." — Source: [Lex Fridman Podcast #104]

Part 2: Hardware Design Philosophy

1. On Simplicity: "Simplicity favors regularity. Coming up with simple, elegant solutions is often harder than building complexity." — Source: [Computer Architecture: A Quantitative Approach]
2. On the RISC Premise: "Processor complexity was wasting transistor budgets; the best way to improve performance was to strip designs down to their bare bones." — Source: [Lex Fridman Podcast #104]
3. On Counter-Intuitive Design: "The prevailing wisdom in the 1970s was that the best way to exploit semiconductor technology was to increase complexity. We took the counter-intuitive opposite approach." — Source: [Berkeley News]
4. On Instruction Sets: "An architecture is an interface between the hardware and the software. Making it smaller meant the hardware could be much faster." — Source: TEDxNiendorf 2024
5. On the Arm Architecture: "The 'R' in ARM stands for RISC. They shipped 10 billion ARM processors last year, more than one for every person on the planet." — Source: [Berkeley Engineering Profiles]
6. On Compilers over Hardware: "Move the burden of managing execution from silicon to the compiler. Software is easier to change than hardware." — Source: [Lex Fridman Podcast #104]
7. On Measuring Performance: "Performance is determined by execution time, not just clock rate or instruction count in isolation." — Source: [Computer Architecture: A Quantitative Approach]
8. On Common Cases: "Make the common case fast. This is the most important and pervasive principle of computer design." — Source: [Computer Architecture: A Quantitative Approach]
9. On Good Design: "Good design demands good compromises, often finding the balance between instruction count and clock cycle time." — Source: [Computer Architecture: A Quantitative Approach]
10. On Contrarian Approaches: "RISC was a contrarian approach. We were a university group proving that the largest industry players were building chips the wrong way." — Source: [mvdirona.com Technical Blog]

Part 3: The Semiconductor Industry & Moore's Law

1. On Moore's Law: "Moore's Law is over. It was a great 50-year run, but we are now in the era where transistor density no longer doubles every 18 months." — Source: [Lex Fridman Podcast #104]
2. On Dennard Scaling: "When Dennard scaling ended, we could no longer count on transistors getting more power-efficient as they got smaller, changing the entire thermal budget of chips." — Source: [Turing Award Lecture]
3. On the Golden Age: "The end of Moore's Law is not the end of progress; it is a new Golden Age for computer architecture." — Source: [Turing Award Lecture]
4. On Silicon Economics: "The cost of a chip is proportional to the fourth power of its area. Small, simple designs have massive economic advantages." — Source: [Computer Architecture: A Quantitative Approach]
5. On Industry Stagnation: "Without the free performance lunch of Moore's Law, hardware designers actually have to innovate again instead of just waiting for the next fab node." — Source: [Lex Fridman Podcast #104]
6. On Legacy Architectures: "Companies become trapped by their own success, forced to maintain decades of backward compatibility that drags down the efficiency of modern silicon." — Source: [Software Engineering Daily]
7. On Fabrication Costs: "As the cost of cutting-edge fabs reaches tens of billions of dollars, only a few companies can afford to manufacture them, concentrating the industry." — Source: TEDxNiendorf 2024
8. On Transistor Budgets: "When we started, we had a budget of thousands of transistors. Today we have billions. The challenge changed from fitting everything in, to deciding what to do with the excess." — Source: [Computer History Museum Oral History]
9. On Amdahl's Law: "Amdahl's Law strictly limits the speedup you can get from parallelizing a program if even a small fraction of the code remains sequential." — Source: [Computer Architecture: A Quantitative Approach]

Part 4: Building Systems

1. On RAID: "We realized that linking together a redundant array of inexpensive disks could outperform a single massive, expensive mainframe drive." — Source: [Berkeley Research History]
2. On Reliability: "The goal of RAID wasn't just to be cheaper; it was to use probability to make a system out of unreliable parts more reliable than a single expensive part." — Source: [Computer History Museum Oral History]
3. On Network of Workstations (NOW): "Why buy a supercomputer when you can connect hundreds of desktop workstations over a fast local network to achieve the same floating-point operations?" — Source: [Berkeley Engineering Profiles]
4. On Fault Tolerance: "In large systems, failure is not an anomaly; it is a statistical certainty. Software must be designed to expect and tolerate component failures." — Source: [Computer Architecture: A Quantitative Approach]
5. On Bottlenecks: "A system is only as fast as its slowest component. Improving CPU speed without improving memory and disk access just creates a different bottleneck." — Source: [Computer Architecture: A Quantitative Approach]
6. On Commodity Hardware: "The PC revolution proved that commodity hardware scales faster than custom enterprise hardware. NOW and RAID just applied commodity economics to the datacenter." — Source: [Software Engineering Daily]
7. On the Cloud: "The Network of Workstations project was essentially a precursor to modern cloud computing— treating a massive cluster of generic machines as a single resource." — Source: [Lex Fridman Podcast #104]
8. On Tape Backup: "RAID didn't eliminate the need for backups, it just eliminated the downtime from single-drive failures. You still need off-site backups." — Source: [Berkeley Research History]
9. On System Abstractions: "A successful system hides the complexity of its underlying components from the end user without sacrificing performance." — Source: [Computer History Museum Oral History]

Part 5: Artificial Intelligence & Domain-Specific Architectures

1. On Domain-Specific Architectures (DSAs): "As general-purpose processors hit performance walls, we have to build domain-specific architectures tailored to particular problems like machine learning." — Source: [Turing Award Lecture]
2. On the Google TPU: "The Tensor Processing Unit was designed because we realized running neural networks on general-purpose CPUs at Google's scale would require doubling the size of our datacenters." — Source: Google I/O 2025
3. On Matrix Multiplication: "Deep learning fundamentally reduces to massive matrix multiplications. If you build hardware optimized exclusively for that, you get exponential efficiency gains." — Source: [Lex Fridman Podcast #104]
4. On Hardware/Software Co-design: "The TPU succeeded because we co-designed the silicon directly with the TensorFlow software stack, rather than developing them in silos." — Source: [Software Engineering Daily]
5. On AI's Carbon Footprint: "Training massive AI models consumes vast energy. We must aggressively optimize hardware and datacenters to mitigate the carbon footprint of machine learning." — Source: Google I/O 2025
6. On Datapath Optimization: "By stripping out the instruction fetching and branch prediction needed for general computing, a TPU dedicates almost all its silicon to arithmetic logic units." — Source: [Turing Award Lecture]
7. On Machine Learning Workloads: "AI workloads are highly predictable in their memory access patterns, allowing hardware to ditch complex caches in favor of software-managed scratchpads." — Source: [Software Engineering Daily]
8. On the Future of AI Chips: "We are entering a phase where the algorithm dictates the silicon layout. The hardware will be as specialized as the neural networks themselves." — Source: [Lex Fridman Podcast #104]
9. On Reduced Precision: "Machine learning doesn't need 64-bit floating-point accuracy. Using 8-bit integers or bfloat16 allows us to pack drastically more compute into the same die area." — Source: [Turing Award Lecture]
10. On Datacenter Scale: "The modern computer is no longer the microprocessor; the computer is the entire warehouse-scale datacenter." — Source: [Computer Architecture: A Quantitative Approach]

Part 6: Open Source Hardware (RISC-V)

1. On RISC-V Origins: "We started RISC-V at Berkeley in 2010 because we needed an instruction set for our research that didn't require signing complex licensing agreements." — Source: [RISC-V Summit Keynote]
2. On the Open Source Model: "RISC-V is aiming to do for hardware what Linux did for software—create a free, open standard that anyone can build upon." — Source: [RISC-V International]
3. On Proprietary ISAs: "Tying the software ecosystem to proprietary instruction sets like x86 or ARM stifles competition and locks the industry into vendor-specific hardware." — Source: [Lex Fridman Podcast #104]
4. On Hardware Security: "An open standard allows thousands of researchers to inspect the architecture for security flaws, making open hardware fundamentally more verifiable than closed silicon." — Source: [Software Engineering Daily]
5. On Extensibility: "RISC-V was designed to be modular. You implement the base integer instructions, and you can add custom extensions for your specific domain without breaking compatibility." — Source: [RISC-V Summit Keynote]
6. On Geopolitics: "Semiconductors are a global necessity. An open standard instruction set prevents any single country or company from holding the underlying architecture hostage." — Source: [Lex Fridman Podcast #104]
7. On Educational Impact: "With RISC-V, students can actually implement a real, commercial-grade processor in an FPGA during a single semester, bridging theory and practice." — Source: [Berkeley Engineering Profiles]
8. On Customization: "Startups no longer have to pay millions up front for an architecture license; they can download RISC-V and immediately start customizing their silicon." — Source: [RISC-V Summit Keynote]
9. On Avoiding Bloat: "By keeping the base RISC-V spec frozen and small, we ensure that the architecture won't suffer from the decades of bloat that plague legacy instruction sets." — Source: [Lex Fridman Podcast #104]
10. On the 50-Year Vision: "We want RISC-V to be the universal standard for computing for the next fifty years, from embedded microcontrollers to the fastest supercomputers." — Source: [RISC-V International]

Part 7: Writing, Teaching, and Communication

1. On Writing Well: "Failing to communicate results through clear writing and presentations is a major career detractor for researchers." — Source: [How to Have a Bad Career in Research]
2. On Quantitative Evaluation: "Computer architecture was taught as an art form based on gut feeling. John Hennessy and I wrote our textbook to make it a hard, quantitative engineering science." — Source: [Computer History Museum Oral History]
3. On Co-Authorship: "Finding a good co-author is like finding a good spouse. John Hennessy and I agreed on almost everything technically, which made writing the book possible." — Source: [Lex Fridman Podcast #104]
4. On Reading Papers: "A researcher should read papers critically. Don't assume the authors are right just because it was published; look for what they omitted." — Source: [Advice to Graduate Students]
5. On Giving Talks: "Your goal in a 20-minute conference talk is not to explain every equation, but to make the audience want to go read your paper." — Source: [How to Have a Bad Career in Research]
6. On Textbooks: "A textbook shouldn't just record history; it should synthesize the chaos of current research into a coherent framework for the next generation." — Source: [Computer History Museum Oral History]
7. On Jargon: "Avoid hiding weak ideas behind dense mathematical notation. If an idea is genuinely good, it can usually be explained simply." — Source: [How to Have a Bad Career in Research]
8. On Teaching: "Teaching undergraduate courses forces you to clarify your own understanding. If you can't explain a concept to a sophomore, you don't actually understand it." — Source: [Berkeley News]
9. On Criticism: "Active researchers must have thick skin. Peer review will tear your work apart, and your job is to extract the signal from the noise of their criticism." — Source: [Advice to Graduate Students]

Part 8: Career Strategy & "Bad Careers"

1. On Strategic Ignorance: "Avoid 'strategic ignorance.' Failing to read the literature and subsequently reinventing a broken wheel is a surefire way to have a bad career." — Source: [How to Have a Bad Career in Research]
2. On Following Trends: "Chasing the current hot topic ensures you will always be a follower. The best research creates the new wave rather than riding the old one." — Source: [How to Have a Bad Career in Research]
3. On Changing Fields: "Don't be afraid to change your research focus every decade. Staying in one narrow subfield for a lifetime leads to diminishing returns and boredom." — Source: [Computer History Museum Oral History]
4. On Industry vs. Academia: "Academia lets you choose the problem; industry gives you the resources to scale the solution. Both are necessary ecosystems." — Source: [Lex Fridman Podcast #104]
5. On Burnout: "Productivity does not always equate to crazy hours. Working to the point of burnout destroys creativity, which is your most valuable asset." — Source: [Reddit Discussions on Academia]
6. On Collaboration: "The lone genius is mostly a myth. All the significant systems I worked on—RISC, RAID, TPU—were the result of intense team collaboration." — Source: TEDxNiendorf 2024
7. On Sunk Costs: "If a research project is failing fundamentally, kill it early. Sticking with a bad idea out of stubbornness is a primary recipe for a bad career." — Source: [How to Have a Bad Career in Research]
8. On Impact: "At the end of your career, you won't count your citations. You will look at whether people actually built things differently because of your work." — Source: [Turing Award Lecture]
9. On Luck: "I attribute a lot of my success to luck—being at Berkeley at the right time, meeting John Hennessy. But you have to be prepared to capitalize when luck happens." — Source: [Lex Fridman Podcast #104]