シャドーイング練習: Complete Roadmap for Backend Software Engineers (START HERE!) - 動画で英語スピーキングを学ぶ

Welcome.

This video is going to give you a step-by-step roadmap to becoming a back-end software engineer.

So not only will this tell you what tech to learn, but it will give you the order in which you should learn it.

So if you have no idea where to start, this is going to take you from where you are right now to the end goal of becoming that back-end engineer.

Now we're going to start by looking at this mind map I created.

Do not fret.

This is not the roadmap.

You do not need to know everything inside of this map.

In fact, you can't even see it.

There's so many things on here.

But if I zoom in, you'll notice that there's themes of different categories and then a bunch of different technology you might encounter.

It might be a good idea to become familiar with these different things, but you don't necessarily have to know every item in this list.

Instead, you should pick one item out of each category and become an expert in it.

So you start by understanding the landscape and what exists out there, but then you narrow in and you become really good at one of those things.

And that's where you're probably going to spend 80% of your time

and then maybe 20% of your time understanding the context of everything.

So understanding the different technologies you might encounter.

That's my general framework for learning.

So what this video is going to do is it's going to give you some example items

that you could start to learn with.

Although if you substituted one of these items with another item from the same category, it still might work.

This is just an example roadmap that I would recommend if you really have no idea where to start.

Now the roadmap is actually at the bottom of this mind map.

So if want to get access to this mind map

and roadmap i'll have a link for that down below and

if you want more direct help me guiding you through this

process with one-on-one mentorship i do have a mentorship program so

if you want to learn more about that that's basically going to give you

that accountability and it will help you build the skills

and the things you need to know for your career

so you can be successful as a software developer

so going through this mind map is a great place to start

but if you want that extra help then check out the mentorship program

so So the secret here is to not learn everything, but rather learn a technology from each category.

This will give you experience in the end-to-end, while also giving you something to compare every other technology against.

So if you're really, really good at the Python programming language, you can compare other languages to that language,

so you don't have to have as much of a struggle learning new languages.

You just think of how it's different than what you already know.

That same idea is going to apply to a lot of different tech.

So we'll start at the very basics, which is the operating system.

You should become pretty comfortable with your operating system.

So you should start to learn the commands to use

and just be competent in working with different tools on that operating system.

Now, I develop on a Mac, but it's often the case, especially within backend engineering, you're going to be deploying to Linux.

So I recommend you learn your primary operating system, Mac, Windows, or Linux, but also make sure you learn Linux.

So if you've been wondering if you should do that, yes.

The answer is yes, you should learn Linux, learn the basic commands.

And if you're on Windows and you want to start to become more familiar with Linux, here's a couple of things you could do.

So to start, you can look into WSL, which is going to give you some of the essential Linux capabilities on Windows.

Another option is to install a different type of terminal.

So if you, for example, download Git, you have the option to include a Git Bash program, which will use MinGW you.

So if that is all foreign language to you, go download Git.

That's going to give you a terminal, which will give you some of the essential terminal commands that you would experience on Linux.

And then the third option, which is going to give you the most one-to-one experience, is to actually just use a Linux operating system.

And you can do this within a virtual machine, or you could, of course, install Linux directly on the hardware, but I would probably just go with a VM and get some experience there.

When you deploy something to a backend server, you're going to need to understand these basic commands because if you need to connect to the server, you're likely going to use SSH,

and this is going to be a connection through the terminal.

So if you want to be able to work with the computer, you'll need to know how to do that in the terminal.

This would include learning the basics of a terminal-based text editor.

So next on here, the editor, I recommend generally VS Code, but since you might on occasion be working in a terminal,

you might want to learn the basics of something like Vim.

But in terms of actually working with code to build applications, your day-to-day editor.

I personally use VS Code.

If you have a preference here, this is the kind of thing where this roadmap is an example.

Feel free to substitute it for another item.

I'm just warning you against trying to learn all of the items.

I like VS Code because you can develop pretty much anything inside of it, and you don't have to have five different IDEs, one for each major language you're working on, for example.

That'll help you get better in VS Code.

That's the tool you use to develop so you're going to become more efficient

and just a better developer even

if you're not directly getting better at a programming language getting better at the tools

