Technical debt accelerates your growth. As financial debt, it allows you to move faster. It accumulates over time and can cripple your business if not paid back. None of this is news, so why is managing technical debt in practice still hard? The answer is communication.

The broken discussion

I was fortunate enough to work on multiple greenfield products in my career and could observe how technical debt grows. In all projects, technical debt was necessary to keep moving fast. In all projects, we reached a point where the effects of technical debt started slowing us down. In all projects, getting buy-in to work on technical debt was hard because the business needed to keep moving, and working on technical debt was not seen as a value-add.

The pattern is usually something like this:

Developers: “We have so much technical debt, it’s slowing us down.”
Business: “Ok, what is the issue?”
Developers: “We need to migrate A to B and refactor C, because the code is really bad.”
Business: “I hear you. Unfortunately, we have this deadline for our new feature coming up, and we really need to deliver this.”
Developers: “Ok…”

The development goes on, and the feature will be delivered. It took longer than expected, but there could be a variety of reasons for that - who knows? The business feels right about its decision to push back on technical debt projects because, after all, the feature was delivered, and the customer is happy. The next development cycle starts, and the conversation either starts over or stops, because the developers have resigned.

Closing the gap

The truth is that most development teams have a hard time selling why they need to work on technical debt and how it is hurting the business. Measuring the effects of technical debt is difficult. However, unless you can clearly articulate how working on a technical debt project affects and benefits the business, you force non-technical people to trust you blindly.

I like this Dilbert illustration because it highlights a common pattern in tech companies. The manager does not understand technology enough to evaluate the problem. The developer is not able to communicate their problem in a way that helps their manager to make a decision. The result is a communication and knowledge gap that leaves both parties frustrated.

If we want to solve technical debt and keep our business moving, we need to close this gap.

Communicate, showcase, establish trust

As developers, we need to put ourselves into the shoes of our managers. Unless a project does not contribute to the company’s success, there is no economic reason to prioritize it. Only if we can explain and measure the impact of our project will it compare to the new shiny feature that promises to increase conversion rates by 10% or drive €20k in monthly recurring revenue. So, before proposing a technical debt project, make sure you know how it negatively impacts the business, and how it positively impacts it after delivery. An example of such an assessment could be:

“The team has to spend 2-3 hours every week debugging issues related to our outdated data sync service. By modernizing the service, we not only reduce that overhead but also cut our customer support tickets by 15% and unblock future feature development in that area. The ROI becomes clear when you compare the one-time effort against recurring time savings and faster delivery for upcoming roadmap items.”

Now, compare this to our Dilbert cartoon. While the technical details of the data sync service are hidden, it is immediately clear to everyone how this change impacts the business. If it would require too much technical expertise to understand the impact, the chances increase that decision makers struggle to assess it. So, it is your job as a developer to translate and help non-technical stakeholders understand the impact.

Finally, once your project is done, make sure to celebrate your success and showcase how the project improved the situation for the business. Not only is celebrating success important for your team, but it will also establish trust with your colleagues. You will be seen both as a facilitator and a technical expert.

• Juniors are slowing down senior engineers

• Senior engineers are more productive due to GenAI

• A lot of the traditional work juniors do is now done by AI

Let’s break these assumptions down.

Juniors are slowing down senior engineers

There’s some truth here. Mentoring takes time. Onboarding, reviewing PRs, and explaining architectural decisions all pull senior engineers away from their own deliverables. In high-pressure environments, this can feel like a drag. However, this view ignores the long-term benefits of growing talent internally.

Juniors bring fresh perspectives. Their questions often surface hidden assumptions. Their eagerness to explore new technologies—sometimes too early—can be annoying but occasionally unlocks new perspectives and potential breakthroughs. Additionally, teaching others has a funny way of exposing your own knowledge gaps and reinforcing your expertise. Pair programming, for instance, is not just about mentorship— it’s a form of active debugging for your thinking. If used correctly, this can have a compounding effect on your overall team’s productivity.

Seniors are more productive with GenAI

Senior engineers can indeed use GenAI tools like LLMs more effectively. They understand how to craft better prompts, set proper context, and—most importantly—review the output critically. According to the “Anthropic Economic Index”, GenAI has increased productivity across many industries, but especially in software engineering, where the benefits compound with experience.2 However, productivity gains don’t translate into needing fewer people; they usually mean more gets built faster. More features, more iterations, more complexity. More maintenance.

