Shadowing Practice: "Software Fundamentals Matter More Than Ever" — Matt Pocock - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

248 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

Hello everyone, having a good conference so far?

Are you having a good conference so far?

Good, wonderful.

I have a message for you that I hope will be A comforting message for folks who believe that

their skill set is no longer worth anything in this new age.

which is I believe that software fundamentals matter now more than they actually ever have. And...

I'm a teacher and I've been recently teaching a course called Claude Code for Real Engineers.

Nice and provocative.

In the process of working on this course, I had to come up with a curriculum about

AI coding which is a bit of a nightmare because things are changing all the time, right?

AI is a whole new paradigm.

We need to chuck out all of the old rules, surely, so that we can bring in the new stuff.

And there's, kind of movement that has come up around this, which is the specs to code movement.

And the specs to code movement says that, okay, you can write a specification about how an application is supposed to work, and then you can use AI to turn it into code.

If there's a problem with the application, you then go back to the spec.

You don't really look at the code.

You just change the spec, you run the compiler again, and you end up with more code.

Raise your hand if you've heard of that.

Keep your hand raised if you've tried it.

Okay, I've tried it too, you can put your hands down.

And what I noticed was I would run it, And I would try not to look at the code.

But I would look at the code

and I realized I would get code out first of all

and then I would run it and I would get worse code.

and I did it again and I got even worse code.

I got it again, I kept running the compiler, kept running the compiler and I would just end up with garbage.

Raise your hand if that's happened to you.

Yes.

I don't think this works.

The idea that we can just ignore the code

and just have the code and let it manage itself is just sort of Vibe coding by another name.

And I didn't believe that back then.

I thought, "Okay, how do I fix the compiler?

How do I make it so that it doesn't produce bad code each time, or worse code?" And so I thought, okay, I need to explain to the LLM,

in English, what a good code base looks like.

Let me dig out one of my old favourite books, which is a philosophy of software design by John Ousterhout.

Go on Amazon, get it.

and he has a definition for what bad code looks like.

He calls it complex code.

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

Right?

So a bad code base is a code base that's hard to change.

If you can't change a code base without causing bugs, then it's a bad code base.

Good code bases are easy to change.

So I thought, ooh, that was good.

Let's try another book, let's try the pragmatic programmer.

Go on Amazon, get it.

they have a whole chapter on something called software entropy.

And this is exactly what I was seeing.

Entropy is the idea that things tend towards disaster and floating away from each other and collapse.

And this is exactly how most software systems behave too, is that every time you make a change to a codebase, If you're only thinking about that change, not thinking about the design of the whole system,

your codebase is going to get worse and worse and worse.

And that's what I was seeing.

Everything inside the specs to code idea that you just run the compiler again and again was making worse code.

Now, there's an idea that sort of drives the SpextaCode movement, which is that code is cheap.

Raise your hand if you've heard that phrase before, that code is cheap.

Well, I don't think this is right.

I think code is not cheap.

In fact, bad code is the most expensive it's ever been.

Because if you have a code base that's hard to change, you're not able to take all of the bounty that AI can offer,

because AI in a good codebase actually does really, really well.

And this means good code bases matter more than ever, which means software fundamentals matter more than ever.

That's the thesis of this talk.

So, let's actually get into practical stuff.

I'm going to talk about different failure modes that you may have experienced

or you may not have experienced yet with AI

and how you can avoid them by just going back to old books and looking at good software practices.

Sound good?

So the first one is that the AI didn't do what I wanted.

I thought I had a good idea in my head

and the AI just did something totally different or it did some like specs that I, you know, it just made something I didn't want.

Raise your hand if you've hit this mode.

Cool, okay.

Well, This is what they say in the Pragmatic Programmer, is that no one knows exactly what they want.

It's that you and the AI, there is a communication barrier there, right?

And so when you're talking to the AI, that's kind of like the AI doing its requirements gathering.

It's basically working out from you what it is that you need.

And, I realized that there was another book, Frederick P.

Brooks, The Design of Design, And it talks about this idea called the design concept.

It's that when you have more than one person designing something together, you have this idea sort of floating between you, this ephemeral idea of the thing that you're building.

