DEV Community: Maame Afua A. P. Fordjour

I Fixed The Bug. Then My Pipeline Refused to Run.

Maame Afua A. P. Fordjour — Mon, 19 Oct 2026 21:06:51 +0000

Every engineer knows the feeling. You finally fix the bug that's been blocking your ticket, you push it, and you sit there waiting for that beautiful green tick.

That was me during my internship. My Terraform kept failing to create a database server because of a disk error. With some help from a senior engineer, I found the problem: my AMI filter was grabbing the wrong image, one that needed a bigger disk than I'd asked for. I fixed the filter, pushed the change and waited.

The pipeline didn't go green. It didn't really go red either. It didn't run at all.

Sometimes your pipeline is broken and your code is completely fine.

Here's what happened, how it got fixed, and what I'd do so it never catches you off guard.

1. Five Failed Jobs, Zero Logs

The pipeline page showed the whole thing as Failed. 5 out of 7 jobs, all red.

Normally that's fine. You click into a job, open the log, scroll to the red text and find your mistake.

This time there was nothing to read. The failure reason just said:

No more compute minutes available
No job log

No stack trace. No Terraform error. Nothing. The jobs never even started, so there was nothing to log.

If you ever see a pipeline full of failed jobs with no logs at all, check this first.

2. Retry Made It Look Even Worse

Of course I hit retry. (We all do.) Instead of running, GitLab threw this at the top of the page:

An error occurred while making the request.
Status cannot transition via "drop"

That one looks properly scary, like something is broken inside GitLab itself. As far as I can tell, it's just GitLab failing to update jobs that never got the chance to start. Same problem, more confusing message.

Retrying won't help until the minutes are back. You'll just get the same error every time. Once the minutes were topped up, one retry was all it took.

3. Compute Minutes Belong to the Account, Not You

Here's the part nobody tells you as a junior: you probably can't fix this yourself.

I told the senior engineer reviewing my change. She couldn't check the monthly quota either, so she pointed me to the colleague who manages our GitLab account. I found out later why: viewing a group's usage needs the Owner role, so a lot of developers can't even see how close they are to the limit.

So there's no point digging through your code. The fix is a message to the right person. Here's roughly what I sent:

Hi, our GitLab pipeline on the Terraform project has stopped running. It says we've run out of CI compute minutes for the month. Would you be able to check the quota when you get a chance? I've got a change ready, it just can't run until there's compute available.

He confirmed we'd run out and topped up the account.

The annoying part was the timing. Between waiting on a review and this, my ticket barely moved for days, and I had to explain at standup that my work was ready but nothing could run. If you're ever in that spot, keep it simple: what's done, what's blocking it, and who's sorting it out.

4. How to Check Before It Happens

If you're an Owner on the group, go to the group (not a subgroup), then Settings > Usage quotas. On a personal account, it's Usage quotas in the left sidebar. (GitLab docs)

A few things I wish I'd known:

Usage resets every month, so this usually bites near the end of the month.
GitLab renamed "CI/CD minutes" to "compute minutes" in version 16.1, so older Stack Overflow answers use the old name.
If you're not an Owner, ask whoever is to keep an eye on it. Way easier than finding out mid-ticket like I did.

5. How to Make Your Minutes Last Longer

If I wanted to stop this from happening again, this is where I'd start.

Only run jobs when their files change. If your Terraform is split into components, there's no reason to plan the database when you only touched the load balancer. rules: changes: sorts that out:

plan:db:
  script:
    - terraform -chdir=db plan
  rules:
    - changes:
        - db/**/*

Stop duplicate pipelines. A push to a branch with an open merge request can start two pipelines, one for the branch and one for the MR. A workflow: rules block at the top of .gitlab-ci.yml can make sure only one runs.

Cancel old pipelines when you push again. Pushed three fixes in five minutes? You don't need all three pipelines to finish. Mark jobs as interruptible: true and turn on auto-cancel for redundant pipelines in your CI/CD settings.

Cache what you download every time. Dependencies and Terraform providers get downloaded on every single run unless you cache them.

Make expensive jobs manual. If a job doesn't need to run on every push, when: manual is your friend.

Use your own runners for heavy work. According to GitLab's docs, project and group runners aren't affected by the compute quota. If your team already has a server, a self-managed runner can take the heavy jobs off your quota completely.

Final Thoughts

The funny thing is, my fix was right the whole time. The pipeline just had nothing to run on.