The bottleneck shifts—not disappears. We still need experienced engineers to review, debug, and steer the outputs of AI. As the systems we build grow more complex, the demand for judgment, context, and architectural thinking grows with it. In fact, as GenAI becomes more widespread, the need for subject-matter experts increases. Or, as IBM famously stated in the 70s:

A computer can never be held accountable, therefore a computer must never make a management decision.3

The work juniors used to do is now done by AI

There is some truth in this. A lot of boilerplate, CRUD logic, or basic scripting can now be generated by AI. But real-world systems aren’t just code, they’re living ecosystems that require debugging, tuning, context, and care. AI may handle repetitive tasks, but it doesn’t replace the need for humans to understand why something is built the way it is.

The real danger here is not that GenAI replaces junior engineers, it’s that we stop giving people the chance to become senior engineers in the future. If we stop hiring juniors today, who will be our seniors in five years?

Conclusion

The current market favors senior engineers, but not because juniors have become irrelevant. It’s a response to short-term pressures and the allure of quick productivity wins. But, organizations that fail to invest in junior talent risk long-term stagnation. Innovation doesn't just come from expertise, it comes from curiosity, naivety, and ambitious people with something to prove.

GenAI is a tool. A powerful one. But tools don’t build great software — teams do, and they need all levels of experience.

These are my learnings and tips for everyone considering going this path (especially in Germany).

Spoiler: I won't advise you to drop out of college and get into tech like so many people advocate. If you are twenty something most likely you should finish your studies or at least join a bootcamp, if this is possible for you.

Find a sponsor

No, not that kind of sponsor that gives you money and baseball caps. A sponsor is a person that believes in you and supports you. In Germany, getting into a company without a degree or anything to show off is near impossible. I was lucky enough to have a friend who offered me an internship position in his startup team, which was originally not even about software development. You will need someone who believes in you and supports you to a) get into the job and b) pull you through when you start struggling and questioning yourself. To get off the ground you might want to consider doing some work for little or no money to show off your potential.

Work on your social skills and learn to adapt

You can only do so much to learn and teach yourself about software development. In my experience, the best software developers were those which were also fit to work in a team. You might be surprised, but if you support others and help them reach their goals, chances are high, they will pay you back with their help. There will be many questions and sometimes you simple might not know what search for in Google. Care for your peers and they will care for you.

At some point, some of your peers will leave the company, you get a new boss or just a new team member. Every time one of those events happen, your personal situation changes with it. You will have a hard time, if you are not able to adapt to new situations, so learn to embrace change and watch out for new opportunities for yourself.

Develop a constant learning habit

If you take anything from this, it should probably be this. Software developers are knowledge workers. Every developer needs to learn new languages, frameworks or design patterns at some point. If you start with little to no knowledge in a team of peers that have some kind of education in software development, you will need to outrank them in your ability to learn something new. This seems hard (and it is), but if you manage to do it, it has the nice side effect that you will likely keep this habit throughout your career.

Just to be clear: this does not mean to work 12+ hours a day, but to improve the way you learn and work. There is a whole industry around productivity. Look out for ways to improve the quality of your work rather than the pure amount of time you work. Working 40 hours a week in front of a screen is exhausting. I have done the same mistake and I have seen many peers do it: working 60+ hours a week, because you just want to finish that feature or fix that bug. Get some sleep and take breaks and fixing that bug, which would have taken you four hours after a hard working day, might just be fixed in a couple of minutes the next morning.

Favour fundamentals over frameworks

Especially at the beginning of your journey the amount of frameworks, languages and design patterns seems overwhelming and staggering. While you probably will need to learn some framework for your job, focus your studies on fundamental concepts of software development. I was working for a company doing mainly backend web development, so I had to teach myself everything from HTTP over databases to a suitable language like Java. There are many great resources out there, but if you are trying to get into web development, I recommend taking a look at these developer roadmaps or your welcome to reach out to me. You will have a much easier time following a structured learning path than I had blindly stumbling from one topic to another and hammering my peers with questions.

T-shaped skills

As described above, you should pick a niche in software development. It is easy to jump from one broad topic to the other, because there is so much out there in surely a real developer knows everything about them, don't they?

They don't.