And that thing that you're building, or the idea of it, is called the design concept.

It's not an asset, it's not something you can put in a markdown file, it is the invisible sort of theory of what you're building.

And so I thought, okay, that's what's going on.

Me and the AI don't share a design concept.

So I came up with a skill.

This skill is very, very simple, it's called Grill Me, and it looks like this.

Interview me relentlessly about every aspect of this plan until we reach a shared understanding.

walk down each branch of the design tree, which is another thing from Frederick P.

Brooks, resolving dependencies between decisions one by one.

This skill is like, the repo containing this skill has like 13 ,000 stars or something, it just went nuts, went viral, people love this thing.

These couple of lines means the AI asks you like 40 questions,

60 questions, I've had it ask people 100 questions before it's satisfied they've reached a shared understanding.

And it means it turns the AI into a kind of adversary where it's just continually pinging you ideas

and trying to reach a shared understanding.

And that means that the conversation that you then generate, you can take that and turn it into a product requirements document or something.

Or if it's a small change, you can just to and turn it directly into issues.

and then your AFK agent will then pick it up.

And don't at me on this, but I personally believe this is better than the default plan mode in the, tool that I use which is claw code.

Plan mode is extremely eager to create an asset.

100

It really wants to just create a plan and start working.

101

Whereas I think it's a lot nicer to reach a shared design concept first.

102

So that's tip number one.

103

Now, failure mode number two is that the AI is just way too verbose.

104

It's like you're almost talking across purposes with the AI.

105

Raise your hand if you feel this if you ever experienced that failure mode.

106

Yeah.

107

It's kind of like the AI is talking, just using too many words to try to communicate what it's doing.

108

It's not like you're talking using the same language.

109

And this to me felt very, very familiar, right?

110

If you've ever been a developer for a long time and you've worked with, let's say, domain experts, someone building an application,

111

Let's say the domain expert wants you to build something on microchips, you have no idea what microchips are.

112

you need to establish some kind of shared language.

113

Right?

114

Because otherwise, they're going to be using terms you don't understand, you're going to be translating that into code that maybe you don't even understand.

115

and certainly the domain expert won't.

116

And so there's this kind of language gap between you and the domain expert. And so...

117

I went back to domain -driven design, DDD, This is something I'm still kind of on the edge of exploring, but everything I'm reading about DDD is just music to my ears.

118

I freaking love it.

119

and DDD has a concept of a ubiquitous language.

120

With the ubiquitous language, conversations among developers, and expressions of the code, and conversations with domain experts, are all derived from the same domain model.

121

a markdown file full of a list of terms that you and the AI have in common.

122

And you really focus on those terms and you really make sure that they're aligned with what it actually means, and you use them all the time.

123

in the code, when you're talking about the code, when you're talking to domain experts.

124

or in our case, when you're talking with AI.

125

So I made a skill.

126

This skill is the ubiquitous language skill.

127

Basically just scans your code base, looks for terminology, and then...

128

creates a Markdown file creates the ubiquitous language Markdown file, a bunch of Markdown tables with all of the terminology.

129

And this, then I pass it to the AI, and I'm able to read it too.

130

and I actually have it open all the time when I'm grilling with the AI and planning and that.

131

What I noticed by reading the thinking traces of the AI not only improves the planning, but it allows the AI to think in a less verbose way,

132

and actually means that the implementation is more aligned with what you actually planned.

133

So this has absolutely been a powerhouse.

134

It's been unbelievably good.

135

So that's tip number two, create a shared language with the AI.

136

Thank you.

137

So, okay, let's imagine that you've aligned with the AI.

138

You know what it is you're supposed to be building.

139

The AI has built the right thing.

140

But it doesn't work.

141

Raise your hands if that's happened to you.

142

Yep, just doesn't work.

143

Well, there's an obvious thing that we can do to make that better, which is we can use feedback loops.

144

We can use static types, if you're not using TypeScript, that's crazy.

145

If you're building a frontend app and you're not giving the LLM access to the browser so it can look around, absolutely needs that.

146

And you obviously also need automated tests.

