YT YouTube2Text

YouTube2Text → Transcripts → I Bet Nobody Explained Real Developer Life in IT Like This (3-Hour Course)

I Bet Nobody Explained Real Developer Life in IT Like This (3-Hour Course) — Transcript

by Cloud X Berry · 27,383 words · 4,809 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00If you're trying to break into tech
0:01right now, you've probably noticed a
0:03frustrating problem.
0:05Tutorials teach you how to write code,
0:07but that's honestly the easy part.
0:10When you get hired, you aren't just a
0:12solo coder anymore. You have to
0:14integrate with a team, existing code,
0:16and moving parts.
0:18You're thrown into a world of Jira
0:19tickets, Git repositories, staging
0:22environments, and deployment pipelines.
0:25It's incredibly overwhelming.
0:27Most people only understand this stuff
0:29after 6 to 12 months on the job. And
0:31honestly, most beginners get massive
0:34imposter syndrome their first week
0:36because no one taught them this stuff.
0:38Most of that only comes from years on
0:40the job.
0:41This course hands you the short version.
0:43So when you talk about it, you sound
0:45like someone who already has the
0:46experience well before you've actually
0:49put in the time.
0:50This course exists to fix that.
0:53In under 2 hours, we are going to walk
0:55through the real-world developer
0:56workflow. We're not going deep into
0:58theory.
0:59The focus is how things actually work in
1:02real jobs.
1:03No dry history lessons on hardware, just
1:06the day-to-day reality of modern IT.
1:08We're going to look at how front ends
1:10and back ends actually talk to each
1:12other using APIs,
1:14how to navigate code reviews and Q&A
1:16pushback without taking it personally,
1:18how to read a status code and a log line
1:20so you can tell where a problem is
1:22before anyone else,
1:24how cloud platforms like AWS actually
1:26fit into the picture, and how developers
1:28are actually using AI tools like Copilot
1:31and Cursor today, including how to
1:33review what the AI hands you because
1:35that's the skill that actually gets you
1:37trusted.
1:38If you want to stop feeling lost in tech
1:40jargon and actually understand how the
1:42industry operates, this is for you.
1:45If this is the part you've been missing,
1:47you'll get a lot out of this. Welcome to
1:49module one. It's a short one with two
1:52ideas.
1:53We'll look at what IT covers inside a
1:55real company using one everyday example.
1:58You'll also see the two reasons depend
2:00on these systems, including companies
2:02that don't sell software at all. By the
2:04end of this module, you'll be able to
2:06explain what IT really is and why a
2:09business can't run without it. Ask 10
2:11people what IT means and you'll get 10
2:14different answers.
2:16Some think it's the guy who fixes your
2:17laptop.
2:18Some think it's just coding.
2:21Neither one is really the full picture.
2:23In real companies, IT is every system
2:26that keeps the business running
2:27digitally.
2:29That includes the app your customers
2:30use, the servers that host it, the
2:32database that stores their information,
2:35the network that connects everything,
2:37and yes, the person who resets your
2:39password when you forget it.
2:41Think about ordering food from an app.
2:43The moment you tap order, you've
2:45triggered a whole chain of IT systems.
2:48The app talks to a server. The server
2:51checks a database to confirm the
2:52restaurant is open.
2:54Another system calculates your delivery
2:55fee.
2:56A notification system pings the driver.
2:59All of that from end to end is IT.
3:03So when people say they work in IT, that
3:06could mean building the app, maintaining
3:08the servers, securing the data, or
3:10supporting the people who use all of it.
3:12It's not one job.
3:14It's an entire ecosystem of jobs working
3:17together.
3:18And here's the part most beginners miss.
3:20None of these systems exist in
3:22isolation.
3:23They're all built and maintained by
3:25teams of people who have to coordinate
3:27constantly.
3:28Which brings us to the next question.
3:30How do companies actually organize all
3:32of this? Here's something that surprises
3:34a lot of beginners.
3:36Most companies aren't in the business of
3:38making software.
3:40A bank isn't a software company. A
3:43hospital isn't a software company.
3:45But almost every single one of them runs
3:47entirely on software.
3:49Companies use IT for two big reasons.
3:52First, to run the business internally.
3:55Things like payroll systems, internal
3:57messaging tools, and databases that
3:59track inventory or employees.
4:02Second, to serve customers externally,
4:05things like a banking app, a hospital's
4:07patient portal, or an online store.
4:10Companies organize all of this in
4:11different ways, and we'll talk about
4:13what that means for your first job near
4:15the end of the course.
4:17In either case, IT isn't a side
4:19department anymore. It's the backbone.
4:22If the systems go down, the company
4:24stops making money, customers can't get
4:26service, and employees can't do their
4:28jobs.
4:29That's why companies invest so heavily
4:31in the people and processes that keep IT
4:34running smoothly.
4:35Now that you understand what IT is and
4:38how companies rely on it, let's zoom in
4:40on the machines themselves. In the next
4:42section, we're going to open up the hood
4:45and look at how computers and operating
4:46systems actually work. Let's recap
4:49module one.
4:50You now know that IT is every system
4:53that keeps a business running.
4:55That goes from the app customers use to
4:57the person who resets your password.
4:59You've seen how one food order sets off
5:01a whole chain of those systems. And you
5:04know companies use them in two ways, to
5:06run the business from the inside and to
5:09serve customers.
5:10When those systems go down, the business
5:12feels it right away. Welcome to module
5:15two.
5:16Let's look at the machine your code runs
5:17on.
5:18We'll begin with the simple loop every
5:20program follows and the three physical
5:23parts your app depends on.
5:25After that comes the operating system
5:27and the rules it sets for your code.
5:29We finish with the screen full of plain
5:31text that developers work in and why
5:34many of them prefer it to a mouse.
5:36By the end of this module, you'll
5:38understand why an app can run out of
5:40memory.
5:41You'll also know why servers are often
5:43run by typing commands. Let's begin.
5:45Let's clear this up right away. If you
5:48get a computer science degree, you'll
5:49spend months calculating binary code.
5:52But honestly, I never calculate binary
5:55on the job.
5:56Let's look at computers the way a
5:57working developer does.
5:59At its core, a computer is a digital
6:02machine. That just means it stores
6:04everything as tiny electrical switches
6:06that are either on or off, ones and
6:09zeros.
6:10Every photo, song, and piece of software
6:13is just millions of these switches.
6:15But you don't need to read the ones and
6:17zeros. You just need to know a computer
6:19is a fast calculator that does exactly
6:22three things, input, process, output.
6:26Think about logging into Instagram or
6:28Netflix. You type your password and
6:30click a button. That's the input. The
6:33system checks if your password is
6:34correct. That's the process. It loads
6:37your feed. That's the output.
6:39Every piece of software you will ever
6:41work on is just doing that loop.
6:44Your job as a developer is to write the
6:46process part. The computer doesn't try
6:49to fix your code. It just follows
6:51instructions like a very obedient robot.
6:54If your code is broken, the machine will
6:56execute that broken code perfectly.
6:58That's exactly why debugging is such a
7:00massive part of the job, and we'll get
7:02into that later. But first, let's look
7:05at the physical hardware that actually
7:07runs your code. Every app you've ever
7:09used depends on just three physical
7:11parts.
7:12If even one of them fails, your app
7:14dies.
7:16Those parts are storage, RAM, and
7:18[clears throat] the CPU.
7:20Storage is your hard drive. It's where
7:22data lives permanently. It holds a
7:25massive amount of data, but pulling that
7:27data is slow.
7:29RAM is your active memory. When someone
7:31opens your app, the system pulls it from
7:33slow storage into fast RAM so it runs
7:36smoothly.
7:37But RAM is strictly limited. If your
7:40code loads too much data at once, RAM
7:42fills up and the app freezes.
7:45The CPU is the engine. It executes your
7:48logic and does the actual math.
7:50You need to care about this because when
7:52your company hosts an app in the cloud,
7:54they pay for these resources based on
7:56usage.
7:57If you write bloated code, your app
7:59chews through RAM and CPU.
8:02That drives up your AWS bill, or worse,
8:05your app crashes in production because
8:06the server ran out of memory.
8:09Storage is where data is saved. RAM is
8:12where data works, and the CPU does the
8:14heavy lifting. But hardware is
8:16completely useless on its own. It needs
8:18a manager, which brings us to the
8:21operating system. You might think your
8:23code runs directly on the computer's
8:24hardware, but in reality, your code
8:27isn't even allowed to touch it.
8:30Hardware only understands electricity.
8:32It has no idea what a database or a web
8:35browser is.
8:36We use an operating system, like
8:38Windows, Mac, or Linux, as a middleman.
8:42In tech, we call this abstraction.
8:45When your backend reads from a database
8:47or sends a response over the network,
8:49it's not doing it directly. Your code is
8:52asking the operating system to do it for
8:54you.
8:55To keep things safe, the operating
8:57system is divided into two strict zones.
9:00First, there is kernel mode. This is the
9:03core engine. It has absolute power over
9:06the hardware.
9:07Second, there is user mode. This is
9:10where your code runs.
9:11User mode is basically a restricted
9:13bubble.
9:14Your app cannot directly touch the
9:16hardware or mess with other programs.
9:19If your code tries to access memory it
9:21doesn't own, the kernel immediately
9:23shuts it down.
9:25This is exactly why one buggy app can't
9:27take down the whole machine, and it's
9:29why you'll see errors like segmentation
9:31fault or out of memory on the job.
9:34That's the kernel stepping in and
9:36stopping a program before it damages
9:38anything else.
9:39Here's the thing. You probably use a Mac
9:42or Windows right now, but the servers
9:44that run the internet overwhelmingly run
9:46Linux.
9:48If you look at the web servers where the
9:49operating system can be identified, more
9:51than nine out of 10 run a Unix-style
9:54system, and most of those are Linux.
9:57You don't need to be an expert in it
9:58today, but you need to understand that
10:00the environment where you write your
10:02code is usually different from the Linux
10:04server where your code actually lives.
10:07And when you deploy your code to that
10:08Linux server, you won't have a mouse to
10:10click around with.
10:12Let's talk about the command line. Here
10:14is something most beginners don't
10:15realize. When developers deploy code to
10:18a server thousands of miles away, they
10:21aren't clicking buttons on a screen.
10:23You've spent your entire life using a
10:25mouse, clicking icons, dragging folders.
10:29It's comfortable.
10:30Early on, most people rely on the mouse.
10:33Over time, you'll notice developers lean
10:35on the keyboard instead because for
10:38repetitive or technical tasks, it's
10:40usually a lot faster.
10:42What you are used to is called a GUI, a
10:45graphical user interface.
10:48But when you get on a dev team, you'll
10:49see developers staring at black screens
10:52with white text.
10:53That is the CLI, the command line
10:56interface.
10:57It's not hacking. It does the exact same
11:00thing your mouse does.
11:01Typing a simple text command in the CLI
11:04is exactly the same as right-clicking
11:06and hitting new folder with your mouse.
11:08Developers do this for two reasons,
11:10speed and automation.
11:13You cannot easily automate 100 mouse
11:15clicks, but you can write a one-line
11:17script to do it instantly in the command
11:19line.
11:20More importantly, when you deploy your
11:22back-end code to a Linux server in the
11:24cloud, there is often no screen and no
11:27mouse waiting for you.
11:28It's a remote machine that expects text
11:31commands.
11:32Even on teams where deployments run
11:33through an automated pipeline, that
11:35pipeline is usually built and maintained
11:38using the CLI. So sooner or later,
11:41you'll need it.
11:42You don't need to memorize a dictionary
11:44of commands today. Just know that as you
11:46step into this industry, you'll notice
11:48developers rely heavily on the keyboard
11:51because it's much faster.
11:53Now that you know the hardware and the
11:54OS, it's time to look at the actual
11:57software.
11:58In the next section, we are going to
12:00break down exactly what happens when you
12:02type a website into your browser.
12:04I'll see you there. Let's recap module
12:06two.
12:07You saw that programs take input,
12:09process it, and give output, and that
12:12your job is to write the process part.
12:14That code depends on three physical
12:16parts. Storage keeps data, RAM holds
12:20what's being worked on, and the CPU does
12:23the work.
12:24Use too much memory or CPU and your
12:26cloud bill goes up or your app crashes.
12:29The operating system sits between your
12:31code and the hardware. That's why one
12:33buggy app usually can't take down the
12:35whole machine.
12:37And since most web servers run Linux,
12:39often with no screen or mouse,
12:41developers get comfortable with the
12:42command line. Welcome to module three.
12:45Let's see what happens when someone uses
12:47a website.
12:49We'll take one page load apart piece by
12:51piece.
12:52Along the way, you'll meet the front
12:54end, the back end, APIs, and the
12:56database, and you'll see what each one
12:58is responsible for.
13:00You'll also learn to read status codes,
13:02a small skill that helps you find
13:04problems much faster.
13:06The last part compares websites and
13:08mobile apps.
13:09By the end of this module, you'll be
13:11able to look at a failed request and say
13:13which part to check first.
13:15Let's start in the browser. You open
13:17your browser, type a website address,
13:19and within a second, the page appears.
13:22It feels simple,
13:23but behind that one click, your computer
13:26is talking to other computers, sending
13:28requests, receiving data, and putting
13:31everything together into a page you can
13:32use.
13:34Let's break down what actually happens.
13:36First, you open a browser like Chrome or
13:39Safari.
13:40You type a website address, such as
13:42example.com, and press enter.
13:45Your browser needs to find the server
13:47hosting that website.
13:49This is where DNS comes in.
13:51DNS stands for Domain Name System. It
13:54translates a domain name, like
13:56example.com, into an IP address that
13:59computers can use to locate the
14:00destination.
14:02You don't need to memorize the entire
14:04DNS process right now. Just remember
14:06this. Humans use names, computers use
14:09addresses.
14:11Once the browser knows where to connect,
14:13it sends a request to the server.
14:15This is called an HTTP request.
14:18For example, your browser might ask,
14:21give me the homepage.
14:22The server receives that request and
14:24decides what to do. Maybe it returns an
14:27HTML page. Maybe it needs to fetch some
14:29data. Maybe it needs to check whether
14:31you're logged in.
14:33The server processes the request and
14:35sends a response back.
14:37That response might contain HTML, CSS,
14:40JavaScript, images, or data.
14:43Your browser receives those files and
14:45uses them to display the website.
14:48By the way, you can actually watch all
14:50of this happen.
14:51Every browser has a developer tools
14:53panel, and the network tab shows every
14:55single request your page makes.
14:58You'll use it in the assignment for this
14:59section.
15:00And that's the basic idea. You request
15:03something, a server processes it, you
15:05receive a response.
15:07Now, here's something important.
15:09The website you see is not necessarily
15:12running entirely on your laptop.
15:14The browser is responsible for
15:16displaying and running the front end.
15:18The back end may be running on a
15:20completely different machine, possibly
15:22in the cloud.
15:24That's why developers need to understand
15:25how these pieces communicate. Because
15:28when a user says the website isn't
15:30working, the problem could be in the
15:31browser, the network, the back end, or
15:34somewhere else.
15:36And that brings us to the next question.
15:38What exactly is the front end and what
15:41does the back end do? When you use an
15:43application, there are usually two major
15:45parts you need to understand, the front
15:48end and the back end.
15:50And if you're entering software
15:51development, you'll hear these two words
15:53constantly.
15:54Let's use a simple example. You open an
15:57online shopping website. You can see
15:59products, search for items, add
16:01something to your cart, and place an
16:03order.
16:04Everything you see and interact with in
16:06the browser is part of the front end.
16:09The front end is the user-facing part of
16:11the application.
16:13It handles things like what appears on
16:14the screen, what happens when you click
16:16a button, how a page responds to your
16:19actions, and how data is displayed.
16:22Common front-end technologies include
16:24HTML, CSS, and JavaScript.
16:27Frameworks like React, Angular, and Vue
16:30are also used to build front-end
16:32applications.
16:33But here's the important part. The front
16:36end usually doesn't own all the data or
16:38business logic.
16:40For example, when you open a product
16:42page, the front end needs product
16:44information.
16:45Where does that information come from?
16:47That's where the back end comes in.
16:50The back end runs on the server side. It
16:52handles things like processing requests,
16:55applying business rules, accessing data,
16:58and communicating with other systems.
17:00Let's say you click Add to Cart. The
17:03front end knows you clicked the button,
17:05but the back end may need to check the
17:07product, verify availability, calculate
17:10the price, and save the cart.
17:12The front end displays the result. The
17:15back end handles the work behind the
17:16scenes.
17:18Now, don't think of front end and back
17:20end as two completely separate
17:22applications that never interact.
17:24They work together. The front end is
17:26responsible for the user experience. The
17:29back end is responsible for server-side
17:31processing and data access, and they
17:33communicate through APIs, which we'll
17:36cover next.
17:37One more thing. A front-end developer
17:39doesn't necessarily need to know every
17:42back-end technology,
17:43and a back-end developer doesn't
17:45necessarily need to build the front end.
17:48But both developers need to understand
17:50how their work connects.
17:52Because if the front end sends the wrong
17:54request, the back end may reject it.
17:56And if the back end returns the wrong
17:58data, the front end may display
18:00something incorrectly.
18:02That's why understanding the complete
18:04application is useful, even if you
18:06specialize in one area.
18:08Now let's look at the piece that
18:09connects these two sides, the API. API
18:13is one of those words you'll hear
18:15everywhere in IT.
18:17Front-end developers talk about APIs,
18:19back-end developers build APIs. QA
18:22engineers test APIs, and cloud
18:25applications communicate with APIs all
18:27the time.
18:29So what is an API?
18:31Let's keep it simple.
18:33An API, or application programming
18:35interface, is a defined way for software
18:38to communicate with other software.
18:40Think about a restaurant. You look at
18:42the menu and decide what you want. You
18:45tell the waiter your order.
18:46The waiter takes it to the kitchen. The
18:48kitchen prepares the food, and the
18:50waiter brings it back.
18:52You don't need to walk into the kitchen
18:53and figure out how everything works. You
18:55just use the interface provided to you.
18:58An API works in a similar way.
19:01Let's say your front end needs to
19:02display a list of products. It sends a
19:05request to the back end through an API.
19:07The back end processes that request,
19:09gets the required data, and sends a
19:11response.
19:13The front end receives the response and
19:14displays the products.
19:16For example, an API might have an
19:18endpoint that simply means give me the
19:21products. The response would come back
19:23as structured data, something like a
19:25list of products, each one with an ID, a
19:28name, and a price.
19:29The front end can use that data to
19:31display the products on the screen.
19:34You don't need to memorize the technical
19:35format right now. We'll keep the deeper
19:37details for another course. But
19:39understand this. An API is a contract
19:43between systems.
19:44It defines how one piece of software can
19:46request something from another piece of
19:48software.
19:49And it's not limited to front end and
19:51back end.
19:52A payment system can communicate with a
19:54shopping application through an API.
19:57A weather application can request
19:58weather data from a weather service. A
20:00mobile app can communicate with the same
20:02back end used by a website.
20:05That's why APIs are such a big part of
20:07modern software.
20:09Now, every one of those API calls comes
20:12back with a little status code. And once
20:14you can read that code, you can tell
20:16where a problem is before anyone else on
20:18the team. Let's look at that next.
20:21Here's a skill that takes about 3
20:22minutes to learn and will make you look
20:24like you've been doing this for years.
20:26Every time the front end talks to the
20:28back end, it sends a request and gets a
20:30response. And every response carries a
20:33three-digit number called a status code.
20:36That number is the back end's one-word
20:38answer to the question, how did that go?
20:40You only need to know a handful.
20:42Anything starting with two means fine.
20:45200 is the classic. You asked for the
20:48products, here are the products.
20:50Anything starting with three means look
20:52somewhere else.
20:54A 301 or a 302 is a redirect. The page
20:57moved.
20:58Anything starting with four means you,
21:01the caller, got something wrong.
21:03400 means the request itself was
21:05malformed.
21:07401 means you're not logged in. 403
21:10means you're logged in but not allowed.
21:12And 404, the famous one, means the thing
21:15you asked for doesn't exist.
21:18Anything starting with five means the
21:20back end got something wrong.
21:22500 is a generic crash on the server.
21:25502 or 503 usually mean the server is
21:28down or overloaded.
21:30So look at this one. The front end sent
21:32get/api/products.
21:35The back end answered 200 and the body
21:38is a small piece of structured text
21:39called JSON.
21:41An ID, a name, a price. That's the whole
21:44conversation.
21:45The front end takes that JSON and turns
21:47it into a product card on the screen.
21:50Now here's why this matters for you.
21:52Remember the question from the first
21:53lecture? The website isn't working.
21:55Where's the problem?
21:57If the request never left the browser,
21:59it's the front end.
22:00If it came back with a four, the front
22:02end probably sent the wrong thing.
22:05If it came back with a five, the back
22:07end broke.
22:08If it came back 200 and the screen is
22:10still wrong, the front end is displaying
22:12the data incorrectly.
22:14Four scenarios, one number tells you
22:16which one you're in before you touch a
22:18single line of code.
22:20Now the back end needs somewhere to keep
22:22the data it's sending back. That's the
22:24database. Let's say you create account
22:26on a website. You enter your name,
22:29email, and password. You close the
22:31browser, come back tomorrow, and your
22:33account is still there.
22:35Where did that information go?
22:37It was stored somewhere. That's the job
22:40of a database.
22:41A database is a system used to store and
22:44manage data so applications can retrieve
22:46and work with it.
22:48In a typical application, the flow looks
22:50like this.
22:51The front end collects the user's input,
22:54the back end processes the request, and
22:56the database stores or retrieves the
22:58information.
22:59Let's take a simple example.
23:01You log into an application.
23:03The front end sends your login details
23:05to the back end.
23:07The back end checks the stored account
23:08information and verifies the
23:10credentials. If the login is successful,
23:12the back end sends a response and the
23:14front end displays your dashboard.
23:17The database is where the application
23:19keeps information such as users,
23:21products, orders, or other business
23:23data.
23:24Now, there are different types of
23:26databases. Relational databases, such as
23:29MySQL, PostgreSQL, and SQL Server, store
23:33structured data in tables.
23:35NoSQL databases, such as MongoDB, use
23:38different data models and are often used
23:40for applications with particular data
23:42and scaling requirements.
23:44You don't need to learn database design
23:46in this course, but you should
23:48understand the difference between the
23:49application and the data it uses. Your
23:52back end code is not necessarily the
23:54permanent storage.
23:56The database is a separate system
23:58responsible for managing data.
24:00And this distinction matters in real
24:02jobs. If a user says their order
24:04disappeared, the problem might be in the
24:06front end, the back end, or the
24:08database.
24:09If an application is slow, the database
24:11could also be part of the problem.
24:13That's why developers need to understand
24:15how data moves through an application.
24:18Now, one last question.
24:20Does a mobile app work completely
24:22differently from a website?
24:24Not necessarily. You use a website on
24:26your laptop.
24:27You open the same service on your phone
24:30and the experience looks a little
24:31different.
24:32The buttons may be arranged differently,
24:35the layout may be different, the app may
24:37use mobile specific features.
24:39But here's the important part. Both
24:42applications can communicate with the
24:43same backend.
24:46For example, imagine you're using a
24:47shopping application. [clears throat]
24:49You add an item to your cart on your
24:50laptop. Then you open the mobile app and
24:53the same item is still in your cart.
24:56How does that happen?
24:57Because both clients can use the same
24:59backend and access the same underlying
25:02account data.
25:04The website and the mobile app are
25:05different clients.
25:07They may have different front end
25:08technologies.
25:09A website might use React.
25:12A mobile application might use Swift,
25:14Kotlin, or a cross-platform framework
25:16like Flutter or .NET MAUI.
25:18But they can still communicate with the
25:20same backend through APIs.
25:23This is a useful concept to understand
25:25before entering IT.
25:27You might work on a front end team, a
25:29back end team, or a mobile team.
25:31Even if your technology is different,
25:33the application architecture can be
25:35connected.
25:36And that's the bigger picture.
25:38The front end displays the experience.
25:41The back end processes the requests. The
25:44API connects systems. The database
25:47stores the data.
25:49Once you understand these four pieces, a
25:51lot of software development starts
25:52making more sense.
25:54In the next section, we'll move into
25:56programming basics and look at how
25:58developers actually write the logic
25:59behind these applications. Let's recap
26:02module three.
26:03You followed one request from start to
26:05finish. DNS turned a name into an
26:08address. The browser asked a server for
26:11a page and a response came back.
26:14You saw how the work splits between the
26:15two sides of an application. An API is
26:18the agreed way for them to talk.
26:21Status codes gave you a quick way to
26:23find a problem. A four usually points at
26:25the caller. A five points at the back
26:28end and a 200 with a wrong screen often
26:31points at the front end.
26:32And since the data lives in a separate
26:34database, your cart can follow you from
26:36your laptop to your phone. Welcome to
26:39module four.
26:40Now let's look at the code that makes an
26:42application work.
26:44You don't need any coding experience for
26:45this.
26:46We'll go through what programming really
26:48is and the few ideas you'll find in
26:50nearly every language.
26:52You'll see how developers avoid writing
26:54the same logic twice and why errors are
26:56a normal part of the work.
26:58We finish with the code your project
27:00uses that somebody else wrote.
27:02By the end of this module, you'll know
27:04the ideas behind most code.
27:06You'll also know why a real project is
27:08full of code your team didn't write.
27:11Let's start with what programming
27:12actually means. Programming is basically
27:15giving a computer a set of instructions
27:17to follow.
27:19When you're writing code, you're not
27:20really talking to the computer in some
27:22magical way.
27:24You're breaking a problem down into
27:25steps that a machine can execute.
27:28For example, let's say you are building
27:30a shopping application and the user
27:32clicks buy now.
27:34Something has to happen behind that
27:36button.
27:37Check whether the product exists,
27:39check whether it's in stock,
27:41calculate the price, create the order,
27:44save the order, return a response.
27:47That's programming.
27:49The language might be Python, Java, C
27:52Sharp, JavaScript, or something else.
27:55The syntax changes, but the underlying
27:57idea stays the same. Take a problem,
28:00break it into logical steps, and tell
28:03the computer exactly what to do.
28:05And this is one of the biggest mindset
28:07shifts for beginners. Programming isn't
28:10primarily about memorizing syntax. It's
28:12about learning how to turn a problem
28:14into a sequence of instructions. Before
28:17you work on real applications, there are
28:19a few programming concepts you'll see
28:21everywhere.
28:22The first is a variable.
28:24A variable is simply a name pointing to
28:26some data.
28:28You might have a username, an order
28:30total, a product ID, or whether a user
28:33is logged in.
28:34Variables let you store information and
28:36use it later.
28:37You can also update their values as your
28:39program runs.
28:41For example, when a customer adds
28:43another item to their cart, you can
28:45update the variable holding the total
28:46number of items.
28:48Then you have conditions.
28:50This is where your program makes
28:52decisions.
28:53For example, if the user is logged in,
28:55show their dashboard. Otherwise, show
28:57the login page.
28:59You can also combine conditions to
29:01handle more complex situations.
29:03For example, you might check whether a
29:05user is logged in and whether they have
29:07permission to access a particular page.
29:10Conditions help your application respond
29:12differently depending on the data or
29:14situation it encounters.
29:16Then you have loops.
29:18A loop is useful when you need to repeat
29:20something.
29:21Let's say you get a hundred products
29:23from a database and need to process
29:25every one of them.
29:26You don't write the same code a hundred
29:28times. You write the logic once and
29:30repeat it.
29:31Loops can also stop when a particular
29:33condition is met, which is useful when
29:35you don't know exactly how many
29:37repetitions you'll need.
29:39For example, you could use a loop to
29:40calculate the total price of every
29:42product in a customer's shopping cart.
29:45These three ideas show up everywhere.
29:48Store data, make decisions, repeat work.
29:51Whether you're working in Python, Java,
29:54C Sharp, JavaScript, or another
29:56language, you'll keep coming back to
29:58these concepts. One of the first things
30:00that separates beginner code from more
30:02practical code is understanding
30:04functions.
30:06Let's say your application needs to
30:07calculate the total price of an order.
30:10You could write that logic directly
30:12inside your checkout code.
30:14But what happens when another part of
30:16the application needs the same
30:17calculation?
30:19You'd end up copying the code.
30:21That's where functions help.
30:23You put a specific piece of logic inside
30:25a reusable function and call it whenever
30:28you need it.
30:29For example, you might write a small
30:31function called calculate total, which
30:34takes in a price and a quantity and
30:36simply returns the price multiplied by
30:38the quantity.
30:40Now you don't care how many times you
30:41need that calculation. You can call the
30:43function whenever you need it.
30:46You can also update the calculation in
30:47one place without changing every part of
30:50your application.
30:52For example, if you later need to
30:54include a discount, you can update the
30:56function to handle that requirement.
30:58Every part of the application that calls
31:00this function can then use the updated
31:02logic.
31:04In real projects, functions get combined
31:06into larger components, services,
31:09classes, modules, and applications.
31:12So when developers talk about writing
31:14reusable code, this is what they're
31:16getting at.
31:18Functions also make code easier to test
31:20because you can check a specific piece
31:22of logic independently.
31:24They help break large problems into
31:26smaller pieces that are easier to
31:28understand and maintain.
31:30Don't write the same logic again and
31:32again when you can isolate it and reuse
31:35it. Here's something beginners usually
31:37discover very quickly.
31:39Your code will break. And that's
31:41completely normal. You might have a
31:43syntax error because you wrote something
31:45incorrectly.
31:47You might have a runtime error because
31:48something went wrong while the
31:49application was running.
31:51Or the code might run perfectly but
31:53still produce the wrong result. That's a
31:56logic error.
31:57And that last one is especially
31:59important.
32:00A program can be completely valid from
32:02the computer's perspective and still be
32:05wrong from the user's perspective.
32:07That's why developers spend a surprising
32:09amount of time debugging.
32:11We'll walk through how that actually
32:13looks, error message and all, in the
32:14next section.
32:16For now, the mindset is what matters.
32:19You fix the actual cause.
32:21You don't randomly change code until the
32:23error disappears.
32:25Sometimes the error message points
32:27directly to the problem.
32:29Other times you need to trace the
32:31execution and understand what the code
32:33is actually doing.
32:35That 's why reading error messages
32:36carefully is such an important skill.
32:39They often provide clues about where
32:41things went wrong and what to
32:42investigate next.
32:44You are not trying to write perfect code
32:46that never breaks.
32:48You're learning how to understand and
32:49fix problems when it does. One final
32:52concept beginners should understand is
32:54that developers rarely build everything
32:56from scratch.
32:58Let's say your application needs to send
33:00an email.
33:01You could spend weeks building an entire
33:03email system yourself,
33:05or you could use an existing library or
33:07service that already solves the problem.
33:10That's why developers use libraries and
33:12frameworks.
33:14A library gives you reusable
33:15functionality. A framework gives you a
33:18larger structure for building
33:19applications.
33:21And these projects often depend on many
33:23other packages. Those are called
33:25dependencies.
33:27For example, a library might handle
33:29email formatting, while another package
33:31handles communication with an email
33:33service.
33:34Using these existing tools saves time
33:36and lets you focus on the specific
33:38requirements of your application.
33:41Of course, you still need to understand
33:42what these dependencies do and whether
33:45they fit your project's requirements.
33:47This is why you'll eventually see
33:49certain files in almost every project.
33:52JavaScript projects have a file called
33:54package.json.
33:56Python projects have a file called
33:58requirements.txt.
34:00Java projects have a file called
34:02pom.xml.
34:04And .NET projects have a project file
34:06ending in .csproj.
34:09These files help define what your
34:10application depends on.
34:12They also help other developers install
34:14the required packages and get the
34:16project running in their own
34:17environments.
34:19So when you join a real project, you're
34:21usually not starting with an empty
34:23folder.
34:24You're joining an existing codebase with
34:26existing frameworks, libraries,
34:28dependencies, and conventions.
34:31And that's much closer to what real
34:32software development looks like. Let's
34:34recap module four.
34:36Programming means breaking a problem
34:38into steps a computer can follow.
34:41The syntax changes from one language to
34:43another, but that idea stays the same.
34:46Variables, conditions, and loops let a
34:48program store data, make decisions, and
34:51repeat work.
34:52Functions let you write some logic once
34:55and use it wherever you need it.
34:57Errors come in three kinds, and the
34:59logic error is the hard one because the
35:01code runs and the result is still wrong.
35:04And libraries and frameworks mean you
35:06rarely build everything yourself.
35:08In module five, we look at how a team
35:10works on code together. Welcome to
35:13module five. This is where the real job
35:16begins. On a real team, you rarely
35:18decide on your own what to build.
35:21Work comes to you in a certain way.
35:23It moves through a set of steps and
35:25other people are involved at each one.
35:27You'll join a codebase you didn't write
35:30and you'll get a ticket that says what's
35:31needed.
35:32Someone will ask how long it's going to
35:34take.
35:35You'll make your change with Git and
35:36you'll see the different environments
35:38code passes through.
35:40When you're done, you'll hand your work
35:41to a teammate in a pull request. By the
35:44end of this module, you'll be able to
35:46take a ticket and follow it through your
35:47team's steps.
35:49Let's start with the code that's already
35:50there. One of the biggest surprises for
35:52new developers is that most of the time
35:55you're not building something from an
35:56empty folder.
35:58You join a company, open your laptop,
36:00clone a repository, and discover that
36:03hundreds of files are already there.
36:06There are APIs, database queries,
36:08configuration files, tests, logging,
36:11authentication, deployment scripts, and
36:14code written by people who may have left
36:16the company years ago.
36:18And then your manager gives you a
36:20ticket, something like add a new field
36:22to the customer API.
36:24That sounds simple,
36:26but before changing anything, you need
36:28to figure out where that API is
36:30implemented,
36:31where the data comes from, which
36:33database table contains the field,
36:35whether another service uses the same
36:37model, whether tests already exist, and
36:40whether adding the field could break
36:42something else.
36:43You might also need to understand how
36:45the application is configured and how
36:47changes move from development into
36:49production.
36:51Sometimes the hardest part isn't making
36:53the change itself,
36:54it's discovering all the places that
36:56change might affect.
36:58This is why being a developer is not
37:00just about writing code.
37:03A huge part of the job is understanding
37:05code that already exists.
37:07Over time, you'll learn to follow the
37:09flow of data, identify important files,
37:12and recognize how different parts of an
37:14application connect.
37:16Your first skill on a real project isn't
37:18typing faster,
37:20it's getting comfortable moving through
37:21code you didn't write, a skill worth its
37:24own closer look later in this course. In
37:26many companies, your work starts with a
37:28ticket.
37:30You might hear terms like Jira, Azure
37:32DevOps, Linear, or GitHub issues.
37:35The tool changes, but the idea is
37:37similar.
37:38Someone creates a piece of work that
37:40needs to be done.
37:42For example, a ticket might say, add
37:44email validation to customer
37:46registration.
37:47The description explains that users
37:49should not be able to register with an
37:51invalid email address,
37:53and the acceptance criteria might say,
37:55the email format needs to be validated,
37:58an error message should show up when
37:59it's wrong, unit tests need to be added,
38:02and existing valid registrations must
38:05continue working.
38:06The important part is that a ticket
38:08usually describes the problem and the
38:10expected outcome, not every line of code
38:13you need to write.
38:14It's your job to understand the
38:16requirement and figure out how to
38:17implement it.
38:19Sometimes the ticket might leave
38:20important details unclear.
38:23You may need to ask questions, discuss
38:25edge cases, or clarify what should
38:27happen when something goes wrong.
38:29You'll also see different types of
38:31tickets. A bug means something isn't
38:33working correctly.
38:35A task is a piece of implementation
38:37work.
38:38A story is a larger piece of
38:39functionality from the user's
38:41perspective, and an epic is a larger
38:43body of work made up of multiple smaller
38:46tickets.
38:47Once you understand this, a ticket stops
38:49looking like an instruction from your
38:51manager and starts looking like the
38:53starting point for an engineering
38:54problem.
38:56You also need to think about how your
38:57change fits into the existing
38:59application and whether it introduces
39:01any risks.
39:02And once you understand the problem,
39:04someone's going to ask you the next
39:05question.
39:07How long do you think this will take?
39:08Once a ticket exists, someone usually
39:11has to answer a question that feels
39:13harder than it should be.
39:14How long will this take?
39:17Many teams don't answer that in hours.
39:19They use story points, a rough relative
39:22measure of effort and complexity rather
39:24than a literal time estimate.
39:27A small, well-understood change might be
39:29a one or a two. Something that touches
39:31several parts of the system or has a lot
39:33of unknowns might be a five or an eight.
39:37The exact scale differs by team, and
39:39that's fine. The number itself matters
39:41less than the conversation that produces
39:43it.
39:44Here's the part beginners aren't warned
39:46about. Your estimates will sometimes be
39:49wrong, often in your first year, and
39:51that's expected, not a sign you're bad
39:53at the job.
39:55A ticket that looked like a two-day
39:56change can turn into a week once you
39:58discover an edge case nobody mentioned
40:01or a piece of the system that behaves
40:02differently than documented.
40:05What actually matters isn't estimating
40:07perfectly. It's noticing early and
40:09saying something.
40:11If you're a day into a two-day ticket
40:13and you can already tell it's going to
40:14take four, that's the moment to flag it
40:17and stand up on the ticket wherever your
40:19team tracks this, not on the final day
40:22when it's already late.
40:24Something like, this is turning out
40:26bigger than expected because of X.
40:29I think it's closer to four days now.
40:31That single sentence, said early, is the
40:34difference between a manageable surprise
40:36and a stressful one.
40:37So don't treat an estimate as a promise
40:39carved in stone.
40:41Treat it as your best guess with the
40:43information you had at the time and
40:45treat updating it honestly as part of
40:47the job, not a failure to admit.
40:50Once your ticket is estimated and picked
40:52up, the next thing you'll actually spend
40:54most of your day using is Git. If you're
40:56working in software development, Git is
40:59going to become part of your everyday
41:00workflow.
41:02You pull the latest code, you create a
41:04branch, you make your changes, you
41:07commit them, you push the branch. Then
41:10you create a pull request.
41:12Someone reviews it, and once it's
41:13approved, it gets merged.
41:16The important thing to understand is
41:18that Git isn't just a place where code
41:20is stored.
41:21It's how teams safely work on the same
41:23codebase.
41:24Two developers can work on different
41:26features without constantly overwriting
41:28each other's work.
41:30Your branch gives you an isolated place
41:32to make changes, and the pull request
41:34gives the team a chance to review those
41:36changes before they become part of the
41:38main codebase.
41:40For example, imagine you're adding a new
41:42payment feature while another developer
41:44is fixing a login issue.
41:46You can both work on separate branches
41:48and commit your changes independently.
41:50Once your work is ready, Git helps bring
41:52those changes together.
41:54Sometimes you'll encounter merge
41:56conflicts when different changes affect
41:58the same part of a file.
42:00You'll need to understand what changed
42:02and decide how to combine the work
42:04correctly.
42:05Git also keeps a history of your changes
42:08so you can understand what happened and
42:09return to earlier versions when
42:11necessary.
42:12You'll eventually encounter terms like
42:14commit, branch, merge, pull request,
42:18rebase, conflict, checkout, and clone.
42:22You don't need to master all of Git
42:23before your first job, but you
42:25absolutely need to understand why Git
42:28exists and how it fits into the
42:30development workflow. Here's another
42:32concept that becomes very real when you
42:34join a company.
42:35Your code usually doesn't go directly
42:38from your laptop to the real users.
42:40There are different environments.
42:43Development is where developers build
42:45and test their changes.
42:47Some teams also have an int environment,
42:49short for integration, which is where
42:51your changes are combined with everyone
42:53else's changes for the first time, just
42:55to make sure nothing conflicts.
42:58Test or Q A is where the application is
43:01validated before release.
43:03Many companies also have a staging
43:05environment, which is set up to look and
43:07behave almost exactly like production so
43:10the team can do one final check before
43:12anything goes live.
43:14And production is the real environment
43:16used by actual customers.
43:19Your code typically moves through
43:20several of these stages in order from
43:22your machine to dev, maybe to int, to
43:26test, to staging, and finally to prod.
43:30Not every company uses all of these
43:31environments and some combine a few of
43:33them, but the idea tends to be the same.
43:36Catch problems earlier in a safer
43:39environment before they ever reach a
43:41real customer.
43:43And this distinction matters.
43:45You don't want to test a database
43:47migration by experimenting directly on
43:49the production database.
43:51You don't want unfinished features
43:52appearing in front of customers,
43:55and you don't want a developer casually
43:56changing production configuration
43:58because they were trying to fix
43:59something.
44:01Later in the course, we'll talk about
44:03how C I C D helps move changes between
44:05these environments safely.
44:07For now, remember one thing. Your laptop
44:11is not production. You finish your
44:13ticket, you open a pull request,
44:16and now a teammate who wasn't in your
44:18head while you were writing this has to
44:20figure out what you changed and why,
44:23usually in the middle of their own busy
44:24day.
44:26A weak pull request just says fixed the
44:28bug and links the ticket.
44:31A good one saves the reviewer real time.
44:34It says what changed, why you approached
44:36it that way, and how to actually test
44:38it. A specific input, a specific screen,
44:42a specific expected result.
44:44Think of it like handing off a task to a
44:46co-worker who's about to go on vacation.
44:49You wouldn't just say I did the thing,
44:51you'd say what you touched, what you
44:53didn't touch, and what to double check.
44:56This matters for your commit messages
44:58too.
44:59Fixed stuff tells a future developer
45:01nothing.
45:02Fix null pointer when discount is
45:04applied to an empty cart tells them
45:06exactly what problem existed and when it
45:09happened.
45:10The same habit applies inside your code.
45:13A comment shouldn't restate what the
45:15next line obviously does.
45:17It should explain the part the code
45:19can't show on its own, why this
45:21particular edge case needed a special
45:23check, or why you didn't use the simpler
45:25approach.
45:26Good documentation also helps when
45:28someone needs to investigate a problem
45:30later.
45:31They can understand the original
45:33decision without having to track down
45:34the person who made it.
45:36None of this is about writing more.
45:39It's about writing exactly enough that
45:41the next person, maybe you 6 months from
45:43now, doesn't have to guess.
45:46So once your pull request is actually
45:48open, what happens next?
45:50That's where code review comes in. Code
45:52review is simple to describe. A teammate
45:55reads your change before it joins the
45:57main codebase. Sometimes they approve it
45:59right away. Often they'll leave a few
46:02comments. They might ask a question,
46:04point out a case you missed, or suggest
46:06a simpler way to do something.
46:08You make the changes and push them to
46:10the same branch, and the pull request
46:12picks them up.
46:14Once your teammate approves, your branch
46:15gets merged.
46:17Those comments can feel personal the
46:19first few times.
46:20They're about the code, and senior
46:22developers get them too.
46:24They also teach you how your team likes
46:26things done.
46:27So let's recap module 5 and how far your
46:29ticket came.
46:31You found your way around code you
46:32didn't write.
46:33You understood what was being asked,
46:35gave an estimate, and worked on your own
46:37branch.
46:39Along the way, you saw the environment's
46:41code passes through on its way to
46:42customers.
46:43Then you wrote a pull request that
46:45someone could follow, and it got
46:47reviewed and merged.
46:49Up to this point, your change has only
46:51moved inside the team.
46:53In module 6, it goes the rest of the
46:55way, out to the using the app. Welcome
46:58to module six. Now let's see what
47:00happens between your laptop and
47:02production. This one is longer because a
47:05lot happens at this stage.
47:07see how code becomes something that can
47:09run, a container is, how a pipeline
47:12moves it all along.
47:14also see where settings and passwords
47:16belong since they stay out of the code.
47:19comes up twice. first time, it's the
47:21habits every company assumes you have.
47:24The second time, it's how you handle
47:26people's data and how you build for
47:28people who use software differently.
47:30The rest is about going live safely.
47:33That covers deployments and going back
47:34to an older version. It also covers
47:37turning features on without a new
47:38release and changing an API without
47:41breaking the apps that use it.
47:43By the end of this module, you'll know
47:44what people mean by a failed build, a
47:46red pipeline, or a rollback.
47:49Let's start. You finished your ticket.
47:51The code works on your machine, but that
47:54doesn't mean the feature is ready for
47:55customers.
47:57Before your change reaches production,
47:59several things usually need to happen.
48:01Your code needs to be built, tests need
48:04to run, the application may need to be
48:06packaged, security or quality checks
48:08might run. Then the application needs to
48:11be deployed to an environment.
48:13A simplified version of that journey
48:15looks like this. You write the code, you
48:18commit it, it gets built, it gets
48:20tested, it gets packaged, it gets
48:23deployed, and finally, it gets verified.
48:27The exact process depends on the company
48:29and technology stack.
48:31A small application might have a very
48:32simple pipeline. A large enterprise
48:35application might have dozens of
48:37automated checks before anything reaches
48:39production.
48:40For example, if a test fails after your
48:42latest change, the pipeline can stop the
48:45deployment before the problem reaches
48:46customers.
48:48Teams also use different environments,
48:50such as development, testing, staging,
48:53and production.
48:54Each environment serves a different
48:56purpose, helping teams validate changes
48:58before exposing them to real users.
49:01Sometimes, a deployment succeeds
49:03technically, but the application still
49:05behaves incorrectly.
49:07That's why teams also monitor logs,
49:09metrics, and application health after
49:12releasing a change.
49:13And if something goes wrong, teams need
49:15a way to roll back the release or
49:17quickly deploy a fix.
49:19This is one reason teams automate these
49:21steps instead of relying on someone to
49:24remember every check manually.
49:26You'll often hear these processes
49:28described as continuous integration and
49:30continuous delivery or CICD. The
49:33important thing to understand is that
49:35writing the code is only one part of
49:37delivering software. You will hear
49:39developers talk about building an
49:41application. What does that actually
49:43mean?
49:44It depends on the language. Some
49:46languages need source code to be
49:48compiled into another form before it can
49:50run. Others may be interpreted or
49:53packaged differently.
49:54But the general idea is the same. You
49:57start with your source code and produce
49:58something that can actually be executed
50:01or deployed.
50:02For example, a project might contain
50:04your source code, its dependencies, some
50:06configuration, and a set of tests.
50:09All of that goes through a build
50:11process, and out the other end comes an
50:13application package. That package could
50:15be a container image, a compiled
50:17application, a deployment artifact, or
50:20another format depending on the
50:21technology.
50:23And this is why developers don't simply
50:25copy random source files onto a
50:27production server. There is usually a
50:29repeatable process that turns source
50:31code into something deployable.
50:33A build process can also catch problems
50:35early, such as compilation errors,
50:37missing dependencies, or incorrect
50:39configuration.
50:41In a team environment, the goal is to
50:43make sure the same source code produces
50:45a consistent, predictable result every
50:48time the application is built.
50:50Once the build is complete, the
50:51resulting artifact can move through
50:53testing and deployment without
50:55developers having to manually assemble
50:57the application each time.
50:59And these days, more often than not,
51:01that something is a container.
51:04Let's talk about what that actually is.
51:06You will hear the word container in your
51:08first week, probably your first day.
51:11So, let's make sure it doesn't scare
51:12you.
51:13Here's the problem containers solve. The
51:16application works on your laptop.
51:18Then it goes to the test server and
51:20breaks.
51:21Different operating system version,
51:23different version of a library, a
51:25missing configuration file,
51:27and the sentence every developer has
51:29said at least once, but it works on my
51:32machine.
51:33A container fixes that by packaging the
51:36application together with everything it
51:37needs to run.
51:39The code, the runtime, the libraries,
51:41the settings,
51:43all of it in one sealed box. That box
51:46runs the same way on your laptop, on the
51:49test server, and in the cloud because it
51:51carries its own environment with it.
51:54A widely used tool for this is Docker.
51:57And the recipe for a container is a
51:58small text file called a Docker file.
52:01You'll see it at the root of many
52:02repositories.
52:04It just says, start from this base, copy
52:07my code in, install the dependencies,
52:09and here's the command to run.
52:12Two words you'll hear together.
52:14An image is the packaged box sitting on
52:16a shelf.
52:17A container is that image actually
52:19running.
52:21Same relationship as a recipe and a
52:23meal.
52:24So, when the build pipeline from the
52:25last lecture finishes, what often comes
52:28out the other end is a container image.
52:30That image gets pushed to a registry,
52:33which is just a storage shelf for
52:34images.
52:35And when it's time to deploy, the server
52:37pulls the image down and runs it.
52:40You don't need to write Docker files on
52:42day one.
52:43But when someone says the image didn't
52:45build or the container keeps restarting,
52:48you now know exactly what they're
52:49talking about.
52:51Now let's look at the machinery that
52:52builds and ships all of this
52:54automatically. CI/CD. Now we get to one
52:57of the most important concepts in modern
52:59software development. CI/CD.
53:03CI usually means continuous integration.
53:07The idea is that developers integrate
53:09their changes into the shared code base
53:11regularly, while automated checks help
53:13catch problems early.
53:15CD can refer to continuous delivery or
53:18continuous deployment depending on the
53:20setup.
53:21The basic idea is that software can move
53:23through the delivery process in a
53:25controlled and repeatable way.
53:27For example, a developer pushes their
53:29code and the CI/CD pipeline picks it up
53:32automatically. It builds the code, runs
53:35the tests, runs quality checks, and
53:37deploys it.
53:38These pipelines are usually triggered by
53:40events such as pushing code, opening a
53:43pull request, or merging changes into a
53:45particular branch.
53:47Instead of a developer manually logging
53:49into a server every time and copying
53:51files around, the pipeline can perform
53:53these steps automatically.
53:55This is one of the major differences
53:57between a small personal project and a
53:59mature engineering environment.
54:02Continuous delivery means the
54:03application is kept ready for release,
54:06often with a manual approval before
54:08production deployment.
54:09Continuous deployment takes this further
54:12by automatically releasing changes that
54:14pass all required checks.
54:16The more software you have, the more
54:18valuable automation becomes.
54:20And when one of those steps turns red,
54:22that's not a disaster. That's the
54:24pipeline doing its job. It caught the
54:27problem before a customer did.
54:29Teams can also configure notifications
54:32so developers know which step failed and
54:34can investigate the problem quickly.
54:36You don't want your production process
54:38to depend on someone remembering 15
54:40manual steps.
54:42You want the process itself to be
54:43repeatable. Here's another thing
54:45beginners often discover when they move
54:47from small projects to real
54:49applications.
54:50Your code is usually the same across
54:52environments, but the configuration is
54:55not.
54:56For example, your application might need
54:58a database URL, an API endpoint, a
55:01storage account, some application
55:03settings, feature flags, and
55:05credentials.
55:06You don't want your production database
55:08URL hardcoded inside your source code.
55:11Instead, applications usually get this
55:14information through configuration or
55:16environment specific settings, often
55:18stored as environment variables with
55:20names like database URL, API URL, or
55:24storage account.
55:25The actual values can change between
55:27development, testing, and production.
55:30For example, your development
55:32environment might connect to a local
55:34database, while production connects to a
55:36managed database hosted in the cloud.
55:39The application code can stay the same
55:41while the configuration determines which
55:43database it uses.
55:45This is also why secrets need special
55:47handling.
55:48Passwords, API keys, and credentials
55:51should not simply be committed to Git
55:52and left sitting inside the repository.
55:55Even if you remove a secret in a later
55:57commit, it may still exist in the
55:59repository's history.
56:01That's why you should rotate exposed
56:02credentials immediately, rather than
56:04assuming deleting the file has solved
56:06the problem.
56:08In real projects, you'll often work with
56:10secret managers, environment variables,
56:12or other secure configuration systems.
56:15One important distinction is that
56:17environment variables are a way to
56:18provide configuration, not automatically
56:21a secure place to store secrets.
56:24Production applications often use
56:26dedicated secret management systems to
56:28control access and manage credentials
56:30safely.
56:31The key idea is simple. Code and
56:34environment specific configuration
56:36should be treated separately.
56:38And since we just mentioned secrets,
56:40let's spend a few minutes on the
56:42security habits every developer is
56:44expected to have.
56:45Not the security team, you. Nobody
56:48expects a junior developer to be a
56:50security expert, but there are five
56:52habits that every company assumes you
56:54already have. If you don't, you find out
56:58the hard way.
56:59First, secrets never go into Git.
57:02Passwords, API keys, tokens, connection
57:06strings, once a secret is committed,
57:08it's in the history forever, even if you
57:11delete it in the next commit.
57:13And on public repositories, automated
57:15bots are commonly scanning for exactly
57:17this kind of leaked key, often catching
57:19them quickly.
57:21This is why production projects
57:22typically keep secrets in environment
57:24variables or a secret manager, and why
57:26there's a file called .gitignore that
57:29tells Git which files to never touch.
57:32If you accidentally commit a secret,
57:34tell your team immediately and rotate or
57:36revoke that credential.
57:38Removing it from the latest version of
57:39the code is not enough to make it safe.
57:42Second, never paste production data or
57:45secrets into an AI tool
57:47or a public chat or a ticket. It's
57:50incredibly tempting when you're
57:52debugging. Just paste the whole log with
57:54the customer's email in it into the
57:56assistant.
57:57Don't. Strip it first.
57:59Leaks like this have caused real, costly
58:01incidents at real companies.
58:04Even when a tool is approved by your
58:05company, understand its data handling
58:08rules before sharing sensitive
58:09information. Use sanitized examples
58:12whenever possible.
58:13Third, never trust input from the
58:16outside.
58:17Remember our registration form? A user
58:19can type anything into that email field,
58:22anything, including things designed to
58:24break your database.
58:26The backend validates every input as if
58:28the user is actively trying to hurt you,
58:31not because most are, because one will.
58:34And validation alone isn't enough for
58:36every threat.
58:37For example, database queries should use
58:39parameterized statements instead of
58:41building SQL by joining user input
58:44directly into a query.
58:46Fourth, HTTPS, always. That's the
58:49padlock in the browser. It means the
58:51data between the user and the server is
58:53encrypted. Every login form, every API,
58:57every environment including test.
59:00You should also avoid disabling
59:01certificate validation just to make a
59:03connection work.
59:05That check helps verify that you're
59:06communicating with the intended server.
59:09Fifth, least privilege. You get access
59:12to what you need for your job and
59:14nothing more. So when you don't have
59:16right access to the production database
59:17on day one, that's not the company being
59:20difficult. That's the company protecting
59:22you. A junior developer with full
59:24production access is one typo away from
59:27a very bad day.
59:29The same principle applies to
59:30application permissions.
59:32A service should only have the access it
59:34needs and credentials should never be
59:36shared casually between people or
59:38applications.
59:40None of this is complicated,
59:42but you'll notice that experienced
59:43developers do all five without thinking.
59:46Start now and by your first job, it'll
59:49be automatic for you too.
59:51All right, the code is built, packaged,
59:53configured, and secured.
59:56Now it needs to actually reach the
59:57environment.
59:58Let's look at what happens during a
1:00:00deployment. Let's say everything passed.
1:00:03The application has been built, tests
1:00:05passed, the deployment pipeline is ray.
1:00:08Now the new version needs to reach the
1:00:10environment.
1:00:11That might mean deploying a container,
1:00:13updating a cloud service, publishing an
1:00:16application package, running
1:00:17infrastructure changes, or updating a
1:00:19server.
1:00:20And deployment isn't always just upload
1:00:23new code and hope for the best.
1:00:25A mature deployment process might
1:00:27include a health check right after
1:00:28deploying, then some smoke tests, then
1:00:31ongoing monitoring before it's
1:00:33considered a real success.
1:00:35Some teams also use gradual rollouts,
1:00:38releasing the new version to a small
1:00:40percentage of users before making it
1:00:42available to everyone.
1:00:44This helps limit the impact if something
1:00:46goes wrong.
1:00:47And sometimes the deployment fails.
1:00:50Maybe the application starts but can't
1:00:52connect to the database.
1:00:54Maybe a configuration value is missing.
1:00:56Maybe a new change causes an unexpected
1:00:58error.
1:00:59Sometimes the deployment itself succeeds
1:01:02but users start experiencing slower
1:01:04response times or errors that weren't
1:01:06caught during testing.
1:01:08That's why teams watch application
1:01:09metrics and logs closely after a
1:01:12release.
1:01:13For critical applications, teams may
1:01:15also use blue-green deployments where
1:01:17two environments are maintained so
1:01:19traffic can switch between the old and
1:01:21new versions when needed.
1:01:23Another approach is a canary deployment
1:01:26where the new version is introduced
1:01:27gradually while the team checks its
1:01:29behavior before expanding the rollout.
1:01:32That's why deployment and monitoring are
1:01:33connected. You don't just ask, did the
1:01:36deployment finish? You also ask, is the
1:01:39application actually healthy after the
1:01:41deployment?
1:01:42Because ultimately, a successful
1:01:44deployment isn't just about getting new
1:01:46code into production. It's about making
1:01:48sure the application continues working
1:01:50reliably for the people using it. Now
1:01:53let's talk about something every
1:01:54developer eventually learns the hard
1:01:56way.
1:01:57A deployment can pass every automated
1:01:59test and still cause a problem in
1:02:01production.
1:02:03Maybe a strange edge case wasn't
1:02:04covered. Maybe the production data is
1:02:06different from your test data.
1:02:08Maybe an external service behaves
1:02:10differently.
1:02:12When that happens, one option is a
1:02:14rollback. That means moving the
1:02:16application back to a previous known
1:02:18good version.
1:02:20Say you released version 1.5 and it
1:02:22caused a production issue. A rollback
1:02:24simply puts version 1.4 back in place
1:02:28while the team figures out what went
1:02:29wrong.
1:02:30For example, imagine a new release
1:02:32causes the checkout page to fail for
1:02:34some customers.
1:02:36Instead of making everyone wait for a
1:02:37fix, the team can roll back to the
1:02:39previous version and restore the
1:02:41checkout experience.
1:02:43The goal isn't to pretend mistakes don't
1:02:45happen. The goal is to make failures
1:02:47recoverable.
1:02:49Of course, rolling back application code
1:02:51doesn't automatically reverse database
1:02:53changes. If a release changes the
1:02:55database structure or modifies existing
1:02:58data, the team needs to consider whether
1:03:00those changes are compatible with the
1:03:02previous version.
1:03:03That's a major principle in modern
1:03:05engineering. You don't design systems
1:03:07assuming nothing will ever go wrong. You
1:03:10design the process so that when
1:03:11something does go wrong, the team can
1:03:14detect it, respond to it, and recover
1:03:16safely.
1:03:17This is also why teams plan their
1:03:19recovery strategy before releasing risky
1:03:22changes rather than figuring everything
1:03:24out during an incident.
1:03:26And recovering safely starts with
1:03:27knowing exactly what data you're
1:03:29responsible for in the first place. A
1:03:31support engineer pastes a customer's
1:03:33full account details, name, email, and
1:03:36order history into a chat tool to ask
1:03:39for help debugging.
1:03:40Nothing malicious happened, but that
1:03:42data just left a system built to protect
1:03:45it and landed somewhere it was never
1:03:47supposed to go.
1:03:49This is what people mean by PII,
1:03:51personally identifiable information.
1:03:54It's anything that can identify a
1:03:56specific person, a name, an email, a
1:03:59phone number. Sometimes it's even a
1:04:01combination of details that aren't
1:04:03identifying on their own, but become
1:04:05identifying together.
1:04:07Handling it carelessly isn't just a
1:04:09security slip. In many places, it's a
1:04:12legal one, too, under rules like GDPR in
1:04:15Europe.
1:04:16Those rules require companies to know
1:04:18where personal data lives, who can see
1:04:20it, and how to delete it if someone
1:04:22asks.
1:04:23The habit that matters most day-to-day
1:04:25is minimizing exposure.
1:04:27When you're debugging, strip personal
1:04:29details out of logs and examples before
1:04:32you share them, the same way you'd strip
1:04:34a password out of a screenshot.
1:04:36When you're building a feature, ask
1:04:37whether you actually need to store a
1:04:39piece of personal data at all or whether
1:04:42a reference to it elsewhere would do the
1:04:43job.
1:04:44Data you never collected can never leak.
1:04:48Accessibility is a related habit that's
1:04:50easy to treat as optional and isn't.
1:04:53A meaningful share of users navigate
1:04:55software with a screen reader or without
1:04:57a mouse or with reduced vision.
1:04:59Small things carry a lot of weight here.
1:05:02Don't convey meaning through color
1:05:04alone. Give images alternative text that
1:05:07describes what they show.
1:05:09Make sure interface elements can be
1:05:10reached and activated using only a
1:05:12keyboard.
1:05:14None of this requires becoming an
1:05:15accessibility specialist. It requires
1:05:18checking before you ship a screen
1:05:20whether someone using only a keyboard
1:05:22could actually get through it.
1:05:24Both of these habits share the same
1:05:26shape.
1:05:27They're invisible when you get them
1:05:28right, and they only become visible,
1:05:30often publicly and expensively, when you
1:05:33get them wrong.
1:05:34That's exactly why they're easy to skip
1:05:36under a deadline and exactly why the
1:05:38teams that build them in as habits
1:05:40rather than afterthoughts tend to avoid
1:05:42the worst version of that story. A team
1:05:45finishes a new checkout flow and wants
1:05:47to ship it carefully, not all at once to
1:05:49every user.
1:05:51So they wrap the new flow in a feature
1:05:53flag and deploy it to production with
1:05:55the flag switched off.
1:05:57The code is live on every server. Nobody
1:06:00sees it yet.
1:06:01That split is the whole idea.
1:06:03Deploying code means moving it to
1:06:05production. Releasing a feature means
1:06:07users can actually reach it.
1:06:09Most of the time those two things happen
1:06:11together. You deploy and users see the
1:06:14change immediately.
1:06:15A feature flag breaks that link on
1:06:18purpose.
1:06:19A feature flag is a setting, often just
1:06:21true or false, that the code checks
1:06:24before deciding which path to run.
1:06:26Turn it off and users get the old
1:06:28behavior. Turn it on and they get the
1:06:30new one.
1:06:31The team can turn it on for themselves
1:06:33first, then a small percentage of real
1:06:35users, then everyone, watching for
1:06:38problems at each step.
1:06:40This changes how risk gets managed. If
1:06:43the new checkout flow breaks something,
1:06:45the fix isn't a rollback and a redeploy.
1:06:48It's flipping the flag back off, which
1:06:50usually takes seconds. The bad code is
1:06:52still sitting in production, but nobody
1:06:54is running it anymore.
1:06:56Flags show up in smaller, everyday
1:06:58forms, too.
1:07:00A flag that hides an unfinished feature
1:07:01from everyone except the team building
1:07:03it.
1:07:04A flag that lets support turn a feature
1:07:06off for one customer having trouble
1:07:08without touching anyone else.
1:07:10A flag used for an A/B test where two
1:07:13groups of users run different code paths
1:07:15so the team can compare results.
1:07:18The catch is that flags aren't free.
1:07:20Every flag is a branch in the code, an
1:07:23if this, else that. And old flags that
1:07:26nobody removes pile up into code that's
1:07:28hard to follow.
1:07:29A flag left in by accident, still
1:07:32checked in some corner of the codebase
1:07:34long after the decision was made, is a
1:07:36common source of confusing bugs.
1:07:38Teams that use flags well usually clean
1:07:41them up once a decision is final, the
1:07:43same way they'd clean up a temporary
1:07:44debug log.
1:07:46So when you hear that something is
1:07:47deployed but not released yet, this is
1:07:50usually why. The code already made it to
1:07:53production. Someone just hasn't flipped
1:07:55the switch. A mobile app calls an
1:07:57endpoint that returns a customer's name
1:07:59as a single field.
1:08:01The backend team decides that's messy
1:08:03and changes it to two fields, first name
1:08:06and last name in the same response.
1:08:08They deploy it.
1:08:09Within minutes the app is crashing for
1:08:12anyone who hasn't updated it because
1:08:14it's still looking for the old field and
1:08:16it isn't there anymore.
1:08:18Nothing was wrong with the new shape.
1:08:20The problem is that the old mobile app
1:08:22was never updated to expect it, and apps
1:08:24don't update themselves the moment a
1:08:26server changes.
1:08:28Someone is always running older code
1:08:30against your newest API, a phone that
1:08:32hasn't auto updated, a partner's system
1:08:35that integrates with you, a script
1:08:37someone wrote last year that still
1:08:38works. That's what backward
1:08:40compatibility means. A change is
1:08:43backward compatible when the old callers
1:08:45keep working exactly as before, even
1:08:48though something changed underneath.
1:08:50Some changes are naturally safe. Adding
1:08:53a new optional field usually doesn't
1:08:55break anyone because old code just
1:08:57ignores fields it doesn't recognize.
1:09:00Renaming a field, removing one, or
1:09:02changing what a field means are the
1:09:04changes that break old callers because
1:09:06they expected something specific and now
1:09:08it's gone or different.
1:09:11When a breaking change is unavoidable,
1:09:13teams usually version the API instead of
1:09:15changing it in place. That might mean a
1:09:18version number in the URL, like a path
1:09:20that says v1 versus v2, or a version
1:09:23noted in a request header.
1:09:25Old callers keep hitting V1 and keep
1:09:28working. New callers can move to V2 once
1:09:31they're ready.
1:09:32The old version doesn't disappear
1:09:33immediately. It usually sticks around
1:09:36for a deprecation window, often
1:09:37announced well in advance, giving
1:09:39everyone time to move before it's
1:09:41finally turned off.
1:09:43This is why a seemingly simple request,
1:09:46just rename this field, is rarely simple
1:09:49in a real system. It isn't about the
1:09:51code being hard to write. It's about
1:09:53every caller you can't see and don't
1:09:55control still depending on the shape
1:09:58you're about to change. Let's recap
1:10:00module six. It was a long one, so here's
1:10:03where your change has been.
1:10:05It got turned into a package, often a
1:10:07container image. A pipeline checked it
1:10:09and moved it along, so nobody had to
1:10:11copy files by hand.
1:10:13The settings stayed outside the code, so
1:10:16the same build could run in test and in
1:10:18production. When it went live, the team
1:10:20watched whether the app stayed healthy.
1:10:22If it didn't, they had a way back. You
1:10:25also saw how teams lower the risk of a
1:10:27change. Feature flags are one way, and
1:10:30keeping an API working for older callers
1:10:32is another.
1:10:33And you picked up the security, privacy,
1:10:36and accessibility habits that stay with
1:10:38you on every change you make. Through
1:10:40all of this, we kept saying your code
1:10:43runs on a server or in production. We
1:10:46haven't said much about where those
1:10:47servers are or who looks after them.
1:10:50For a lot of companies, the answer is
1:10:52the cloud. And that's module seven.
1:10:55Welcome to module seven. You've heard
1:10:57the word cloud a few times by now. Let's
1:11:00see what it really means. We'll go
1:11:02through the few building blocks most
1:11:04cloud apps use and how much of the work
1:11:06you can hand to the provider.
1:11:08When an app grows, you'll hear words
1:11:10like scaling and availability, so we'll
1:11:13explain those too.
1:11:14Then it gets practical. You'll see what
1:11:17a developer really touches in the cloud
1:11:19and how a forgotten server turns into a
1:11:21bill.
1:11:22The last part is about you.
1:11:24We'll look at the different jobs around
1:11:26all this, and you'll get a way to tell
1:11:28one might suit you.
1:11:29By the end of this module, you'll be
1:11:31able to say what it means for an app to
1:11:33run in the cloud. You'll also know which
1:11:35parts of it you deal with yourself.
1:11:37Let's get into it. The cloud sounds like
1:11:39some completely different kind of
1:11:41technology. It isn't. At a basic level,
1:11:44the cloud is still computers, storage,
1:11:47networks, and databases.
1:11:49The difference is that instead of your
1:11:51company buying physical servers, putting
1:11:53them in a data center, and managing
1:11:55everything yourself, you can rent those
1:11:57resources from a cloud provider.
1:11:59Companies like AWS, Azure, and Google
1:12:02Cloud operate huge data centers filled
1:12:05with infrastructure.
1:12:06You request what you need through their
1:12:08platform, maybe a virtual machine, some
1:12:11object storage, a managed database, or a
1:12:14serverless function that just runs your
1:12:15code without you managing a server at
1:12:17all.
1:12:18You use the service, configure it, and
1:12:21pay based on the service and usage
1:12:22model.
1:12:23For example, imagine you're building an
1:12:25online shopping application. You might
1:12:28host the application on a virtual
1:12:29machine, store product images in cloud
1:12:31storage, and use a managed database to
1:12:34store customer and order information.
1:12:36These services work together to support
1:12:38the same application.
1:12:40You can also scale resources as your
1:12:42needs change. If more customers start
1:12:44using your application, you can increase
1:12:47capacity or configure certain services
1:12:49to scale automatically depending on the
1:12:51architecture.
1:12:53Another important difference is that you
1:12:54don't always have to manage the
1:12:56underlying infrastructure yourself.
1:12:58With managed services, the cloud
1:13:00provider handles many operational tasks,
1:13:03allowing your team to focus more on
1:13:05building and maintaining the
1:13:06application.
1:13:07So when someone says our application
1:13:10runs in the cloud, it doesn't mean the
1:13:12application is floating somewhere. It
1:13:14means the application is running on
1:13:16infrastructure provided through a cloud
1:13:18platform. You don't need to memorize
1:13:20hundreds of cloud services. Start with
1:13:22the basic building blocks.
1:13:24Compute is where your application
1:13:26actually runs. That could be a virtual
1:13:29machine, a container platform, a
1:13:31serverless function, or another compute
1:13:33service.
1:13:34Storage is where you keep files and
1:13:36objects, things like images, videos,
1:13:39backups, and documents.
1:13:42Databases store your application's
1:13:43actual data, customers, orders,
1:13:46products, transactions, and so on.
1:13:49And networking is what connects all
1:13:51these pieces together, controlling how
1:13:53traffic moves between users,
1:13:55applications, databases, and other
1:13:57services.
1:13:58For example, imagine an online shopping
1:14:01application.
1:14:02Compute runs the application. The
1:14:04database stores customer and order
1:14:06details. Storage holds product images,
1:14:09and networking allows customers to
1:14:11access everything through their
1:14:12browsers.
1:14:14A very simple application might just
1:14:16have users hitting an application, which
1:14:18talks to a database and maybe some
1:14:20object storage.
1:14:21A larger application usually adds more
1:14:23pieces in front of and around that.
1:14:26A load balancer spreading traffic across
1:14:28multiple copies of the application, a
1:14:30cache sitting in front of the database
1:14:32to speed things up, and storage handling
1:14:35the larger files.
1:14:36Each additional component usually solves
1:14:38a specific problem.
1:14:40A load balancer helps distribute
1:14:42incoming traffic. A cache reduces
1:14:44repeated requests to the database, and
1:14:46additional application instances help
1:14:48handle more users.
1:14:50As the application grows, you might also
1:14:52introduce monitoring to track its
1:14:54health, identity services to control who
1:14:57can access it, and backup systems to
1:14:59help recover from failures.
1:15:01You don't need to understand every
1:15:03service yet.
1:15:04What matters is that cloud applications
1:15:06are usually built by combining these
1:15:08same few building blocks, just at
1:15:10different scales. Here's one of the
1:15:12biggest advantages of the cloud.
1:15:14You don't always have to manage the
1:15:15underlying infrastructure yourself.
1:15:18Let's say your application needs a
1:15:19database. One option is to run that
1:15:22database yourself on a virtual machine.
1:15:25Now you're the one responsible for
1:15:27updates, backups, monitoring, scaling,
1:15:30and keeping the operating system
1:15:31maintained.
1:15:33Another option to use a managed database
1:15:35service where the cloud provider handles
1:15:38much of that underlying infrastructure
1:15:39for you, so your team can focus more on
1:15:42the database and the application itself.
1:15:45Of course, managed doesn't mean the
1:15:47provider handles absolutely everything.
1:15:49Your team may still be responsible for
1:15:51database access, data security, query
1:15:54performance, and deciding how backups
1:15:57and recovery should work.
1:15:59That same idea shows up across cloud
1:16:01services, and you'll often hear three
1:16:03terms for it.
1:16:04Infrastructure as a service, or IaaS,
1:16:08means you manage more of the
1:16:09infrastructure yourself.
1:16:11Platform as a service, or PaaS, means
1:16:15the provider manages more of the
1:16:16underlying platform for you.
1:16:19And software as a service, or SaaS,
1:16:22means you simply use the finished
1:16:23software. Your company might use
1:16:25Microsoft 365, for example, without
1:16:28managing a single server that runs it.
1:16:31Think about it this way. With IaaS, you
1:16:34get more control but take on more
1:16:36operational responsibility.
1:16:39With PaaS, you spend less time managing
1:16:41the platform.
1:16:43With SaaS, you use an application that's
1:16:46already built and maintained by the
1:16:48provider.
1:16:49The right choice depends on what you're
1:16:51building, how much control you need,
1:16:53your team's expertise, and how much
1:16:55operational work you're prepared to take
1:16:57on.
1:16:58The important lesson isn't memorizing
1:17:00those three letters. It's understanding
1:17:02how much infrastructure your team is
1:17:04actually responsible for managing. Cloud
1:17:07platforms become especially useful when
1:17:09an application grows. Let's say your
1:17:11application normally has 1,000 users.
1:17:15Then a marketing campaign suddenly
1:17:17brings in 100,000.
1:17:19Your system needs to handle that jump in
1:17:21traffic, and that's where scaling comes
1:17:23in. Adding more copies of your
1:17:25application, giving existing ones more
1:17:27resources, or adding caching to absorb
1:17:30the extra load.
1:17:32There are two common approaches to
1:17:33scaling.
1:17:34Vertical scaling means giving an
1:17:36existing server more resources, such as
1:17:39CPU and memory.
1:17:41Horizontal scaling means adding more
1:17:43instances of the application so the
1:17:45workload can be shared across them.
1:17:47You'll also hear the word availability.
1:17:50Businesses don't want their application
1:17:52to go down just because one server
1:17:54failed. So cloud architectures often
1:17:56spread things across multiple instances,
1:17:59zones, and regions with backups in
1:18:01place, specifically to reduce the impact
1:18:04when something does fail.
1:18:05For example, if one application instance
1:18:08becomes unhealthy, a load balancer can
1:18:10direct traffic to other healthy
1:18:12instances.
1:18:13This helps keep the application
1:18:14available while the team investigates
1:18:16the failure.
1:18:17However, simply running multiple
1:18:19instances doesn't guarantee high
1:18:21availability.
1:18:23The architecture also needs to account
1:18:24for dependencies, database failures,
1:18:27network issues, and other potential
1:18:29points of failure.
1:18:31And then there's cost.
1:18:33Cloud infrastructure isn't free.
1:18:35Compute, storage, networking, and
1:18:37databases all come with a price tag
1:18:39attached.
1:18:40So developers eventually start thinking
1:18:42about something beyond does this code
1:18:44work? They also start asking how much
1:18:47does this application actually cost to
1:18:49run?
1:18:50That's a very real part of modern
1:18:52software engineering. You might be
1:18:54wondering, am I expected to become a
1:18:56cloud administrator as a developer?
1:18:58Not necessarily.
1:19:00Your role depends on the company and the
1:19:02team.
1:19:03But even application developers commonly
1:19:05interact with cloud systems day to day.
1:19:08You'll open up application logs to see
1:19:10what happened, check the status of the
1:19:12deployment, look at environment
1:19:13variables, glance at metrics, and
1:19:16confirm whether a service is actually
1:19:18healthy.
1:19:19When something breaks, you might check
1:19:20database connectivity, dig into why a
1:19:23deployment failed, or investigate why an
1:19:25API suddenly started returning errors.
1:19:28For example, if an API suddenly becomes
1:19:31slow, you might check its response
1:19:33times, look for errors in the logs, and
1:19:35see whether the database or another
1:19:37dependent service is causing the delay.
1:19:40You may also use cloud dashboards to
1:19:42understand resource usage, identify
1:19:44unhealthy services, and determine
1:19:46whether an issue started after a recent
1:19:48deployment.
1:19:50These clues help you narrow down the
1:19:51problem before making changes.
1:19:54So you don't necessarily need to know
1:19:56every cloud service that exists.
1:19:58You need to understand how your
1:19:59application fits into the cloud
1:20:01environment around it, and that's
1:20:03becoming a basic part of working in IT.
1:20:06There's one more part of that
1:20:07environment worth understanding early
1:20:09because it has nothing to do with
1:20:11whether your code works,
1:20:13what it costs to keep running. Someone
1:20:15spins up a cloud server to test
1:20:17something on a Friday afternoon. They
1:20:19forget about it over the weekend.
1:20:21On Monday, a message shows up in a
1:20:23shared channel asking whose instance has
1:20:25been running since Friday.
1:20:27This happens often enough in real
1:20:29companies that most of them build small
1:20:31habits around it.
1:20:32Cloud resources are billed by usage, not
1:20:35by a fixed yearly fee the way older
1:20:37on-site hardware often was.
1:20:39A server, a database, or a block of
1:20:41storage keeps costing money for every
1:20:44hour it exists, whether or not anyone is
1:20:46actually using it.
1:20:48Cloud infrastructure is appealing
1:20:49because you can spin something up in
1:20:51minutes.
1:20:52That same convenience is exactly what
1:20:54makes it easy to accidentally leave
1:20:56something running.
1:20:57Here's the simplest habit and one of the
1:20:59first things many developers are told on
1:21:01day one at a company that takes the
1:21:03cloud seriously.
1:21:05Stop or delete anything you spun up for
1:21:07testing once you're done with it,
1:21:09especially before a weekend.
1:21:11It sounds almost too obvious to mention,
1:21:13and it's also one of the most repeated
1:21:15pieces of advice in real engineering
1:21:17onboarding because the mistake is so
1:21:20easy to make and so visible when it
1:21:22happens.
1:21:23Most cloud providers also offer tagging,
1:21:26a way of labeling resources with who
1:21:28created them and what project they
1:21:29belong to.
1:21:31Many also offer budgets or alerts that
1:21:33notify someone when spending crosses a
1:21:35threshold.
1:21:36These exist specifically because which
1:21:39team's resource is this and why is it
1:21:41still running is a common enough
1:21:43question that it needed tooling, not
1:21:45just good intentions.
1:21:47Cost isn't usually a developer's main
1:21:49job, but it's part of the judgment that
1:21:51separates someone who thinks only about
1:21:53whether code works from someone who
1:21:55thinks about what it costs to keep
1:21:57working.
1:21:58A feature that works perfectly and
1:22:00quietly runs up an unnecessary bill
1:22:02every month is still a problem, just one
1:22:04that shows up on a different kind of
1:22:06dashboard.
1:22:07That same judgment, knowing which parts
1:22:09of the job are actually yours, is worth
1:22:12applying to your career path too, not
1:22:14just your cloud bill. Should I become a
1:22:16DevOps engineer is a question a lot of
1:22:19developers ask without being totally
1:22:21sure what the job actually involves
1:22:23day-to-day versus what a job title just
1:22:25sounds like it should involve.
1:22:27These roles overlap more than their name
1:22:29suggest and the boundaries shift from
1:22:31company to company. So treat what
1:22:34follows as a rough map, not a strict
1:22:36definition.
1:22:37Start with the one you already know.
1:22:40A software developer mainly writes the
1:22:42application itself, the features
1:22:44customers actually interact with.
1:22:46A DevOps engineer is working on a
1:22:48different layer. They focus on the
1:22:50systems that build, test, and deploy
1:22:53that application.
1:22:54That means the pipelines, the
1:22:56infrastructure, and the automation that
1:22:58gets code from a developer's machine
1:23:00into production reliably.
1:23:02Then there's site reliability
1:23:04engineering, usually shortened to SRE.
1:23:08It grew out of a similar need, but it
1:23:10leans further toward keeping things that
1:23:11already exist running well.
1:23:14That means deciding how reliable a
1:23:16service needs to be, watching for when
1:23:18it isn't, and often writing code that
1:23:20cuts down on manual, repetitive,
1:23:22operational work.
1:23:24Platform engineering is a newer, related
1:23:26focus again, building the internal tools
1:23:29and self-service systems that let other
1:23:31developers deploy and operate their own
1:23:33services without needing deep
1:23:35infrastructure expertise themselves.
1:23:37In a lot of companies, that's what lets
1:23:39a growing engineering team avoid needing
1:23:41a DevOps specialist embedded in single
1:23:44team.
1:23:45And DevSecOps takes that same DevOps
1:23:47idea, the build and deploy pipeline, and
1:23:50folds security checks directly into it.
1:23:53It scans code and dependencies for known
1:23:55vulnerabilities automatically as part of
1:23:57every change instead of treating
1:23:59security as a separate review bolted on
1:24:01at the end.
1:24:03None of these are strictly more advanced
1:24:05than writing application code, despite
1:24:07how the industry sometimes talks about
1:24:09them.
1:24:09They're different focuses on different
1:24:11parts of the same system.
1:24:13The feature itself, the pipeline that
1:24:15ships it, the infrastructure it runs on,
1:24:18the reliability of all of it, and the
1:24:20security of all of it.
1:24:22Plenty of developers move between these
1:24:24focuses more than once across a career,
1:24:27and plenty of companies blend several of
1:24:29these responsibilities into a single
1:24:31role, especially smaller ones.
1:24:33If you're trying to decide what to lean
1:24:35toward, a reasonable question to ask
1:24:37yourself is which part of a production
1:24:39incident you find most interesting. If
1:24:41it's why did this specific feature
1:24:43behave wrong, that's closer to
1:24:45application development. If it's why did
1:24:48our deployment pipeline let this
1:24:49through, that's closer to DevOps. If
1:24:52it's why didn't we catch this was
1:24:54getting slower weeks before it broke,
1:24:56that's closer to SRE.
1:24:58There's no wrong answer here, and the
1:25:00honest truth is you don't have to know
1:25:02yet. Most people figure this out by
1:25:04actually doing the work for a while, not
1:25:07by picking a lane before their first job
1:25:09even starts. Let's recap module seven.
1:25:12The cloud is still computers, storage,
1:25:15networks, and databases, and you rent
1:25:17them instead of buying them. Most cloud
1:25:20apps use the same few building blocks,
1:25:22and how much you manage yourself depends
1:25:24on the services you choose. You saw two
1:25:27ways to scale and why extra copies alone
1:25:29don't guarantee an app stays up. You
1:25:32also saw what a developer really touches
1:25:34in the cloud, like logs, deployments,
1:25:36and metrics.
1:25:38And anything you leave running keeps
1:25:39costing money.
1:25:41Then we looked at roles like DevOps,
1:25:43SRE, and platform engineering. You don't
1:25:46have to pick one yet. Whichever you lean
1:25:48toward, one change is reaching all of
1:25:50them. And module eight is about that
1:25:53change. Welcome to module eight. You've
1:25:56now seen the whole route from a ticket
1:25:58to an app running in the cloud.
1:26:00There's one question you've probably
1:26:02been asking for a while.
1:26:04AI tools can write code now, so does any
1:26:07of this still matter?
1:26:08We'll start with what these tools can do
1:26:10today and where developers use them on
1:26:12normal tickets.
1:26:14You'll also see how they get things
1:26:15wrong in ways that are hard to notice.
1:26:18Then you'll read through one AI written
1:26:20change with me and look for the problems
1:26:22yourself.
1:26:23The last part steps away from the code
1:26:25editor. It looks at other roles on a
1:26:27team and at how companies are changing
1:26:29the way they plan their work.
1:26:31By the end of this module, you'll be
1:26:33able to check an AI written change
1:26:35instead of just accepting it.
1:26:37Let's start with today's tools. There
1:26:39was a time when AI and coding just meant
1:26:41autocomplete. It finished your line,
1:26:44maybe suggested a small function.
1:26:46That's not what it means anymore.
1:26:48Today, developers work inside AI native
1:26:51IDEs like Cursor, Claude Code, and
1:26:54Copilot's agent mode.
1:26:56These tools don't just suggest a line.
1:26:58You can hand them a task and they'll
1:27:00read across your codebase, edit multiple
1:27:02files, run your tests, see what failed,
1:27:05and try again, mostly on their own.
1:27:08Think about what that means in practice.
1:27:10A task that once required you to jump
1:27:12between files, trace dependencies, make
1:27:15changes, and run tests manually can now
1:27:17be handled by an AI agent in one
1:27:20workflow.
1:27:21That's a real jump in capability.
1:27:23But here's the part that hasn't changed.
1:27:26These tools only know what's inside
1:27:28their context. They don't actually know
1:27:30why a workaround exists in your billing
1:27:32code or what a stakeholder really meant
1:27:35by a vague ticket or which obvious
1:27:37refactor will quietly break a rule
1:27:40nobody wrote down anywhere.
1:27:42And even when the code looks clean and
1:27:44the tests pass, there can still be a
1:27:46problem.
1:27:47The tests might not cover that business
1:27:49rule or the agent might have
1:27:50misunderstood what the feature was
1:27:52supposed to do in the first place.
1:27:54Let's say you have a five-year-old
1:27:55application with thousands of files,
1:27:58internal APIs, business rules, and
1:28:00assumptions nobody documented.
1:28:03You can hand the whole task to an agent
1:28:05and get something that runs.
1:28:06That doesn't mean it's correct. You
1:28:08still need to understand the problem,
1:28:10give the tool the right context, and
1:28:12actually review what comes back before
1:28:14it ships.
1:28:16This is why understanding the codebase
1:28:18still matters.
1:28:19The better you understand the system,
1:28:21the better you can guide the agent, spot
1:28:23mistakes, and decide whether its
1:28:25solution is actually safe to release.
1:28:28So the useful mindset isn't the AI will
1:28:31handle this for me now.
1:28:32It's the AI can do a lot more of the
1:28:35work, which means my job has shifted
1:28:37from typing code to reviewing and
1:28:39directing it, and I'm still the one
1:28:41responsible for the result. Let's take a
1:28:44normal development task.
1:28:46You receive a ticket saying add
1:28:47validation to the customer registration
1:28:50API.
1:28:51In an AI-native IDE, a developer might
1:28:54just describe that task directly to the
1:28:56agent.
1:28:57It can go explore the existing code on
1:28:58its own, find the registration endpoint,
1:29:01draft the validation logic, write a few
1:29:03tests, run them, and fix anything that
1:29:06fails, often before the developer has
1:29:08read a single line of the existing file.
1:29:11But notice what's still true.
1:29:13Someone still had to write that ticket
1:29:15clearly.
1:29:16Someone still decided what valid
1:29:18actually means for this business,
1:29:20whether an empty phone number should be
1:29:21allowed, whether existing users are
1:29:24grandfathered in.
1:29:25The agent can execute a well-scoped task
1:29:28fast.
1:29:29It can't decide what the right scope is.
1:29:32And this is where experience makes a
1:29:33difference.
1:29:35A developer who understands the business
1:29:37can spot missing requirements, ask the
1:29:39right questions, and give the agent
1:29:41enough context to avoid making
1:29:43assumptions that could cause problems
1:29:44later.
1:29:45And once the agent produces a change,
1:29:47the developer still opens the diff,
1:29:49reads through what actually changed
1:29:51across those files, checks it against
1:29:53the ticket, and sends it through code
1:29:55review like anything else.
1:29:57That review matters because the agent
1:29:59might solve the immediate problem while
1:30:01introducing a different one, as breaking
1:30:03an existing API contract or changing how
1:30:06another part of the application behaves.
1:30:09So the workflow hasn't disappeared, it's
1:30:11shifted.
1:30:12Less time typing the implementation,
1:30:14more time scoping the task clearly
1:30:16upfront and reviewing the result
1:30:18carefully afterward.
1:30:20Experienced developers know exactly
1:30:22where that balance sits, when to just
1:30:25let the agent run, and when a task is
1:30:27sensitive enough that they need to slow
1:30:29down and drive it themselves. Here's the
1:30:31part beginners really need to
1:30:32understand, and it matters even more now
1:30:35that AI can touch your whole codebase at
1:30:37once.
1:30:38An agent can change 10 files and every
1:30:41single test can pass and the change can
1:30:44still be wrong.
1:30:45It might quietly break a business rule
1:30:47that wasn't written down anywhere.
1:30:49It might clean up a piece of logic that
1:30:52looked redundant but was actually
1:30:54handling a rare, important case.
1:30:56It might introduce a security gap while
1:30:58technically solving the ticket exactly
1:31:00as written.
1:31:01And this is the tricky part. A small AI
1:31:04suggestion that's wrong is easy to spot.
1:31:07A large, multi-file AI change that's
1:31:10mostly right and subtly wrong is much
1:31:13harder to catch because it looks
1:31:15thorough. It ran. The tests passed. It
1:31:18reads like something a careful engineer
1:31:20would write.
1:31:21So when you're reviewing AI-generated
1:31:23code, don't stop at asking whether the
1:31:26tests passed. Ask yourself what the code
1:31:29actually changed, why those changes were
1:31:31necessary, and whether anything else in
1:31:33the application depends on the old
1:31:35behavior.
1:31:36That's exactly why review matters more
1:31:39now, not less. You still read through
1:31:41what changed, you still run it yourself,
1:31:44you still check it against the actual
1:31:46business requirement, and you still ask
1:31:48what this change assumed that might not
1:31:50be true.
1:31:51Approving an AI-generated change you
1:31:53don't
1:31:54doesn't save you time. It just moves the
1:31:57hard part to whenever it eventually
1:31:58breaks, except now you're debugging code
1:32:01you never actually understood in the
1:32:03first place. If you take one sentence
1:32:05out of this section, make it this one.
1:32:08The better your fundamentals are, the
1:32:10more useful an AI native IDE becomes.
1:32:14Here's why.
1:32:15An agent hands you a change across six
1:32:17files using a pattern you've never seen.
1:32:20If you don't understand programming,
1:32:22APIs, databases, and Git, you'll accept
1:32:25it and hope.
1:32:26If you do understand them, you can read
1:32:29that diff, spot the bad assumption, ask
1:32:31the agent to fix just that part, and
1:32:34judge whether the whole approach even
1:32:35fits your application.
1:32:37And the same principle applies when
1:32:39something goes wrong.
1:32:40If you understand how the pieces fit
1:32:42together, you can trace the problem,
1:32:44give the agent useful feedback, and
1:32:46guide it toward a better solution
1:32:48instead of blindly asking it to try
1:32:50again.
1:32:51Take Git as another example.
1:32:53If you understand branches, commits, and
1:32:56diffs, you can see exactly what the
1:32:58agent changed, compare it with the
1:32:59original implementation, and undo a
1:33:02change if something goes wrong.
1:33:04Without that knowledge, you're relying
1:33:06on the tool without knowing how to
1:33:07recover when things break.
1:33:09The same goes for databases and APIs.
1:33:12When an agent changes a database query
1:33:14or modifies an API response, your
1:33:17fundamentals help you recognize whether
1:33:19the change could affect performance,
1:33:21break another service, or cause problems
1:33:23for existing users.
1:33:25You don't need to memorize every
1:33:27programming language or understand every
1:33:29framework in advance, but you do need a
1:33:32solid foundation because that's what
1:33:34helps you separate a good solution from
1:33:36one that only looks good.
1:33:38Same tool, completely different outcome.
1:33:41The difference is you.
1:33:43So let's actually do it. In the next
1:33:45lecture, we're going to look at an AI
1:33:47generated change together and find
1:33:49what's wrong with it. Let's make this
1:33:51real. Same ticket as before. Add email
1:33:54validation to customer registration. You
1:33:57describe it to the agent in your IDE.
1:33:59Two minutes later, it's done. Tests
1:34:01pass. Here's the change. Now, most
1:34:05beginners look at this and see two
1:34:06things. Green means added, tests are
1:34:09green, ship it. Let's slow down and read
1:34:12it the way a reviewer reads it. Start at
1:34:14the top. The agent added a function
1:34:16called is valid email. Good. It's
1:34:19reusable. That's what we'd want. Inside,
1:34:22there's a pattern that checks the email
1:34:23format. Letters and numbers, an at sign,
1:34:26a domain, a dot, a couple of letters.
1:34:29Looks reasonable. Look closer at the
1:34:31characters it allows before the at sign.
1:34:34Letters, numbers, dots, underscores,
1:34:37hyphens. Now think about real email
1:34:40addresses. Have you ever seen one with a
1:34:42plus sign in it? Like name plus
1:34:44newsletter at gmail.com? Lots of people
1:34:47use those. They're completely valid, and
1:34:50this pattern rejects them.
1:34:52Every test passed because the agent also
1:34:55wrote the tests, and it only tested
1:34:57addresses it already believed were
1:34:59valid. That's the trap. The tests agreed
1:35:02with the code because the same
1:35:03assumption wrote both. Keep going. The
1:35:06new check runs every time someone hits
1:35:08the registration endpoint. Now scroll to
1:35:10the ticket. The acceptance criteria said
1:35:13existing valid registrations must
1:35:15continue working. Does anything here
1:35:17touch existing users? Actually, look at
1:35:20where the agent put the call. It's in
1:35:22the shared save customer function, not
1:35:25the register function. That function
1:35:27also runs when an existing customer
1:35:29updates their profile. So a long time
1:35:31customer with a plus sign in their email
1:35:33would now be blocked from changing their
1:35:35address.
1:35:36That's two problems. One is a wrong
1:35:39assumption inside a pattern. The other
1:35:41is a change in the wrong place. Neither
1:35:44one shows up as a red test. Both would
1:35:46show up as a support ticket next week.
1:35:49So what does the review look like? Not
1:35:51this is wrong. Something like this
1:35:54pattern rejects plus addresses which are
1:35:56valid. Also, the validation runs in save
1:35:59customer, so it affects profile updates.
1:36:02Can we move it to the registered path
1:36:03and add a test for a plus address?
1:36:05Then you hand that back to the agent and
1:36:07it'll fix it in 30 seconds. That's the
1:36:10whole skill. You're not competing with
1:36:12the tool on typing. You're reading its
1:36:14work against the ticket, against the
1:36:16business, and against what real users
1:36:18actually do. You'll get a diff like this
1:36:21in assignment three for this section.
1:36:23Try to find both problems yourself
1:36:25before you look at the answer.
1:36:27Now let's zoom out because this isn't
1:36:29only happening to developers, and this
1:36:32shift isn't only happening in code
1:36:34editors.
1:36:35The same kind of AI agent is showing up
1:36:37across IT,
1:36:38summarizing a messy incident timeline
1:36:40for a support engineer, drafting and
1:36:43explaining SQL for someone on the data
1:36:45team, generating a first pass of test
1:36:47scenarios for a tester, or pulling
1:36:50together a project update for a manager
1:36:52before a meeting.
1:36:53For example, a data engineer might use
1:36:56AI to draft a SQL query, but still needs
1:36:59to check whether the joins are correct
1:37:00and the results make sense.
1:37:02A tester might generate dozens of test
1:37:04cases in seconds, but still needs to
1:37:07decide whether the important edge cases
1:37:09are covered.
1:37:10The work gets faster, but knowing what
1:37:12good work looks like still matters.
1:37:15So when you enter IT today, don't think
1:37:18of AI as one tool bolted onto your
1:37:20editor.
1:37:21Think of it as a layer running
1:37:23underneath almost every role on a team,
1:37:25doing more of the first draft so people
1:37:27can spend more time deciding, reviewing,
1:37:30and judging whether that first draft is
1:37:32actually right.
1:37:34And this changes what it means to be
1:37:35good at your job. It's no longer just
1:37:38about how quickly you can produce
1:37:39something yourself.
1:37:41It's also about how well you can use
1:37:43these tools, recognize their mistakes,
1:37:45and take responsibility for the final
1:37:47outcome.
1:37:48The specific tools will keep changing.
1:37:51The skill that doesn't go out of date is
1:37:53knowing when to hand something to AI,
1:37:55how to direct it well, and how to verify
1:37:58what it hands back. AI-native IDEs
1:38:01aren't just changing how individual
1:38:02developers write code. They're starting
1:38:04to change how entire companies plan and
1:38:07build software.
1:38:09Think about how software development has
1:38:10evolved over time.
1:38:12Years ago, teams used waterfall,
1:38:14planning everything up front and
1:38:16building it in one long sequence.
1:38:18Then came Agile, breaking that into
1:38:20short iterative cycles. Then CICD and
1:38:24DevOps, automating testing and
1:38:26deployment so releases could happen
1:38:28constantly instead of once a year.
1:38:30AI is becoming the next layer on top of
1:38:33that evolution, not a replacement for
1:38:35it.
1:38:36Here's the interesting part. Now that an
1:38:38agent can build and test a well-defined
1:38:40task in minutes, the bottleneck has
1:38:42moved. It's no longer how fast can we
1:38:45write this code, it's how clearly can we
1:38:48define what we actually want built.
1:38:51Companies are realizing they need to
1:38:52invest more, not less, into the planning
1:38:55stage.
1:38:56Real effort goes into defining the
1:38:58problem, the requirements, and what is
1:39:00explicitly out of scope before any agent
1:39:03touches the code.
1:39:04You might hear people call this shifting
1:39:06left.
1:39:07Strictly speaking, that phrase comes
1:39:09from testing. It means running your
1:39:11tests earlier in the process instead of
1:39:13at the very end, but the spirit is the
1:39:15same.
1:39:16Catch the problem while it's still cheap
1:39:18to fix.
1:39:20Why does that matter so much now?
1:39:22Because an AI agent follows instructions
1:39:24literally, and it can move very fast in
1:39:27the wrong direction.
1:39:29Give it a vague, half-finished
1:39:30requirement, and it will guess
1:39:32confidently and often incorrectly.
1:39:35Give it a clear, well-scoped problem,
1:39:38including what's explicitly out of
1:39:39scope, and it can move remarkably fast
1:39:42in the right direction.
1:39:44None of this replaces human judgment.
1:39:46Deciding whether a problem is even worth
1:39:48solving or whether a product is worth
1:39:50building at all is still a human call.
1:39:53AI can execute that decision faster once
1:39:56it's made. It doesn't make the decision
1:39:58for you.
1:40:00You'll likely see this play out wherever
1:40:01you end up working. Smaller, more
1:40:04flexible teams, more time spent up front
1:40:06turning a rough idea into a clear,
1:40:08detailed plan, and AI native tools
1:40:11handling more of the actual
1:40:13implementation once that plan exists.
1:40:16And the fundamentals you're learning in
1:40:17this course, understanding requirements,
1:40:20systems, and how the pieces fit together
1:40:22are exactly what makes you valuable in
1:40:24that kind of environment. Let's recap
1:40:26module eight.
1:40:28We started with a question, and the
1:40:30answer is yes. Everything you've learned
1:40:33still matters. An agent can read your
1:40:35code, change many files, and run the
1:40:38tests mostly on its own, but it only
1:40:40knows what's in its context. So a change
1:40:43can pass every test and still be wrong.
1:40:46You saw that in our review. The email
1:40:48check rejected valid addresses and ran
1:40:51in the wrong function.
1:40:52The agent wrote its own tests, so they
1:40:54passed, and neither problem showed up.
1:40:57Your basics are what let you catch that.
1:41:00AI is changing other roles, too, and
1:41:02companies are spending more time on
1:41:04planning because a vague request can now
1:41:06go wrong very fast.
1:41:08In module nine, we leave the code for a
1:41:11while and look at your working day.
1:41:13Welcome to module nine.
1:41:15Where do your hours go on a real team?
1:41:17This is a big module, so here's what it
1:41:20covers.
1:41:21The topics are mixed together, so they
1:41:23won't come in this order.
1:41:24Some of it is about normal days. That
1:41:27means your meetings and what it's like
1:41:29to work across time zones. It also means
1:41:31the many hours that go into keeping
1:41:33older software running.
1:41:35Some of it is about the bad days. That's
1:41:38when production has a problem or when
1:41:40you're the one on call.
1:41:42You'll also see how a team watches its
1:41:44systems so it can find trouble early.
1:41:46The rest is about you as the new person
1:41:49on the team. You'll learn how to ask for
1:41:51help, what to do when you first join,
1:41:53and how to write things people will
1:41:55read.
1:41:56A few topics come up twice, like team
1:41:58review meetings and production problems.
1:42:00So if something sounds familiar, you're
1:42:02not lost. We're just going a little
1:42:04deeper the second time.
1:42:06By the end of this module, you'll know
1:42:08what to expect from your days on the
1:42:09team.
1:42:10Let's start with a normal day. A
1:42:12developer's day usually doesn't start
1:42:15with opening an editor and coding for
1:42:17eight straight hours.
1:42:18A normal day could start with a stand-up
1:42:20meeting where you talk about what you
1:42:22worked on yesterday, what you're working
1:42:24on today, and whether anything is
1:42:26blocking you.
1:42:27These meetings are usually short, but
1:42:29they help the team understand where
1:42:31things stand.
1:42:32If you're stuck waiting for another team
1:42:34or need help with a technical problem,
1:42:37this is a chance to bring it up before
1:42:38it delays your work further.
1:42:40Then you might spend the next couple of
1:42:42hours working on your ticket, reading
1:42:44existing code, searching the repository,
1:42:47checking a database query, running the
1:42:49application, looking at logs, and
1:42:52probably asking another developer a
1:42:54question at some point.
1:42:55And sometimes what looks like a small
1:42:57task turns out to be much bigger than
1:43:00expected.
1:43:01You might discover that the code depends
1:43:03on another service, that the existing
1:43:05behavior isn't documented, or that you
1:43:07need to understand how an older part of
1:43:09the application works before you can
1:43:11safely make a change.
1:43:13Then you might have a meeting about a
1:43:14new requirement.
1:43:16Later, someone reviews your pull request
1:43:18and asks you to change something. You
1:43:20make the change, run the tests again,
1:43:22and update the pull request.
1:43:24This is also where communication becomes
1:43:26important. You might need to explain why
1:43:29you chose a particular approach, discuss
1:43:31an alternative with a teammate, or
1:43:33clarify a requirement with the person
1:43:35who requested the change.
1:43:37Writing code is only one part of getting
1:43:40the right solution delivered.
1:43:42And then you might spend the afternoon
1:43:43investigating a completely different
1:43:45problem because something broke in
1:43:47another part of the system.
1:43:49That's normal.
1:43:50Some days have lots of coding. Some days
1:43:53have almost none.
1:43:54As you gain experience, you'll also get
1:43:56better at managing these interruptions,
1:43:59deciding what needs attention first, and
1:44:01knowing when to ask for help instead of
1:44:03spending hours stuck on the same
1:44:05problem.
1:44:06The job is really a combination of
1:44:08coding, debugging, communication,
1:44:11investigation, meetings, reviews, and
1:44:14problem solving. You will probably hear
1:44:16the word standup quite a lot.
1:44:18A typical daily standup is a short team
1:44:21meeting where everyone shares what
1:44:22they're working on and whether they're
1:44:24blocked.
1:44:25It usually sounds something like,
1:44:27yesterday I finished the customer API
1:44:29changes. Today I'm working on the
1:44:31validation ticket.
1:44:33I'm blocked because I don't have access
1:44:34to the test database.
1:44:36That's useful because everyone gets
1:44:38visibility into what the team is doing.
1:44:41You'll also hear a handful of other
1:44:42terms. A sprint is a fixed period during
1:44:45which a team works on a set of planned
1:44:47work. The backlog is the list of work
1:44:50that may need to be done.
1:44:51Planning is when the team decides what
1:44:53work to take on next. And a
1:44:55retrospective is when the team discusses
1:44:57what went well, what didn't, and what
1:45:00could improve.
1:45:01A retro is worth understanding properly
1:45:03because it's one of the few meetings
1:45:05built entirely around improving how the
1:45:07team works, not just what the team
1:45:09ships. It usually follows a simple
1:45:12pattern.
1:45:13What went well, what didn't, and what
1:45:16the team will actually try differently
1:45:17next sprint. The value isn't in the
1:45:20complaining part. It's in that last
1:45:22step. Walking away with one or two
1:45:24concrete changes rather than just a list
1:45:27of frustrations that gets repeated every
1:45:29retro with nothing changing.
1:45:31As a junior, you don't need to run these
1:45:33meetings. You just need to actually
1:45:35contribute. A small process friction you
1:45:38noticed is exactly the kind of thing
1:45:40retros exist to surface.
1:45:42Different companies follow Scrum,
1:45:44Kanban, or something customized.
1:45:46Don't get too caught up in memorizing
1:45:48the terminology.
1:45:49The important thing is understanding
1:45:51that software development is a team
1:45:53activity. Your code is only one part of
1:45:56the process. And on some teams, that
1:45:59daily standup doesn't even happen live
1:46:01because the team isn't all working the
1:46:03same hours to begin with. A growing
1:46:05number of teams aren't all sitting in
1:46:06the same office or even the same
1:46:09country. You might have a teammate
1:46:11finishing their day as your starts. That
1:46:14changes how the team actually
1:46:15communicates, and it's worth
1:46:17understanding early.
1:46:19The biggest shift is that async, meaning
1:46:21not expecting an immediate reply, often
1:46:24becomes the default instead of the
1:46:25exception.
1:46:27If you ask a one-line question like,
1:46:29does this work? To someone 8 hours ahead
1:46:31of you, you might not hear back until
1:46:33tomorrow. And then you'll likely need
1:46:35another full day for the follow-up
1:46:37question you didn't think to ask up
1:46:39front.
1:46:40The fix is writing messages with enough
1:46:42context the first time, what you're
1:46:44trying to do, what you've already tried,
1:46:46and exactly what you need from them. So
1:46:49a single reply can actually unblock you
1:46:51instead of starting a slow back and
1:46:53forth.
1:46:54For example, instead of saying, I'm
1:46:56getting an error, can you help? Explain
1:46:59which application you're working on,
1:47:01what you were trying to do, the error
1:47:03you received, and what you've already
1:47:04checked.
1:47:06If you can include a relevant log or
1:47:07screenshot, even better. Your teammate
1:47:10can investigate while you're offline
1:47:12rather than spending another day just
1:47:14trying to understand the problem.
1:47:16Some distributed teams also run standup
1:47:18asynchronously. Everyone posts their
1:47:21yesterday, today, and blockers in a
1:47:23channel instead of talking live
1:47:25precisely because there's no single time
1:47:27that works for everyone.
1:47:29That's not a lesser version of a
1:47:30standup. It's a reasonable adaptation
1:47:33once a team is genuinely spread across
1:47:35time zones.
1:47:36This also means you need to get
1:47:38comfortable making progress
1:47:39independently. If you're blocked on one
1:47:41task, you might document what you found,
1:47:44move to another ticket, or investigate a
1:47:46separate part of the problem while you
1:47:48wait for a response.
1:47:50That way, your entire day doesn't depend
1:47:52on someone else being available.
1:47:54And here's something worth internalizing
1:47:56early.
1:47:57A fast reply doesn't make you look more
1:47:59dedicated, and a slower one, within
1:48:01reason, doesn't make you look less
1:48:03committed. What actually matters on a
1:48:06distributed team is whether your
1:48:07communication gives people what they
1:48:09need without requiring you to be online
1:48:12at the same moment they are.
1:48:14Whichever hours your team works, a lot
1:48:16of what actually fills those hours isn't
1:48:18building new features at all. It's
1:48:20maintenance. Here's something that
1:48:22surprises many beginners.
1:48:24Not every developer spends their time
1:48:26building exciting new features. A lot of
1:48:29software work is maintenance. You might
1:48:31fix a bug that appeared after a release,
1:48:34update an old dependency, improve a slow
1:48:36database query, tweak a configuration
1:48:39value, look into a customer complaint,
1:48:41add some logging, clean out unused code,
1:48:44upgrade a framework version, or modify a
1:48:47feature that's existed for five years.
1:48:50And sometimes the fix itself is
1:48:52surprisingly small.
1:48:54A single configuration change might
1:48:55resolve the issue, but finding that
1:48:58setting could take hours of
1:48:59investigation.
1:49:01That's because understanding why
1:49:02something broke is often harder than
1:49:04actually fixing it.
1:49:06That might sound less exciting than
1:49:08building something brand new, but it's a
1:49:10huge part of how real software works.
1:49:13Companies have applications that have
1:49:14been running for years. Those
1:49:16applications make money, customers
1:49:19depend on them, and someone has to keep
1:49:21them working.
1:49:22Think about an online banking
1:49:24application, for example. It might have
1:49:26been built years ago, but customers
1:49:28still use it every day to check
1:49:30balances, transfer money, and pay bills.
1:49:33The team can't simply stop everything
1:49:35and rebuild the entire application
1:49:37whenever a better technology comes
1:49:38along.
1:49:39They need to improve it carefully
1:49:41without breaking the things people
1:49:43already rely on.
1:49:45A lot of this maintenance work exists
1:49:47because of something you'll hear called
1:49:48technical debt.
1:49:50It's not necessarily bad code. It's
1:49:52usually a shortcut that made sense at
1:49:54the time. A quick fix shipped to hit a
1:49:56deadline or a design decision that
1:49:59worked fine until the application grew
1:50:01past what it was originally built for.
1:50:03Like financial debt, it's not inherently
1:50:06a disaster, but it accumulates interest.
1:50:09The longer it sits unaddressed, the
1:50:11slower and riskier future changes
1:50:13become.
1:50:15Part of maintenance work is paying some
1:50:16of that down deliberately instead of
1:50:18only ever adding more of it.
1:50:20For example, imagine a piece of code
1:50:22that works perfectly well today, but is
1:50:25difficult to understand and has no
1:50:27tests.
1:50:28Every time someone needs to change it,
1:50:30they have to spend extra time figuring
1:50:32out how it works and checking that
1:50:33nothing else breaks.
1:50:35Adding tests and simplifying that code
1:50:37might not deliver a new feature, but it
1:50:40can make every future change safer and
1:50:42faster.
1:50:44So when you get your first job, don't be
1:50:46surprised if your first ticket is fix
1:50:48this existing issue instead of build
1:50:51this amazing new application. That's
1:50:53normal software development. Now let's
1:50:56talk about one of the most stressful
1:50:57situations for a developer.
1:51:00Something breaks in production.
1:51:02Maybe customers can't log in, maybe an
1:51:04API is suddenly returning errors, maybe
1:51:07orders are getting stuck, or maybe a
1:51:09recent deployment introduced a problem
1:51:11nobody caught.
1:51:13The first priority isn't writing new
1:51:15code, it's understanding the impact.
1:51:18What's actually broken? How many users
1:51:21are affected? When it started? What
1:51:23changed recently? And what the logs
1:51:25show?
1:51:26Depending on what they find, the team
1:51:28might roll back the deployment, disable
1:51:30a feature, fix a bad configuration
1:51:32value, or ship a quick hotfix to stop
1:51:35the bleeding.
1:51:36After the problem is under control, the
1:51:38team usually investigates why it
1:51:40happened and what can prevent it from
1:51:42happening again.
1:51:44This step is often called a root cause
1:51:46analysis or a post-incident review.
1:51:49A useful one usually asks a chain of
1:51:51questions rather than stopping at the
1:51:53first answer.
1:51:54The deployment caused it, sure. But why
1:51:57did that change get through review and
1:51:58testing without anyone catching it?
1:52:00And what would need to be true for it to
1:52:02get caught next time?
1:52:04The output isn't just a written
1:52:05explanation, it's a short list of
1:52:08concrete follow-up actions. Better test
1:52:10coverage here, an alert that should have
1:52:12fired sooner there, that someone
1:52:14actually owns and follows up on.
1:52:17You'll hear terms like incident, hotfix,
1:52:20rollback, root cause, and post-incident
1:52:23review.
1:52:24These aren't just technical words. They
1:52:26describe how teams respond when real
1:52:28systems fail.
1:52:30And eventually, every developer learns
1:52:32that production problems are just part
1:52:34of working with software.
1:52:36And sometimes that problem shows up
1:52:38outside of normal working hours
1:52:39entirely, which is where on call comes
1:52:42in. At some point, you'll hear that a
1:52:44teammate is on call this week. And if
1:52:47you've never experienced it, the phrase
1:52:49alone can sound intimidating.
1:52:51It's worth understanding what it
1:52:53actually involves before you ever get
1:52:55anywhere near it yourself.
1:52:57On call means that for a set period,
1:52:59usually a week, someone on the team is
1:53:02the person who gets alerted if something
1:53:03breaks outside of normal working hours.
1:53:06A server issue at 2:00 a.m., a spike of
1:53:08errors on a weekend.
1:53:10It exists because real systems don't
1:53:12stop running just because the office is
1:53:14closed, and someone needs to be
1:53:16reachable if something genuinely urgent
1:53:18happens.
1:53:20For example, imagine an online shopping
1:53:22application suddenly stops processing
1:53:24payments late at night.
1:53:26The on call engineer might receive an
1:53:28alert, check the monitoring dashboard,
1:53:30look at the error logs, and work out
1:53:32whether the issue is affecting all
1:53:34customers or just a small part of the
1:53:36system.
1:53:37The immediate priority is to understand
1:53:39the impact and restore the service
1:53:41safely, not to rush into a random fix.
1:53:44For a junior developer, on call is
1:53:47rarely something you're handed on day
1:53:48one.
1:53:49Most teams ease people into it
1:53:51gradually, often shadowing a more
1:53:53experienced teammate first, watching how
1:53:55they respond to an alert before ever
1:53:57being the primary responder yourself.
1:54:00And being on call doesn't mean you're
1:54:02expected to fix every problem alone at
1:54:042:00 a.m. The actual job in that moment
1:54:08is usually to acknowledge the alert,
1:54:10assess how serious it is, and escalate
1:54:12to someone with more context if it's
1:54:14beyond what you can safely handle.
1:54:16Knowing when to wake someone else up is
1:54:18a completely legitimate on call skill,
1:54:21not a failure.
1:54:23You'll also find that teams prepare for
1:54:24these situations before anything goes
1:54:26wrong.
1:54:27They document common issues, define who
1:54:30should be contacted, and create runbooks
1:54:32that explain the first checks to
1:54:34perform.
1:54:35Good monitoring and clear instructions
1:54:37make incidents easier to handle,
1:54:39especially when the person responding
1:54:41didn't build the part of the system
1:54:43that's failing.
1:54:44Not every company has on-call and not
1:54:46every role includes it. It depends
1:54:48heavily on what you're building and how
1:54:50critical it is that it stays running.
1:54:53But if your team does have it, know that
1:54:55it's a rotation. It's usually gradual,
1:54:58and asking for help in the middle of an
1:54:59alert is exactly what it's there for.
1:55:02And that willingness to ask for help
1:55:04isn't just an on-call skill. It's one of
1:55:07the most important habits you can build
1:55:09in your first few months, on-call or
1:55:11not. Here's a skill that can save a
1:55:13beginner weeks of frustration.
1:55:15Knowing when to ask for help.
1:55:18When you're new, it's easy to think I
1:55:20should figure this out myself. So you
1:55:22spend 3 hours trying random things.
1:55:25That's usually worse than spending 10
1:55:27minutes asking a good question.
1:55:30But before you ask, there's a quick
1:55:31order of operations that experienced
1:55:33developers follow without thinking about
1:55:35it.
1:55:36First, read the actual error message,
1:55:39all of it, not just the first line.
1:55:41Second, check the project's own
1:55:43documentation or readme because a lot of
1:55:46bugs are setup steps you skipped. Third,
1:55:50search the exact error text in quotes
1:55:53because someone has almost certainly hit
1:55:55it before.
1:55:56Fourth, ask an AI assistant to explain
1:55:59the error and treat the answer as a
1:56:00lead, not a verdict.
1:56:02And then, if you're still stuck after 15
1:56:05or 20 minutes, ask a person.
1:56:07One thing worth remembering is that the
1:56:0915 or 20 minutes isn't a strict timer.
1:56:12Some problems genuinely need longer
1:56:14investigation while others are worth
1:56:16escalating sooner, especially if they
1:56:18affect production or block the rest of
1:56:20the team.
1:56:22The goal isn't to solve everything
1:56:23alone. It's to make a
1:56:25effort before getting someone else
1:56:27involved. That sequence matters because
1:56:30of what it gives you when you finally do
1:56:31ask, a list of what you already tried.
1:56:35The important part is how you ask.
1:56:38Instead of just saying, it's not
1:56:39working, can you help? Try something
1:56:42like, I'm working on the customer API.
1:56:45The request reaches the service, but the
1:56:47database call is timing out. I checked
1:56:49the logs and the timeout starts right
1:56:51after the query runs.
1:56:53I haven't changed the database
1:56:54configuration. Do you know whether this
1:56:56environment has had this issue before?
1:56:59Notice that this question gives your
1:57:00teammates somewhere to start. They can
1:57:03look at the database connection, check
1:57:04whether the environment has a known
1:57:06issue, or suggest the next investigation
1:57:08step.
1:57:09You're not asking them to solve a
1:57:11mystery with no clues. That's a much
1:57:13better question. You've explained what
1:57:15you're doing, what you expected, what
1:57:18actually happened, and what you've
1:57:19already checked. And when someone helps
1:57:22you solve the problem, take a moment to
1:57:24understand the fix. Write down what
1:57:27caused the issue, why the solution
1:57:28worked, and how you might recognize the
1:57:31same problem next time. Otherwise, you
1:57:33risk getting stuck on the exact same
1:57:35thing a few weeks later. Experienced
1:57:38developers generally don't expect
1:57:39beginners to know everything. They do
1:57:42expect you to investigate before asking.
1:57:44Your first few weeks at a new company
1:57:46can feel overwhelming. You'll hear a
1:57:49hundred terms you've never seen, and
1:57:51you'll understand maybe half of most
1:57:53conversations. That's normal. So instead
1:57:56of trying to understand everything,
1:57:58here's what experienced developers
1:58:00actually do in week one.
1:58:02First, get the application running on
1:58:04your machine, not perfectly, just
1:58:06running.
1:58:07Clone the repository, follow the README,
1:58:10and when the setup steps are out of
1:58:11date, and they usually are, write down
1:58:14every step that didn't work. Fixing that
1:58:16README is often a great first pull
1:58:18request.
1:58:19Second, find the five places where
1:58:22everything happens, where the tickets
1:58:24live, where the code lives, where the
1:58:26pipeline runs, where the application is
1:58:28deployed, and where the logs are.
1:58:31If you know those five, you can follow
1:58:33almost any conversation on the team.
1:58:36Third, watch one change go all the way
1:58:38through.
1:58:39Pick any teammate's pull request and
1:58:41follow it. The review comments, the
1:58:43merge, the pipeline, the deployment.
1:58:46You'll learn more about your team's real
1:58:48workflow from one PR than from any
1:58:50onboarding document.
1:58:52Fourth, take a small ticket early. A
1:58:55typo fix, a log message, a tiny bug.
1:58:58The point isn't the ticket. The point is
1:59:01going through the whole workflow once,
1:59:03end to end, while the stakes are low.
1:59:05And fifth, keep a personal glossary.
1:59:08Every internal system name, every
1:59:10acronym, every oh, that's the service
1:59:13that handles payments moment. Write it
1:59:15down.
1:59:16In a month, that document is the map of
1:59:19the system in your head.
1:59:20And that's how confidence actually
1:59:22develops. Not by knowing everything, by
1:59:25gradually needing less context to
1:59:27understand what's going on around you.
1:59:29That confidence gets tested for real the
1:59:31first time something breaks badly enough
1:59:33that the whole team notices. Somewhere,
1:59:36a customer is staring at an error page
1:59:38right now, and your team just found out.
1:59:42What happens in the next 10 minutes
1:59:43matters more than what happens in the
1:59:45next 10 hours.
1:59:47Most teams grade how serious a problem
1:59:49is using a severity level, often
1:59:51shortened to SEV.
1:59:53SEV one is the worst. A full outage or
1:59:56data loss affecting many customers.
1:59:59SEV three or SEV four is a minor issue
2:00:02affecting a few people with an easy
2:00:04workaround.
2:00:05The severity decides how loudly to raise
2:00:08the alarm. It decides whether to wake
2:00:10people up overnight, and it decides
2:00:12whether leadership needs to know
2:00:14immediately.
2:00:15Getting the severity roughly right
2:00:17quickly matters more than getting it
2:00:19exactly right.
2:00:21A SEV one called in as a SEV three can
2:00:24sit ignored while customers suffer.
2:00:26The reverse just means someone double
2:00:28checks and downgrades it.
2:00:30During an active incident, the instinct
2:00:32of a new developer is often to
2:00:34immediately start trying fixes.
2:00:36A more useful first move is almost
2:00:38always to communicate.
2:00:40Say what you know, say what you don't
2:00:42know yet, say what you're checking next.
2:00:45Often in a dedicated channel, everyone
2:00:47affected can watch.
2:00:48This isn't bureaucracy for its own sake.
2:00:51An incident with several people quietly
2:00:53trying different fixes in isolation is
2:00:55slower and more dangerous than one
2:00:57person stating clearly, I'm about to
2:01:00restart this service before doing it.
2:01:03Once the immediate fire is out, most
2:01:05teams hold a postmortem, a written
2:01:07account of what happened, why, and what
2:01:10will change so it's less likely to
2:01:11happen again.
2:01:13The standard the better ones hold to is
2:01:15blameless. The document describes the
2:01:17sequence of events and the gaps in the
2:01:19system that allowed it, not which person
2:01:21to blame.
2:01:23This isn't about being nice. A team
2:01:25where admitting, I pushed the change
2:01:27that caused this leads to blame, is a
2:01:29team where people start hiding problems
2:01:31instead of reporting them early, which
2:01:33makes the next incident worse, not
2:01:35better.
2:01:36A good postmortem usually separates two
2:01:38different questions. The first is what
2:01:41happened in plain specific detail.
2:01:44The sequence of events, timestamps, the
2:01:47exact symptoms.
2:01:49The second is what will change. Is there
2:01:51a test that should have caught this? A
2:01:53check missing from the deploy pipeline?
2:01:55An alert that should have fired sooner
2:01:57but didn't?
2:01:58The second part is where the real value
2:02:00is. A postmortem that just describes the
2:02:03outage without naming a concrete
2:02:05follow-up tends to repeat itself
2:02:07eventually. If you're newer on the team,
2:02:09you'll often be reading more postmortems
2:02:11than writing them at first. Read them
2:02:13anyway.
2:02:15They're one of the fastest ways to learn
2:02:16how a system actually behaves under
2:02:18stress instead of how it's supposed to
2:02:20behave on a good day.
2:02:22A good postmortem is also, quietly, a
2:02:25piece of writing.
2:02:26And the habits that make it useful apply
2:02:28to a lot of what you'll write day to
2:02:30day. You finish a feature and three
2:02:32weeks later, someone asks you the exact
2:02:35question your own commit message could
2:02:36have answered, if only you'd written one
2:02:39worth reading.
2:02:40Most documentation problems aren't about
2:02:42writing too little. They're about
2:02:44writing in a way nobody comes back to.
2:02:47A giant README nobody updates after the
2:02:49first month helps nobody.
2:02:51A short, specific note placed where
2:02:53someone will actually look for it helps
2:02:55a lot.
2:02:56Start with the README every project
2:02:58seems to have and few people maintain.
2:03:01At minimum, it should answer three
2:03:03questions fast. What is this? How do I
2:03:06run it? Where do I go if something's
2:03:08broken?
2:03:09If a new teammate still has to ask you
2:03:11those three questions after reading it,
2:03:13the README isn't doing its job yet, no
2:03:15matter how long it is.
2:03:17For a bigger decision, some teams keep a
2:03:19short document often called an ADR, an
2:03:22Architecture Decision Record.
2:03:24It covers what problem you were solving,
2:03:26what options you considered, and why you
2:03:28picked the one you did.
2:03:30The value isn't really for today. It's
2:03:32for the person six months from now,
2:03:34possibly you, wondering why on earth it
2:03:37was done this way, who would otherwise
2:03:39have to guess or ask around.
2:03:41Async communication, a message in a
2:03:43channel instead of a conversation in
2:03:45person, has its own habit worth
2:03:47building.
2:03:48Say the conclusion first, then the
2:03:50reasoning, not the other way around.
2:03:53Going with option B, here's why, reads
2:03:56in two seconds. A message that opens
2:03:58with several paragraphs of context
2:04:00before finally landing on the point
2:04:02often gets skimmed, misread, or answered
2:04:05incorrectly by someone who stopped
2:04:06reading halfway through. If someone
2:04:09needs to act on what you wrote, make the
2:04:11action obvious without requiring them to
2:04:13read the whole thing first. The same
2:04:15applies to status updates, especially
2:04:18during something ongoing.
2:04:19Still looking into it, said once with
2:04:22silence after, reads very differently
2:04:24from the same words repeated every so
2:04:26often along with what's been ruled out
2:04:28so far. The second version costs you
2:04:31almost nothing extra to write and tells
2:04:33everyone watching that progress is
2:04:35actually happening.
2:04:37None of this requires good writing in
2:04:38some formal sense. It requires one
2:04:41question before you hit send or save.
2:04:44If someone read only the first sentence
2:04:46of this, would they still know what to
2:04:48do next?
2:04:49If the answer is no, that sentence needs
2:04:52to move to the top. Standups are the
2:04:54meeting most people picture when they
2:04:55hear Scrum,
2:04:57but a team running sprints usually has
2:04:59two other recurring meetings that shape
2:05:01the work just as much, and new
2:05:03developers often walk into both without
2:05:05knowing what to expect.
2:05:07Sprint planning happens at the start of
2:05:09each sprint, a fixed chunk of time,
2:05:11often one or two weeks, that the team is
2:05:14committing to.
2:05:15The team looks at the backlog, the pile
2:05:17of tickets waiting to be worked on, and
2:05:19decides what fits into this sprint.
2:05:22For each ticket, someone explains what
2:05:24it involves, and the team estimates how
2:05:26much effort it takes, often in story
2:05:28points rather than hours.
2:05:30This is where you'll hear a ticket
2:05:32argued over for 10 minutes, not because
2:05:34the task is hard, but because nobody's
2:05:36sure yet what done actually means for
2:05:39it.
2:05:40Planning goes better when tickets are
2:05:41specific.
2:05:42Fix the login page invites that
2:05:44confusion.
2:05:46Fix the login page so it shows an error
2:05:48message when the password is wrong,
2:05:50doesn't.
2:05:51A retro, short for retrospective,
2:05:53happens at the end of the sprint after
2:05:55the work is done.
2:05:57It isn't about reviewing the product,
2:05:59it's about reviewing how the team
2:06:00worked.
2:06:02A common format asks three questions.
2:06:04What went well? What didn't?
2:06:07What should we change going forward?
2:06:09A flaky test that wasted a day, a ticket
2:06:12that turned out way bigger than
2:06:13estimated, a deployment that went
2:06:15smoothly for once. All of that is retro
2:06:17material.
2:06:19The part that makes retros actually
2:06:20useful is psychological safety, the
2:06:23sense that you can say, I underestimated
2:06:25this, or that process didn't work
2:06:28without it being held against you.
2:06:30A retro where nobody says anything
2:06:32honest just produces the same problems
2:06:34again next sprint.
2:06:36So if you're new to a team and planning
2:06:38feels like arguing over tickets and
2:06:41retro feels like complaining with
2:06:42structure, that's normal.
2:06:45Both are the team's way of getting a
2:06:46little better at predicting and working
2:06:48together,
2:06:49sprint at a time. A service has been
2:06:51quietly failing for 20 minutes before
2:06:54anyone notices, not because it crashed,
2:06:57but because one in every 20 requests was
2:06:59returning an error and nobody was
2:07:01watching that number.
2:07:03The service looked up. It just wasn't
2:07:05fully working.
2:07:07This is the gap that monitoring exists
2:07:09to close.
2:07:11Shipping code and watching it work are
2:07:13two different skills, and a team that's
2:07:15good at the first but blind to the
2:07:17second finds out about problems from
2:07:19angry users instead of from their own
2:07:21tools.
2:07:23At its simplest, monitoring means
2:07:24collecting numbers about a running
2:07:26system over time.
2:07:28The most common ones are error rate, how
2:07:30often requests fail, latency, how long
2:07:33requests take to come back, and traffic,
2:07:36how many requests are coming in at all.
2:07:39A dashboard turns those numbers into a
2:07:41graph you can glance at instead of a
2:07:43wall of log lines you'd have to read one
2:07:45by one.
2:07:46An alert is a rule that watches one of
2:07:48those graphs and notifies someone when
2:07:50it crosses a line that matters, error
2:07:53rate above a certain percentage or
2:07:55latency above a certain number of
2:07:56seconds.
2:07:57Good alerts are specific enough to act
2:07:59on.
2:08:00A vague alert that fires constantly for
2:08:02things nobody needs to act on trains
2:08:05people to ignore it, which means the one
2:08:07time it matters it gets ignored, too.
2:08:10Monitoring is different from the
2:08:11incident response you may have heard
2:08:13about elsewhere.
2:08:14Incident response is what happens after
2:08:16something is clearly broken and everyone
2:08:19knows it.
2:08:20Monitoring is what catches the problem
2:08:22quietly, often before users notice,
2:08:24sometimes before it becomes an incident
2:08:26at all.
2:08:27You don't need to build any of this
2:08:29yourself as a junior developer,
2:08:31but you will be expected to glance at a
2:08:33dashboard before and after you deploy
2:08:35something and to know that a quiet
2:08:37dashboard is a good sign, not a boring
2:08:40one. Let's recap module nine. A normal
2:08:43day is a mix of coding, reading,
2:08:46meetings, and questions.
2:08:48You learned what those meetings are for
2:08:49and how teams in different time zones
2:08:51keep work moving by writing clearly the
2:08:54first time.
2:08:55And you saw how much of the job is
2:08:57looking after software that already
2:08:59exists.
2:09:00Then came the bad days. When production
2:09:03breaks, you find out the impact first,
2:09:05and you tell people what you're doing
2:09:07before you try a fix.
2:09:09For a new developer, on call usually
2:09:11means checking the alert and bringing in
2:09:13the right person if it's too big to
2:09:15handle safely.
2:09:16A blameless post mortem turns a failure
2:09:19into real changes, and good monitoring
2:09:21can catch trouble before customers do.
2:09:24For your own start, you now have an
2:09:26order to follow before asking for help.
2:09:28You also have five things to do in your
2:09:30first weeks, and you can write notes and
2:09:33updates that put the point first.
2:09:35That covers the work itself. Module 10
2:09:38is about your place in all of this.
2:09:40Welcome to module 10, the last
2:09:42[clears throat] one.
2:09:43It's about everything around the work.
2:09:46That means the company you join, the
2:09:48people you work with, and where all of
2:09:50it can take you.
2:09:52We'll start before you're even hired.
2:09:54You'll see the kinds of companies out
2:09:55there, the roles on a team, and what a
2:09:58company really expects from a junior.
2:10:01From there, we get to the harder side of
2:10:03working with people.
2:10:04Someone will reject your work. Someone
2:10:06else will want it sooner than you can
2:10:08safely ship it. And some days, you'll
2:10:10get one more task when you're already
2:10:12too busy.
2:10:14You'll know what to say when that
2:10:15happens.
2:10:16After that, the focus moves to your own
2:10:18growth. You'll see how to make sure your
2:10:20work gets noticed and how to use your
2:10:22time with your manager well. You'll
2:10:25learn to talk with people who don't
2:10:26write code, and you'll see where you fit
2:10:28in the company and how to find someone
2:10:30who can guide you.
2:10:32By the end of this module, you'll know
2:10:33how to handle the people side of the
2:10:35job. You'll also know how to look after
2:10:37your own growth.
2:10:39Let's begin with the choice you'll run
2:10:40into as as as you start applying. One
2:10:43thing you'll hear a lot when you start
2:10:44looking for IT jobs is product company
2:10:47versus service company.
2:10:50A product company builds and operates
2:10:52its own software product, a banking
2:10:54platform, an e-commerce app, a developer
2:10:57tool, a SaaS product.
2:10:59The team is usually focused on improving
2:11:01and maintaining that one product over
2:11:03time.
2:11:04For example, imagine a company that
2:11:06builds a project management tool used by
2:11:09thousands of businesses.
2:11:10Its developers might spend months
2:11:12improving the same product, adding
2:11:14features, fixing bugs, and responding to
2:11:17customer feedback.
2:11:18Over time, they get to understand the
2:11:21product and its architecture in
2:11:22considerable depth.
2:11:24A service company works differently. It
2:11:27provides technology services to clients.
2:11:30So you might work on a banking project
2:11:32for one client and a retail project for
2:11:34another right after.
2:11:36That can mean jumping between different
2:11:37technologies, industries, and project
2:11:40environments.
2:11:41Imagine you're working for a service
2:11:43company and your client is a bank. You
2:11:45might help build an API, migrate data to
2:11:48the cloud, or maintain an existing
2:11:50application.
2:11:51If the project ends and you're assigned
2:11:53to a retail client, you could find
2:11:55yourself working with a completely
2:11:57different technology stack and business
2:11:59domain.
2:12:00That variety can be a valuable learning
2:12:02experience, especially early in your
2:12:04career.
2:12:05But don't oversimplify this into product
2:12:07is good, service is bad.
2:12:09That's not how the real world works.
2:12:12A great team in a service company can
2:12:14give you more practical experience than
2:12:16a poorly managed product team.
2:12:18There's also some overlap between the
2:12:20two.
2:12:21Product companies hire consultants and
2:12:22external teams, while service companies
2:12:25sometimes build and maintain systems for
2:12:27the same client for many years.
2:12:29The actual work can matter more than the
2:12:32category the company falls into.
2:12:34What actually matters is what you'll be
2:12:36working on day to day, what technology
2:12:39you'll use, whether you'll touch real
2:12:41production systems, whether you'll
2:12:43actually get code reviews, whether there
2:12:45are experienced people around you, and
2:12:47whether you'll own work that matters.
2:12:50Those questions tell you a lot more than
2:12:52the label on the company.
2:12:54And your first job doesn't lock you into
2:12:55one path. You can start in one type of
2:12:58company, build real experience, and move
2:13:00later. Another thing beginners often
2:13:03struggle with is understanding all the
2:13:05different roles inside an IT team.
2:13:07You'll hear titles like software
2:13:09developer, front end developer, back end
2:13:12developer, data engineer, data analyst,
2:13:15DevOps engineer, cloud engineer, QA
2:13:18engineer, security engineer, product
2:13:20manager, and plenty more.
2:13:23These roles overlap at some companies,
2:13:25but they generally focus on different
2:13:27parts of the system.
2:13:29A front end developer focuses heavily on
2:13:31what users actually interact with.
2:13:33A back end developer works more with
2:13:35APIs, business logic, databases, and
2:13:38services.
2:13:40A data engineer builds the systems that
2:13:41collect, transform, move, and prepare
2:13:44data.
2:13:46A DevOps or platform engineer usually
2:13:48focuses on infrastructure, deployment,
2:13:51automation, and reliability.
2:13:53And a QA engineer focuses on validating
2:13:56software and catching problems before
2:13:58users ever see them.
2:14:00Let's take an online shopping
2:14:02application as an example.
2:14:04The front end developer builds the
2:14:05product pages and shopping cart that
2:14:07customers see.
2:14:08The back end developer handles things
2:14:10like orders, payments, and customer
2:14:12accounts.
2:14:13The data engineer makes sure sales and
2:14:15customer data flows into systems where
2:14:17it can be analyzed, while the QA
2:14:20engineer tests whether the checkout
2:14:21process works correctly, including
2:14:23situations where a payment fails.
2:14:26Meanwhile, the cloud or platform
2:14:28engineer helps keep the application
2:14:30running in the right environment,
2:14:32manages deployment pipelines, and makes
2:14:34sure the infrastructure can handle the
2:14:36workload.
2:14:37The security engineer looks for
2:14:38vulnerabilities and helps protect
2:14:40customer information.
2:14:42Each role contributes to making the same
2:14:44application work reliably and safely.
2:14:48Then there are roles outside direct
2:14:49development entirely. Product managers
2:14:52who think about what should be built and
2:14:54why, designers who shape the user
2:14:56experience, and project or delivery
2:14:58people who help coordinate the work.
2:15:01For example, before a team builds a new
2:15:03checkout feature, the product manager
2:15:05might define the customer problem. The
2:15:08designer works out how the experience
2:15:10should look, and the developers figure
2:15:12out how to implement it.
2:15:13The QA engineer validates the finished
2:15:15feature, while other team members help
2:15:17make sure it can be deployed and
2:15:19operated reliably.
2:15:21These people are solving different parts
2:15:23of the same problem.
2:15:25The important thing is that real
2:15:27software is rarely built by one person.
2:15:30A production application is usually the
2:15:32result of a lot of different roles
2:15:34working together.
2:15:35So when you join a company, don't only
2:15:37learn who writes code, learn who does
2:15:40what. That makes the entire system much
2:15:43easier to understand. A common mistake
2:15:45beginners make is thinking companies
2:15:47expect a junior developer to know
2:15:49everything. Usually, they don't.
2:15:52Nobody expects you to know every
2:15:54framework, every cloud service, or every
2:15:57internal tool on your first day.
2:15:59What companies actually need from a
2:16:01junior is much more basic.
2:16:03Can you understand a requirement, read
2:16:05existing code, and solve a reasonably
2:16:07scoped problem? Can you test your own
2:16:10work? Speak up clearly when you're
2:16:12blocked? Pick up something you've never
2:16:13seen before and take feedback without
2:16:16getting defensive about it?
2:16:18Think about it from the team's
2:16:19perspective.
2:16:20A senior developer can teach you how
2:16:22their application works or help you
2:16:24understand a new technology, but they
2:16:26need to be able to trust that you'll ask
2:16:28when something is unclear, check your
2:16:30work before handing it over, and tell
2:16:32them honestly when something goes wrong.
2:16:35Those things matter a lot more than they
2:16:36sound.
2:16:37You might not know how the company's
2:16:39deployment system works. That's okay.
2:16:41You can learn it.
2:16:43But if you don't ask questions, don't
2:16:45test your changes, don't communicate
2:16:47problems, and can't take feedback, all
2:16:49the technical knowledge in the won't fix
2:16:51that.
2:16:52And remember, nobody expects you to
2:16:54learn everything overnight.
2:16:56You might make mistakes, misunderstand a
2:16:58requirement or need help with something
2:17:01that seems obvious to everyone else.
2:17:03What matters is whether you learn from
2:17:05those experiences and gradually become
2:17:07more confident working independently.
2:17:10So when preparing for your first job,
2:17:12don't focus only on collecting
2:17:13technologies. Build the ability to learn
2:17:16and work inside an existing system.
2:17:19That's much closer to what your first
2:17:20year will actually require.
2:17:22And part of working inside a system is
2:17:25working with people who don't always
2:17:26agree with you.
2:17:28Let's talk about that. Here's a moment
2:17:29nobody warns you about.
2:17:31You finish your ticket, you're proud of
2:17:33it, and the Q&A engineer moves it
2:17:35straight back to in progress with a
2:17:37note, fails when the email has uppercase
2:17:40letters.
2:17:41Your first reaction is going to be a
2:17:43little sting. That's human.
2:17:45Here's the thing to understand.
2:17:47Q&A rejecting your ticket is not Q&A
2:17:50rejecting you. It's the system working
2:17:53exactly as designed. That bug was going
2:17:55to be found by somebody. Better a
2:17:57teammate on Tuesday than a customer on
2:18:00Saturday.
2:18:01So what do you do?
2:18:02You say, good catch. You reproduce it,
2:18:05you fix it, and you add the uppercase
2:18:07case to your tests so it never comes
2:18:09back. That's it.
2:18:11The developers who get respected fast
2:18:13are not the ones who never get bugs.
2:18:15They're the ones who handle them without
2:18:17drama.
2:18:18Now the other direction.
2:18:20A product manager pings you. Can we just
2:18:22ship the registration change today? The
2:18:24marketing campaign starts tomorrow.
2:18:26Your code review isn't done. The staging
2:18:28tests haven't run. You're new. You want
2:18:31to be helpful, and just ship it sounds
2:18:34like being helpful.
2:18:35It isn't.
2:18:36Here's a better answer, and you can use
2:18:38it word for word.
2:18:40I can't skip the review and staging run
2:18:42safely. What I can do is get it into
2:18:44review right now and flag it as urgent.
2:18:47If it passes, it can go out this
2:18:49afternoon. If we skip those steps and it
2:18:51breaks registration during the campaign,
2:18:53that's a worse day for everyone.
2:18:56Notice what that does. It doesn't say
2:18:58no. It says what's possible, what the
2:19:01risk is, and puts the decision where it
2:19:03belongs,
2:19:04which brings us to the most important
2:19:06rule for a junior.
2:19:08Decisions like that don't happen in a
2:19:09private chat. They happen on the ticket
2:19:12or in the team channel where your lead
2:19:14can see them.
2:19:15If the product manager still wants to
2:19:17skip steps, that's a call for your lead
2:19:19to make, not you.
2:19:21Escalating isn't tattling. It's how the
2:19:23team protects both the product and you.
2:19:26And one more.
2:19:28Sometimes a senior developer will push
2:19:30back on your approach in code review,
2:19:32and you'll be sure you're right.
2:19:33Ask why, genuinely. Most of the time
2:19:37there's a reason you haven't seen yet,
2:19:39an old incident, a system you didn't
2:19:40know about. Occasionally you'll actually
2:19:43be right, and saying, here's what I was
2:19:45thinking, does that change anything? Is
2:19:47how you find out.
2:19:49Disagreement is a normal part of
2:19:50building software with other people.
2:19:53Handle it calmly, keep it visible, and
2:19:55it turns into trust faster than anything
2:19:57else you can do. Here's something nobody
2:20:00puts in a job posting. Even on a healthy
2:20:02team, people have different incentives,
2:20:05different priorities, and sometimes
2:20:07different opinions about who should get
2:20:08credit for what.
2:20:10That's not necessarily a toxic
2:20:12workplace. That's just what happens
2:20:14whenever more than a few people work
2:20:15together.
2:20:17The question isn't how to avoid this
2:20:18entirely, it's how to move through it
2:20:21without damaging your own reputation in
2:20:22the process.
2:20:24The most reliable protection you have is
2:20:26keeping decisions and disagreements
2:20:28visible instead of private.
2:20:30If a disagreement with a teammate
2:20:32happens in a side conversation, it can
2:20:34quietly turn into two different stories
2:20:36later.
2:20:37If it happens on the ticket, in the pull
2:20:39request, or in the team channel,
2:20:41everyone can see what was actually said
2:20:43and agreed to.
2:20:44This isn't about distrust. It's just a
2:20:47habit that protects everyone, including
2:20:49you.
2:20:50For example, suppose you suggest one
2:20:52approach to solving a problem, but
2:20:54another developer recommends something
2:20:56different.
2:20:57Instead of turning it into a personal
2:20:58argument, explain your reasoning, listen
2:21:01to theirs, and document the final
2:21:03decision.
2:21:04If the team chooses their approach,
2:21:06support that decision and move forward.
2:21:08You don't have to win the argument to
2:21:10contribute something valuable.
2:21:12The second habit is simple, but easy to
2:21:14forget under pressure.
2:21:16Don't vent about a coworker to other
2:21:18coworkers.
2:21:20It feels satisfying in the moment, and
2:21:22it almost always comes back around.
2:21:25If someone's work or behavior is
2:21:26genuinely a problem, that's a
2:21:28conversation for your manager, calmly
2:21:31and factually, not a conversation for
2:21:33the group chat.
2:21:34And when you raise a concern, focus on
2:21:36specific behavior and its impact rather
2:21:39than making assumptions about someone's
2:21:41intentions.
2:21:42Saying that a missed handover delayed
2:21:44your work gives your manager something
2:21:46concrete to address. Saying that someone
2:21:48is lazy or doesn't care turns the
2:21:51conversation into a judgment about their
2:21:53character.
2:21:54And the third habit is the one that
2:21:56actually builds a good reputation over
2:21:58time, not through impressing people, but
2:22:00through being consistently easy to work
2:22:02with,
2:22:03following through on what you say you'll
2:22:05do,
2:22:06giving credit to people who helped you,
2:22:09helping a teammate without immediately
2:22:10expecting something back.
2:22:12None of this is about being naive. It's
2:22:15that a reputation for being
2:22:16straightforward and reliable tends to
2:22:18open more doors than any amount of
2:22:20self-promotion.
2:22:22That doesn't mean you should quietly
2:22:23accept everything or take responsibility
2:22:26for problems that aren't yours. You can
2:22:28disagree respectfully, set boundaries,
2:22:31and speak up when something is unfair.
2:22:33Being professional means handling those
2:22:35situations constructively, not
2:22:37pretending they don't exist.
2:22:39You don't need to win every disagreement
2:22:41or be liked by everyone.
2:22:43You need to be someone people trust to
2:22:45act the same way whether or not they're
2:22:47in the room.
2:22:48Staying professional through moments
2:22:49like this is one part of protecting your
2:22:52reputation.
2:22:53The other part is protecting your time,
2:22:55which is its own skill entirely. At some
2:22:58point, someone is going to hand you a
2:23:00new task while you're already juggling
2:23:02two others, and every instinct you have
2:23:04will want to say yes anyway.
2:23:06As a beginner, saying yes to everything
2:23:09can feel like the safe choice. Often,
2:23:12it's actually the choice that causes the
2:23:13most damage later.
2:23:15Here's why. If you quietly take on more
2:23:18than you can realistically finish, one
2:23:20of two things happens. Something slips
2:23:22through with less attention than it
2:23:24deserved, or you end up working long
2:23:26hours just to keep up.
2:23:28Neither one is sustainable, and neither
2:23:31one is actually what a good manager
2:23:32wants from you, even if it feels like
2:23:34the helpful answer in the moment.
2:23:37And there's another problem with
2:23:38constantly saying yes. Your manager
2:23:40might assume your workload is manageable
2:23:42because you're never raising any
2:23:44concerns.
2:23:45By the time a deadline slips or the
2:23:47quality of your work starts to suffer,
2:23:49the problem has already become much
2:23:51harder to fix.
2:23:52The skill isn't refusing work. It's
2:23:55making the trade-off visible instead of
2:23:57invisible.
2:23:58Something like, I'm currently finishing
2:24:00the payment ticket and reviewing a
2:24:02teammate's pull request. I can start
2:24:04this new one today, but the payment
2:24:06ticket would slip to tomorrow. Which
2:24:08would you like me to prioritize?
2:24:10That's not saying no. It's handing the
2:24:12actual decision to the person who has
2:24:14the full picture instead of silently
2:24:16overcommitting and hoping it works out.
2:24:19This is especially important when you're
2:24:20new because you might not yet know how
2:24:22long a task will take.
2:24:24If you discover that something is more
2:24:26complicated than expected, communicate
2:24:28that early.
2:24:30You don't need to have the perfect
2:24:31solution or a new deadline ready. Just
2:24:33explain what you found, what remains,
2:24:36and where you need help.
2:24:37The same idea applies to your time
2:24:39outside of work hours.
2:24:41Occasionally, something urgent genuinely
2:24:43can't wait. But if every evening or
2:24:46weekend starts to feel like an
2:24:47emergency, that's not a personal failing
2:24:50to push through quietly. It's a signal
2:24:52worth raising with your manager because
2:24:54it usually means something in the
2:24:55workload or the process needs to change.
2:24:59Of course, different teams have
2:25:00different expectations, and some roles
2:25:03do involve occasional after hours
2:25:04support.
2:25:05The important distinction is between an
2:25:07agreed responsibility that you can plan
2:25:09for and a constant pattern of unexpected
2:25:12work that leaves you unable to switch
2:25:14off.
2:25:15Protecting your time isn't about doing
2:25:17less. It's about making sure the person
2:25:19deciding what gets prioritized actually
2:25:22has accurate information to decide with.
2:25:25And all of this, the workload, the push
2:25:27back, the politics feeds into a bigger
2:25:30question we're thinking about early.
2:25:33Where do you actually want this career
2:25:34to go? Your career probably won't go
2:25:37exactly according to the plan you have
2:25:39right now. You might start as a
2:25:41developer and move into cloud. You might
2:25:43start in testing and end up in
2:25:45automation. You might begin with one
2:25:47programming language and spend most of
2:25:49your career using a completely different
2:25:51one.
2:25:52You might discover you actually enjoy
2:25:53working with data more than building
2:25:55applications or that you like
2:25:57infrastructure more than writing
2:25:58application code.
2:26:00And sometimes the change happens because
2:26:02of a project you never expected to work
2:26:04on.
2:26:05You might get assigned to a cloud
2:26:06migration, start learning how the
2:26:08infrastructure works, and discover
2:26:09that's the part of the job you enjoy
2:26:11most.
2:26:12You don't have to figure out your entire
2:26:14career before you start working. That's
2:26:16normal.
2:26:17Technology changes, companies change,
2:26:20your own interests change, and your
2:26:22career changes right along with them.
2:26:24The useful thing to build early isn't an
2:26:27attachment to one particular technology.
2:26:29It's a strong foundation.
2:26:31Programming, databases, networking, Git,
2:26:35cloud concepts, debugging, system
2:26:37thinking, and communication.
2:26:40Once those fundamentals are solid,
2:26:42picking up a new tool becomes far
2:26:44easier.
2:26:45Think about it this way. If you
2:26:47understand databases, learning a new
2:26:49database platform becomes much easier
2:26:51because the underlying concepts are
2:26:53familiar.
2:26:54If you understand networking, a new
2:26:56cloud provider's networking services
2:26:58won't feel completely foreign.
2:27:00You're learning a different
2:27:00implementation of concepts you already
2:27:02understand.
2:27:04A framework can fall out of fashion, a
2:27:06cloud service can get replaced, a
2:27:08programming language can rise or fall in
2:27:11popularity, but the ability to learn
2:27:13quickly and solve problems stays useful
2:27:16no matter what changes around it.
2:27:18This is also why you shouldn't feel
2:27:19pressured to learn every new technology
2:27:22the moment it appears.
2:27:23Pay attention to what's relevant to your
2:27:25role, build depth in the areas you use,
2:27:28and explore new tools when there's a
2:27:30genuine reason to.
2:27:31Understanding a few things well is often
2:27:34more valuable than knowing a little
2:27:36about everything.
2:27:37And since we just talked about logging
2:27:39your work, it's worth saying plainly,
2:27:42genuine career growth usually isn't the
2:27:44result of politics or self-promotion.
2:27:47It's the compounding effect of
2:27:48consistently delivering, taking
2:27:50ownership of problems beyond just your
2:27:52assigned ticket, and being someone
2:27:54people can rely on. Visibility matters,
2:27:57which is exactly why that habit of
2:27:59logging your own work matters, but
2:28:02visibility only helps you if there's
2:28:04real substance underneath it.
2:28:06Growth that isn't built on that
2:28:07foundation tends to be short-lived.
2:28:10Building that kind of foundation is one
2:28:12thing, making sure anyone actually
2:28:14notices it is another.
2:28:16Here's something that surprises a lot of
2:28:18first-year developers. Your manager does
2:28:21not remember most of what you did 6
2:28:23months ago.
2:28:24Not because they don't care, but because
2:28:26they're tracking an entire team, not
2:28:28just you. When appraisal season comes
2:28:30around, they're often reconstructing
2:28:32your year from memory, a few Jira
2:28:34tickets, and whatever you tell them.
2:28:37If you don't tell them, that work
2:28:39quietly disappears from the story.
2:28:41The fix is a habit, not a personality
2:28:44trait.
2:28:45Once a week, write two or three lines
2:28:47for yourself, what you shipped, what
2:28:49problem it actually solved, and anything
2:28:52notable, a teammate you helped unblock,
2:28:54a bug you caught before it reached
2:28:56customers, a process you improved.
2:28:58It doesn't need to be polished, it just
2:29:00needs to exist somewhere outside your
2:29:02own memory.
2:29:04For example, instead of writing worked
2:29:06on the payment API, record that you
2:29:09fixed a timeout issue that was causing
2:29:11payment requests to fail intermittently.
2:29:13The second version captures the actual
2:29:15impact of your work, and six months
2:29:18later, you'll remember much more clearly
2:29:20what you contributed and why it
2:29:21mattered.
2:29:23This isn't self-promotion in the pushy
2:29:25sense.
2:29:26Your manager is very likely advocating
2:29:28for you in rooms you're not in, deciding
2:29:30on raises, promotions, or new
2:29:32opportunities, often based on incomplete
2:29:35information.
2:29:36Giving them an accurate, specific record
2:29:38of your impact isn't political
2:29:39maneuvering. It's making sure the person
2:29:42representing you actually has the facts.
2:29:45When appraisal time comes, that running
2:29:47log turns into your self-review almost
2:29:49automatically. Specific, honest, and
2:29:52grounded in things that actually
2:29:54happened, instead of a vague attempt to
2:29:56remember your whole year in one sitting.
2:29:59It can also help you spot patterns in
2:30:00your own development.
2:30:02You might notice that you're taking on
2:30:03more complex tasks, helping teammates
2:30:06more often, or becoming the person
2:30:08people approach for a particular area of
2:30:09the system.
2:30:11Those patterns can help you identify
2:30:13what you're getting better at and where
2:30:14you want to grow next.
2:30:16Genuine growth in your career tends to
2:30:18come from this same place. Consistent,
2:30:21visible impact over time, not from
2:30:24politics and not from constantly
2:30:26promoting yourself in the moment.
2:30:28The log is just what makes sure that
2:30:30consistency doesn't get forgotten.
2:30:32And that log doesn't have to wait for
2:30:34appraisal season to be useful. There's a
2:30:36much more regular place it belongs, your
2:30:39one-on-ones. At some point, your manager
2:30:42will start scheduling a recurring
2:30:43one-on-ones, usually 15 to 30 minutes,
2:30:46just the two of you.
2:30:48A lot of juniors treat this as a status
2:30:50update. Here's what I've been working
2:30:51on, and leave most of the value on the
2:30:54table.
2:30:55A one-on-ones is one of the few pieces
2:30:57of time at work that's actually meant to
2:30:59be about you, not about the sprint.
2:31:02Status updates already happen at
2:31:04stand-up.
2:31:05This is the time for things that don't
2:31:06fit into a five-minute team meeting. A
2:31:09blocker you've been sitting on quietly,
2:31:11a piece of feedback you want but haven't
2:31:13been given, a question about where your
2:31:15career could go, or simply flagging that
2:31:18a project's timeline feels off before it
2:31:20becomes a bigger problem.
2:31:22For example, maybe you've been
2:31:24struggling with a particular part of the
2:31:25codebase for two weeks, but you haven't
2:31:28mentioned it because you don't want to
2:31:29look inexperienced.
2:31:31Your one-on-one is a good place to bring
2:31:33that up. Explain what you've tried and
2:31:35ask for guidance.
2:31:36You don't have to arrive with every
2:31:38problem already solved.
2:31:40Sometimes knowing when to ask for help
2:31:43is part of becoming a better developer.
2:31:45This is also exactly where that work log
2:31:47from earlier becomes useful in the
2:31:50moment, not just at appraisal time.
2:31:53Instead of a vague things are going
2:31:54fine, you can walk in with something
2:31:57concrete.
2:31:58I shipped the discount feature. It's the
2:32:00one the support team mentioned came up a
2:32:01lot. I'd like to try picking up
2:32:03something closer to the payment service
2:32:05next. Is that realistic?
2:32:07That's a very different conversation
2:32:09than one built entirely on the spot.
2:32:11And pay attention to the feedback you
2:32:13receive.
2:32:14If your manager suggests improving how
2:32:16you communicate progress, for example,
2:32:18don't treat it as a criticism to forget
2:32:21once the meeting ends. Pick one
2:32:23practical thing to work on before your
2:32:25next one-on-one, then follow up on how
2:32:27it went.
2:32:28That's how a short conversation turns
2:32:30into actual progress over time.
2:32:33You don't need an agenda every single
2:32:35week, but it 's worth walking in with at
2:32:37least one real thing, a blocker, a
2:32:40question, or something you want feedback
2:32:42on, rather than treating the meeting as
2:32:44something to get through.
2:32:45Managers generally want to help, but
2:32:48they can only act on what you actually
2:32:50bring to them.
2:32:51And all of this, the log, the
2:32:53one-on-ones, the honest conversations
2:32:56about workload points toward the same
2:32:58bigger question.
2:33:00What actually makes someone good at this
2:33:02job? After working with developers for a
2:33:04while, you notice something interesting.
2:33:07The person who knows the most syntax
2:33:10isn't necessarily the strongest
2:33:11developer.
2:33:13Someone might know 10 programming
2:33:14languages and still struggle to
2:33:16understand a simple production issue.
2:33:18Meanwhile, another developer might know
2:33:20just one language extremely well, but be
2:33:23excellent at breaking down problems,
2:33:25debugging systems, communicating with
2:33:27the team, and making changes safely.
2:33:30That's because software engineering is
2:33:32bigger than writing code.
2:33:34You need the technical skills, sure, but
2:33:37you also need judgment. Knowing when to
2:33:39ask for help, when to keep [snorts]
2:33:41investigating, when not to make a risky
2:33:43change, when a quick fix is genuinely
2:33:46enough, and when a problem actually
2:33:48needs a deeper solution.
2:33:50You build that judgment by working
2:33:52through real problems, not just by
2:33:54watching tutorials or learning new
2:33:55frameworks.
2:33:57When something breaks, take the time to
2:33:59understand why it broke, what caused it,
2:34:02and how you could prevent the same issue
2:34:03from happening again.
2:34:05Over time, those experiences start
2:34:07changing how you approach problems.
2:34:10You need to communicate clearly,
2:34:12and you need to understand that your
2:34:14code affects other people, not just your
2:34:16own to-do list.
2:34:18There's a related trap worth naming
2:34:19directly.
2:34:21It's possible to complete ticket after
2:34:22ticket for months and still barely
2:34:25understand how the system actually fits
2:34:27together.
2:34:28Finishing tickets keeps you employed.
2:34:30Understanding the system is what makes
2:34:32you genuinely valuable.
2:34:34That means occasionally reading code you
2:34:36weren't assigned to touch, asking why
2:34:39something was built a certain way
2:34:40instead of just how to change it, and
2:34:42noticing how your one piece connects to
2:34:44the rest of the application.
2:34:46The developers people actually go to for
2:34:48help aren't necessarily the ones who've
2:34:50closed the most tickets.
2:34:52They're the ones who can answer, Wait,
2:34:54how does this whole thing actually work?
2:34:57And you don't have to understand the
2:34:58entire system overnight. Start with the
2:35:01part you're working on, then follow the
2:35:03connections.
2:35:04Where does the data come from?
2:35:06What calls this service? What happens
2:35:08after your code runs?
2:35:10Each answer gives you a slightly bigger
2:35:12picture, and eventually, problems that
2:35:15once seemed confusing start making
2:35:17sense.
2:35:18So, as you progress in your career,
2:35:20don't measure yourself only by how much
2:35:22code you can write.
2:35:24Measure yourself by the problems you can
2:35:25understand and solve.
2:35:28Understanding the system is only half of
2:35:30it, though. You also have to be able to
2:35:32explain what you understand to people
2:35:34who don't share your technical
2:35:35vocabulary, which is its own skill worth
2:35:38building on purpose. A product manager
2:35:40asks, Can we just add a filter to this
2:35:43page by Friday? And a developer answers
2:35:45with a sentence full of words like
2:35:47schema migration and cache invalidation.
2:35:50Both people walk away from that
2:35:51conversation a little frustrated, and
2:35:54neither one was wrong.
2:35:56Different roles on a software team
2:35:57aren't just doing different tasks.
2:36:00They're usually optimizing for different
2:36:01things, and talking past each other
2:36:03usually comes from forgetting that.
2:36:06A product manager is mainly thinking
2:36:07about what the business and the customer
2:36:09need and when.
2:36:11A designer is thinking about how it
2:36:12should look and feel and whether it's
2:36:14actually usable.
2:36:16QA is thinking about what could go wrong
2:36:18and whether it 's been checked. None of
2:36:21them are thinking primarily about your
2:36:22database schema, and they shouldn't have
2:36:24to.
2:36:25The habit that closes that gap is
2:36:27translating constraints into outcomes
2:36:29instead of mechanisms.
2:36:31Instead of saying, that requires a
2:36:33schema migration, try something like
2:36:35this.
2:36:36That's possible, but it touches how we
2:36:38store existing data, so it'll take a bit
2:36:41longer and needs to go out carefully,
2:36:43probably Tuesday instead of Friday.
2:36:45That gives a non-technical teammate
2:36:47something they can actually act on, a
2:36:49timeline and a reason, not a term they
2:36:52have to look up.
2:36:53This works in both directions. When a
2:36:55request seems vague, like make it faster
2:36:58or make it feel more modern, it helps to
2:37:01resist answering it purely technically
2:37:03right away.
2:37:04Ask what specific moment prompted the
2:37:06request.
2:37:07Make it faster often means one
2:37:09particular screen felt slow to one
2:37:11particular person on one particular day,
2:37:14not that the whole system needs a
2:37:16redesign.
2:37:17Finding that specific moment usually
2:37:19turns a vague ask into a concrete
2:37:21solvable problem.
2:37:23Q&A deserves that same respect in the
2:37:25other direction. You already know not to
2:37:27take a rejected ticket personally. The
2:37:30missing half of that habit is what to do
2:37:32next. Ask for the exact steps that
2:37:34reproduce what they saw.
2:37:36A bug report with a vague recollection
2:37:38on your side and precise steps on theirs
2:37:41isn't a disagreement to win. It's
2:37:43missing information to go find.
2:37:45None of this means hiding technical
2:37:47reality or pretending constraints don't
2:37:49exist.
2:37:50It means remembering that the person
2:37:52across from you is optimizing for
2:37:53something just as real as your technical
2:37:56concern. And the fastest way through a
2:37:58disagreement is usually translating your
2:38:00constraint into their terms, not
2:38:02insisting they learn yours first. Get
2:38:05comfortable with that kind of
2:38:06translation and a lot of the friction
2:38:08that makes a first job feel exhausting
2:38:11quietly disappears. You ask your manager
2:38:13for something small, a paid tool license
2:38:16say, something that costs less than a
2:38:18dinner out.
2:38:19Two weeks later, you still don't have an
2:38:21answer.
2:38:22It's tempting to assume the company is
2:38:24just slow or doesn't care.
2:38:27Usually that's not it.
2:38:29Your request is standing in a line you
2:38:30can't see and it helps to know who else
2:38:33is in that line.
2:38:34Most engineering teams run two separate
2:38:37ladders at once and the confusing part
2:38:39is that both of them use the word senior
2:38:41somewhere.
2:38:43One ladder is for people who keep
2:38:44writing code and solving technical
2:38:46problems directly, often called the
2:38:48individual contributor track or IC for
2:38:51short.
2:38:52It usually runs from junior to mid-level
2:38:55to senior.
2:38:56At some companies, it continues into
2:38:58staff or principal engineer.
2:39:00Those are people who are still hands-on,
2:39:02but whose decisions now shape how
2:39:04multiple teams build things, not just
2:39:06their own code.
2:39:07The other ladder is for people who
2:39:09manage people. That one usually runs
2:39:12from engineering manager to director to
2:39:14VP of engineering and sometimes at the
2:39:17very top a CTO, the most senior
2:39:20engineering role in the company.
2:39:22Here's the distinction that actually
2:39:24matters day-to-day.
2:39:25An engineering manager's job is to
2:39:27support their team. That means running
2:39:29one-on-ones, giving feedback, deciding
2:39:32priorities, and clearing obstacles.
2:39:34They're usually not writing much
2:39:36production code themselves anymore.
2:39:38A senior or staff engineer on the other
2:39:41hand might outrank a lot of people in
2:39:43technical judgment while having nobody
2:39:45reporting to them at all.
2:39:47Seniority and being someone's boss are
2:39:49not the same thing, and mixing them up
2:39:52is an easy mistake to make in your first
2:39:54few months.
2:39:55So where did your two-week request
2:39:57actually go?
2:39:59In a lot of companies, something like a
2:40:00budget item, even a small one, follows
2:40:03the management ladder, not the technical
2:40:05one.
2:40:06Your manager might be able to approve it
2:40:08alone. If not, it goes up to their
2:40:10manager, a director, who's balancing it
2:40:12against requests from several teams, not
2:40:15just yours.
2:40:16If it's bigger, it might need a VP's
2:40:18sign-off, someone thinking about the
2:40:20budget for an entire part of the
2:40:22company, not a single request.
2:40:24Each step isn't necessarily someone
2:40:26being difficult. It's someone who has to
2:40:28weigh your one request against everyone
2:40:31else's, and that takes longer than you'd
2:40:33expect from the outside.
2:40:35And where does the CEO fit into all
2:40:37this?
2:40:38At a small startup, you might actually
2:40:40talk to them directly. At a larger
2:40:42company, the CEO is usually several
2:40:44layers removed from your day-to-day work
2:40:46entirely, focused on the company as a
2:40:48whole rather than any single team's
2:40:50decisions. The product side of the house
2:40:53runs a similar ladder in parallel.
2:40:55Product managers, then a director of
2:40:57product, then a VP, sometimes up to a
2:41:00chief product officer.
2:41:02The engineering and product ladders meet
2:41:04near the top to decide what the company
2:41:06builds and in what order. None of this
2:41:09means you need to learn everyone's name
2:41:10or title.
2:41:12In practice, almost everything you do
2:41:14will run through your direct manager and
2:41:16maybe a tech lead or a senior engineer
2:41:18you work closely with. The rest of the
2:41:20chain mostly matters for reason.
2:41:23It explains the timing. And it explains
2:41:26the no you sometimes get for reasons
2:41:28that have nothing to do with you. A slow
2:41:31approval is rarely about you personally.
2:41:34It's usually just a request waiting its
2:41:36turn in a line with a lot of other
2:41:38requests in it. So the next time
2:41:40something you asked for takes longer
2:41:41than it seems like it should, remember
2:41:43this. It's probably not stuck because
2:41:46it's a bad idea.
2:41:48It's stuck because it's standing in a
2:41:49line. And now you know roughly how long
2:41:52that line is.
2:41:53Understanding that chain helps you make
2:41:55sense of decisions above you.
2:41:57It's a separate question who you
2:41:59[snorts] can actually turn to for
2:42:00advice. You have a question that doesn't
2:42:03belong in a one-to-one with your
2:42:04manager. Something like, should I stay
2:42:07on this team or should I try to move to
2:42:09a different one?
2:42:10Your manager is the wrong person to ask
2:42:12that to, at least at first. They're the
2:42:15person evaluating you. That changes what
2:42:17you can safely say to them.
2:42:19This is where a mentor comes in.
2:42:22A mentor is different from a manager in
2:42:24one important way. A mentor doesn't
2:42:26decide your raise. They don't write your
2:42:28performance review. They're not involved
2:42:31in whether you get promoted.
2:42:32That's exactly what makes them useful.
2:42:35You can ask them things you wouldn't ask
2:42:37your manager and they can give you an
2:42:38honest answer without it affecting your
2:42:40career.
2:42:41Some companies assign you a mentor on
2:42:43day one. Most don't. If nobody hands you
2:42:46one, you're allowed to go find one
2:42:48yourself.
2:42:49Here's how people actually do it. Look
2:42:51for someone whose day-to-day work looks
2:42:53like where you'd like to be in a couple
2:42:55of years. That person doesn't have to be
2:42:57the most senior engineer in the
2:42:59building. It just has to be someone a
2:43:01few steps ahead of you doing something
2:43:03you find genuinely interesting.
2:43:05Now the part that feels awkward. You do
2:43:08not walk up to them and ask, will you be
2:43:10my mentor? That question puts a lot of
2:43:13weight on one moment and most people
2:43:15freeze up and say no, even if they'd
2:43:17have said yes to something smaller.
2:43:19Ask a small thing instead. Something
2:43:22like, I've got a couple of questions
2:43:24about how you code review. Could I grab
2:43:2615 minutes sometime?
2:43:28That's an easy yes. And if the
2:43:30conversation goes well, you ask again
2:43:32next month.
2:43:33A few habits make this sustainable
2:43:35instead of a burden on them.
2:43:37Come with a specific question, not just
2:43:40can we chat.
2:43:41Keep it short and end on time even if
2:43:43they offer to go longer.
2:43:45And actually use what they tell you.
2:43:48Nothing kills a mentor relationship
2:43:50faster than asking the same question
2:43:52twice because you didn't act on the
2:43:53answer the first time.
2:43:55You don't need a title for any of this.
2:43:57You just need one person, a little
2:43:59further down the road than you, willing
2:44:01to answer a question every few weeks.
2:44:04That's the whole relationship and it's
2:44:06worth more than it sounds like at first.
2:44:08Let's finish with the most important
2:44:10thing I want you to take away from this
2:44:11course.
2:44:13Your first IT job can feel overwhelming.
2:44:16There will be tools you've never used.
2:44:18There will be meetings full of
2:44:19terminology you don't recognize. Code
2:44:22bases will look enormous at first and
2:44:25tickets will sometimes make no sense
2:44:27until you actually dig in.
2:44:29There will be days you feel like
2:44:30everyone else already knows what they're
2:44:32doing and you don't.
2:44:34That's normal.
2:44:35Don't expect yourself to become an
2:44:36expert in your first few weeks.
2:44:39And remember, the people around you who
2:44:41seem to know everything were beginners
2:44:43once too.
2:44:44They've had their own confusing days,
2:44:46broken things they didn't mean to break,
2:44:48and spent hours trying to understand
2:44:50problems that seem obvious to them now.
2:44:52You're seeing their experience today,
2:44:55not all the steps it took to get there.
2:44:57Your goal is simply to keep building
2:44:59context. Then gradually take on more
2:45:02responsibility. After a few months,
2:45:05things that felt complicated will start
2:45:07looking familiar. You'll recognize the
2:45:09tools. You'll understand the
2:45:11architecture. You'll know exactly where
2:45:13to look when something breaks and
2:45:14exactly who to ask when you're stuck.
2:45:17Don't worry about learning everything at
2:45:19once either. Focus on the task in front
2:45:21of you. Understand what you 're doing
2:45:23and why and learn something from each
2:45:26experience. You don't need to know every
2:45:28answer. You need to get a little better
2:45:30at finding the answers.
2:45:32And some day a new developer will ask
2:45:34you a question you once had yourself.
2:45:37That's when you'll realize how much
2:45:39you've actually learned. If this course
2:45:41has helped you understand a little more
2:45:43about how IT works and feel more
2:45:45confident about getting started, then
2:45:47it's achieved what I hoped it would. It
2:45:49took almost a month to research, write,
2:45:51and edit this course. If you found it
2:45:54useful, please leave a comment and tell
2:45:56me which part you liked most. And if
2:45:58you'd like to support the channel,
2:45:59please subscribe. It really helps.
2:46:02Thanks for watching and best of luck on
2:46:04your journey into tech.

About this transcript

This page contains the full transcript of I Bet Nobody Explained Real Developer Life in IT Like This (3-Hour Course) by Cloud X Berry, generated from the public captions YouTube serves with the video. The transcript has 27,383 words across 4,809 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.