As developers we all specialise in something and this is important. If you are looking for jobs, you want to differentiate yourself from others and most companies have specific requirements for the people they hire. There is a well-known concept among developers, which is called the T-shaped developer. It is based on the notion to specialise in one topic and then develop broader understanding of other topics around that.

Take responsibility and get shit done

Even though the mantra of developing a "get things done"-attitude seems kind of obsolete, it is not. If you take responsibility and commit to goals with your team lead, you do not only develop a better feeling to estimate the time of your work, you actually learn to "own" your work. There are only few things more rewarding than working on something that is actually yours. This can lift you through hard days when you may lack motivation and it will show your boss and peers that you actually care and they can rely on you.

To make this happen you will also need to let some things go and learn to prioritise. From my experience, there is no need for a super framework or tool to organise your work. I use very simple and effective methods:

• Define your goals for the next six months

• Choose a simple tool to manage your day to day tasks (I personally prefer KanBan boards)

• Define your daily tasks on the evening before, starting with the most important to the least important.

• Every morning, check if your tasks today are in line with your long term goals. Try to eliminate everything that is not.

• Be consistent with your daily tasks but be flexible with goals, if new opportunities arise.

The hard part here is to really be consistent in prioritising the right tasks and then sticking to them. Defining my tasks on the evening before is probably the most valuable productivity hack. If you start planning your day in the morning, you are tempted to avoid difficult tasks.

Promote yourself

One thing many people feel uncomfortable with, including me, is promoting themselves. As a software developer without a degree you will need to do this at least to some extent. You do not need to be a Twitter influencer with 100k followers, but you should make sure to always have an up-to-date LinkedIn profile , a GitHub profile with some projects that showcase your skills and a CV. I do like Twitter as well, since you can easily connect with people from the tech industry, but it has not provided any value in terms of getting a new job or project so far.

Setting up a small portfolio or blog like this one can also be beneficial. First, you have one platform that you own to link to all your social media accounts and promote yourself. Second, blogging about what you learn and do does not only help with promoting, but also with understanding more deeply what you write about. I am not super consistent with blogging so far, but every time I do, I am surprised by how much value I get out of it for myself. Third, building a blog can be a perfect sample project to showcase your engineering skills.

Conclusion

As I mentioned in the beginning, I would not advise you to take this path, if you have the possibility, time and money to get a proper education in computer science. Having a degree and something that proves your skills will make your life much easier and less stressful. But if you do not have that for any reason, it can be done and the job as a software developer can be very rewarding one, not just financially.

If you are considering a career in software development without a degree, I would love to know more about where you are at and I hope my learnings were helpful. Feel free to reach out to me.

Subscribe now

best experience possible. While there are many people who offer usability tests for user-facing products, API usability testing is a bit more tricky, since

your customers are developers.

In this blog post, I will provide you with a guide on how you can get started with API usability testing without burning through your valuable startup budget. We

will look at when to test, who to test and eight simple steps to organize your testing.

The Timing

The best time to start usability testing is right at the beginning of your project. If you have not done that, the second best time is now.

It is true. Do not fall into the trap of testing your APIs for usability shortly before a release. Make it part of your development process early on and gather feedback as early as possible, so you can iterate on that feedback and change your product while it is easy to do so.

If you are working in a somehow agile development process, which I will assume at this point, your development cycle will probably look something like this.

The best time to do your usability testing is after you have designed your product or in our case, the API.

With modern tools like Swagger and the OpenAPI standard you can easily generate Mock APIs which can then be used for usability testing with real users or your team.

If you do not have mock APIs and prefer to develop first, usability tests can also be done after the Development stage.

The Users

Developers come in different forms and shapes. They vary in their roles and skill sets, but also in the way they perceive content. If you can, try to determine which roles and skills your customers have and derive **user personas** from it. This will help you to view your APIs from your customers perspective and find suitable candidates for a usability test.

We will not go into detail on how to define user personas, but I recommend watching this short video by Pluralsight to get an idea.

In reality, we often do not know the developers who will integrate our APIs when we start developing a new API. Therefore, it is helpful to assume a broad variety of different skill sets and find users of different backgrounds. As we do not want to hire an agency and spend as little money as possible on usability testing, there are mainly two easy options:

• Freelance developer platforms
  Upwork, fiverr, etc.. Look out for developers of various backgrounds and hire them for a 30-60 minute usability test. We will go into detail on how to do that in the next section.

