DEV Community: Maame Afua A. P. Fordjour

How My "Illegal" Visit to Tech Show London Turned Into a Summer Internship Win

Maame Afua A. P. Fordjour — Thu, 05 Mar 2026 01:04:10 +0000

I officially became a "Tech Outlaw" today. 😂

Don't worry I didn't do anything malicious. I just happened to be in the right place at the "wrong" time. This year, I made a personal vow to stop being such an introvert. I decided to move past the workstation in my room and actually see the opportunities waiting in the real world. When I saw the "Tech Show London" flyer on Instagram, specifically mentioning DevOps, Cloud, and Infrastructure, I knew I had to be there.

I registered, showed up for Day One, and that’s where the adventure (and the "crime") began.

Part 1: The "Accidental" Infiltration

Yesterday morning at the ExCeL was electric. Hundreds of people were streaming in, multiple shows were running simultaneously, and in the chaos, I simply scanned my badge and sailed through the gates. I spent the first few hours feeling like a total pro, soaking up the atmosphere and jumping between the Cloud and DevOps keynotes.

I was taking frantic notes, thinking, "This is it. I’m finally in the room where it happens." Three major "lightbulb" moments hit me:

The Cloud-Native Shift: It’s no longer about just "using" the cloud for storage; it’s about architecting systems specifically for it so they can scale at the speed of light.

The Human Side of DevOps: A speaker hammered home that you can have a perfect Docker or Kubernetes setup, but if your team’s communication is broken, your tech stack won't save you. DevOps is a culture, not just a toolkit.

The "Headache" Economy: Walking the floor, I realized why thousands of tech firms exist. One solves security, one solves speed, one helps find bugs—every booth is there to cure a very specific "headache" for a developer.

I even cornered one of the keynote speakers afterward. I told him I was an aspiring DevOps engineer, and he gave me invaluable advice on what to prioritize in my studies. To top it off, I managed to secure a CPD (Continuing Professional Development) certificate for the sessionssomething I didn't even know existed!

Part 2: The "Bathroom" Blunder

Everything was going perfectly until I needed the restroom. I walked up to a security guard for directions, and she took one look at my badge, then looked at me, and her eyebrows shot up.

"Wait a minute... you're a student?" she asked.
I gave her a massive, confident smile. "Yes, I am!"
She let out a laugh and shook her head. "Honey, you aren't supposed to be here until tomorrow at 2 PM! Students are Day Two only."

And just like that, my "illegal" residency at Tech Show London came to an end. I was politely shown the exit, but I wasn't even mad. I already had the notes, the speaker's advice, and my certificate in hand.

I was exhausted from studying for an exam next week and considered going home for a nap. But then, a reminder popped up on my phone: a DevOps Meetup I had totally forgotten about. Despite the fatigue, I decided to push through.

Part 3: The Pivot to "Data’s Revenge"

The meetup was "DevOps Next Generation: Data’s Revenge" hosted by Fivium, Tarmac, and CODER at Adam Street.

If I hadn't been kicked out of the ExCeL, I might have missed this entirely, and that would have been a tragedy. The energy was completely different more intimate and way more focused. I listened to Beverly Clarke MBE and Darko Klincharski drop gems about the industry, it was quite interesting to listen to how much money companies pay to use cloud services, the figures were massive! and mind blowing.

After the keynote, realising I was the only student there, surrounded by all these platform engineers, DevOps engineers and even CTO's and hiring managers, I decided to take a huge risk. During the session, I stood up and asked:

"Is there anyone here looking for an intern who is incredibly keen to learn about DevOps and ready to work to gain experience?"

The room went quiet for a second, and then everything changed. One of the key speakers told me to leave with 6 networks here and even mentioned there were hiring managers in there with us. They all looked at me and smiled and told me to come see them after the keynote!

As soon as the keynotes ended and the pizza and drinks started flowing, I was swarmed. I didn't need to send a single CV or give my GitHub. Instead of being "Applicant #452" in an automated system, I was a real person having a conversation over a slice of pizza. By the end of the night:

Two companies offered me the opportunity to come in for the summer to pair program and learn the ropes of DevOps.

I connected with a start-up that wants me to grow alongside them as they build their infrastructure.

I ended up connecting and taking advise from people who had been in the DevOps job role for years, coolest thing was taking advice from a platform engineer that had been in the game for 30 plus years! He mentioned to me how during his time, he had to write code on physical pieces of papers, imagine!

My final thoughts are, Never be afraid to use your voice or put yourself out there. You truly never know who is watching. I now have a summer internship secured just from a conversation over pizza. I didn't have to wait for three rounds of interviews or an HR algorithm to "pick" me.

Opportunities pop up when you are actively searching. I'll definitely keep showing up in these tech spaces legally or otherwise! 😉

Gemini Mechanic: Fixing Your Gadgets with AI

Maame Afua A. P. Fordjour — Mon, 02 Mar 2026 21:39:32 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I created a project called Gemini Mechanic. It is a smart assistant that helps people fix broken hardware and electronics. Many people feel lost when a gadget stops working. My web app lets users take a photo of the problem or type a description to get help right away.

Google Gemini is the brain of this project. It looks at the photos to figure out what is wrong. Then it gives the user a list of repair steps and tells them what parts they need to buy. This makes it much easier for regular people to repair their own things.

Demo

GitHub Repo