and the things you use will help you become a better developer as well.

So that's the basics the next thing you should learn is source control

or version control and for this you're going to want to learn git

and I recommend using it in the terminal to become familiar with those commands

and then you can host your repositories in GitHub.

GitHub is a service where we can host our code.

Git is just a software you can install to help you manage and organize your code, keeping track of any changes you make to that code.

You will definitely want to use Git for all of your projects.

I recommend to everybody that they put all of their projects in GitHub for organizational sake, as well as showing activity as a developer.

Here's all the stuff I've been working on.

Even if the code sucks, It's just a matter of showing that you're working on something.

And most likely, if you don't put your code up on GitHub, five years down the road, you're going to lose that project.

You're going to wish you had it.

So if you start tracking all of your stuff now and getting it up on GitHub, you'll thank yourself in the future.

Next up, backend language.

So pick a programming language.

If you're not sure which one to go with, I would recommend Python.

I say Python because it's fairly easy to learn.

Working on web projects is really simple in Python.

and Python can do a whole lot of other stuff.

So it's a very good general purpose language.

Obviously, there are other languages you can use for this.

So you might use JavaScript and TypeScript.

That would be fine.

But if you're unsure, then I would recommend starting with Python.

I have a six hour Python video on YouTube as well as a seven hour part two.

So if you want a little bit of Python material, you can check that out.

I also have a Python mastery course, which is going to be a lot more information.

100

and it includes like nine hours of backend Python material.

101

So that's going to be a lot of applied Python for building backend services.

102

So if you're interested in that course, I will have a link to that down below as well.

103

So the programming language gives you the freedom to do pretty much whatever you want.

104

You can code anything.

105

But if you specifically want to build something like an API or some backend for a website, doing that from scratch could take a lot of work.

106

So because of that, it's often the case that backend frameworks exist, which is really just a software library that other people have invested their time,

107

skill, and energy into to make building web applications a lot easier.

108

So every major programming language is going to have at least one backend framework you could use to start building websites.

109

Some are going to have a lot of options, and you'll have to choose which backend framework to start with.

110

In the case of Python, there are a couple out there you might have heard of Flask, Django, FastAPI.

111

And I would just recommend if you're going to pick one of those, pick Django.

112

Django gives you a ton of features and capabilities out of the box.

113

It's going to help you learn larger scale backend development, and it will give you conventions and structure.

114

So you're not just left with an empty Python file saying good luck.

115

It will give you some starting points on how to structure your projects.

116

And this will help you start to build larger scale backend systems.

117

Now, if you're going to be working with data, which most likely you are, you're going to want to start familiarizing yourself with databases.

118

The question is, which database do you use?

119

I'm going to recommend you start with Postgres.

120

There are a ton of different databases out there, and they're generally categorized as SQL databases or SQL databases, which are structured in tables,

121

or NoSQL databases, which could be graphs or key value pairs, documents.

122

There's a bunch of different variations for NoSQL databases.

123

Most likely, you can cover all of your needs with Postgres, and if needed, you can have a JSON column

124

which will allow for semi-structured data where you can vary the values in that data.

125

So Postgres is going to give you the foundation that will work in 99% of cases.

126

It's also open source and free to use for commercial use, so it's a great starting point.

127

And if you learn Postgres, switching to any other structured database is going to be super easy.

128

So do not get caught up on the technology.

129

Same with, for example, the framework or the language.

130

learning the first and getting really good at it is the most important thing.

131

Then if for some reason you have to switch to something else, you will have a foundation that will make it a lot easier.

132

A lot of the same paradigms are going to be applied.

133

So you might follow particular design patterns or structures.

134

Those are going to also exist in other frameworks and languages.

135

So do not stress, just pick something and get really good at it.

136

Next up, we're going to talk about how do you go from Django to connecting to a database such as Postgres.

137

and this is going to be done in a few different ways.

138

Most likely you're going to start with an ORM.

139

So an ORM is an object relational mapper

140

and that's going to make it easier to work with a database because you'll just be working with objects in your code.

141

You're not using any SQL, you're just using Python or whatever language that's in

142

and the library is going to do all of the SQL for you and give you the objects you need.

143

So that's an ORM, you should become familiar with least one

144

so the django orm is fine you should also learn raw sql