So I'm curious: what's the most annoying reason your pipeline has failed that had nothing to do with your code? Drop it in the comments. I want to collect them all 😅

'Localhost' is a Lie: Everything Uni Missed About Real-World Tech

Maame Afua A. P. Fordjour — Tue, 13 Oct 2026 19:47:36 +0000

Every CS student knows the drill. You get an assignment, write your code on your laptop using localhost, zip the folder, and submit it before midnight. If it runs on your screen, you get an A and move on.

Then you start an internship or try building a real app for real people, and reality hits you:

In school, your code is temporary. In the real world, your code has to live.

Doing an internship and building full-stack software taught me more practical engineering in six months than years of lectures ever did. Here are 5 simple truths university never told me.

1. Localhost is a Lie

In uni, if your code works on your laptop, your job is done.

In the real world, writing the code is only half the battle. Getting it onto the internet (deployment) is where the real work begins.

The first time I tried deploying a project, everything broke:

Missing environment variables crashed my server.
Strange CORS errors blocked my frontend from talking to my backend.
My app worked fine on my machine, but ran super slow online.

School teaches you how to write code locally. Industry teaches you how to actually get that code to live on the internet without breaking.

2. Real Data is Messy

Uni assignments give you clean data. Every mock user types their name correctly, no fields are empty, and your database calls never fail.

Real users don't act like that:

People type letters into number boxes.
APIs drop connections out of nowhere.
Data arrives broken or missing half the fields.

Building real apps taught me to write defensive code. You have to build loading screens, error popups, and backup plans so your app doesn't crash the second a real person touches it.

3. Simple Code Beats "Smart" Code Every Time

Uni loves complex math and clever algorithms. It makes you feel like "good code" has to look complicated.

In a real job, clever code is a nightmare.

No senior developer wants to read a 10-line function wrapped into one confusing line of JavaScript. They want code with clear names that makes sense right away. If someone else (or future-you at 2 AM) can't read your code easily, it’s not good code.

4. You spend more time reading code than writing it

In school, every project starts with a blank folder. You know every single line because you wrote it yourself.

In the real world, you get dropped into a huge codebase with thousands of lines written by developers who left the company two years ago.

Learning how to open an existing project, trace how data moves, and fix a bug without breaking three other things is a huge skill. Uni almost never prepares you for that.

5. Breaking things is how you actually learn

School makes you terrified of making mistakes because a bug lowers your GPA.

In the real world, breaking things is how you grow.

My biggest breakthroughs didn't come from getting high marks on an assignment. They came from breaking a build, staying calm under pressure, digging through logs to fix it, and making sure I never made that same mistake again.

Final Thoughts

A computer science degree gives you a solid base, but shipping real projects makes you an engineer.

If you're still in uni and worried about the gap between your grades and your actual skills: stop waiting for your courses to catch up. Build small projects, try deploying them, get an internship, and don't be afraid to break things.

Photo by Dom Fou on Unsplash

'Someone Already Built That' is the Favourite Excuse of Broke Developers

Maame Afua A. P. Fordjour — Sat, 26 Sep 2026 13:48:26 +0000

Let me tell you a quick story about a developer named Sam.

Sam is incredibly smart. For a whole year, he stayed up late building a super complex AI tool for digital creators. He launched it online. He posted about it constantly.

The result? Crickets. He got exactly zero paid users.

One weekend, Sam went to a neighborhood barbecue. He started talking to a guy named Bob. Bob owns a medium sized company that sells cardboard boxes to local restaurants. It is not a sexy business at all.

Bob was complaining about how his sales team tracks their custom orders. They were using an ancient spreadsheet that crashed all the time. They were losing track of emails, missing shipments, and losing money.

Sam asked Bob why he did not just buy a modern software tool. Bob sighed. He said the big software tools were way too expensive and had a hundred features his team did not even need. They just wanted something simple that actually worked.

So, Sam made a choice. He stopped working on his shiny AI app. Instead, he spent two weeks building a very basic order tracker just for Bob.

Bob loved it. He loved it so much that he happily paid Sam $400 a month to keep using it.

Then Bob showed it to his friend who runs a commercial cleaning supply business. That friend wanted it too.

Within a few months, Sam had a highly profitable software business. He was not on the front page of tech magazines, but he was making a fantastic living.

This is the magic of boring companies.

When we hang out on the internet, we get tricked into thinking we have to build the next big thing. We think we have to invent a new social network or a wild new app that changes the world.