I previewed it and realised the embedded version doesn’t allow the camera to be used so you can just access the live link here:

Live demo

In my demo, I used my broken iPhone 8 as an example. The app was able to recognize the phone and see that the screen was detached. It provided a full repair guide. It included steps to turn off the power and remove the ribbon cables safely.

What I Learned

One of the biggest lessons I learned was about mobile design. Most people are not at a desk when they are trying to fix something. They are usually holding their phone while they work. I spent a lot of time making the app mobile responsive so it looks good on small screens.

I also learned how to write better instructions for the AI. For repairs, safety is the most important part. I had to make sure Gemini always reminds users to do things like disconnect the battery before they start working.

Google Gemini Feedback

Working with Gemini was a good experience, but I did face some challenges:

Picking the right model: I spent a lot of time testing different Gemini models. I needed one that was smart enough to recognize small parts but fast enough to work on a phone. I don’t know why whenever I try to use Gemini as the ai for any of my projects, I always run into errors. But with the project I was pushed to figure it out, took me a couple of hours till I found the best model to run it with.
Mobile speed: Making sure the app stayed fast while the AI was thinking was tricky. I had to optimize the code so the user experience stayed smooth on mobile devices.

Open Source
I want to make this project open source so everyone can use it. If you have ideas for new features or want to add more repair data, please feel free to contribute to the GitHub repo. I would love to see what we can add to make it better.

Know Your Rights, Find Your Support — Built for Brent

Maame Afua A. P. Fordjour — Sun, 01 Mar 2026 19:52:26 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Brent is one of London's most diverse and deprived boroughs. 340,000 residents. 130+ languages spoken. A 27% child poverty rate, one of the highest in the capital.

The people who live here are not short of resilience or community spirit. What they are often short of is information. Not because it doesn't exist but because it's scattered across dozens of council web pages, NHS portals, charity websites, and government guidance documents, written in bureaucratic language, rarely updated, and almost impossible to navigate under stress.

When someone is facing eviction tonight, they don't have time to search five websites. When a young person gets stopped and searched, they should already know their rights. When a resident doesn't know there are fully funded training courses available to them for free — that information gap has a real cost.

I live in Brent. I built this for my neighbours.

What I Built

Brent Navigator is a free, community webapp that puts verified, plain-English information in one place, organised around the moments that matter most to residents.

Nine sections covering the full range of issues Brent residents face:

Crisis Support — Mental health lines, domestic abuse contacts, emergency services
Health — NHS urgent care, GP registration, healthy living support
Housing — Renting rights, social housing bidding system, eviction process, emergency housing
Employment — Free job search tools, fully funded training courses, benefits explained, starting a business
Cleaner Brent — Bin collection finder, fly-tipping reporting, bulky waste options
The Hub — Community groups, local events, faith organisations, local news, and an interactive Leaflet.js map with 17 clickable location pins across the borough
Youth & Rights — Stop and search rights, education entitlements, mental health support, care leaver entitlements
Tax & Budget — Council tax discounts, where the money goes, accountability tools, financial help
Council FAQs — A searchable accordion of 32 verified answers to the most common resident questions

Every phone number is real. Every link goes somewhere useful. Every piece of content was verified against official sources.

Demo

Live app: brent-navigator.vercel.app

GitHub: github.com/Maame-codes/brent-navigator

Dashboard

Tabs on the different help available

Interactive Map featuring places in Brent

How I Built It

Stack:

React + Vite
Framer Motion for page transitions
Leaflet.js for the interactive map
CSS custom properties for theming
Deployed on Vercel, source on GitHub

The content was the hardest part.

Every section required genuine research, verifying phone numbers against official sources, checking council policy documents, confirming addresses. The Housing section alone covers the Locata bidding system, Section 21 validity checklist, illegal eviction law, deposit protection rules, and emergency housing routes. That's not content you can make up or guess at. People will use this in real situations.

The CSS nearly broke me.

I'll be honest, my CSS sucks. It was the reason why I never wanted to ever get into front-end anyway and getting this to be responsive was a battle. So forgive me if it is not the most aesthetically pleasing site there is, I TRIED MY BEST 😂. The sidebar needed to become a hamburger menu on mobile without pushing or shifting the main content. The interactive map needed to render correctly on small screens. The tab navigation inside each section needed to wrap without breaking the layout. I spent significant time wrestling with position: fixed, overflow-x: hidden, -webkit-overflow-scrolling: touch, and overscroll-behavior to get the mobile experience feeling smooth and native. It's not glamorous work but it matters — most Brent residents access the internet on a phone.

The tab persistence was a small detail that mattered a lot.

Early on, refreshing the page would always kick you back to the dashboard. For an app that residents might bookmark and return to repeatedly, that's genuinely frustrating. I added localStorage to persist the active tab across sessions so the app remembers where you were.

Why I built it this way.

I could have built a simple link directory. Instead I chose depth real explanations, real context, real phone numbers. The Housing section tells you that you don't have to leave just because you receive an eviction letter. The Youth section tells you exactly what an officer must say before a stop and search. The Benefits section explains the Universal Credit taper rate in plain English so residents aren't scared to take a job.

That's the difference between a directory and a navigator. This is built to help real people, and solve real problems in a neighbourhood I live in.

Built with ❤️ for the 340,000 residents of Brent, London.