145

so working with the database directly all of the databases will

146

have different tools for connecting to them most likely you can

147

just start by connecting to the database from the terminal so

148

if you're in postgres you can learn a little bit about psql there are also often extensions

149

and softwares you can use to visualize the database

150

so you can look at pgadmin and i think visual studio code also has some extensions for Postgres.

151

It's handy to know that raw SQL, if you're limited to just using an ORM, you're going to have a painful time as a backend developer.

152

And I would say this is one of the areas that will distinguish you from a full stack developer.

153

It's often the case that a full stack developer will just know the ORM layer, at least a beginner full stack developer.

154

They'll often basically think of the data layer as the last thing that they should worry about.

155

And they prioritize the functionality of the web pages.

156

And while that's important, I would flip that

157

and say you should probably prioritize the data layer

158

because think of the potential consequences if you build an application and you mess something up there, right?

159

You could have a data leak, you could have security issues.

160

These should not be an afterthought.

161

So if you prioritize getting really good at SQL and the data layer, you're going to set yourself apart from a lot of the developers

162

that are just average in a bunch of technologies because they spread themselves thin

163

trying to learn the full stack from the beginning.

164

For those of you who've been following this channel for a while, I started with database design and I think starting with the databases is what has helped me tremendously in my career.

165

Next up, we have the front end.

166

Huh, should we learn the front end?

167

That's a great question because if you're the backend developer, you might not even deal with the front end.

168

So if you imagine at one point you will do full stack development, which is very possible, you should at least learn the basics of the front end,

169

and specifically starting with the connections between the front end and the back end.

170

So learn how to fetch data, retrieving data from an API, as well as learning how to do any transformations you need. If necessary,

171

say the structure in the back end is a little bit different than how you might use it in the front end, learn how you can do those transformations.

172

I would recommend if you want to start working on some front end stuff.

173

Don't prioritize too much the design with the CSS and the HTML.

174

While it's all important, I think you should first prioritize accessing data from the backend

175

and then potentially creating an SDK or some functions to make that very easy.

176

So if in the front end, you just had a function in JavaScript that was like get users, that could give you a good practice exercise of getting data from the backend

177

and making it very easy to use on the front end.

178

So it's often the case you'll be working with some front end frameworks such as React.

179

So you can learn how to do this stuff in React, or you can use many of the other tools out there

180

that exist for basically synchronizing the front end and the back end, such as React Query or Redux Toolkit Query.

181

So check out those tools if you want to get started in that.

182

So now you have a pretty good idea of the full stack.

183

You might not be a full stack developer because you're prioritizing the back end, but you have an idea of how things are all connected, and you're not completely useless at the front end.

184

You don't want to be an expert at all this other stuff and then be like, what's an HTML?

185

I've never heard of that.

186

So at least know the basics of front end.

187

Next up, we have communication, which is pretty broad.

188

So let's expand on this.

189

Here are a few different ways apps can communicate.

190

Basically, transferring data from the back end to the front end.

191

So we already talked about REST.

192

This would be the API.

193

So retrieving data from the back end and making it usable on the front end.

194

Next up, let me talk about Webhooks, which flips this around.

195

It's an interesting technology or approach that will basically be a broadcast instead of someone making a request.

196

So if you have something happen on your backend and you want to let people know about it, you can learn more about webhooks.

197

These are often used for software integration.

198

So if you're working with some kind of application and you want to receive notifications from that software, when you're trying to integrate with the service,

199

they might have the ability for you to provide a webhook endpoint, which will receive information when something happens.

200

Just as a completely random example, here is something from the Stripe docs you can receive Stripe events in your webhook endpoint.

201

You might want your application to receive events as they occur in your Stripe accounts

202

so that your backend systems can execute actions accordingly.

203

So it's kind of like a flipped API where you can

204

receive updates instead of having to constantly request something from the Stripe API to see if some changes have been made.

205

It's set up pretty much the same way.

206

You would just create a post endpoint on your backend and give that URL to some service such as Stripe.

207

So I put that one in here as it might be something handy to know if you want to start connecting services.

208

Now WebSocket is a bi-directional connection between the client and the server.

209

So in REST, you can only take requests from the client and then give a response.

210

