DEV Community: Ladipo Samuel

dockerizing your fastapi application

Ladipo Samuel — Thu, 16 Jul 2026 09:30:20 +0000

Ladipo Samuel

Jul 16

Docker Series Part 3: Dockerizing Your First Application.

#beginners #docker #python #tutorial

5 min read

Docker Series Part 3: Dockerizing Your First Application.

Ladipo Samuel — Thu, 16 Jul 2026 09:30:02 +0000

In the first two parts of this series, we focused on understanding Docker.

We talked about why Docker was created, why the infamous "works on my machine" problem existed for years, and how Docker solved it. We also looked behind the scenes at Docker's architecture and understood the relationship between the Docker Client, Docker Engine, Docker Hub, Images, and Containers.

Now it's time to put all of that knowledge into practice.

Today, we'll take a simple FastAPI project and package it into a Docker Image that can run consistently across different environments. The project itself is intentionally small because the goal isn't to learn FastAPI: it's to understand how Docker packages applications.

I'll also attach the GitHub repository used in this article so you can clone it and follow along.

github link: https://github.com/ladicodes/docker-demo

Our Project

Before introducing Docker, our project looks like this:

docker-workshop-api/
│
├── main.py
├── requirements.txt
└── README.md

At this stage, it's just another Python application.

It works because our machine already has Python installed, along with every dependency the project requires.

But if we send this same project to another developer, they may run into completely different problems:

Different Python versions
Missing dependencies
Different operating systems
Different environment configurations

This is exactly the kind of inconsistency Docker was designed to eliminate. Instead of sending just our source code, Docker allows us to package the entire runtime environment alongside the application.

The Dockerfile: Docker's Instruction Manual
Docker doesn't magically understand how to package your application. You have to tell it exactly what to do: that's where the Dockerfile comes in.

A Dockerfile is simply a text file containing step-by-step instructions Docker follows to build an Image.

Let's build ours one instruction at a time.

Step 1: Choosing a Base Image
FROM python:3.12-slim

Every Docker Image starts from another Image. Instead of installing Python ourselves, we're using the official Python Image published on Docker Hub.
You'll also notice we're using python:3.12-slim instead of the regular Python Image.

The slim variant removes unnecessary packages while keeping everything needed to run Python applications. This produces smaller Images, which means faster downloads, quicker deployments, and lower storage usage. We'll go much deeper into Image optimization in Part 4.

Step 2: Setting the Working Directory
WORKDIR /app

Think of this as running:

cd /app

inside the container.

From this point onward, every instruction in the Dockerfile executes relative to this directory. Having a dedicated working directory keeps the Image organized and prevents files from being scattered throughout the filesystem.

Step 3: Copying Dependencies First
COPY requirements.txt .

This line copies only the dependency file into the Image. You might be wondering: Why not copy everything immediately?
The answer is Docker Layers. Docker builds Images layer by layer.

If your dependencies rarely change but your application code changes frequently, Docker can reuse the dependency layer during future builds instead of reinstalling everything from scratch. That dramatically speeds up build times. It's a small decision now that saves minutes later in larger projects.

Step 4: Installing Dependencies
RUN pip install --no-cache-dir -r requirements.txt

The RUN instruction executes commands while the Image is being built. Here, Docker installs every package listed in requirements.txt.

The --no-cache-dir flag tells pip not to keep unnecessary installation cache files, helping reduce the final Image size. Every instruction like this becomes part of the final Image.

Step 5: Copying the Application
COPY . .

Now that our dependencies are installed, we copy the rest of the project into the Image. At this point, Docker has everything it needs:

Application code
Dependencies
Configuration
Runtime environment

The application has officially been packaged.

Step 6: Documenting the Application Port
EXPOSE 8000

This tells anyone using the Image that the application is expected to listen on port 8000. It's worth noting that EXPOSE doesn't automatically make the application accessible from your computer. It simply documents which port the application uses inside the container.

We'll map that port when we actually run the container.

Step 7: Starting the Application
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