I Left My First Hackathon at 8 PM — And it Was a Massive Success!

Maame Afua A. P. Fordjour — Sun, 22 Feb 2026 13:55:12 +0000

Most hackathon stories start with "We stayed up for 36 hours and drank 10 Red Bulls."

Mine is different. Yesterday was Day 1 of my first-ever hackathon, Hack London (HackLDN). By 8 PM, I was heading for the exit. I didn't finish the project, and I didn't stay for the midnight games and karaoke (I did get a really nice chicken burrito, lots of snacks & drinks & also pizza(^///^)).

Yet, I walked away with two recruiter contacts, a laptop covered in cool stickers, and a realization about the global dev community that surprised me. Here is why every aspiring developer needs to stop worrying about "finishing" and just start showing up.

They tell you hackathons are 24-hour marathons fueled by caffeine, Red Bull, and zero sleep. They tell you that if you aren't there when the sun comes up, you haven't "really" attended.

They’re wrong. I am sure people who have never been to hackathons probably think to have to close your eyes and be able to code something that wins you a prize. Absolutely not!

I made sure I went to the premises early, that was when most people network and try to find teams. The people I spoke to during that period, I would say 30-40% of them actually had no coding experience, just curious minds.

So you don't have to be a coding expert to go for these things. Some go to find co-founders, others go for the free food(no kidding, one guy told me this when I went to grab coffee😂'I am just here for the stickers and free food'...well fair enough😂😂), others just go to learn too out of curiosity. I was definitely in that learning category, I always say you never know what you can learn in these type of events.

Yesterday, I walked into Hack London as a first-timer with a laptop, a copy of my CV (obviously), and a lot of nerves. In those few hours, I gained more than most people do in a full weekend of coding. Here is why Day 1 of my first hackathon was a total game-changer.

The "Sticker-Clad" Reality

Walking into the venue, the energy is infectious. You see the "HACKER" badges, the lanyards, and the immediate race to claim a spot. My laptop is now officially part of the community, sporting fresh stickers from Google DeepMind, ElevenLabs, PyCharm and MLH. (Didn't spare my nintendo switch, she also got one of Hack London's stickers on her hehe)

But beyond the swag, there was a deeper realization: I was finally in the room where things happen.

The MLH x Dev.to Connection

One of the coolest parts of the day was meeting a representative from MLH (Major League Hacking), Quinn was super nice and very supportive big-ups to him fr （￣︶￣）↗　, he answered every single question and was always ready to help. I actually first heard about MLH because of their recent acquisition of Dev.to. It felt like a "full circle" moment to be at an MLH event while being a fan of this platform.

But here’s the kicker: While talking to other hackers, I realized that a huge number of people in the UK dev scene haven't discovered Dev.to yet! It seems to have a massive footprint in the US, but over here, it’s still a bit of a "hidden gem." If you're reading this from the UK, welcome to my favourite corner of the internet!

The "Early Exit" Dilemma

I teamed up with a group of talented people, and we started getting to know each other and thinking of a project. The ideas were flowing, the GitHub repo was initialized, and the vibes were high.

Then came 8 PM. I had other commitments I couldn't move, and I had to make the tough call to step away. Even though I couldn't cross the finish line with my team, the hours spent collaborating taught me more about real-world team dynamics than any solo project ever could.

Skipping the "Black Hole" of Job Portals

If you're a student, this is the real secret sauce of HackLDN or any hackathons in general. There were recruiters on-site who were actually hiring.

If you're a student, you know the pain: uploading a CV to a portal and never hearing back.

At HackLDN, I got to bypass the "AI gatekeepers." I met actual recruiters who were hiring. I didn't just "apply", I looked them in the eye, sent them a copy of my CV, and had a real conversation. That 5-minute human interaction is worth 100 LinkedIn "Easy Applies."

Final Thoughts: Just Go

If you’ve been holding back from your first hackathon/ any other thing in general because you don't think you're "good enough" or can't stay for the full 24 hours just go anyway.

Show up for Day 1. Grab the stickers. Talk to the sponsors. Meet the MLH reps. Hand over your CV.

You don't need to pull an all-nighter to jumpstart your career. You just need to be in the room.

Suffering from BUGS: How I Almost Deleted My Entire Project

Maame Afua A. P. Fordjour — Thu, 19 Feb 2026 03:23:34 +0000

You know that iconic DJ Khaled album, "Suffering from Success"? The one where he looks overwhelmed by how much he's winning?

Yeah... I WISH that was me.

For the last 48 hours, I wasn't suffering from success. I was Suffering from Bugs. Specifically, the kind that make you question if you should drop out of Computer Science and just become a farmer instead.

I spent two days staring at a screen that screamed 500 Internal Server Error and ModuleNotFoundError. I was winning on localhost:3000 (it worked perfectly!), but the moment I tried to deploy? Disaster.

Here is the story of how I almost deleted my entire project out of frustration, and how I turned a 45-second nightmare into a win

1. The "Works on My Machine" Trap

I think everyone who codes in general has faced this trap maybe one too many times in their life. The reason I decided to build this project in the first place was because I have an upcoming quiz worth 30 marks of my final grade in a couple of weeks, and looking at 80+ slide per every week's lecture would be a nightmare for my revision. I do write notes (in my own words for better understanding) but when it gets to the last minute, I still cannot go through all my notes to refresh my memory of 200+ slides or even more for half of my semester. Then I decided to build 'SlideSift': Very simple tool that basically summarizes your lecture notes, just for revision.

Some of us including myself, are slow learners, and I struggle to just read or study something once, for it to stick forever. People with those kind of abilities are so lucky! But if you are like me, this would actually help you in your uni studies.

I built it using Google Gemini Pro. On my laptop, it was beautiful. It felt like magic.

But then I tried to deploy it to Render.

The Reality Check:

Cloud servers are not your laptop. They don't care that "it works for me."

My requirements.txt was a mess. The server installed an ancient version of the AI library that didn't even know what "Gemini" was.

Lesson Learned: If you don't lock your dependencies (e.g., google-generativeai>=0.8.3), the cloud will humble you very quickly.

2. The 45-Second Awkward Silence

The perfect scenario of how I was feeling whiles waiting for the web app to summarize the notes I uploaded, is very similar to those times when DVD's were a thing, you insert the disc into your DVD player, and sometimes if its corrupt, it shows 'disc error'. Or for my gamers, if any of you ever used the Nintendo GameCube, sometimes when you insert the tiny disc, it takes like 2 mins to load and gives you an error, then while it loads, you pretend to look into the sky so it loads faster... 😂only to receive an error and all you feel is disappointment.

Anyway, back to the story:

Once I finally fixed the crash (after what felt like 50 deploys), I hit the next wall: Latency.

Gemini Pro is smart, but it is slow.

I would upload a PDF, click "Summarize," and then... wait.
And wait.
And wait.

It took 45 to 60 seconds to get a response (Honestly speaking I think at a point it took like a solid 3 mins to even end up giving me an error).

Gemini pro took 45 to 60 seconds to summarize a single PDF. Then I tried to change it to Gemini Flash 1.5, for some weird reason I crashed the app when I used the Flash version, it didn't work at all.

Imagine showing this to a recruiter:

Recruiter clicks "Summarize"
... spinner spins ...
... awkward silence ...
... "So, how's the weather?" ...
... still spinning ...

Or people even using this, with modern technology in 2026, no one would wait 3 mins for a web app to work, let's be honest here. Even me the creator, didn't want to wait that long!

I hated it. It felt broken. I seriously considered hard-coding a loading message that said: "Go make a coffee, this will take a while."

This is when the Imposter Syndrome kicked in hard. I thought, "Real engineers build fast apps. I built a loading screen simulator."

3. The Pivot: Choosing Speed (Groq)

I realized I didn't have a Code problem; I had an Architecture problem.

I didn't need the "smartest" model in the world (Gemini Pro) to summarize a PDF. I needed the fastest one.

I scrapped the Google integration and switched to Groq (running Llama-3).

Groq is an inference engine designed purely for speed.

The result?

Before: > 50 seconds.

After: < 30 seconds.

It was instant. I clicked the button, blinked, and the notes were there. I literally screamed. I had been sitting behind my PC for hours, just surviving on zero sleep, dried mango slices (love them) and iced americano just to stay awake to make it work.

4. Why I Didn't Quit (The DevOps Mindset)

Well I did almost delete the entire repo and the project itself, because I kept on having so many deployment issues and Render kept on sending these error messages to my mail:

I got almost 20 of these messages and that was the time I almost gave up on this. But when I was staring at those error logs, wanting to delete the repo, I realized something: This IS the job.

As a CS student, I love writing code. But as an aspiring DevOps engineer, my job isn't just to write code, it's to ship it.

Fixing the requirements.txt? That's Environment Management.
Switching from Gemini to Groq? That's System Design.
Handling the "Cold Start" on the free tier? That's Cost Optimization.

Honestly, that's why I am always heavy on building as you learn, because truly, that is the only way to make it stick. If I am to work on another project and face these issues, I would immediately know what to do. Tech is so fascinating, you will lose your mind sometimes but its truly remarkable.

The Result

Slide Sift is now live. It turns chaotic lecture slides into pristine study guides instantly.

Try it here (Live Demo)
(Note: It’s on the free tier, so give it at most 50s to wake up the first time!)

Check the code on GitHub

To anyone stuck in "Deployment Hell" right now:

Don't delete the repo.
Take a walk. Drink some water/ coffee for my coffee lovers 😉. CRY IF YOU HAVE TO

The error is probably just a missing environment variable. You got this. 💙

DevOps From Scratch: Entry #04

Maame Afua A. P. Fordjour — Wed, 18 Feb 2026 15:17:54 +0000

When I first started my Linux journey, I had this image in my head of a dark room, green text scrolling at light speed, and a keyboard-only lifestyle. I thought if I didn't spend every second in a terminal, I wasn't doing it right.

But as I dug into Chapter 5 of my training (just a reminder that I am using the Linux Course from the Linux Foundation (personal preference)), I realized something cool: Linux isn't just a command-line tool. It actually has a very sophisticated graphical side. Learning how the screen you look at actually works—from the login page to the windows you drag around made the whole system feel a lot less intimidating.

Here is what I learned about the visual side of Linux.

1. The Engine Behind the Screen

In many operating systems, the desktop is built directly into the core system. In Linux, the graphical interface is more like an "app" that runs on top of everything else. There are two main engines that make this happen:

X Window System (X11): This is the old-school veteran. It’s been around for decades. One neat trick it has is the ability to run a program on one computer but show the window on a totally different screen over a network.
Wayland: This is the new kid on the block. It’s designed to be faster, smoother, and more secure than X11. Most modern versions of Linux are switching to this now.

2. Desktop Environments vs. Window Managers

People often get these confused, but they do different jobs:

Window Manager: This is a small program that handles just the basics—the borders of your windows, the buttons to close or minimize them, and moving them around.

Desktop Environment: This is the whole package. It includes the window manager plus the taskbar, the file folders, the settings menu, and even the wallpaper.

GNOME: Very clean and modern. It’s what you usually see on Ubuntu.

KDE Plasma: If you are moving from Windows, this will feel very familiar. It is super easy to customize.

XFCE: This is great if you have an older laptop because it doesn't use much power or memory.

3. The Login Gatekeeper

That screen where you type your password when you first turn on the computer? That is called a Display Manager. Its only job is to check who you are and then start up your favorite desktop environment.

4. The Magic Escape Hatch (TTY)

This is probably the coolest pro tip I found. If your screen ever freezes and your mouse won't move, you aren't stuck! Linux has hidden text-only screens called Virtual Consoles or TTYs.

You can jump between them using keyboard shortcuts:

Ctrl + Alt + F3 (through F6): These take you to a purely black-and-white text screen. You can log in here and fix things using commands if the visual part of the computer breaks.

Ctrl + Alt + F2 (or F1): This usually jumps you right back to your normal desktop.

Why Learn This for DevOps?

You might wonder why a DevOps student needs to care about desktop icons. Even though most servers we manage don't have a screen at all, knowing how these layers work is helpful. It helps you set up your own laptop for work and understand how to "forward" a visual app from a server to your own computer when you need to run a specific tool. And also I have a strong believe that it is always good to master the basics (foundations) of anything you want to learn deeply.

P.S for my flash card buddies, I updated Flashy, just to refresh your memory :)

Nike Was Right: The Only Coding Advice You Actually Need

Maame Afua A. P. Fordjour — Mon, 16 Feb 2026 13:03:45 +0000

I am pretty sure anyone who opens this would wonder what a shoe brand has got to do with coding? But just hear me out on this one. Let me start by saying a story that even led to me writing this in the first place.

I spent about three hours yesterday staring at a blank VS Code window on my pc. Well I was not literally staring at it for three hours because that would be a bit psychotic. I had my VS code opened and I was ready to work on a project I had in mind.

But a friend sent me a TikTok video and I made the mistake of opening it. I read the comments and laughed for about 15 minutes. TikTok comments are actually always funnier than the videos themselves. Anyway I ended up just doom scrolling on TikTok for about three hours and then switching through my social media apps. I then just got bored of everything and realized that I had successfully wasted my time. I then asked myself what I was even looking for. I could have used that time for something extremely productive.

The Trap of Waiting to be Ready

We look at what experts are doing and we feel small. We think we need to be perfect before we even type our first line of code.

But while we are waiting to feel prepared, the time just slips away. This kind of overthinking is the biggest thing that slows us down. We are not actually researching. We are just procrastinating because we are afraid to fail.

This is how procrastination slows us down. We overthink everything and we wait for a feeling of being ready that never actually comes. We think we need to watch one more tutorial or read one more article. But while we are waiting, we are just standing still. And standing still is not a good thing, because as you are standing still, some are crawling, others walking slowly, some walk briskly and most are running.

The Nike Philosophy

I started thinking about that famous Nike slogan lately. "Just do it".

It sounds simple, but it is actually the best coding/ life advice ever. In the world of tech, we often try to learn everything before we do anything. We want to master Python and Git and every other tool before we build a single thing.

The truth is that you only learn by doing. You do not learn to swim by reading a book about water. You have to jump in. Coding is exactly the same.

You learn when your code breaks.
You learn when you spend an hour fixing a weird path error.
You learn when you finally make that first messy commit.

The Cost of Overthinking

If you wait until you feel like an expert, you will wait forever. Procrastination is just a fancy way of saying you are afraid.

Just getting up to do something is what actually gets the job done. Doom scrolling and overthinking will only make you feel worse.

I am learning that it is okay to be confused. Most of us are just Googling things as we go anyway. I don't know who needed to hear this but if you are like me and you procrastinate a lot, JUST DO IT anyway. And you will eventually get better at whatever it is :)

DevOps From Scratch: Entry #03

Maame Afua A. P. Fordjour — Wed, 11 Feb 2026 07:19:34 +0000

After installing Ubuntu on my laptop mainly for this linux learning journey, I left it there for about almost two weeks (not my fault! had to focus on some uni work). I am continuing my journey through the Linux Foundation course, for the DevOps from Scratch journey. Today I am looking at chapter 4. This chapter is about how a Linux system starts up. When I first started learning I just pressed the power button and waited. Now I want to understand the steps happening behind the screen.

Understanding the startup process is important. If a system fails to start you need to know which step went wrong to fix it. Here is what happens when you turn on a Linux machine.

The Startup Steps

The process follows a specific order. Each step prepares the system for the next one.

1. BIOS and UEFI

When you turn on the computer the first thing that runs is the BIOS or UEFI. This is small software stored on your motherboard. It checks your hardware like your RAM and keyboard to make sure everything is working. This check is called a POST.

2. The Bootloader

Once the hardware is ready the BIOS looks for a bootloader. In Linux the most common one is called GRUB. The job of the bootloader is to load the Linux Kernel into the memory of the computer. There is a funny story linked to the GRUB, this is why I love to document my entire learning process, because even before I continued with the learning process into chapter 4, I literally forgot the password to the laptop I installed the Linux on! I had to do a quick google search on how to reset your ubuntu passcode at the welcome screen, and it was actually a smooth processs really, All I had to do was to hard restart my machine thrice, and it did take me to the GRUB bootloader, so I really had a happy moment when I saw that in the online course :)