With WebSockets, you can actually deliver something to the client without waiting for a request.

211

Once that WebSocket connection is made, it's maintained, and either the client or the server can then communicate to the other one.

212

This is used for real-time web applications, so if you want to, for example, create a chat application,

213

a video game that might have players interacting with one another in real time, these are all different things you can do with WebSockets.

214

Definitely a valuable skill to know as a back-end developer.

215

As mentioned, it does go into front-end some because the client in this scenario is going to be the browser.

216

And that's pretty typical.

217

It's not going into the design of the front end.

218

And that's what I would kind of avoid at first when you're trying to become a competent backend developer.

219

So worry about data and communication.

220

Next up on this list, we got notations.

221

This is really simple.

222

JSON, Markdown.

223

If you've done any development, you're probably familiar with these.

224

But JSON is a notation

225

that you'll often use with REST APIs very simple key value pairs

226

and pretty much just looks like a JavaScript object with some

227

minor differences such as the keys being quoted markdown is a notation language for documentation even

228

if you're not writing docs you'll probably want to know the basics of markdown

229

because you should have a readme showing how to set up your projects

230

and run them locally

231

so the readme.md is going to use a markdown this is

232

really easy to learn you can learn the basics in 60 seconds I have a YouTube short

233

which covers 80% of the things you're going to use with markdown next up we have protocols

234

so the ones you should be familiar with to start https

235

and ssh https is hypertext transfer protocol secure

236

and this is where you will become familiar with tls certificates

237

or you'll likely just hear ssl certificates this is something you'll

238

have to do to create the https connection for your services

239

so not only when they visit the front end

240

but the connection between the front end and the back end

241

so you want to learn the basics of how to do that And as for SSH, we already talked about that a little bit.

242

You'll be using that if you need to remote into any servers.

243

There are a lot more protocols, but this is a good starting point.

244

Next up, we have testing.

245

We can start with Postman and Swagger.

246

We talk a little bit more about automated testing and CICD integration in the MindMap video.

247

So if you wanted to refer to that.

248

But these are two good tools to start with

249

that allow you to easily build and document APIs and give you really easy ways to test them.

250

So within Postman, you can make a collection and you can run through that collection, checking to make sure you get all the expected results.

251

And it has some automated testing capabilities.

252

So you can script that out, hit run, make sure everything is working.

253

So if you change stuff, you can confirm you don't have any major regressions.

254

Swagger is an interesting tool because it will give you a web page with a list of all the different API endpoints.

255

And you can invoke those from the web page.

256

great documentation tool but really handy for testing

257

because you can just go in there hit run

258

and confirm you get the result you expect it'll also give you the expected structure for the API endpoints

259

so if any stakeholders need to test the API they can very easily

260

or you in six months who doesn't remember what you're supposed

261

to send to an API you can just check the swagger

262

endpoints here's a very basic pet store example where you can see all the different endpoints

263

and you can go in here

264

and for example get a store inventory try it out hit execute

265

and get a result for stuff that takes data it'll give you the structure

266

that you will send in a post request so

267

when you try it out you can go in here

268

and provide values for these things

269

and then hit execute it'll also give potential issues such as a 405 invalid input

270

so it basically gives a good overview of the way your API works, which can be great for other people who might be using your API.

271

So those are two good testing tools.

272

Next up, we have cloud providers.

273

A couple of things here.

274

I guess I lied.

275

Just one thing here, AWS.

276

I originally said a couple of things

277

because I thought maybe there would be Vercel or Netlify or one of these other platforms as a service companies.

278

Those are great to learn and a great place to start.

279

But as a backend engineer, I would probably encourage you to learn one of the infrastructure companies such as AWS, Google Cloud, Azure, and there's other ones,

280

but those are the main three because that is going to give you complete control, pretty big learning curve, but if you want to become a better back-end developer,

281

I'm going to try and push you past the resistance to learn the platform.

282

Just go into AWS, start to dork around with it, and become familiar with it.

283

This is something people can dedicate their entire career to, so it is overwhelming, just know that going into it, it'll take some time to start to become familiar.

284

Next up, we have containerizing.

285

So you could put your applications in Docker containers.

286

So you'll want to learn Docker, Docker Compose for basically a very simple orchestration.