But while everyone is fighting over those crowded spaces, a quiet group of developers is getting rich in the background. They are building simple software for freight companies, packaging plants, and wholesale suppliers.

Walk into the back office of any boring company. You will not find sleek software. You will find messy filing cabinets and people pulling their hair out over manual data entry.

These businesses lose thousands of dollars every week because they are so disorganized. And the best part is that they actually have money to spend. To a boring company, paying $500 a month for software that saves them 10 hours a week is a complete no brainer.

Now, you might be thinking that someone has already built these tools. You might think the market is totally full.

Do not let that stop you.

Just look around your life right now. Think about phones, cars, or kitchen appliances. Everyone knows Apple, but there are dozens of other phone brands out there making millions of dollars. You might have never even heard of some of them, but they still have loyal customers who prefer their specific pricing, features, or simplicity. The same thing happens with car brands and washing machines. There is almost never just one company that gets every single customer.

Software is the exact same way. It is almost never a game where one winner takes everything. Just because a giant company like Salesforce exists does not mean Bob wants to use it. Big software is usually too expensive, too complicated, and trying to please everyone at once.

The world is huge. There is always a specific target market, a local region, or a tiny niche that wants your exact version of a tool. You do not need a million users to build a great business. You just need fifty boring companies paying you a few hundred bucks a month.

So, how do you do this?

Stop trying to think of ideas in your bedroom. Go talk to people who run traditional businesses. Do research on these 'unsexy' and 'unattractive' businesses, even construction. Talk to a logistics manager or a factory owner. Ask them what part of their day makes them want to scream.

Look for the messy spreadsheets. Look for the boring, repetitive tasks.

You do not need to change the whole world. You just need to solve a real problem for a real business.In as much as some build for the love of the game, making some $ while doing what you love would be much, much better. Embrace the boring stuff, because that is exactly where the real opportunity is hiding ƪ(˘⌣˘)ʃ.

Photo by xyzcharlize on Unsplash

Disappeared Since March: Taking a Long Break Was My Best Decision Yet

Maame Afua A. P. Fordjour — Wed, 23 Sep 2026 17:06:01 +0000

If you checked my profile recently, you probably noticed my page has been completely quiet since March 12th. No project updates, no new posts, and zero commits.

To be completely honest, I hit a wall.

I was burning out. Balancing my university studies with endless personal projects and trying to keep up with new tools finally caught up to me. The pressure of school assignments and exams, on top of coding in my free time, became too much to handle. My brain felt like a browser with fifty tabs open, and I could not figure out which one to close.

So, I did something that used to scare me: I stepped away completely.

First, I shifted my full focus to my studies. I needed to make sure I was staying on track with school without the extra pressure of creating content or building side projects.

Then, once school allowed for it, I packed my bags and went on a much needed holiday. For the first time in a very long time, I closed my laptop and left it behind. I decided to stop worrying about code, stop checking tech news, and just rest.

What Happened When I Stopped Coding

At first, taking time off felt a bit strange. It is easy to feel like you are falling behind when you are not constantly building.

But after a few days of good food, actual rest, and exploring new places on my holiday, something amazing happened. My mind cleared up. I spent my trip talking to new people, enjoying the view, and letting my brain breathe.

Without forcing it, my creative spark came back. I started noticing simple everyday problems and thinking of fun ways to solve them. I was not thinking about coding out of pressure anymore. I was thinking about it because I genuinely missed it.

Why Breaks Are Essential

We talk a lot in tech about consistency and working hard, but we rarely talk about the importance of powering down.

Taking a break is not a sign of giving up. Just like a system needs downtime for updates, your brain needs rest to operate at its best. Stepping away to focus on school and enjoy a holiday gave me perspective, fresh inspiration and ideas.

I Am Back!

I am refreshed, full of new ideas, and ready to write and build again.

If you are currently feeling tired, stuck, or overwhelmed by your studies and work, this is your sign to take a breath. Step away for a bit, go on a walk, or take that holiday you have been putting off. The code will still be here when you get back.

It is great to be back!

I Got Lost in Canary Wharf for 30 Minutes, But I Found the Future of SRE

Maame Afua A. P. Fordjour — Thu, 12 Mar 2026 17:15:04 +0000

If you've ever been to Canary Wharf, you know it's less of a business district and more of a high-stakes escape room designed by someone who really dislikes Google Maps.