This instruction defines what should happen whenever a container starts from this Image. In our case, Docker launches the FastAPI application using Uvicorn.

You may notice the application listens on:

0.0.0.0
This often confuses beginners. 0.0.0.0 isn't the address you'll open in your browser. Instead, it tells the application to listen on all available network interfaces inside the container.

From your own computer, you'll access the application through:

http://localhost:8000, by entering uvicorn main:app --reload

because Docker maps your computer's port to the container's port.

Building Our First Docker Image

Now that our Dockerfile is complete, it's time to package the application.

Run:

docker build -t docker-workshop-api .

Let's quickly break this command down.

docker build: Builds a Docker Image.

-t: Assigns a name (tag) to the Image.

docker-workshop-api: The name we'll use whenever we want to create containers from this Image.

dot(.): Perhaps the most overlooked part of the command. The dot tells Docker to use the current folder as the build context, allowing it to locate the Dockerfile and every file referenced by COPY.
Once the build completes, you can confirm the Image exists by running: docker images

You'll now see your newly created Image listed locally. At this point, nothing is running yet. You've simply created the package.

Creating a Running Container

Now we can create a running application from that Image.

docker run -p 8000:8000 docker-workshop-api

This is where many beginners accidentally mix up Images and Containers.

Remember:

An Image is the package. A Container is the running instance of that package.

The docker run command creates a brand-new Container from the Image before starting the application.

The -p 8000:8000 flag maps:

Your Computer (8000)
│
▼
Container (8000)

This allows your browser to communicate with the application running inside Docker.

If everything goes well, you'll see something similar to:

INFO: Uvicorn running on http://0.0.0.0:8000

Although the application listens on 0.0.0.0 inside the container, you should open:

http://localhost:8000/docs

From there, FastAPI's interactive documentation lets you test every endpoint and confirm your application is running successfully inside Docker.

Where We Go From Here

Congratulations.

You've just Dockerized your first application.

More importantly, you've connected the concepts we've covered throughout this series:

Python Project
│
▼
Dockerfile
│
▼
docker build
│
▼
Docker Image
│
docker run
│
▼
Docker Container
│
▼
Running Application

Understanding this flow is far more valuable than memorizing commands because every Docker project, whether it's a personal project or a production system follows this same journey.

But we're not done yet. Our application works, but there are still important questions to answer.

Why are some Docker Images over 1GB, while others are only a few hundred megabytes?

Why do some projects rebuild in 5 seconds, while others take 5 minutes?
How do production teams build Images that are smaller, faster, and more secure?

That's exactly what we'll explore in Part 4, where we'll dive into Docker layers, caching, .dockerignore, base Images, and practical techniques for optimizing Docker Images like experienced engineers.

See you in the next part.🚀

part 2 on understanding docker

Ladipo Samuel — Mon, 06 Jul 2026 17:53:03 +0000

Ladipo Samuel

Jul 6

Docker Explained (Part 2): Understanding Docker's Architecture, Images & Containers

#architecture #beginners #docker #tutorial

4 min read

Docker Explained (Part 2): Understanding Docker's Architecture, Images & Containers

Ladipo Samuel — Mon, 06 Jul 2026 17:29:51 +0000

One of the biggest mistakes people make when learning Docker is jumping straight into commands without understanding what's happening behind the scenes.
You'll see people type commands like:
docker run nginx

The application starts, everyone is happy, and they move on. But have you ever stopped to ask yourself: what actually happens after I press Enter?
It might seem like Docker is magically running your application, but it's actually following a simple process every single time.

Think of it like this:
You
│
▼
Docker Client
│
▼
Docker Engine
│
▼
Docker Hub (if needed)
│
▼
Docker Image
│
▼
Docker Container
│
▼
Running Application

Let's break this down.

Docker Client
The first component your command interacts with is the Docker Client.
Think of it as the messenger between you and Docker.

When you type: docker run nginx
The Docker Client doesn't create containers or download images. Its only responsibility is to receive your command and send it to the Docker Engine. A simple example is ordering food through an app. You place your order using the app, but the app doesn't prepare your meal. It simply sends your request to the restaurant: the Docker Client works exactly the same way.

