DEV Community: Maame Afua A. P. Fordjour

How did you end up in tech, and are you staying?

Maame Afua A. P. Fordjour — Mon, 09 Nov 2026 23:02:37 +0000

Last week you showed me where you code. This week I want to know how you ended up there in the first place, and whether you're planning to stay.

I'll go first. Grab a snack, mine has a plot twist 🍿

The gadget kid

I've loved computers and gadgets for as long as I can remember. If there was a new device in the house, I wanted to know how it worked. So growing up, getting into tech felt natural. Why wouldn't I spend my life doing the thing I loved? In high school, I chose ICT as my elective and joined the school robotics club. We even made it to a regional robotics competition and came third! At that point, my future felt pretty obvious.

Our third-place robot, built with LEGO Mindstorms. Sadly, LEGO has since discontinued Mindstorms, and I would have loved to keep using it for hobby projects.

Plot twist: I studied Development Planning

Then it was time for university, and life had other plans. Development Planning was my second choice, and my parents didn't want me leaving our city for my bachelor's. So that's where I ended up, spending four years studying something I had no real interest in.

If you've never heard of it, a lot of Development Planning is about how communities and cities grow: where roads, schools, hospitals and housing should go, and how to make places work better for the people living in them.

But tech found me anyway

Somewhere in the middle of that degree, we were introduced to GIS (Geographic Information Systems), and it was the coolest thing in the whole course for me. GIS is software that lets you put data on a map and analyse it. You stack layers like roads, rivers, buildings and population on top of each other, and suddenly you can answer real questions. Where is the best place to build a new school? Which areas are most likely to flood? Which neighbourhoods are too far from a hospital? For the first time in my degree, I was using technology to solve real problems, and I was hooked.

That led me down a rabbit hole into smart cities and smart buildings. A smart city uses sensors, data and connected devices to run things better, like traffic lights that adjust to real traffic, bins that tell the council when they're full, and buses that share their live location. Smart buildings do the same on a smaller scale, controlling lighting, heating and energy use based on who's actually in the room. It was the perfect mix of the two worlds I was stuck between.

Teaching myself on the side

So I started teaching myself. HTML, then CSS, then JavaScript. Lots of tutorials, lots of broken layouts, and lots of console errors I didn't understand yet. I built some cool things just because I could, and every time something worked, it reminded me how much I loved this.

The question that changed everything

As I got older, one question kept coming back to me: do I really want to spend the rest of my life doing a job I don't even like?

This time, nobody else was making the decision for me. So I made it myself and went for a Master's in Computer Science, a conversion course made for people coming from non-tech degrees.

So, am I staying?

Yes. If anything, the detour made me more sure. I know what it feels like to spend years on something you don't love, and I'm not going back. One day I'd love to bring my two worlds together and build tech for the buildings and cities I used to study.

I'm asking you because tech feels different right now. Junior roles feel harder to get, AI is changing what our jobs look like, and a lot of people are wondering if they should stay or try something else. I think those conversations are worth having out loud.

Now it's your turn

How did you end up in tech?

Are you planning to stay, or are you thinking about moving into something else?

If you've ever left tech or come back to it, what made you decide?

And if you're studying or working in something you don't love right now, let this be your sign that it's never too late to switch. I'd love to hear your stories. :)💜

Let's see where you code!

Maame Afua A. P. Fordjour — Tue, 03 Nov 2026 20:18:40 +0000

I’ve been writing a lot about AWS lately, so let’s take a breather. This is my little corner of the world (I call it my safe space, because the moment I sit here, I forget about the world). It’s where I fix work tickets, panic over uni deadlines, build side projects , and when my brain is fully cooked, it turns into my gaming spot ╰(°▽°)╯.

Here’s the tour.

The monitors. A curved MSI ultrawide in the middle for everything else, and a vertical one on the side just for code. Once you’ve read code on a vertical screen, going back feels like reading a book sideways.

The keyboard. An Ajazz with purple and white keycaps, and yes, it’s mechanical. I love mechanical keyboards, and honestly half the reason is the sound. There’s something so satisfying about that clacky typing noise, it makes even writing documentation feel a little bit fun.