I arrived for SRE Day London 2026 at the Everyman Cinema feeling prepared. I had my bag, my notes, and a general idea of where I was going. Fast forward 30 minutes, and I was still wandering around Crossrail Place like a lost protagonist in a sci-fi movie. Between the multiple levels and the "Level -2" hidden entrance, the frustration was real. I spent nearly half an hour pacing back and forth, trying to figure out how to actually get into the venue. Honestly speaking I probably hit 2k on my daily steps from walking around in circles to find the exact location. And for some weird reason, google maps and apple maps don't work really well in Canary Wharf, did some research. Apparently it is due to something called The urban canyon effect. If you are interested in reading more about how that affects GPS signals, you can read this article: urban canyon

But honestly? The second I stepped inside, the frustration evaporated.

The Swag Haul

First things first: the swag. As a student, you quickly learn that the quality of an event is often proportional to the stickers on the table. SRE Day did not disappoint. I loaded up on fridge magnets and stickers, but the highlight was definitely the SRE Day t-shirts. I managed to cop one, and let's just say it's going straight into my weekly rotation.

The Knowledge Drop: Morning to Midday

The talks kicked off at 09:00, and sitting on those comfortable Everyman sofas made it feel more like a movie premiere than a tech conference. Here is a breakdown of what I learned before 15:00:

Peter Marshall (Imply): He opened with a keynote on Decoupled Observability. The big takeaway here was that we are often limited by "tightly coupled" architectures where data is stuck to specific tools. By decoupling the data layer, we can scale our detection and investigation without the costs spiralling out of control.

Dewan Ahmed (Harness): He talked about Secure by Default in AI-driven delivery. As we move faster with AI, we run the risk of "automating insecurity at scale." He challenged us to look beyond just scanners and build confidence directly into the pipeline.

Matt Henderson (Phoebe): This was fascinating he compared software reliability to the human immune system. Instead of just reacting to alerts and scrambling when things break, we need systems that can predict and prevent failures, just like our bodies handle threats before we even feel sick.

Tyler Hannan (ClickHouse): He asked a controversial question: Do Metrics Matter? While metrics are the fastest way to see if a system is unhealthy, Tyler pointed out that as systems get more complex, metrics alone aren't enough to understand the "why" behind unpredictable failures.

Birol Yildiz (ilert): He showed AI SRE in action. We're moving toward a world where AI agents can diagnose and remediate outages autonomously. Imagine an incident fixing itself without anyone getting paged at 3 AM!

Lunch and the Afternoon Sprint

After a much-needed pizza break (shoutout to incident.io for powering that!), we dove into the afternoon sessions:

Deniz Yalcin & William Ravensbergen (ING): They reminded us that reliability starts with Customer Data. In banking, if upstream data is malformed or delayed, everything else fails from fraud prevention to user trust. It's an underrated SRE dependency.

Adriana Villela (Dynatrace): She emphasized that Observability is a Team Sport! We often fall into the trap of creating "Observability Silos" just like we did with DevOps. To succeed, observability needs to be integrated across the whole organization, not just a single team.

Heather Thacker (Gatling): She broke down the Performance Testing Arsenal. It's one thing for your app to work on a laptop, but another to handle 10x traffic during a marketing campaign. She covered load, stress, and soak testing—essential tools for any SRE.

Tasmia Niazi: This session was super relatable for me. She shared her journey from learner to leader, explaining that SRE is a mindset and a culture, not just a job title. Adopting that state of mind is what builds resilient teams.

Getting Involved: Tracer Cloud and Open Source

During the networking and sponsor crawl at 14:30, I had the coolest discovery: Tracer Cloud's Open SRE Agent. It's a tool focused on cloud-native alert investigation, using AI to figure out root causes before humans even have to step in.

Because I've been looking for ways to get more "hands-on" experience, I officially signed up to be a contributor! If you want to jump in and contribute to the repo as well, you can find it here:

Tracer-Cloud / opensre

Build your own AI SRE agents. The open source toolkit for the AI era.

OpenSRE v0.1: Build Your Own AI SRE Agents

The open-source framework for AI SRE agents, and the training and evaluation environment they need to improve. Connect the 60+ tools you already run, define your own workflows, and answer production questions on your own infrastructure.

Quickstart · Docs · FAQ · Security

🚧 Public Alpha: Core workflows are usable for early exploration, though not yet fully stable. The project is in active development, and APIs and integrations may evolve.

Before you begin

Make sure you have:

A terminal open in a code project
A Git repository (recommended for the full workflow demonstration)