Docker Engine
Once the Docker Client receives your command, it forwards it to the Docker Engine. If the Docker Client is the messenger, then Docker Engine is the brain. This is where the work happens.

The Docker Engine is responsible for:

Building Docker Images
Creating and starting Containers
Managing Docker Networks
Managing Docker Volumes
Pulling Images from Docker Registries

Without the Docker Engine, Docker simply cannot function. The first thing the Engine asks itself is: "Do I already have this image?"
If the answer is yes, Docker continues. If the answer is no, Docker needs somewhere to download it from. That's where Docker Hub comes in.

Docker Registry (Docker Hub)
A Docker Registry is simply a place where Docker Images are stored. The most popular registry is Docker Hub. Think of Docker Hub as GitHub but instead of hosting source code, it hosts Docker Images.
If Docker Engine can't find an image locally, it automatically reaches out to Docker Hub, downloads the image, stores it on your computer, and then continues the process. The nice thing is that Docker only downloads an image once.

The next time you run the same image, Docker simply uses the local copy, making the process much faster. Understanding this explains why your very first Docker command usually takes longer than every command after it.

Docker Images != Just a Blueprint
One of the most common explanations you'll hear is: "A Docker Image is a blueprint."
While that's true, it doesn't tell the whole story. A Docker Image is a complete, read-only package that contains everything your application needs to run.

That includes:

Your application code
Runtime (Python, Node.js, Java, etc.)
Dependencies
Required libraries
Configuration
Operating system packages

Think of it as a snapshot of your application at a particular point in time. Once an image is built, Docker treats it as immutable, meaning it doesn't change. If you modify your application, Docker doesn't update the existing image. Instead, it creates a completely new image.
At first, this might sound inefficient. In reality, it's one of Docker's biggest strengths. Because Images never change, every developer, testing environment, CI/CD pipeline, and production server runs exactly the same package.
That's one of the biggest reasons Docker became so popular: It removed the uncertainty of different environments.
Another important thing to know is that Images are not running. They simply exist, waiting to be used. You can think of an Image as a packaged application that's ready to be launched whenever you need it.

Docker Containers: Where Your Application Comes Alive
Here's something many beginners don't realize: docker never runs an Image directly. Instead, it creates a Container from that Image. A Container is simply the running instance of a Docker Image. Unlike Images, Containers are alive; they consume CPU; they use memory; they process requests; they respond to users.
They are the part that's actually executing your application. One of Docker's biggest advantages is that a single Image can create multiple Containers.

For example:

Every container starts from the exact same Image. That's why Docker delivers consistency. Instead of creating three different applications, Docker simply creates three running instances from the same package.
Containers are also designed to be temporary. If a container crashes, becomes corrupted, or is deleted, Docker doesn't expect you to repair it. You simply create another container from the original Image.
Since the Image never changed, the new Container behaves exactly like the previous one. This idea of treating containers as disposable is one of the biggest mindsets shifts Docker introduces. Instead of fixing running environments, you recreate them.

It's faster, cleaner and far more predictable.
Developer Tip: If there's one thing to remember from this section, let it be this:

Images are packages. Containers are running applications.
Docker never runs an Image directly; it always creates a Container from it.

Why Understanding These Concepts Matters Before Writing Your First Command
You may have noticed that we still haven't written a single Docker command and that's by design.
Learning Docker isn't about memorizing commands; it's about understanding what's happening every time you run one.
Once you understand how the Docker Client, Docker Engine, Docker Hub, Images, and Containers work together, Docker stops feeling complicated. The commands become logical because you know what's happening behind the scenes.

That's the purpose of this series: not just to teach you how to use Docker, but to help you understand why it works the way it does.
Now that we've built that foundation, it's time to put it into practice. In the next part, we'll build our first Docker Image and learn how a Dockerfile brings everything together.
.

What Is Lua AI? A Simple Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:55:51 +0000