3. The Linux Kernel

The kernel is the heart of the operating system. It manages the hardware and the memory. It also starts the very first process on the system.

4. Init and Systemd

The kernel starts a process called init. On most modern Linux systems this is now called systemd. This is the mother of all processes. It has a process ID of 1. Its job is to start all the other services you need like your network or your desktop interface.

Kernel Space and User Space

The system is divided into two parts.

Kernel Space is where the kernel runs. It has full access to the hardware.

User Space is where your applications like a browser or a terminal run.

This division keeps the system safe. If an app in the user space crashes it should not take down the whole kernel.

A Useful Command

One way to see what happened during your startup is using the dmesg command.

dmesg | less

I will explain this command thoroughly.

dmesg stands for display message. It shows the messages from the kernel buffer. These are logs that tell you exactly what the kernel did while the system was starting.

The pipe symbol takes the output of the first command and sends it to the second command.

less is a tool that lets you scroll through a long list of text one page at a time.

Using this command is a great way to see how the kernel interacts with your hardware.

My Progress

Learning these basics helps me move away from just following tutorials. Instead of guessing why a system is slow or not starting I can now look at the logs and understand the steps.I am enjoying documenting this path as I learn how systems work under the hood.

And for my flash card buddies, I have updated Flashy, it has flash cards for this chapter of the course, in case you want to revise :)