287

And then you could also find a place to store your images, such as Elastic Container Registry from AWS.

288

So you don't have to containerize your applications to start, but you may want to become familiar with that, as you'll probably run into that if you're working as a professional developer.

289

There's ups and downs to using Docker.

290

It can be simpler in certain scenarios if you know the commands to use.

291

So what I recommend if you go down the route of learning Docker, start to take notes of all the commands you use so that you don't have to think and memorize everything.

292

You can just refer to those to set up your application and get it running.

293

And you're not lost because you have this new layer of abstraction.

294

so definitely spend some time studying containerization

295

if that's something you're going to end up using I put question marks here

296

because they're kind of optional but I would say

297

if you get this far in this list you should start

298

learning these things CI CD continuous integration continuous deployment this is going to allow you to tie into your repository

299

and have the latest code automatically deploy you can also do a bunch of other stuff like automated testing

300

or creating images or scanning the source code for any issues.

301

Tons of different things you can do.

302

So you might want to start familiarizing yourself with a CICD pipeline.

303

There are a lot of different ones out there.

304

I put code pipeline here.

305

And the reason I put that there is because for all of the technologies, I am basically just saying,

306

hey, learn the AWS version of the software so you start to become familiar with AWS as a whole.

307

But there are other very popular tools out there.

308

GitHub Actions is a big one.

309

So you might want to look at that if you're using that at work, or if you're familiar with that already.

310

But if you're in the AWS ecosystem, you can pretty much do everything.

311

They have a service for everything you'd ever possibly want to do.

312

So you got the container registry, you have the CICD pipeline, you have the hosting, everything you need.

313

It may kind of tie you into that AWS system.

314

But again, as I mentioned, once you learn one of these things, it's so much easier to learn another.

315

So if you're already familiar with all the services in AWS that you would likely use, if you needed to switch to Azure or Google Cloud Platform or some individual technology for some of these,

316

such as GitHub Actions, you could totally do that without a lot of difficulty.

317

Next up, we have hosting.

318

And here is basically some more specific stuff as for where the server is ran and where the static files go.

319

So I didn't just put AWS, what service specifically are you going to use?

320

And I just mentioned three you should be familiar with here, Elastic Beanstalk.

321

That's AWS's platform as a service.

322

They're going to make it very easy to deploy an application.

323

I use very easy in quotes because it's kind of a pain.

324

But there's also Fargate, which is probably something you would use if you're containerizing.

325

Similar idea to Elastic Beanstalk as well, though.

326

And this is an example of something that is serverless, so you don't have to allocate a server with a certain amount of RAM or anything like that.

327

You just pay for what you use.

328

So those are two different options.

329

You can just go direct into EC2, but that might require a little bit more knowledge to get things working.

330

But doing that is not going to be a bad idea either.

331

Then we have S3.

332

That is the storage on AWS.

333

So you'll probably use that

334

and that's where you would host your front end of the application as well as any files

335

So if users are uploading things to your app, you'll need to know how to put those in s3 next up We have CDNs.

336

This is a content delivery network This will basically provide different locations

337

that your app is cached from So if somebody makes a request

338

and they're closer to one of these edge locations They don't

339

have to make the request all the way to your main server

340

They'll just hit the CDN the big one here is cloudflare

341

and this is one scenario where I actually broke my rule of using all AWS stuff.

342

CloudFront is the AWS CDN.

343

You could totally use CloudFront.

344

I've experimented with that.

345

I put CloudFlare here because I think that's probably the go-to that most people are going to be familiar with already.

346

So you can go with CloudFlare or within AWS CloudFront.

347

Next on the list we have monitoring.

348

So you can explore things like CloudWatch, PagerDuty.

349

This is how you look into your app, make sure things are working the way you would expect, and get notified if anything goes wrong.

350

So this is once your app is already in production, so definitely check those out if you need more details on your app.

351

Cool.

352

Next up, we have issues, issue tracking.

353

You just use GitHub, keep it simple, but you might be working in a team environment where you have to use something like JIRA or whatever.

354

You probably won't have too much of an issue picking that up.

355

I just put it in this list because it was one of the categories from the larger mind map.

356

So this is basically some way to keep track of what's going on in your application.

357