• Onboarding of new developers
  When a new developer joins your team, he can be tasked to make a usability test of the API. This has the nice side effect that they get to know the product/API and a unique view of how users perceive it.

API Usability Testing in 8 Steps

To learn as much as possible from our tests, we need a bit of preparation. These are eight simple steps, to get everything out of your usability tests:

1. Define an explicit task on what your tester is supposed to test.

2. Give as little information as possible, but as much as needed to get started with the assigned task.

3. Find a way to observe the user when using your API. Nowadays, where in-person meetings are less common, you can make use of screen sharing/recording tools.

4. Make sure, the user speaks out loud while testing your product, explaining what he or she is thinking at each step.

5. Provide a possibility for questions, if the user gets stuck at a certain point of the process and does not find any other option than asking for help.

6. Create a detailed report on the observations during the test.

7. Derive learnings and tasks from your observations.

8. Share your learnings and observations with your team.

One other way to get started with usability testing is to do a Hackathon based on your API. This has the positive side effect that you do not only learn about the usability but also potential use cases of your API.

Conclusion

API usability testing does not have to be an expensive and tedious task. Getting started with it will immediately improve your understanding of your own product and how users perceive it. You will be astonished by how much your personal conceptions may differ from a user's fresh view on your API and your customers will thank you for providing the best user experience.

Subscribe now

Check out this well-written blog series of NGINX, if you want to get deeper into microservices architecture.

Flexibility leads to complexity

Don't get me wrong. The microservices pattern takes away a lot of complexity introduced by highly cohesive and monolithic systems, but it introduces a new kind of complexity. The fact that teams are flexible in the way they build their microservices - even if you have certain guidelines in place - makes it more difficult for your clients to access your system. They possibly need to

- talk with all the different services

- understand which service provides the data they need

- communicate via different protocols.

In terms of user experience, this is not optimal and might lead to frustration on the client side. The complexity increases the learning curve of your system.

A simplified overview of clients A,B and C which require different data from individual services X,Y, and Z of a microservice architecture. All are accessible via different protocols: REST, GraphQL and gRPC.

The picture above illustrates such a microservice architecture. Even if your microservices do not use different communication protocols such as in this example: Talking to multiple hosts might still require multiple ways of authentication, understanding different styles of API design, etc..

An API gateway as the single entry point

An API gateway might help you with this complexity. As the term "gateway" implies, the main purpose of an API gateway is to be the single entry point for your microservice architecture. It is build on top of your individual services and routes requests of clients to these services. It does not contain or know of any business or domain logic of the individual services.

An API gateway sitting between your microservices and the clients who want to access these services. The API gateway provides a unified interface to the clients and hides implementation details of the services X, Y, and Z.

Upsides of API gateways

As the illustration shows, an API gateway makes it possible to easily hide implementation details of our microservice architecture and unify the external interface. This enables clients to have a single point of entry to your system, thus, making it more accessible. Besides these UX improvements, the API gateway can be used to centralize and handle topics such as

- authentication

- permission handling

- API security

- policies (rate limits, allow-listing, etc.)

This enables the individual microservice teams to concentrate on the core business/domain logic of their service and improves development speed. The API gateway might further support your system by providing extensive (access) logging and collecting performance as well as business related metrics of your clients.

Downsides of API gateways

Introducing a new part in your architecture always comes with certain challenges and so does an API gateway. The API gateway is another piece of software in our system that has to be developed, deployed and maintained. While this was also one of the upsides listed above, a single point of entry to our application might also become a bottleneck in two different ways.

First, it has to be highly scalable. Since it is another layer between every request of the client and our microservices, it needs to have as little impact on the request latency as possible. Second, it can slow down development, since every microservice has to be exposed via the gateway.

The API composition pattern

So far, we have introduced the API gateway simply to route each request of a client to a microservice and back. With microservices being self-contained and the owner of their domain and data models, they often fail the expectations of clients on how to consume the data. Clients might want to query data of multiple sub-domains at the same time or just a small portion of the data a single microservice offers. To fit these needs, the API composition pattern can be applied.

Overview of an API gateway with API composition. Composition 1 composes data of service X and Y to a single resource, while Composition 2 composes data of service Y and Z to a single resource.

Even though the API composition now manipulates the payloads of one or multiple microservice(s), an API composition still remains free of any domain or business logic. Each composition could also be defined as an aggregate of the microservices behind the API gateway to fit the clients need and improve the developer experience.