I Stopped Trying to Learn Every DevOps Tool: And Started Building a Platform Instead

Maame Afua A. P. Fordjour — Wed, 11 Feb 2026 05:17:40 +0000

The DevOps Hero Burnout is Real

Let's be real for a second. being a student and juggling school work with external studies is the TOUGEST thing ever, my first few months in the DevOps world felt like a total nightmare. Every roadmap I looked at was just a giant wall of logos: Docker, Kubernetes, Terraform, Ansible, Jenkins, ArgoCD, Prometheus, Grafana... the list literally never ends.

The advice was always the same: "You need to know how everything works under the hood." But here is the reality: system complexity has officially outpaced what one person can actually coordinate. Trying to be a DevOps Hero who masters every single tool is a losing battle that leads straight to burnout before you even graduate. I was spending 80% of my time fighting with messy YAML files and only 20% actually building cool things.

So, I decided to stop. I stopped trying to learn every single tool, and I started building a Platform for myself instead.

The Shift: From Tool Fatigue to Golden Paths

In the industry right now, we are seeing a massive shift. By 2026, it is predicted that 80% of software engineering organizations will have dedicated platform teams. Why? Because the "You build it, you run it" culture, while great in theory, usually breaks down when things get big.

It creates a Cognitive Load that is simply too heavy. Senior engineers end up becoming "human glue," spending all their time helping others provision basic infrastructure instead of actually innovating.