147

And one sort of thing I notice here is that even with these feedback loops the LLM doesn't use them very well.

148

It doesn't kind of like get the most out of its feedback loops in the way that a veteran developer would.

149

And so it does, what it tends to do is just does way too much at once, it will produce huge amounts of code and then think oh I should probably type check that actually.

150

Or I should, yeah, maybe check a test on that.

151

Or maybe do something like that.

152

And this in the pragmatic program they describe as outrunning your headlights,

153

as essentially driving too fast because the rate of feedback is your speed limit.

154

The rate of feedback is your speed limit, which means that you should be testing as you go, taking small deliberate steps.

155

And the AI by default is really not very good at that.

156

So, skill number three is TDD.

157

You should be using test -driven developments.

158

because TDD forces the LLM to really takes small steps.

159

You create a test first, you make that test pass, and then you refactor the code to make it nicer and consider the design.

160

The issue here is that testing is really hard.

161

Testing has always been hard.

162

Thank you.

163

And the reason for that, Thank you is there a ton of different decisions you need to make when you write a test.

164

You need to figure out how big a unit do you want to test.

165

You need to figure out what to mock, you need to figure out what behaviours do you even want to test in the first place.

166

And all of these decisions are dependent, so if you are testing a really big unit, like an entire massive application, then it might be quite flaky, you might not want to test that many behaviours.

167

If you only test this unit, you need to mock this unit.

168

It's all interlinked.

169

And I've been thinking about this for years, for my entire development career.

170

And what we notice is that good codebases are easy codebases to test.

171

Right?

172

So here we're starting to get back to the idea of code being important.

173

It's that the better your code base is, the better your feedback loops are because you're able to give better feedback to the LLM, it produces better code.

174

And so I thought, what does a good codebase, what does a testable codebase look like?

175

Again, we go to John Asterhout, He talks about having deep modules in your code base.

176

not shallow modules, not lots of modules that expose lots of functions,

177

There should be relatively few large deep modules with simple interfaces.

178

Let's compare them quickly.

179

Deep modules, lots of functionality hidden behind a simple interface, hiding the complexity.

180

You can look inside the deep module if you want to, but you don't need to.

181

You can just use the interface.

182

Shallow modules, not much functionality, complex interface.

183

And, I'll just wait for you to take the photos.

184

Shallow modules in a codebase kind of look like this.

185

We have a ton of different tiny little blobs that the AI has to walk through and navigate.

186

And this is really hard for the AI to explore, actually.

187

And so often what you'll see is if you have a code base like this, which AI is really good at creating code bases like this, is that you'll have a situation where AI doesn't understand what your code is doing.

188

It will attempt to explore the code, but because it's poorly laid out, filled with shallow modules, it doesn't maybe get to the right module in time or doesn't understand all the dependencies,

189

all that stuff.

190

It doesn't understand your code.

191

And so what does a codebase full of deep modules look like?

192

Well, it looks like this.

193

where it's the same code, but it's just structured inside boundaries, where you have these interfaces on the top.

194

And these interfaces, you should probably have a lot of control over them and design them really well.

195

Otherwise, AI might mess up the design.

196

But the implementation, you can kind of leave that to the AI a bit.

197

So, how do you turn a codebase that looks like this, into a codebase that looks like that?

198

Well, I've got a skill for that.

199

Improve code -based architecture.

200

Turns out this is not, it's quite complicated to do this, but it's like a set of steps that you can reusably do again and again.

201

You just sort of explore the code base, look for opportunities where there's code that's related, and wrap all of that in a deep module.

202

And this is a testable code base because the boundaries around this code are so, so simple.

203

You test at the interface, you verify using that interface, and you're good to go.

204

So this is a code base that rewards TDD.

205

But how about failure mode number six?

206

Which is your, okay, let's say your feedback loops are working, let's say that things are kicking into gear, you're able to ship more code than you ever have before, but your brain can't keep up.

207

Right?

208

Raise your hand if you felt more tired than you have ever before in your development career.

209

Yeah, me too.

210

It's knackering.

211