This pattern introduces some more advantages. With API composition in place, we suddenly can

- make up for bad design decisions and apply a new shiny interface

- hide legacy systems and replace these whenever we have the time for it

- enable specialists for API design and developer experience to create a consistent design of the overall API.

On the other hand, as with the API gateway itself, we introduce another layer in our overall system. Development teams have to be careful that API composition does not evolve to a replacement for good API design of the individual microservices or mixing up the domain logic and models within the API gateway.

Conclusion

API gateways and API composition are a useful tool to reduce complexity of microservice architectures. They can help with handling access and monitoring of the overall system, as well as enabling clients to request data as they expect it. Nevertheless, one has to be careful when introducing a new layer to a system, since it inevitably leads to more dependencies in the development chain.

What do you think of this approach? Have you faced similar challenges? If yes, how did you solve them?

If you have no experience and you want to get started with this technology, you have come to the right place. You will get a succinct overview of the topic and some best practices on how to leverage Docker for your own projects or your projects at work.In this part, we will learn a short definition of the technology and we will dive into more detail on the basic elements of Docker: images and containers. To get some immediate hands-on experience, we will build our own docker image and spin up containers from it. 

Contents

• What is Docker?

• Images

• Containerizing your application

• Containers

• Best Practices

What is Docker?

You probably know about the concept of virtual machines (VMs). VMs are simulating operating systems with system-specific pre-installed software. They are managed by a hypervisor (virtual machine monitor) which manages and shares hardware for multiple VMs on a single physical machine. VMs need a big amount of memory and computing power and therefore are expensive to setup and maintain. Furthermore, moving VM workloads between hypervisors and cloud platforms is not as easy and intuitive as it could be. 

In contrary,Docker or other containerization technologies are running on the host operating system (OS). Containers contain your application code, dependencies, your runtime system and system libraries, settings and tools. That is it. Nothing more than the bare minimum of what you need to run your application. They do not need a full-blown OS to setup, instead they free up a lot of CPU, RAM and storage for running applications. As long as a host has the Docker Engine running, you can easily port Docker containers from one host to another. You will never have to worry, what kind of server your application is running on or how to ship between hypervisors. You simply pick or create your own docker image and focus on developing your software.

This image visualisation is copied from the Docker website and illustrates the difference:

Source: https://www.docker.com/resources/what-container#/package_software

Images

As a developer, you should be familiar with the concept of object-oriented programming. In a way, you can think of images as classes and containers as objects. Images are your templates to build containers on.

To start out, you usually pull an image from a docker registry like Docker Hub. Images are made of one or multiple stacked read-only layers. The only writable layer is build by the container as the illustration below shows. We will discuss what exactly a layer is in a minute.

Source: https://docs.docker.com/v17.09/engine/userguide/storagedriver/imagesandcontainers/#container-and-layers

Getting started

So, to dive deeper, let’s start and play around with Docker. If you have not done so already, go here and install the Docker Engine on your host. When you’re done, open your command line tool and type:

docker pull node:latest

Congratulations! You have pulled your first Docker image. Let’s look at what happened here:

The docker pull command initiates a call to a Docker registry (the default is  Docker Hub) to pull an image with the name node and the tag latest. A Docker registry serves as a storage server for docker images. From the command above, we can deduce the following syntax:

docker pull <name>:<tag> 

The name specifies the name of the image and the tag specifies the version of a particular image. (Attention: Image tags are mutable. To make sure, you can rely on an image version, you might want to consider image digests). 

In this case, we pulled an image with a pre-installed version of Node.js. Your output should look like this

Working with images

Let’s have a closer look at the image we just pulled. Execute the following command in your terminal:

docker images

This will return a list of all your images like this

You can see the name of the image, the tag we specified before, a unique image id, a timestamp when it was created and the size of the image. To further inspect the image execute:

docker inspect node:latest

Here you can see a lot of metadata for the image like the size of the image, the different layers, the underlying OS and much more. We will come back to the inspect command in the the Best Practices section.

Now, let's remove the image with:

docker rmi node:latest

This way, we removed the image and the respective layers of the image from our Docker host.

Note that all these commands can be executed with the image id, but they will only work, as long as no container based on the image is running. To understand how images are built and why they are structured into layers, we will build a simple Node.js server, containerize it and spin up our first containers from it.