Platform Engineering solves this by creating Internal Developer Platforms (IDPs). The goal isn't to take away a developer's power, but to give them Golden Paths: pre-defined, best-practice workflows that allow them to ship code without needing to be an infrastructure expert.

What I Built: My Personal IDP (TutorCLI)

Instead of manually configuring every single deployment, I built a tool called TutorCLI. It is my own personal version of an Internal Developer Platform.

Instead of me having to remember the exact flags for a complex tar backup or a docker network command, my platform handles the complexity for me. It provides:

Abstraction: It hides the low-level infrastructure details behind a simple interface.

Self-Service: I can provision what I need without waiting for my own "mental" approval or re-reading documentation for the 10th time.

Safety Guardrails: It audits my commands for common student mistakes, like the danger of a destructive rm -rf, before they even execute.

Building this taught me more about DevOps than any 10-hour tutorial ever could. I wasn't just using tools; I was architecting a system that made those tools invisible.

Why Platform-as-a-Product is the Future

The secret to viral growth in 2026 isn't knowing the most tools. It is about understanding Developer Experience (DevEx).

High-maturity platform teams report a 40-50% reduction in cognitive load for their developers. This allows teams to move from environment provisioning taking days to taking just a few hours. We are moving away from "enablement-by-heroics" and toward "enablement-by-design."

For students, this is a superpower. If you can show an employer that you don't just know how to use Kubernetes, but you know how to build a platform that makes Kubernetes easy for others, you are ahead of 90% of the applicant pool.

3 Simple Steps to Start Your Own Platform Journey

If you are a student feeling overwhelmed by the toolchain, just stop. Do this instead:

Identify your "Toil": What is the one command or configuration you have to look up every single time?

Build a Wrapper: Write a script or a simple CLI, like my TutorCLI, that automates that specific Golden Path.

Standardize Your Patterns: Stop reinventing the wheel for every project. Create a template that encodes your best practices for security and deployment.

Final Thoughts

The era of the Generalist Hero is ending. We are moving into the era of the Platform Engineer. Don't just learn the tools: build the stage they perform on.