Ladipo Samuel

Jul 1

What Is Lua AI? A Developer's Guide to Building AI Agents

#agents #ai #llm #programming

3 min read

A Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:54:27 +0000

Ladipo Samuel

Jul 1

What Is Lua AI? A Developer's Guide to Building AI Agents

#agents #ai #llm #programming

3 min read

What Is Lua AI? A Developer's Guide to Building AI Agents

Ladipo Samuel — Wed, 01 Jul 2026 13:54:04 +0000

There's no shortage of AI frameworks today. Every week, a new one promises to make building AI agents easier, so it's easy to dismiss another platform without looking into it. I thought the same until I spent some time going through Lua's documentation.

What stood out to me wasn't that Lua helps you build AI applications; a lot of tools already do that. It's where it tries to reduce the complexity.

When most developers think about building an AI agent, they immediately think about choosing an LLM, writing prompts, connecting APIs, managing conversations, handling tool calls, deploying the application, and making everything work together reliably. Before long, you realize you're spending more time building the infrastructure around the agent than the actual solution you're trying to create.

Lua takes a different approach. Instead of asking you to build all of that yourself, it lets you focus on the part that actually matters: the logic behind your application.

Imagine you're building a customer support assistant for your product. The AI shouldn't just answer questions; it should also be able to check an order, reset a password, create a support ticket, or fetch account information. Traditionally, you'd spend a good amount of time wiring all these pieces together. With Lua, you simply expose those capabilities as TypeScript functions, and the agent can intelligently decide when to use them. You're writing code you already know how to write, while Lua handles much of the AI orchestration behind the scenes.

As I explored further, I realized that the platform is built around just a few concepts, and once those click, everything else starts making sense.

The Agent is exactly what it sounds like: the brain of your application. It's where you define how your AI behaves, what it should know, and which capabilities it has access to.

Then there are Skills. I like to think of these as departments in a company. If your agent works for an e-commerce business, you might have one skill for customer support, another for payments, and another for inventory. Each skill groups together the tools related to that specific responsibility, making your agent easier to organize as it grows.

Inside every skill are Tools. These are simply TypeScript functions that perform real work. A tool might send an email, call your backend API, query a database, process a payment, or retrieve user information. If you've built APIs before, writing tools will probably feel very familiar because you're just writing functions that solve real problems.

Lua also supports webhooks and scheduled jobs, which means your agent doesn't only respond when someone sends it a message. It can react to external events, like a successful payment or a GitHub webhook, or even perform scheduled tasks automatically, such as sending reminders or generating daily reports.

One thing I genuinely appreciate is that Lua doesn't try to replace your existing backend. If you've already invested time building APIs or services, you don't have to throw them away. Your agent simply sits on top of what you've already built, giving users a more natural way to interact with your application.

Getting started is also surprisingly straightforward. You install the CLI, authenticate, create a project, define your agent, build your tools, test everything locally using the built-in chat environment, and deploy when you're ready. The workflow feels familiar, especially if you're already comfortable working with TypeScript projects.

The more I explored Lua, the more I realized that it's less about making AI "smarter" and more about making developers more productive. Instead of spending hours connecting different services and managing the plumbing around an AI application, you can spend that time building features users actually care about.

That's probably my biggest takeaway. Good developer tools don't just help you write code faster; they remove unnecessary complexity so you can focus on solving real problems. From what I've seen so far, that's exactly the direction Lua is trying to take.

I'm still exploring the platform, but if you're interested in building AI agents that can do more than answer questions, Lua is definitely worth checking out. I'm looking forward to building with it and sharing what I learn along the way.

if you want to understand docker, you should check this out

Ladipo Samuel — Mon, 29 Jun 2026 16:36:59 +0000

Ladipo Samuel

Jun 29

Docker Explained (Part 1): Understanding Docker Before Writing Your First Command

#beginners #docker #softwareengineering #tutorial

4 min read

if you want to understand docker and also want to follow along, you should check this out

Ladipo Samuel — Mon, 29 Jun 2026 16:24:37 +0000