And I think that this is a code base that actually makes it harder for your brain, because you, as well as the AI, need to keep all of that information in your head.

212

Whereas this, not only is it simpler, for you to read and understand, it also means you can kind of treat these modules,

213

or these deep modules, as grey boxes.

214

You can kind of say, Okay.

215

I'm going to just design the interface, but I'm not going to worry too much, or not review the implementation too much.

216

You can do this obviously with things that are less critical in your application

217

You can't do this with various things like finance or whatever, but in many, many modules in your app, you don't need to think about the implementation too much,

218

as long as you have a testable boundary outside the module, and as long as you understand its purpose and can design it from the outside.

219

I have found this has really saved my brain because I can just go, "Okay, the AI, I'll let you handle what's inside the big blob."

220

I'm just going to test from the outside and verify it.

221

So that's tip number five.

222

Design the interface, delegate the implementation.

223

But this means that whenever we're touching the code, whenever we're planning stuff, we need to think about and be aware of the modules in our application.

224

We need to know that map really well.

225

It needs to be part of our ubiquitous language.

226

We need to build it into our planning skills as well.

227

So my writer PRD, inside the PRD I'm specific about the module changes and the interfaces inside those modules.

228

How they're being modified, I'm thinking about them all the time.

229

And this comes from Kent Beck.

230

Invest in the design of the system every day.

231

This is the core of it, right?

232

Because specs the code, we are not investing in the design of the system.

233

We are divesting from it.

234

We're getting rid of that.

235

Whereas this, I think, is absolutely key.

236

Thank you. And so...

237

Code is not cheap.

238

That's the message I want you to take away.

239

Code is important.

240

If we think about AI as a really great on the ground programmer, a kind of tactical programmer, a sergeant on the ground making the code changes.

241

You need someone above that You need someone thinking on the strategic level.

242

and that's you.

243

and that requires software fundamental skills that we've been using for 20 years, for longer.

244

Now if you were interested in any of the skills I put up here, it's in the GitHub repo Matt Pokok skills.

245

And if you're interested in the training that I do or any free stuff, I'm on YouTube, I'm on Twitter, but I'm also at AIHero .dev where I have a newsletter that you can check out.

246

Thank you so much.

247

I hope that this gives you confidence in this new AI age, that you can actually make a good impact.

248

Thank you.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

אותו ערוץ

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

Daily ConversationUniversity StudentsWorking Adults

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Daily ConversationUniversity StudentsWorking Adults

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

Business EnglishUniversity StudentsWorking Adults

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Business EnglishInterview EnglishUniversity Students

Why Software Factories Fail

Daily ConversationUniversity StudentsWorking Adults

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Business EnglishUniversity StudentsWorking Adults

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

Business EnglishUniversity StudentsWorking Adults

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

Business EnglishUniversity StudentsWorking Adults

FOR YOU

המלץ על סרטון

12 משפטים

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “"Software Fundamentals Matter More Than Ever" — Matt Pocock”. המילים שחוזרות הכי הרבה: code, module, design, base, skill. בסרטון הזה יש 248 משפטים ו-3281 מילים לתרגול Shadowing. הדיבור נמשך 17:56. הדובר מדבר מהר, כ-183 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. 84% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.

אוצר מילים מרכזי בסרטון הזה

15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
module שם עצם	/ˈmɑd͡ʒul/	מוֹדוּל
compiler שם עצם	/kəmˈpaɪlɚ/	מְהַדֵּר
spectacles שם עצם	/ˈspɛktəkl̩z/	מִשְׁקָפַיִם \ משקפיים
programmer שם עצם	/ˈpɹoʊɡɹæmɚ/	מְתַכְנֵת, תׇּכְנִיתָן
terminology שם עצם	/ˌtɝ.məˈnɑ.lə.d͡ʒi/	טֶרְמִינוֹלוֹגְיָה
mock פועל	/mɑk/	סנט
verify פועל	/ˈvɛɹɪfaɪ/	וידא
float פועל	/fləʊt/	צָף
complexity שם עצם	/kəmˈplɛk.sɪ.ti/	מורכבות
adversary שם עצם	/ˈæd.vəɹˌsɛɹi/	יָרִיב, אוֹיֵב
ephemeral שם תואר	/ɛˈfɛ.mə.ɹəl/	בֶּן חֲלוֹף
claw שם עצם	/klɔ/	טוֹפֶר, טֹפֶר
paradigm שם עצם	/ˈpæɹ.ə.daɪm/	פָּרָדִיגְמָה
navigate פועל	/ˈnæv.ɪ.ɡeɪt/	נִוֵּט
delegate שם עצם	/ˈdɛlɪɡət/	בא־כוח, נָצִיג