GitHub Copilot CLI Challenge: 'The Linux Compass'

Maame Afua A. P. Fordjour — Tue, 27 Jan 2026 07:21:14 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built The Linux Compass, a terminal-based utility designed to bridge the gap between AI discovery and permanent technical knowledge.

As a Computer Science student , I am currently documenting my journey into infrastructure through a Linux/DevOps learning series. I noticed a recurring problem: I would use GitHub Copilot CLI to find a command, use it once, and then forget it. This "knowledge decay" is a major hurdle for students. I created a basic website for an web based app called 'Flashy' (Flashcard learning style because I am a slow learner and suffering with extreme ADHD), but that was not enough either, this challenge pushed me to create something that will be beneficial to me, and other students out there to solve that problem whiles in the terminal.

The Linux Compass wraps the GitHub Copilot Agent in a Python workflow that forces a "Learning Loop." It captures the user's goal, assists in finding the command, triggers an educational breakdown (the "why"), and then automatically synchronizes the session into a persistent Markdown study log (LINUX_STUDY_LOG.md).

Demo

GitHub Repository: Linux-compass

How it Works:
(Go through the ReadMe in the Github repo to get started!)

Below are screenshots of how it works:

1)Initiating a Query The tool greets the user and consults the Copilot Agent for the specific Linux task.

2) The Educational Breakdown The Compass doesn't just provide an answer; it enforces understanding by calling the explain agent automatically.

3) Successful Synchronization The session concludes with a success message once the data is safely logged.

4)The Persistent Study Log By opening LINUX_STUDY_LOG.md, we see the automated entry: timestamp, learning goal, and verified command. This creates a structured, searchable history of my technical growth.

My Experience with GitHub Copilot CLI

My journey with the GitHub Copilot CLI was a rollercoaster of technical troubleshooting that ultimately made me a better developer.

The Struggles:

The biggest challenge was dealing with the 2026 Agentic Update of the GitHub CLI. Early in development, I faced a "Version Conflict" where the CLI refused to recognize simple prompts. I kept getting the error: error: Invalid command format.

I had to dive deep into the CLI documentation to discover the new Interactive Payload Pattern. I learned that the 0.0.395 version of the extension required the suggestcommand and the -p prompt to be passed as a single, nested string within the -i (interactive) flag.

The Breakthrough:

Once I understood how Python's subprocess module needed to "hand over" terminal control to the Copilot agent, everything clicked. I also navigated Windows-specific hurdles, such as migrating my project from the restricted System32 directory to a trusted user space and upgrading to PowerShell Core (pwsh) to support the modern Copilot features.

The Impact:

GitHub Copilot CLI turned the terminal from a "scary black box" into an interactive tutor. Instead of just giving me a command, the explain feature allowed me to build a tool that teaches me. For a student aiming for a career in DevOps, this isn't just a shortcut it's a productivity multiplier that ensures I am learning efficiently while I build.

The HIDDEN Gem in the Google AI Challenge💎

Maame Afua A. P. Fordjour — Fri, 23 Jan 2026 06:24:15 +0000

First of all, if you haven’t participated in the google AI challenge, please do so right now. Not for the prize pool, but for something way better. I don’t believe in new year resolutions, but I just decided to “just do things” this year. Even if I am not ready, I would rather participate and fail, than not trying at all.

As developers, we often skip projects or challenges if we think we won't win. That is a mistake. Challenges are rarely just about the prize; they are about the ecosystem access they provide. If you just code your submission and leave, you’re leaving 90% of the value on the table.

Recently, I decided to try my hand at the Google AI Challenge (specifically the New Year, New You Portfolio Challenge). I wanted to test my skills and maybe build something cool for my portfolio. I was so focused on the prize pool, till I realised there were hidden gems that anyone who participated in, gets! I ended up walking away with something potentially more valuable long-term, and I almost completely missed it.

The "Wait, What's This?" Moment

After submitting my project, I was clicking around my Google profile settings and noticed a new badge and a change in my status. It turned out that simply by participating, I had been formally onboarded into the Google Developer Program.

I had always assumed these programs were expensive "enterprise" things or required some elite status. I dug a little deeper and realized I was in the Standard Tier.

The cost? $0.

This was my realization:
Sometimes the best part of participating in a challenge isn't the leaderboard; it's the ecosystem you get invited into. If you just code your project and leave, you miss the hidden gems scattered around the platform.

If you are a student, a bootcamper, or an aspiring developer operating on a budget of zero, this program is a goldmine. Here is what I found hidden in plain sight, and why you should sign up immediately.

1. The Holy Grail:
35 Free Monthly Learning Credits
As a student, the biggest barrier to learning cloud computing isn't intellect; it’s fear of the accidental $500 bill because you left a Kubernetes cluster running overnight.

The Standard membership solves this.
When you join and link your profile to Google Cloud Skills Boost (formerly Qwiklabs), you receive 35 learning credits every single month.

Why this is huge:

These aren't just "watch a video" credits. These are for hands-on labs where Google spins up actual, temporary cloud environments for you to break things in. You can practice deploying AI models, setting up CI/CD pipelines, or managing databases without ever putting in a credit card.

If you use them up, you just wait until next month for a reload. It's a permanent learning allowance.

2. AI Assistant Baked Right Into the Docs