Ladipo Samuel

Jun 29

Docker Explained (Part 1): Understanding Docker Before Writing Your First Command

#beginners #docker #softwareengineering #tutorial

4 min read

Docker Explained (Part 1): Understanding Docker Before Writing Your First Command

Ladipo Samuel — Mon, 29 Jun 2026 16:16:40 +0000

Most Docker tutorials start by asking you to install Docker and run your first container. I don't think that's the best way to learn.

If you've ever tried learning a new technology, you've probably experienced this before. You copy commands from a tutorial, everything works, but if someone asks you why it works, you're stuck. You know the syntax, but you don't understand the concept.

Docker deserves better than that.

Before writing a single command, it's important to understand the problem Docker was built to solve. Once you understand the problem, every Docker command starts making sense.

Why Docker Changed Software Engineering

Software engineering has always been about solving problems, but one problem managed to frustrate developers for years.

Imagine you spend days building an application. You install all the required libraries, configure your environment, fix dependency issues, and finally everything works perfectly. You push your code to GitHub, feeling accomplished.

A few minutes later, your teammate clones the project.

They install the dependencies.
Run the exact same command.
And everything breaks.

At first, you think they made a mistake. Then another teammate tries. Same result!!!!

Eventually someone says the sentence almost every developer has heard at least once:

"It works on my machine."

That sentence became a running joke in software engineering, but behind the joke was a real problem.

Every developer's computer is different; one person uses Windows; another uses macOS; someone else develops on Linux; one developer has Python 3.12 installed; another still has Python 3.10; someone upgraded Node.js yesterday; sllomeone else forgot to install PostgreSQL entirely.

Even when everyone follows the same documentation, tiny differences between machines can produce completely different results. The application itself isn't always the problem—the environment is.

As projects became larger and teams became more distributed, this problem became even more expensive. Developers spent hours debugging issues that had nothing to do with their code. Deployments became unpredictable, onboarding new engineers took longer, and production environments often behaved differently from development machines.

Docker didn't just introduce another development tool.

It introduced consistency.

Instead of asking every developer to manually recreate the same environment, Docker packages everything an application needs to run into a portable, isolated environment. Whether it's running on your laptop, your teammate's computer, a CI pipeline, or a production server, the application behaves exactly the same.

That simple idea changed how modern software is built, tested, deployed, and maintained.

What Docker Actually Is?

You'll often hear Docker described as "a containerization platform."

That's technically correct.

It's also not particularly helpful if you're learning Docker for the first time.

Here's a much simpler way to think about it.

Imagine you're speaking at a conference.

Instead of carrying your script in one place, your slides somewhere else, your notes in another folder, and your examples on a flash drive, you put everything into one notebook.

Wherever you go, everything you need goes with you.

Docker does something very similar.

It packages your application together with everything it needs to run.

That includes:

Your application code
The runtime (like Node.js or Python)
Libraries and dependencies
Environment configuration
System packages required by the application

Instead of depending on whatever already exists on another computer, Docker brings its own environment along.

That's why the same application behaves consistently whether it's running on your machine, your teammate's laptop, or a production server.

Docker isn't replacing your application.

It's making sure your application always has everything it needs to run successfully.

Containers Explained Properly

The word container is probably the first Docker term you'll hear, and it's also one of the most misunderstood. Many tutorials describe a container as "a lightweight virtual machine."

While that comparison helps initially, it's not actually what a container is. A container is simply an isolated environment where your application runs.

Think of it as giving your application its own workspace.

Inside that workspace are all the tools your application needs, but it's isolated from other applications running on the same computer.

That isolation is important.

If one application requires Python 3.12 and another still depends on Python 3.10, they can both run on the same machine without interfering with each other because each container carries its own environment.

Containers are also designed to be temporary. You don't usually modify a running container forever. Instead, if your application changes, you create a new container from an updated image. This makes deployments predictable because every new container starts from the same clean state.

This idea of treating containers as disposable is one of the biggest mindset shifts Docker introduces.