Containerizing your application

To keep things simple, I set up a simple Node.js server. You can find the source code here. For this example, you do not need any experience with Node.js. You simply need to have node and the node package manager npm installed and follow along the tutorial. You can install both as described here.

Clone the repository, cd into the repository’s folder and execute the following commands to build the application and install all dependencies.

npm install && npm run build

Now, let’s run the server with

npm start

Now, our server should be running. If you navigate your browser to http://localhost:8080, you should see a "Hello World of Docker" message.

Great! Now, let’s see how we can make an image of this application and spin up a container of it. Remember, our image is our template for all our containers and it should do only one thing: run our application.

In the project repository, create a new file and name it Dockerfile. In there, copy the following code:

FROM node:latest
WORKDIR app
COPY . .
RUN npm install && npm run build
EXPOSE 8080
ENTRYPOINT ["npm", "start"]

To build your image, execute docker build -t my-first-docker . in the same directory as your Dockerfile. You should see the different steps building. When we execute docker images, we can see our newly created image:

There are two kind of instructions in a Dockerfile. Those, which add data and therefore create a new layer and those which simply add metadata to the image. I will walk you through those steps and explain in detail what they are doing.

The FROM command specifies a base image, on which we want to build our image. In our case, we use the latest image from the node repository. This image has Node.js pre-installed since we want to build a Node.js server. In general, it is recommended to use base images from official repositories since you do not have to worry about installing Node.js properly. 

WORKDIR creates a working directory for your application. It is seen as best practice, because we avoid unreadable syntax like cd .. && do foo. The working directory will be your default directory in which the following RUN, COPY, etc. commands will be executed. Our working directory will be app.

COPY copies files from your project directory into the Docker image. For now, we will just copy all files in our working directory, even though this is not considered best practice. Notice: this is the first time we are adding data to our image. Thus, this instruction creates a new layer in your image. Each instruction of this type creates its own layer.

RUN executes a command in the default shell of the image. Since it adds data, it creates another layer. In our case, we add data by installing all dependencies with npm install and building the compiled files with npm run build.

EXPOSE exposes a specified network port for our container.

ENTRYPOINT sets a default shell command, which will we be executed when we start a container and run it. This command makes the Docker image an executable when run. We could also use the CMD instruction to achieve this behaviour. Nevertheless, it is recommended to set ENTRYPOINT whenever you want your users to use this image in a specific way. If you want to give your users more flexibility, choose CMD, because it can be overwritten more easily.

Containers

As explained, containers are the runtime counterpart to images. Containers accept an image and a command as arguments. The image is used to run the container and the command specifies the application, the container should run. Let’s use our example to elaborate on this. Run:

docker run -it my-first-docker

And just like that, you have your first docker container running! The run command starts a container. You pass an image as an argument and with the -it flag you will attach your shell to the container’s shell. To exit the container, you can simply press CRTL-C on Linux/Win or CMD-C on MacOS.

Now, we do not want to attach our shell every time we build a Docker container. In these cases, you can add the -d flag to run a daemon of the container. We can try it like this:

docker run -d -p 8080:8080 my-first-docker

Your docker container is now started in the background. At the same time, we mapped the exposed port 8080 of the container to our local port 8080.  Run:

docker ps

As you can see, our docker container is running. Docker assigns a unique CONTAINER ID to every container. We also can see the command, which is executed as specified in our ENTRYPOINT command in the image, the mapped ports and a randomly assigned name for the container (can be specified manually with the —name flag). If you move back to your browser and navigate to http://localhost:8080, you should see your “Welcome to Docker World” message again, since all traffic on our local port 8080 is routed to our running docker container.

To stop the container, simply use:

docker stop <CONTAINER ID>

Now that our container is stopped, we can see the running and stopped containers with:

docker ps -a

You can see the container still exists. To remove our container completely, we can use a final:

docker rm <CONTAINER ID>

Conclusion

For now, this should be everything to get started with Docker and experiment a bit on your own. We learned, why Docker is such a great alternative to VMs, what images and containers  are, how we can containerize our own app and how to interact with our running containers. Hopefully, this has helped you to dive into this amazing technology.

In the next part, we will have a look at some general best practices when working with Docker, especially on how to build your images and set up your Dockerfiles.

Stay tuned!

Subscribe now