Introduction
About 100 days ago, I reached out to my mentor because I was confused about my career and wasn't really sure what direction I was heading in.
I was already learning software engineering, building projects, applying for opportunities, and trying to figure out how to move forward. But I felt like I was doing all of that quietly, and I wasn't sure if anyone was even seeing the work I was putting in.
My mentor suggested that I start the #100DaysOfCode challenge, with the goal of increasing my visibility, sharing what I was learning, and hopefully putting myself in a position where opportunities could find me.
At first, I wasn't completely sure what I was getting myself into.
But I decided to try.
My name is Onatade Abdulmajeed Adeyincka. I'm a software engineer and a backend-focused full-stack developer from Nigeria, primarily working with Java, Spring Boot, JavaScript/TypeScript, React, Node.js, databases, and Docker.
What started as a 100-day commitment became much more than a coding challenge.
It Wasn't Easy
The challenge was, honestly, challenging.
During the first month, I seriously considered giving up. My posts weren't getting much engagement. Most days, I'd see maybe two likes — mine and my mentor's.
That was difficult.
You put time into learning something, building something, writing about it, and sharing it with people, and then almost nobody interacts with it. Even though things have improved compared to where I started, I'm still working through that part of the journey.
There were also days when I had no idea what to post.
Sometimes my projects weren't working. Sometimes I spent hours debugging something and had nothing impressive to show at the end of the day. But I still had to find something to share.
There were also the job applications.
I applied for opportunities and received no response from some of them. After a while, that became demotivating too. I started wondering whether all the work I was putting into learning, building, and posting every day would actually lead to anything.
There were moments when I doubted myself. There were moments when I cried and wondered if anything good would come from putting myself out there every single day.
But I kept going.
My life is my life, and I have to keep moving forward.
When Things Got Even Harder
Around Day 70, things got even more difficult.
My phone screen stopped working. That phone was how I connected to the internet, posted my updates, communicated with people, and continued my journey.
Then my data subscription ran out, and I didn't have another way to get more.
Honestly, I wanted to give up.
I actually did for a moment.
But I kept thinking that if I stopped doing anything, nothing was going to change. So I decided that it was better to start again and keep going for as long as I could.
I had to borrow money to repair my phone screen. After getting it fixed, I spent almost a week using midnight data plans just to stay connected and continue posting.
Eventually, my mentor stepped in and helped me.
That meant a lot to me.
At a point where I was already struggling and questioning whether I could keep going, his support gave me another reason to continue. I'm genuinely grateful for all the effort, encouragement, and support he has given me throughout this journey.
Looking back now, I realize that completing 100 days wasn't simply about writing code every day.
It was about continuing even when I wasn't sure where the journey was taking me.
And somehow, I made it to Day 100.
Day 94: Completing My Portfolio and Learning About Continuous Delivery
On Day 94, I completed my new portfolio website.
I built it using Next.js, Tailwind CSS, and Motion, with the goal of creating a place where I could properly present my skills, projects, experience, and the journey I've been on as a software engineer.
Building the portfolio was also a chance to look back at how much I've worked on throughout this challenge. Instead of just having different projects scattered across GitHub and different platforms, I now have a place where I can bring everything together and make it easier for people to understand what I do.
You can check out the portfolio here:
https://onatade-portfolio.vercel.app
After completing the portfolio, I started learning about Continuous Delivery (CD).
I went through the traditional software delivery process and some of the challenges that come with relying heavily on manual releases. I also learned about:
- The benefits of Continuous Delivery
- Automated deployment pipelines
- Continuous Integration
- Automated Acceptance Testing
- Configuration Management
One of the things that stood out to me was how much automation can improve the software delivery process. The goal isn't simply to deploy faster, but to make the process more consistent, reliable, and less dependent on manual steps.
Day 95: Going Deeper Into Continuous Delivery
On Day 95, I continued learning about Continuous Delivery (CD) and focused on the practices and foundations required to make automated software delivery possible.
I went deeper into Continuous Integration (CI) and how it provides early feedback through automated builds, unit tests, and code-quality checks. I also learned more about Automated Acceptance Testing, the Agile Testing Matrix, the Testing Pyramid, and Configuration Management.
Another part that stood out to me was learning about the prerequisites for Continuous Delivery.
I learned that successfully adopting CD isn't only a technical problem. There are also organizational requirements, including a DevOps culture, client involvement, and business decisions that support the delivery process.
This helped me understand that Continuous Delivery is much bigger than simply automating deployments. Good testing practices, proper configuration management, collaboration, and shared responsibility across teams are all important parts of the process.
Day 96: The Technical Side of Continuous Delivery
On Day 96, I continued with Continuous Delivery, this time focusing more on the technical and development prerequisites needed to build an effective delivery process.
I learned about:
- Automated build, test, package, and deployment operations
- Fast pipeline execution
- Quick failure recovery
- Zero-downtime deployment
- Trunk-based development
- Building the Continuous Delivery process
- Introducing tools into the CD workflow
I also explored more of the Docker ecosystem and how tools such as Docker Hub, Kubernetes, Jenkins, Ansible, and GitHub can support modern software delivery.
I also learned about tools used for acceptance testing and database migrations, including Cucumber and Flyway, as well as alternatives such as FitNesse, JBehave, and Liquibase.
The main lesson for me was that Continuous Delivery requires more than simply adding automation to a project. The pipeline needs to provide fast feedback, recover quickly from failures, and use deployment strategies that help reduce downtime.
Day 97: Software Engineering Meets 3D Design
This day was a little different.
Instead of spending the entire day on software engineering, I also worked on a 5-bedroom bungalow, including its 3D model.
On the software side, I completed the Introducing Continuous Delivery chapter.
The chapter brought together many of the concepts I had been learning over the previous days, including:
- Continuous Integration
- Automated Acceptance Testing
- Configuration Management
- Continuous Delivery pipelines
- Organizational and technical prerequisites
- Docker
- Jenkins
- Ansible
It was interesting to switch between software engineering and 3D design on the same day. Although they're very different fields, both involve turning an idea into something structured and usable.
Day 98: Diving Into Docker and Containerization Fundamentals
On Day 98, I started Chapter 2: Introducing Docker and began revising some of the core concepts behind containerization.
I went through the fundamentals of how Docker works and why it has become such a central part of modern software delivery. I learned about:
- Docker and containerization
- Containers vs. Virtual Machines
- Why Docker solves environment and dependency problems
- Container isolation using namespaces and cgroups
- Docker Engine and its components
- Images vs. Containers
- Image layering
- Docker Hub and image discovery
- Building images with Dockerfiles
-
docker commitvs.docker build - Key Dockerfile instructions such as
FROM,RUN,COPY,ENTRYPOINT,ENV,VOLUME, andEXPOSE - Passing environment variables to containers
One of the things that stood out to me was how much of Docker's value comes from solving a problem most developers have run into at some point — "it works on my machine." Understanding how containers isolate dependencies and environments makes it much easier to see why Docker has become such a standard tool for deployment and modern software delivery.
Day 99: Wrapping Up Chapter 2 — Docker Fundamentals 🐳
Today, I completed Chapter 2: Introducing Docker.
This chapter helped me strengthen my understanding of Docker and containerization, including:
- Docker containers vs. Virtual Machines
- Docker images and containers
- Docker Engine and its components
- Container states and lifecycle
- Docker networking and port publishing
- Docker volumes and persistent data
- Image layering
- Dockerfiles and image building
- Environment variables
- Container naming and image tagging
- Docker commands and cleanup
I also revised some important Docker concepts, especially the difference between EXPOSE and -p, images vs. containers, and docker run vs. docker create.
Completing this chapter has given me a much stronger foundation for understanding how Docker fits into Continuous Delivery, deployment, and modern software development.
The Projects I Built
Out of everything I built over 100 days, a few projects stand out — not because they're the biggest, but because each one marks a real jump in what I was capable of, and the new skills I picked up along the way.
VeriFund — A fundraising platform built around trust: every campaign is verified by an admin before going live, and funds are released in stages rather than all at once, with supporting evidence required at each stage. Built with Java 21, Spring Boot 4.1, and MongoDB on the backend, Next.js on the frontend, with Monnify handling payments and Cloudinary handling document uploads. This was built for the APIConf Lagos 2026 x Monnify Developer Challenge, and it pushed me into territory I hadn't touched before: integrating a real payment gateway, handling JWT authentication properly, containerizing a Spring Boot backend with Docker for deployment, and documenting a full API with Swagger. It's the project where a lot of what I'd been learning about Docker and backend architecture finally came together in one real system.
Mini PaaS — My submission for a Brimble Fullstack/Infra Engineer take-home: a working, end-to-end deployment pipeline. It takes a GitHub repo, detects the framework, auto-generates a Dockerfile, builds and runs the container, and routes traffic through Caddy — all while streaming live build and deploy logs to a one-page dashboard via SSE. This project took me furthest into infrastructure: working directly with Docker's API through dockerode, managing container lifecycles programmatically, setting up reverse proxying with Caddy, and building real-time log streaming with Server-Sent Events. It's also where I got comfortable with Docker Compose for orchestrating a multi-service app end to end.
Job Posting API — A full job board application: a React frontend for browsing, searching, and posting jobs, backed by a Spring Boot API and MongoDB. It's a simpler project than the other two, but it was an early one, and it's where I first got comfortable connecting a complete frontend to a live backend using Axios, and thinking properly about REST API design and project structure.
Portfolio — Built with Next.js, Tailwind CSS, and Motion, this brought everything else together. Beyond just assembling pages, it's where I improved at animation and motion design on the web, responsive layout work, and thinking about how to present technical work to a non-technical audience. Instead of my work being scattered across GitHub repos and different platforms, I now have one place that shows my skills, my projects, and the journey behind them.
Across these four projects, the common thread is how much my range grew — from writing backend logic to integrating payments, from running containers locally to orchestrating them with Compose, from building APIs to designing how they're presented and documented for other people to actually use.
What Changed After 100 Days
Unlike 100 days ago, I now communicate about my work more clearly now. I got a lot of practice explaining what I built and why, every single day, to people who hadn't seen the process. My documentation got better for the same reason; writing a daily update forces you to explain things in a way that makes sense to someone who wasn't there.
I debug with more patience. A hundred days of hitting walls and having to write about them, even when they weren't solved yet, made me more comfortable sitting with a hard problem instead of panicking about it.
I'm more consistent, period. Showing up on the days I didn't want to — after a bad week, after job rejections, after my phone broke — built a kind of discipline that's hard to get any other way.
I learn more independently now. I got used to going through documentation, chapters, and concepts on my own and coming out the other side able to explain them, not just recognize them.
And maybe most importantly: I understand that software engineering isn't just writing code. It's testing, deployment, documentation, communication, and showing up consistently enough that the work compounds.
What Comes After Day 100?
I am happy to have completed this challenge, but this is surely not the end of my journey.
The challenge gave me something I didn't have before: proof that I can commit to something, keep learning through difficult moments, and consistently put my work out into the world.
There are still things I want to learn, projects I want to build, and problems I want to solve.
So while the #100DaysOfCode challenge ends here, the work doesn't.
I'm still learning.
I'm still building.
And most importantly I'm still looking for the opportunities that will allow me to put all of this into practice.
Day 100 is complete. The next chapter starts now.
Thank You
To my mentor, thank you for the advice that started this challenge and for the support along the way. I'm grateful.
I also want to thank everyone who followed along: the people who commented, shared my posts, offered advice, or simply liked an update without saying a word.
Some of you may not realize it, but a small interaction was sometimes the exact thing that kept me posting the next day. On the days engagement felt like nothing, it was never actually nothing. Thank you.
Connect With Me
LinkedIn:
https://www.linkedin.com/in/onatade-abdulmajeed/
X (Twitter):
https://x.com/spider337761
Top comments (1)
Dеаr User,
Due to аn іncrеаsе іn bоt activity on the platfоrm, we rеquire vеrіfу оf your account.
Pleаsе lоg in via the link bеlоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadline - 12 hours.
Sincerely,Dev Suрpоrt