We all know the struggle: you have 40 tabs open, flipping between Stack Overflow, documentation, and ChatGPT trying to figure out why an API isn't working.

As a member, you get Gemini (Google’s AI) integrated directly into the developer documentation side panel. You can highlight a confusing piece of code in the docs and ask Gemini to explain it or convert it to a different language right there on the page. It saves an immense amount of context-switching energy.

3. Access to Project IDX

This is a massive perk if you are a student working on an older laptop that sounds like a jet engine when you open VS Code.

Membership gives you access to Project IDX, Google’s AI-first, browser-based development environment. It’s basically a high-powered dev machine in the cloud that's pre-configured with frameworks like Flutter, Angular, Next.js, and integrated AI assistance. You can build full-stack apps from a Chromebook without melting your CPU.

4. The "Verified" Flex

When you complete those hands-on labs using your free credits, you earn "Skill Badges."

These aren't just digital stickers. They attach to your public Google Developer Profile (which you get upon joining).

This is a verified, shareable URL that proves to recruiters or hiring managers that you haven't just read about a technology—you've actually built something with it in a live environment. It’s an instant resume booster.

How to grab your free membership (The 60-second setup)

Don't overcomplicate it. You don't need to win a hackathon to get in.

Head over to the Google Developer Program homepage.
Sign in with the Google account you use for coding.
Click join, and make sure you select the Standard plan (the free one).
Crucial Step: Once you're in your dashboard, follow the prompts to link your account to "Google Cloud Skills Boost" to ensure you get those 35 monthly credits.

The takeaway

Participate in everything. Do the hackathons, do the challenges. Even if you don't win the main prize, keep your eyes open for the tools and access they give you along the way.

Sometimes the real prize is just free access to the tools you need to build your next big project.

Participation is the Asset

We often skip projects because we think, "I'm not good enough to win." But the real reward isn't the trophy.

It’s the access. It’s the free cloud credits, the community invitations, and the professional tools that stay with you long after the contest ends.

Don't just code for the prize. Code for the "hidden gems" that are waiting for you in the fine print.

Touching GRASS: My Experience at the Stripe Developer Meetup

Maame Afua A. P. Fordjour — Wed, 21 Jan 2026 01:09:15 +0000

The "Alien" Leaves the Ship

If you read my last post, you know my struggle. I’ve spent a lot of time feeling like an alien coding in my room, thinking the tech industry was some scary, exclusive club where everyone is a genius and no one is shy.

But I made a promise to stop hiding. So, yesterday, I forced myself to go to the Stripe London Developer Meetup.

I stood outside their office in Bishopsgate for a solid minute, debating if I should just turn around and go home. Am I experienced enough to be here? What if someone asks me a question I can't answer?

I took a breath, walked in, and... wow.

Inside the Beast (Stripe's London office)

First off, the office is cool. Like, "I definitely want to work in tech" cool.

But the vibe wasn't intimidating. It was buzzing. There was that distinctive hum of people excited about what they build. And yes, there were refreshments (free food, wine, beer and soft drinks definitely help cure social anxiety).

I realized something quickly: The "scary professionals" were just people eating pizza.

Theory vs. Reality (The Talks)

As a student I’m used to theory part of things. But seeing how it works in the real world is a different experience. We had two speakers, Marina Kim and Andrew Robinson (Wish I had their accounts to tag them on here, but I couldn't speak to them after the talk).

Marina Kim broke down how to build a multi-seller SaaS using Stripe Connect. It wasn’t just "here is code", it was the actual stories and lessons learned from a technical lead.

Then Andrew Robinson (a Solutions Architect at Stripe) spoke about "The $/£/€100 Problem" and Adaptive Pricing. This was my "brain-blast" moment. I realized that behind a simple "Buy Now" button, there is a massive, complex engine handling global currencies. It made me appreciate the complexity of the systems I hope to help manage one day.

Hitting the DevOps Jackpot (Highlight of my night)

After the talks came the part I dreaded: Mingling.

I saw people chatting in circles. My instinct was to check my phone and look busy. Instead, I first spoke to the people who were seated on my right and left, which was easier since they were in such close proximity. I later on walked around to see people who were just by themselves, I introduced myself and spoke to them and met some really cool people, added them on my LinkedIn!

And I got lucky. I didn't just meet random people, I ended up chatting with two professionals actively working in DevOps and one used to work in that field-my dream career.

This wasn't a formal interview. It was just a chat. I asked them: "If you were me, what would you focus on?"

The advice I got in those 10 minutes was worth more than an entire semester of Googling for a 'roadmap'. They didn't treat me like a clueless student, they treated me like a future colleague. And gave me so much advise and even gave me their LinkedIn to reach out if I have any questions!

The Plot Twist

I also bumped into other students from my own university!

It turns out, I wasn't the only "alien" who decided to beam down for the night. We were all there, feeling the same nerves, trying to figure out this industry together.

The Takeaway

If you are reading this and thinking, "I'm not ready for meetups," you are wrong.

You don't go to meetups because you know everything. You go to meetups to meet the people who do.

I walked in terrified. I walked out with:

Free resources (they let us take one of their technical books for free!).
Connects on LinkedIn (and a strategy to follow up).
Real advice from DevOps engineers.
A huge confidence boost.

The real world isn't as scary as the code errors on my screen. I’m already looking for the next event.

Buy me a coffee