Not so much the running application, but the code of the application.

358

If there's bugs, if there's things that need added, you can do all of that within GitHub.

359

Next up, big jump, we have need more.

360

So if you manage to make it this far, you're already a pretty proficient developer.

361

But if you still want more, you want to advance your career, or you're doing some specialized applications, I'm going to share now some other things you could learn.

362

So you really have two paths here.

363

You could learn everything up to this point in more depth, or you can learn some more of these technologies.

364

I wouldn't go into this need more section though, if you're not already proficient in all of the technologies up to this point.

365

So let's explore this.

366

I have a few different things here.

367

Languages, full stack development, more on communication, no SQL, and more on containerization.

368

So let's start with languages.

369

I would recommend learning one or two lower level languages.

370

So you can learn Rust, Go.

371

You might want to learn C++ if that makes sense for the kind of stuff you're working on.

372

Although I would say it's less common to be used in more of a web development ecosystem.

373

So I've used Rust to build APIs even.

374

Probably not something I would use C++ for.

375

So I just gave two as an example here, but you know, just explore some different languages.

376

And then I would also recommend JavaScript and TypeScript.

377

So that's going to be used for the front end and you could also use it for the back end as well.

378

This is just the most popular language.

379

You're going to want to have a working knowledge of it.

380

Now when it comes to full stack, listed a few things here.

381

So we have Next.js.

382

You could learn how to have static site generation.

383

And this is going to have a backend component to it.

384

And then as I mentioned earlier, some state management tools such as React Query or RTK Query.

385

Next up we have comms.

386

So here are some other means of communication.

387

You can learn about protocol buffers.

388

These are great for inter-app communication or if you have a microservice architecture.

389

This is more efficient than JSON as it's serialized as binary.

390

So you can't read the transferred message, but you can then deserialize it on the receiving end.

391

And that is going to make a more efficient transfer.

392

GraphQL is another approach to making APIs.

393

It's going to allow the client to basically request data like SQL, where the client can retrieve exactly what it wants.

394

So definitely worth learning the basics of GraphQL.

395

And you may also be interested in learning a message broker which can be used for inter-app communication such as RabbitMQ.

396

Now for databases I mentioned you can use Postgres for most of your scenarios.

397

Still think that's true but it's probably something where you might want to learn a couple of the NoSQL databases.

398

I listed three here as an example.

399

I would say the most important one here would be Redis

400

because this is going to be a caching layer for your backend services.

401

I would almost even move this to before the need more section.

402

So probably out of all of this stuff, I would look into Redis.

403

But I think if you get to this point and you haven't learned Redis, you could pick it up pretty easily.

404

It's essentially an in-memory database that will improve the overall performance of your app.

405

So caching is a whole topic you can study more on with backend engineering.

406

It gets pretty complex, but that is probably the first place I would start.

407

MongoDB, that's a popular one, and that's why I put it there.

408

It's a document database, as is Firebase.

409

But Firebase is really popular, and a lot of people will use it basically as a backend as a service.

410

So it's something you might want to become familiar with.

411

Pretty popular as the backend for mobile applications.

412

So definitely check that out if that applies to you.

413

There are a ton of NoSQL databases.

414

So I just picked a couple as examples.

415

I would learn Redis, but then as for the other two, you could pick whatever makes sense for the kind of stuff you're working on.

416

And then for containerization, the next logical step is to get into Kubernetes,

417

which is an orchestrator, which helps you coordinate all of these different containers and deploy them.

418

And for this, you could use a service like EKS, Elastic Kubernetes Service, inside of AWS.

419

This is a step just beyond basic Docker, so definitely worth learning if you'll be using containers heavily in your career.

420

So that is the overall structure.

421

Yeah, it's a lot, but it's also not that bad.

422

Once you start going through this, your rate of learning goes up because you're more familiar with the core principles, which I put a lot of thought into that in the order of this.

423

I try to set it up in a way

424

that makes the stuff that's over here easier to learn based on the stuff you learned back here.

425

Just as a basic example, you know, if you go in and you start SSHing into servers, but you haven't even learned the basics of Linux, you're going to have a hard time.

426

I want to reiterate, this is not the only path you can take.

427

This is an example path.

428

