Shadowing Practice: Complete Roadmap for Backend Software Engineers (START HERE!) - Learn English Speaking with Video

Les maken...
1
Welcome.
2
This video is going to give you a step-by-step roadmap to becoming a back-end software engineer.
3
So not only will this tell you what tech to learn, but it will give you the order in which you should learn it.
4
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.
5
Now we're going to start by looking at this mind map I created.
6
Do not fret.
7
This is not the roadmap.
8
You do not need to know everything inside of this map.
9
In fact, you can't even see it.
10
There's so many things on here.
11
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.
12
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.
13
Instead, you should pick one item out of each category and become an expert in it.
14
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.
15
And that's where you're probably going to spend 80% of your time
16
and then maybe 20% of your time understanding the context of everything.
17
So understanding the different technologies you might encounter.
18
That's my general framework for learning.
19
So what this video is going to do is it's going to give you some example items
20
that you could start to learn with.
21
Although if you substituted one of these items with another item from the same category, it still might work.
22
This is just an example roadmap that I would recommend if you really have no idea where to start.
23
Now the roadmap is actually at the bottom of this mind map.
24
So if want to get access to this mind map
25
and roadmap i'll have a link for that down below and
26
if you want more direct help me guiding you through this
27
process with one-on-one mentorship i do have a mentorship program so
28
if you want to learn more about that that's basically going to give you
29
that accountability and it will help you build the skills
30
and the things you need to know for your career
31
so you can be successful as a software developer
32
so going through this mind map is a great place to start
33
but if you want that extra help then check out the mentorship program
34
so So the secret here is to not learn everything, but rather learn a technology from each category.
35
This will give you experience in the end-to-end, while also giving you something to compare every other technology against.
36
So if you're really, really good at the Python programming language, you can compare other languages to that language,
37
so you don't have to have as much of a struggle learning new languages.
38
You just think of how it's different than what you already know.
39
That same idea is going to apply to a lot of different tech.
40
So we'll start at the very basics, which is the operating system.
41
You should become pretty comfortable with your operating system.
42
So you should start to learn the commands to use
43
and just be competent in working with different tools on that operating system.
44
Now, I develop on a Mac, but it's often the case, especially within backend engineering, you're going to be deploying to Linux.
45
So I recommend you learn your primary operating system, Mac, Windows, or Linux, but also make sure you learn Linux.
46
So if you've been wondering if you should do that, yes.
47
The answer is yes, you should learn Linux, learn the basic commands.
48
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.
49
So to start, you can look into WSL, which is going to give you some of the essential Linux capabilities on Windows.
50
Another option is to install a different type of terminal.
51
So if you, for example, download Git, you have the option to include a Git Bash program, which will use MinGW you.
52
So if that is all foreign language to you, go download Git.
53
That's going to give you a terminal, which will give you some of the essential terminal commands that you would experience on Linux.
54
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.
55
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.
56
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,
57
and this is going to be a connection through the terminal.
58
So if you want to be able to work with the computer, you'll need to know how to do that in the terminal.
59
This would include learning the basics of a terminal-based text editor.
60
So next on here, the editor, I recommend generally VS Code, but since you might on occasion be working in a terminal,
61
you might want to learn the basics of something like Vim.
62
But in terms of actually working with code to build applications, your day-to-day editor.
63
I personally use VS Code.
64
If you have a preference here, this is the kind of thing where this roadmap is an example.
65
Feel free to substitute it for another item.
66
I'm just warning you against trying to learn all of the items.
67
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.
68
That'll help you get better in VS Code.
69
That's the tool you use to develop so you're going to become more efficient
70
and just a better developer even
71
if you're not directly getting better at a programming language getting better at the tools
72
and the things you use will help you become a better developer as well.
73
So that's the basics the next thing you should learn is source control
74
or version control and for this you're going to want to learn git
75
and I recommend using it in the terminal to become familiar with those commands
76
and then you can host your repositories in GitHub.
77
GitHub is a service where we can host our code.
78
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.
79
You will definitely want to use Git for all of your projects.
80
I recommend to everybody that they put all of their projects in GitHub for organizational sake, as well as showing activity as a developer.
81
Here's all the stuff I've been working on.
82
Even if the code sucks, It's just a matter of showing that you're working on something.
83
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.
84
You're going to wish you had it.
85
So if you start tracking all of your stuff now and getting it up on GitHub, you'll thank yourself in the future.
86
Next up, backend language.
87
So pick a programming language.
88
If you're not sure which one to go with, I would recommend Python.
89
I say Python because it's fairly easy to learn.
90
Working on web projects is really simple in Python.
91
and Python can do a whole lot of other stuff.
92
So it's a very good general purpose language.
93
Obviously, there are other languages you can use for this.
94
So you might use JavaScript and TypeScript.
95
That would be fine.
96
But if you're unsure, then I would recommend starting with Python.
97
I have a six hour Python video on YouTube as well as a seven hour part two.
98
So if you want a little bit of Python material, you can check that out.
99
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.

Context & Background

The video offers a clear roadmap for aspiring backend software engineers, guiding viewers through essential technologies and learning strategies. The speaker emphasizes focusing on one tool per category to build expertise, using relatable examples like choosing a programming language and mastering Linux commands. The dialogue is conversational yet informative, making it ideal for English learners looking to practice technical vocabulary and natural speech patterns.

Top 5 Phrases for Daily Communication

  • "Do not fret" โ€“ A friendly way to say "don't worry," useful in calming others or easing stress.
  • "Narrow in" โ€“ To focus closely on a specific topic, perfect for discussing goals or projects.
  • "End-to-end" โ€“ Describing a process from start to finish, common in work or project talks.
  • "Essential capabilities" โ€“ Core features or functions, great for explaining tools or skills.
  • "Accountability" โ€“ Taking responsibility for tasks, a key term in professional settings.

Step-by-Step Shadowing Guide

To practice with this video using the shadowing technique (or "shadowspeak"), follow these steps. First, watch the video once to grasp the main ideas. Then, play short 5-10 second clips, pause, and repeat the speaker's words aloud, mimicking their tone, pace, and stress. Pay attention to phrases like "Do not fret" โ€“ notice how the speaker softens the "t" in "fret" for a natural flow. Next, focus on technical terms like "backend engineering" and "Linux commands"; repeat them to improve pronunciation. For longer sentences, break them into chunks: "The secret here is to not learn everything, but rather learn a technology from each category." Practice each chunk until you can say it smoothly. Finally, record yourself and compare it to the video to spot areas for improvement. This method, often called "shadow speak," helps build fluency and confidence in both daily and technical English. Consistent practice with this video will not only boost your speaking skills but also familiarize you with industry vocabulary, making it a powerful tool for english speaking practice.

Wat is de Shadowing-techniek?

Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop โ€” als een schaduw die de spreker volgt met slechts 1โ€“2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert โ€” waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.

Shadowing-techniek: lees de volledige stap-voor-stap-gids โ†’