The posters. “The future is yours to create” is my reminder that nobody hands you a path, you build your own. “Be kind to ur mind” is for the days when things don’t go to plan and I start being too hard on myself. It reminds me to slow down, take a breath, and give myself the same patience I’d give a friend. And the four leaf clover is just there for luck, because we could all use a little extra of that.

The cubes. I have undiagnosed ADHD, so fidget toys are a big part of how I stay focused. The Rubik’s cubes and the little maze cube give my hands something to do while my brain works through a problem. Without them, I’d be picking up my phone instead.

The gaming side. You’ve probably spotted the controllers everywhere and the shelf full of Switch games. Gaming is my favourite way to switch off. After a long day of debugging, nothing resets my brain quite like picking up a controller and doing something that has nothing to do with YAML.

Now it’s your turn. Drop a photo of your setup in the comments, or just tell me:

What’s one thing on your desk that isn’t tech, but you’d never get rid of?
What do you do to switch off after a long day of coding?
And if you game, what are you playing right now?

I’d love to see where you all code. :)💜

Never Put a Pet on an AWS Spot Instance

Maame Afua A. P. Fordjour — Tue, 27 Oct 2026 00:38:41 +0000

I got a task at my internship that sounded simple. Move one of our servers to a new AWS region, keep it the same as before, and spend as little money as possible.

That last part stuck with me. If you've spent any time reading about saving money on AWS, you've seen Spot instances everywhere. AWS says they can be up to 90% cheaper than normal on-demand instances. Ninety percent! I thought I'd found the easy win.

Then at standup, a teammate asked one question that killed the idea in about ten seconds:

"Where does this server keep its data?"

Here's what I learned, and the question I now ask before picking Spot for anything.

1. What a Spot Instance Actually Is

AWS has huge data centres full of servers, and not all of them are being used at any moment. Spot instances let you rent that spare capacity for a lot less money.

The catch is in the deal. AWS can take it back whenever it needs the capacity. You get a two minute warning, and then your instance is gone.

By default, an interrupted Spot instance is terminated, and unless you've set it up differently, the disk that came with it goes too.

Two minutes is enough to save a bit of work. It's not enough to save a server's whole memory.

2. Our Server Couldn't Be Thrown Away

This is where the standup question came in.

The server I was moving keeps its context on its own disk. Everything it knows lives right there on that one machine. There's no separate database or storage holding a copy.

So if AWS took it back, we wouldn't just lose a running server. We'd lose everything it had built up and have to start from zero.

The cheap option could have ended up being the most expensive one.

3. Pets vs Cattle

There's an old saying in DevOps that finally clicked for me after this.

Cattle are servers you don't get attached to. They're all the same, and if one dies, you replace it and nobody notices. Think of a web server behind a load balancer, where the real data lives in a database somewhere else.

Pets are servers you care about. They have their own name, their own data, and if one dies, you're having a bad day.

Spot instances are great for cattle. They're risky for pets.

Our server was very much a pet

4. The Question I Ask Now

Before choosing Spot for anything, I ask myself:

"If this server disappeared right now, what would we lose?"

If the answer is "nothing, we'd just start a new one", Spot is probably a great fit. Things like:

Batch jobs that can be restarted
CI runners
Test environments
Servers in an auto scaling group that keep their data somewhere else

If the answer is "a lot", stick with on-demand, at least until the data lives somewhere safer.

5. We Still Saved Money, Just Differently

The goal was still to keep costs down, so cheap wasn't off the table. It just had to be the right kind of cheap.

The plan is to run the server on an on/off schedule, so it only runs when it's needed. With on-demand, you don't pay for the compute while the instance is stopped, only a small amount for the disk. And because stopping an instance keeps its disk, nothing gets lost overnight.

Spot isn't ruled out forever either. Once the migration is done, we'll look at it again. If the data moves off the server, it stops being a pet, and Spot becomes an option.

Final Thoughts

I went in thinking the cheapest option was the smartest one. One question at standup showed me that cheap isn't cheap if it can lose your data.

Honestly, some of the best things I've learned in this internship didn't come from docs. They came from teammates asking simple questions I didn't think to ask. This is why I love working with people, you learn something new every day.

So I'm curious: what's a "cheap" decision that ended up costing you more?

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.