The most valuable thing is just learning the technology a bit deeper and not spreading yourself thin across too many different technologies.

429

While, yeah, this is a lot of technologies, they're all in different categories.

430

Some people might say, I'm going to become an expert by learning Django, Flask, and FastAPI.

431

But by doing that, you're actually just becoming a beginner in three different things.

432

So keep your learning path very thin, where you're just learning one or two things from each category so that you're most efficiently using your time.

433

To conclude, if you found this useful and you want to use it as a reference, you can get the link to the mind map and roadmap down below.

434

And as a reminder, I have the mentorship if you need guidance through this entire process.

435

You can definitely do this on your own, but you might lose track of where you are or not really understand how everything fits together.

436

If that's the case, you would benefit from the additional mentorship and accountability.

437

So I have that in the mentorship program.

438

I'll have a link to that as well.

439

So check that out if that sounds interesting to you.

440

The goal is not just to learn technology, but learn it in such a way that it will help your career or help you land a job.

441

And that's what I help people with.

442

Thank you so much for watching and if you want to see more backend content, stay tuned.

443

See you next time.

✨ おすすめ動画

67 文

このレッスンについて

このレッスンでは、バックエンドエンジニアになるためのロードマップについて説明した動画を使い、英語のスピーキングとリスニングを練習します。動画の内容は技術的な用語も含みますが、ゆったりとしたトーンで話されているので、shadow speak（シャドーイング）の練習に最適です。特に、「順序」や「カテゴリーから一つ選ぶ」といった論理的な説明を聞き取り、そのリズムに合わせて発音することで、英語の表現力を向上させることができます。

重要な語彙とフレーズ

roadmap：ロードマップ（計画）
backend engineer：バックエンドエンジニア
category：カテゴリー（分類）
Linux：リナックス（オペレーティングシステム）
mentorship program：メンターシッププログラム（指導プログラム）
end-to-end：エンドツーエンド（全体的な）

練習のヒント

動画で英語学習をする際、shadow speechのテクニックを使うと効果的です。この動画のスピードは中程度で、話者が重要なポイントを強調するときには少しゆっくり話すので、そのタイミングを捉えて発音を真似しましょう。例えば、「do not fret」（心配しないで）というフレーズは軽いトーンで話されていますが、「you should learn Linux」（リナックスを学ぶべきです）は断定的な口調です。こうしたイントネーションの違いを観察し、同じように発声することで、英語の発音を良くすることができます。

また、技術用語が多いので、一度動画を聞いてから、難しい単語をメモして意味を確認しておきましょう。その後、shadowingを行うと、単語の発音だけでなく、文脈の中での使い方も覚えることができます。繰り返し練習することで、自然に英語のリズムに慣れ、スピーキングの流れもスムーズになります。shadowspeaksのような方法を継続的に行えば、短期間で大きな進歩が見込めます。

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
条件文 if + 節, will/would + 動詞 — 条件とその結果	if I zoom in, you'll notice · if you're unsure, then I would recommend · if you're not writing docs you'll probably
現在完了進行形 have/has been + -ing — 以前に始まり今も続いている動作	you've been wondering · I've been working · who've been following
関係詞節 who / which + 節 — 人や物について情報を加える	basics, which is · WSL, which is · program, which will
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	have invested · has helped · I've never heard

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: Complete Roadmap for Backend Software Engineers (START HERE!) - 動画で英語スピーキングを学ぶ

The Ultimate IoT Roadmap in 2026? | Embedded Systems & IoT Career Roadmap

Prompt Engineering - Guidelines

AWS Machine Learning Engineer Associate: What You Need to Know

Best NextJS Folder Structures | Beginner - Intermediate - Advanced

CS50x 2026 - Introduction

If I started a YouTube channel from scratch, I’d do this

If you’re an aspiring product designer, watch this (roadmap included)

Executing Monitoring, Evaluation and Learning (MEAL) | Complete Practical Guide

My Vibe Coding Workflow (Step by Step Workflow)

Fastest way to become an AI Engineer in 2026

A Career in IT

How to go from B1/B2 to C1? (in 5 minutes)

このレッスンについて

重要な語彙とフレーズ

練習のヒント

この動画の文法

シャドーイングとは？英語上達に効果的な理由