Docker vs Virtual Machines

One of the first comparisons people make is between Docker and Virtual Machines. They solve similar problems, but they solve them very differently.

A Virtual Machine creates an entirely new computer inside your computer.
It includes its own operating system, its own kernel, its own system resources, and everything required to behave like a completely separate machine.

That makes Virtual Machines incredibly powerful, but also heavier. They consume more storage, take longer to start, and require more system resources.

Docker containers take a different approach.

Instead of creating a completely new operating system, containers share the host operating system's kernel while keeping applications isolated from one another.

The result is a much lighter environment that starts in seconds, uses fewer resources, and is easier to distribute.

A simple way to picture it is this:

A Virtual Machine is like building a completely separate house on its own piece of land.
A Docker Container is like living in your own apartment inside a modern building. You have your own private space, but some infrastructure is shared, making it far more efficient.

That's one of the reasons Docker became so popular. Developers could run multiple isolated applications on the same machine without the overhead of multiple operating systems.

At this point, you should understand why Docker exists, what problem it solves, what a container really is, and why containers became the preferred approach over traditional Virtual Machines.

In Part 2, we'll go one level deeper by exploring Docker's architecture, understanding Images and Containers in depth, and explaining one of the concepts that confuses almost every beginner: what's the real difference between a Docker Image and a Docker Container?

Backend Concepts I Understand Better Because of Fintech

Ladipo Samuel — Sun, 21 Jun 2026 16:42:06 +0000

One day, I walked into a supermarket to buy a few things. I paid with my card, but the POS machine froze. The cashier looked at me and said, "Sorry, please try again."

Immediately, one thought came to mind:

"What if the first transaction actually went through?"

Most people would simply retry and hope for the best. But after spending more time understanding fintech systems, I realized this situation has a name. It's one of the reasons idempotency exists.

In simple terms, idempotency ensures that whether a transfer request arrives once or five times, the result remains the same. Duplicate payments are far more expensive than failed payments. That small experience reminded me that some of the concepts we learn as backend engineers aren't just interview topics. They're solving real problems around us every day.

One thing I appreciate about fintech is that it changed the way I think about software engineering. It forced me to look beyond APIs and databases and understand what really happens when systems start dealing with money, reliability, and trust.

For example, I used to think APIs were simply endpoints that returned JSON. Fintech taught me that APIs are like contracts. Once other systems depend on them, changing a field carelessly or returning inconsistent responses can break integrations and affect real users.

Databases are another thing I appreciate much more now. Everything works when there are a few hundred rows. But when transactions become millions, indexes, transactions, and query optimization suddenly become the difference between milliseconds and seconds. Many performance issues aren't solved by adding more servers. They're solved by understanding your queries better.

Then there's concurrency. Imagine two withdrawal requests hitting the server at almost the same time. Without proper locking or transaction management, both requests might read the same balance and approve the withdrawal. Race conditions sound like textbook problems until they start affecting money.

Caching also became much more interesting to me. Everyone loves Redis because it's fast. But fintech taught me that speed isn't everything. Stale data can be dangerous. Sometimes correctness is more important than performance. The hard problem isn't adding a cache. It's knowing when cached data should no longer be trusted.

Authentication and authorization are concepts I understand differently now. Knowing who a user is and knowing what they are allowed to do are completely different problems. When money is involved, permissions matter. A user being logged in shouldn't automatically mean they can perform every operation.

Queues changed the way I think about requests. Early on, I wanted everything to happen immediately. Send emails, generate receipts, notify users, update analytics, all inside one request. Fintech made me appreciate asynchronous processing. Just because something needs to happen doesn't mean it needs to happen right now.

Then, we have reliability. At times, Providers fail, Networks timeout, Webhooks arrive late and even systems crash. Production systems aren't systems that never fail. They're systems that know how to recover. Retries, circuit breakers, and graceful degradation suddenly become necessities rather than nice-to-have features.

Security also stopped feeling like a separate concern. SQL injection, hardcoded secrets, poor validation, weak password handling—these things aren't tasks for later. They should be second nature. In fintech, security is a responsibility, not just a feature.