Step 1: Install and start opensre

macOS or Linux:

curl -fsSL https://install.opensre.com | bash -s -- -gh

Windows (PowerShell):

& ([scriptblock]::Create((irm https://install.opensre.com/install.ps1))) -gh

Then start OpenSRE:

opensre

Windows details: Windows.

The installer fetches the latest build from main without requiring sudo…

View on GitHub

Contributing to open-source is one of the best ways to move from theory to reality.

What's Next?

Despite the 30-minute maze-running session at the start, SRE Day was a massive win. I came for the t-shirt, but I left with a contributor invite and a much clearer picture of where the industry is heading.

If you are curious about cloud or have deep interests in reliability, it doesn't matter if you're not in London! They host events all around Europe. You should definitely subscribe to their page on Luma to check out their upcoming events.

Also, if you're looking to give back, they have an option to help out as a Community Hero! It's a great way to support the ecosystem while growing your own network.

Now, if someone could just build an agent to help me navigate Canary Wharf next time... that would be great because honestly, I became Maame 'the explorer' in those 30 minutes😂.

DevOps From Scratch: Entry #05

Maame Afua A. P. Fordjour — Sat, 07 Mar 2026 16:39:39 +0000

Chapters 6 and 7 of the Linux Foundation LFS101 course cover System Configuration from the Graphical Interface and Common Applications. On the surface, these sound like the "not-so-technical" chapters, the ones you skim to get to the real stuff.

But I actually found them more useful than I expected. Here's why.

Chapter 6: System Configuration from the Graphical Interface

After all the kernel talk and boot process deep-dives from previous entries, this one felt like a breather. It's about what you can configure directly through the Ubuntu desktop, no terminal required.

Display, Date & Time Settings are all inside GNOME's Settings panel, just like you'd expect. But one thing that caught my attention was the NTP (Network Time Protocol) option for syncing time automatically. In DevOps, this actually matters. If multiple servers disagree on the time, your logs won't line up and debugging becomes a nightmare. So even "setting the clock" has a real professional reason behind it.

Network Manager is what Linux uses to handle all your connections: WiFi, ethernet, VPNs. The GUI version lives in your top-right taskbar and does a lot of the heavy lifting automatically. The insight the course gives though is that everything you configure through that GUI maps to a config file underneath. The GUI is the training wheels. Knowing what's behind it is what matters for DevOps.

Installing and Updating Software the course clears up a distinction I was fuzzy on:

sudo apt update    # refreshes your list of available packages (installs nothing)
sudo apt upgrade   # actually downloads and installs newer versions

Always run update before upgrade. Now I properly understand why. ✅

Chapter 7: Common Applications

This chapter is a guided tour of the Linux app ecosystem. The apps work great, they just have different names to what you're used to.

Internet & Communication

Need	Linux App
Web browser	Firefox, Chromium
Email	Thunderbird, Evolution
File transfer	FileZilla
Messaging / VoIP	Pidgin, Ekiga

Nothing groundbreaking, but good to know your way around.

Productivity & Dev Tools

LibreOffice is the open-source Microsoft Office. Writer, Calc, and Impress cover Word, Excel, and PowerPoint respectively. It even reads .docx and .xlsx files. Won't need it much for DevOps, but it's there.

On the dev side, Linux is properly in its element: gcc for compiling, gdb for debugging, Eclipse or VS Code as an IDE, and of course git for version control, which was also created by Linus Torvalds. The man really said "I'll just build Linux AND the version control system while I'm at it." 😂

Multimedia & Graphics

VLC needs no introduction, it plays everything, everywhere, always. Audacity covers audio editing, Kdenlive handles video editing, and GIMP is the open-source Photoshop alternative that's been around since 1996. Inkscape handles vector graphics too (think open-source Illustrator).

The full ecosystem laid out like this is honestly impressive. There's a free, open-source alternative for basically everything.

The One Big Takeaway

Linux is a complete operating system, not just a terminal with some files floating around it.

Everything in the GUI maps directly to a config file or CLI command underneath. Using the desktop to set things up is fine. Knowing what's happening underneath is what separates someone who uses Linux from someone who understands it.

That's the gear I'm trying to shift into. Slowly but surely.(Just like the way penguins walk)

P.S. I've updated Flashy with a new deck for both chapters, go test yourself if you've been following along!

What's Next?

Command Line Operations we're leaving the desktop behind and going full terminal. Nervous and excited in equal measure. See you in the next one!

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 :)