Phrasal verbs שתשמעו

מילה	משמעות
figure out פועל	הֵבִין, מצא תשובה
check out פועל	בדק

משפטים שכדאי לחזור עליהם

משפטים קצרים ושלמים מהסרטון שאפשר להשתמש בהם בשיחה יומיומית:

Are you having a good conference so far?
You don't really look at the code.
Raise your hand if you've heard of that.
Keep your hand raised if you've tried it.
Raise your hand if that's happened to you.

דקדוק בסרטון הזה

המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:

מבנה	בסרטון
הווה מושלם ממושך (Present perfect continuous) have/has been + -ing — פעולה שהתחילה בעבר ועדיין נמשכת עכשיו	I've been thinking · we've been using
הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו	I've been · has come · you've heard
משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר	coding which is · this, which is · books, which is
סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה	is called · being modified

הגייה ששווה לשים לב אליה

הדובר משתמש ב-84 קיצורים וצורות מקוצרות, כמו you're, I'm, doesn't. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

הצלילים של “sh” ו-“zh”: shallow /ˈʃæloʊ/, speculation /ˌspɛk.jəˈleɪ.ʃən/
מילים ארוכות — שימו לב להטעמה: ubiquitous /juːˈbɪkwɪtəs/, dependency /dɪˈpɛndənsi/, terminology /ˌtɝ.məˈnɑ.lə.d͡ʒi/, speculation /ˌspɛk.jəˈleɪ.ʃən/, complexity /kəmˈplɛk.sɪ.ti/

צלילים שדוברי עברית מתקשים בהם:

/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: programmer /ˈpɹoʊɡɹæmɚ/, shallow /ˈʃæloʊ/, pragmatic /pɹæɡˈmætɪk/, adversary /ˈæd.vəɹˌsɛɹi/, knacker /ˈnækɚ/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: programmer /ˈpɹoʊɡɹæmɚ/, pragmatic /pɹæɡˈmætɪk/, entropy /ˈɛntɹəpi/, microchip /ˈmaɪkɹoʊˌt͡ʃɪp/, verify /ˈvɛɹɪfaɪ/
עיצור קולי בסוף מילה — /b/, /d/, /g/, /z/, /v/ בלי להפוך אותם לאטומים: spectacles /ˈspɛktəkl̩z/, blob /blɑb/, provocative /pɹəˈvɒk.ə.tɪv/, derive /dɪˈɹaɪv/, expose /ɪkˈspoʊz/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו module, compiler, spectacles.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: "Software Fundamentals Matter More Than Ever" — Matt Pocock - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Why Software Factories Fail

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

A Return to Code

AI & Education: Generative AI & the Future of Critical Thinking

What is clean code? - Uncle Bob

Everyone Is Wrong About AI Coding

Psychology of Intelligence: Learn Anything So Fast It's Almost Unfair

mattpocock/skills: A complete AI Coding workflow, end-to-end

I've Changed My Opinion On DEVELOPERS Vibe Coding

P1 机器学习的应用【2024公认最好的 | 吴恩达机器学习 | 教程 | Machine Learning Specialization(超爽中英!)】

How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

DHH has gone completely off the rails...

They want mediocre developers...

אוצר מילים והערות הגייה לשיעור הזה

אוצר מילים מרכזי בסרטון הזה

Phrasal verbs שתשמעו

משפטים שכדאי לחזור עליהם

דקדוק בסרטון הזה

הגייה ששווה לשים לב אליה

איך לתרגל עם הסרטון הזה

מהי טכניקת השאדואינג?