Observability is probably one of the most underrated things I appreciate now. Logs, metrics, traces, alerts—these things felt unnecessary when I first started. But if a transfer fails at 2 AM, how do you know? If latency increases, where do you start? Without observability, debugging becomes guessing, and guessing isn't a strategy.

Another concept I find fascinating is reconciliation. Your system says a transfer failed. The bank says it succeeded. Which one is right? Distributed systems don't always agree. Webhooks get missed. Networks fail. Reconciliation exists because eventually, someone has to answer the question, "What actually happened?"

Perhaps one of my favorite concepts is CAP theorem. Before learning more about distributed systems, I thought software engineering was about making systems fast, available, and always correct. CAP taught me that trade-offs exist. During network failures, you often choose between consistency and availability. Social media platforms can tolerate some inconsistency. Financial systems are much less forgiving. Sometimes delaying a response is better than showing the wrong balance.

The more I learn about fintech, the more I realize how important backend engineering is. It's about building trust. Because in fintech, bugs aren't just bugs. Sometimes they're money.

Of course, this is just scratching the surface. We touched on more than 10 concepts here, and each of them deserves an article (or even a book) of its own. Understanding them deeply will make you a better engineer, not just in interviews, but when building real systems. I'll also be breaking down some of these concepts in the videos I'll be starting this week. I'd love to hear your thoughts and know which concepts you'd like me to dive deeper into.

Information Is Not Enough

Ladipo Samuel — Sun, 14 Jun 2026 15:12:23 +0000

Last week, I wrote purely technical content, then I had a conversation with one of the people who reads my work. From that conversation, I started thinking: if I keep sharing technical knowledge but there is still a gap between knowing and doing, how does that knowledge become useful? An article is just information. There are still a few steps between reading something and actually putting it into action.

After reading articles, watching videos, or gaining insights, what you have received is information. Information can be extremely valuable, but it can also be completely useless if it is never applied. The next step is understanding. After reading something, make sure you truly understand it. If there are gaps, ask questions, leave comments, reach out to the author, or discuss it with others. Don't rush to consume the next piece of content without understanding the one in front of you.

Once understanding comes conviction. For example, imagine you read an article about becoming a senior engineer. Don't immediately tell yourself that you can't become one until you've spent a certain number of years in the industry. Instead, convince yourself that it is possible. Start understanding how senior engineers think, communicate, solve problems, and take ownership. Gradually, your mindset begins to shift.

However, conviction alone is not enough. Conviction can fade. Think about someone who goes to the gym consistently and starts building muscle. If they stop completely, those gains gradually disappear. Conviction works in a similar way. It gets you started, but something stronger is required to sustain it. That thing is belief.

Your belief system is one of the most important things you will ever develop. Conviction tells you that something is possible, belief makes you act on it. If you believe you can build a startup, you begin forming a team, making plans, learning the necessary skills, and taking action. Over time, what once seemed impossible starts becoming reality.

Then comes the final stage: lifestyle. Once something becomes part of your lifestyle, it becomes natural. You no longer force yourself to do it, it becomes who you are. Information, understanding, conviction, belief, lifestyle. When these stages work together, growth becomes inevitable.

One reason many people give up is because they have unknowingly built the wrong lifestyle. Starting things and quitting becomes normal. Giving up becomes familiar. Over time, that pattern starts to define them. The good news is that mindsets can be rewired.

This article is information. Take the time to understand it. If you have questions, ask them. Once you understand it, convince yourself that you are capable of more than you currently believe. Turn that conviction into belief and let that belief shape your lifestyle.

I'll use myself as an example. Over the past few years, I've ventured into programming, media management, community management, technical writing, public speaking, robotics, and even leading communications for an entire department. None of these happened overnight. They started as information, became understanding, turned into conviction, grew into belief, and eventually became part of my lifestyle.

You can do more than you think. Sometimes, the biggest thing you need to change is not your skill set; it's your mindset.