Forem: Seun Agbede

My two cents on tech certs

Seun Agbede — Sat, 17 May 2025 11:31:44 +0000

As professionals in the fast-moving tech industry, it's fair to say we're constantly playing catch-up with emerging technologies. One popular way people stay current in this ever-evolving landscape is through tech certifications. These credentials offer a means of validating skills—and sometimes, they’re even necessary for compliance.

But how much weight should certifications really carry? And how should professionals approach them?

After chatting with a few colleagues, I realized there's no single consensus—opinions vary widely. More people than I expected seem to resent certifications, pursuing them only because their employers require it. A few Reddit threads (my source of unquestionable truth these days) seem to echo that sentiment too.

TL;DR

Certifications validate knowledge, not mastery
Being certified ≠ Being a subject-matter expert (SME)
Certifications aren’t inherently bad or useless
Like most things in life, their value depends on how you use them

My two cents

1. Certifications Validate Knowledge — Nothing More, Nothing Less
Certifications can be valuable, but they’re not a golden ticket to expertise or career success. Passing a certification exam means you've studied the material and can recall it under test conditions. That’s it.

It doesn’t mean you’ve deployed a production-grade system, debugged a critical outage, or optimized a real-world architecture.

Take me, for instance — passing the AWS Solutions Architect Associate exam doesn’t mean I can stand shoulder to shoulder with career architects who’ve been doing this longer than I’ve been in tech. Certifications provide a structured way to learn, but they’re not proof of real-world mastery.

2. Being Certified ≠ Being an SME
Some professionals fall into the trap of thinking that a certification makes them a subject-matter expert. That’s risky—especially in fields like cybersecurity or cloud engineering, where hands-on experience is irreplaceable.

An SME is someone who has solved complex, unscripted problems—not someone who memorized a question dump. Certifications should supplement experience, not replace it.

We've all met that one guy who has every certification under the sun but struggles with basic tasks. It’s awkward and avoidable.

3. Practical experience always trumps theory
No certification can replicate the lessons you learn from:

Debugging a failing CI/CD pipeline at 3:00 AM
Troubleshooting a network bottleneck under pressure
Fixing a code regression you accidentally introduced
Delivering a feature under an impossible deadline

Real-world problem-solving builds instincts no exam can test.
That’s why, in interviews, candidates with “battle-tested” experience often stand out and go on to get roles. They usually provide more structured, in-depth answers because they’ve lived the problems, not just studied them.

4. Certifications are great for learning new tech and opening up
opportunities
I don't think certifications are all useless though. One of the best uses for certifications is the structured learning it provides especially when exploring unfamiliar territory. If you're a backend engineer interested in cybersecurity, studying for Security+ or CISSP can give you a solid foundation in understanding the fundamentals of security. As a developer working mostly on-prem, you may use an Azure or GCP cert to get hands-on with cloud concepts, virtualization etc. This helps with breaking into new fields or trying to stand out in a crowded job market. I feel it signals initiative and shows employers you’re committed to continuous learning.

5. It’s what you make of them that matters
At the end of the day, certifications are just tools. Some people collect them like trophies without deepening their skills. Others use them strategically—to fill knowledge gaps and propel their careers forward. I think certifications should guide learning and not replace hands-on practice. They should certainly be paired with labs, pet projects, or real-world applications.

Final Thought

Tech certifications are useful but they’re just one piece of the puzzle. Their real value lies in how you apply what you’ve learned. So study for the exam, sure but then go build, break and fix things in the real world. That’s where true expertise is forged.

What’s your take on tech certifications? Have they helped your career, or do you think they’re overrated? Leave your thoughts in the comments! 🚀

AWS Summit London 2025: AI, Rap Battles & Snowflake Slides

Seun Agbede — Mon, 05 May 2025 08:17:32 +0000

Last week, I attended my first ever AWS Summit in London and it was a whirlwind of innovation, pleasant encounters and pure tech excitement. Despite a rocky start (more on that later), the day left me buzzing with inspiration — especially after seeing just how deeply AI is shaping the future of tech. I'm not exaggerating when I say 99% of all the sessions were AI focused.

Summit Entrance

TL;DR: AI is everywhere and here to stay! 🤖. Slides over stairs 😬. My first AWS Summit was a blast 🚀

A Late Start 🕰️

I’ll admit it — I missed the keynote. London’s infamous morning rush coupled with a wrong turn on my way down from Nottingham meant I arrived just as the opening speech was wrapping up. That minor setback didn't dampen my enthusiasm for long though. The palpable energy radiating from the bustling crowds and vendor stalls, along with the exciting schedule of sessions and workshops ahead, assured me the day held much more in store.

With my badge in hand, I strode purposefully inside.

A few fascinating stops ✨

My introduction to the event was immediately captivating. I walked straight into a live rap battle unfolding between an AWS employee and an AI, with a separate AI presiding as judge. Donning my wireless silent disco headphones, I found myself nodding along to the beat, bobbing my head along with the grinning audience as the AI competitor delivered flawless rhymes. The AI judge, perhaps predictably, declared its digital counterpart the winner. The spectacle was both deeply impressive and a little unsettling. It felt a bit dystopian and vividly demonstrated that LLMs are now capable of far more than just generating code or writing essays.

Architecture

I also had the opportunity to attend a GitLab-hosted Fireside Chat on Innovating with AI in Regulated Industries. Chris Hutchinson, Director of Enterprise ToolChain at Barclays, shared his experience deploying GitLab Duo as the foundation of their enterprise pipelines. Having last used GitLab over a year ago, I was impressed by their relatively new AI-powered GitLab Duo offering. Hearing firsthand accounts of its capabilities, from suggesting security fixes to generating CI/CD pipelines, left me desperately wanting to head back home and git it a try!

GitLab-hosted Fireside Chat

Another interesting session I attended was one about agentic AI. If you're not too familiar with what agentic AI is, it is

a form of Artificial Intelligence that can autonomously plan, act, and adapt to achieve complex goals—like a self-directed "agent."

Imagine prompting an LLM with "book me a 5-day Bali holiday" and instantly, a Task Breakdown Agent dissects this into sub-tasks e.g. find the cheapest London-Bali flights, book a central 4-star Bali hotel, research/book a Bali cultural activity and identify top-rated Bali restaurants. Then, Specialist Agents like a Flight Agent scours platforms for optimal flight fares, a Hotel Agent compares options and seeks perks, an Activity Agent handles bookings and calendars, and a Dining Agent reserves suitable restaurants. So from that simple prompt you don’t just get suggestions, you actually get things done!

Or imagine another scenario where you tell agentic AI to write code → test it → deploy it to production → monitor for failures → self-heal by fixing its own code vulnerabilities etc. Pretty incredible right?

It was no doubt the standout session for me. The potential for autonomous, self-improving systems is mind-blowing when you really think about it.

Agentic AI session

Unexpected Reunions 👋🏾

One of the other highlights of the summit was undoubtedly reconnecting with former colleagues and classmates. I ran into a university peer and a former coworker, and it was genuinely nice to catch up with familiar faces. We swapped stories about career changes, AWS cloud certifications and the rapid advancements in AI. Seeing how much everyone has achieved was truly inspiring.

Last but not least 🛝

The Snowflake stand had a slide! Not a metaphorical one — an actual, physical slide from the first floor to the ground floor. Obviously, I took the express route down because if there’s one thing tech conferences need more of, it’s playful moments between all the futuristic talks.

Universal sign of the Millennial ✌🏾🤪✌🏾

Leaving Inspired 💫

By the end of the day, one thing was clear: AI isn’t just a tool anymore — it’s a collaborator, a competitor (in rap battles, at least), and a catalyst for reimagining how we build tech. Whether it’s GitLab Duo streamlining DevOps or multi-agent systems redesigning workflows, the future is being written in code—and AWS Summit 2025 gave me a thrilling preview.

Till the next one!

For the culture 📸

My Terraform meetup experience

Seun Agbede — Sat, 06 May 2023 22:25:23 +0000

I find attending technology events a good way to learn more about the industry and stay up to date with it's ever changing landscape. It's also a great way to network, pick up new skills or even gain a different perspective on an area you're already familiar with.

One way I plug myself into the community is by looking up events local to me on meetup.com. As a DevOps engineer, I joined the devopsplayground group on the platform and have found their events interesting and educative. Recently, I attended one which was focused on Terraform. The venue was at GlobalLogic (a digital consulting services company in London) and this is how it went.

Arrival

In typical fashion, I arrived on time so I could get a good feel for the room and most importantly, figure out the directions to the bathroom.

Pardon the tired look. This was an after work meetup

The organisers did a great job of making the registration process seamless and in no time I was seated and ready to go. By the way, the GlobalLogic office is really nice and located in a choice area. I had a good view of Tower Bridge and the River Thames from where I sat.

Presentations

The presentations kicked off with a brief introduction to Terraform.

Terraform is an open-source tool developed by HashiCorp that enables developers and operations teams manage infrastructure as code. This means defining and provisioning infrastructure resources using simple, declarative configuration files which allow for more efficient, repeatable, and scalable deployments.

So basically you write some lines of code and boom! You have your EC2 instances (or whichever resource you fancy) up and running.

It was then followed by an hour-long lab session where we used Terraform to build interesting objects in Minecraft. We were provided relevant access to development environments which allowed us focus on core Terraform workflows.

In the process, we got to see some of the benefits of using an IaC tool - such as the reduced deployment time and infrastructure reliability. We also got tips on how to overcome common challenges, debug common errors, set log paths etc. We got to touch base on best practices as well e.g using version control for the configuration files, reusing configurations with modules, using a remote backend to store the terraform.tfstate file etc.

This is one of the things I built during the session
Don't you dare judge me...haha

You can watch the full presentation or go through the READMEs used for the labs.

We concluded with a Q&A session, where attendees got the chance to ask questions and share their own interesting experiences using Terraform.

Networking

Afterwards, I did some more mingling where I was able to share my thoughts on the presentations with others over pizza and drinks. I sadly couldn't steal a picture here but trust me when I say there was a great variety of food on display.

It was good to hear from other DevOps enthusiasts in the room, ask questions and lean in on their experiences.

Special Bash Parameters

Seun Agbede — Sun, 26 Feb 2023 11:12:04 +0000

It's always amazing observing experts. It often leaves you inspired, motivated and hungry for more professional growth of your own. Recently, I switched teams and now work alongside someone who has been writing bash scripts professionally for longer than I have been alive. Watching him approach problems has left me in awe.

This week, I learnt about built-in bash parameters from him and thought to explore them a little more.

NB: The shell treats these parameters specially. They can only be referenced. Assignment to them is not allowed.

Parameters explored

Asterisk - $*
At sign - $@
Hashtag - $#
Question mark - $?
Zero - $0

1. Asterisk *

Variable	Usage
$*	Stores all the arguments that were entered on the command line ($1 $2 ...)

For example take script foo.sh below

#!/bin/bash

# loops over arguments and prints them in a new line

for i in $* ; do
  echo -e "$i\n" 
done

Now run the script and pass a few arguments

$ ./foo.sh arg-1 arg-2 arg-3 arg-4
arg-1

arg-2

arg-3

arg-4


# notice double quotes around "arg-2 arg-3" are ignored 
# they are treated as 2 seperate arguments

$ ./foo.sh arg-1 "arg-2 arg-3" arg-4
arg-1

arg-2

arg-3

arg-4

However, when we place $* in double quotes "$*" all the arguments are taken as a single string

#!/bin/bash

#notice the change with "$*"

for i in "$*" ; do
  echo -e "$i\n" 
done

$ ./foo.sh arg-1 arg-2 arg-3 arg-4
arg-1 arg-2 arg-3 arg-4

2. At sign @

Variable	Usage
$@	Stores all the arguments that were entered on the command line, individually quoted ("$1" "$2" ...)

$@ is similar to $* but with a subtle difference.

#!/bin/bash

for i in $@ ; do
  echo -e "$i\n" 
done

$ ./foo.sh arg-1 arg-2 arg-3 arg-4
arg-1

arg-2

arg-3

arg-4


# same behaviour as $*
# double quotes are ignored

$ ./foo.sh arg-1 "arg-2 arg-3" arg-4
arg-1

arg-2

arg-3

arg-4

However, $@ behaviour changes when in double quotes "$@"

#!/bin/bash

#notice the change with "$@"

for i in "$@" ; do
  echo -e "$i\n" 
done


# double quotes are treated as a single argument
$ ./foo.sh arg-1 "arg-2 arg-3" arg-4
arg-1 

arg-2 arg-3 

arg-4

With "$@", all the arguments that were entered are treated individually quoted ("$1" "$2"...)

This is generally the behaviour we often want when writing scripts and how it differs from $*

3. Hashtag #

Variable	Usage
$#	Stores the number of command-line arguments that were passed to the shell program.

Take foo.sh

#!/bin/bash

echo "Number of arguments entered is : $# "

$ ./foo.sh arg-1 arg-2 arg-3 arg-4
Number of arguments entered is : 4


$ ./foo.sh arg-1 arg-2 
Number of arguments entered is : 2

4. Question mark ?

Variable	Usage
$?	Stores the exit value of the last command that was executed.

It's also called exit status and this variable stores the exit value of the last command that was executed. It is an integer number.

If $? equals 0, the previously run command was successful.
If $? is between 1-255, the command failed.
If $? equals 127, then the command is not found.

Example usage :

$ echo "Hello there!" > file.txt

$ cat file.txt
Hello there!

$ echo $?
0

# returns 0 as the last run command was successful.

$ cat non-existent-file.txt
cat: non-existent-file.txt: No such file or directory

$ echo $?
1

# returns 1 as the last run command was unsuccessful.

You can see the usefullness of $? in this urlchecker script bar.sh

#!/bin/bash

curl --output /dev/null --silent ${1} && exit_code=$? || exit_code=$?

    if [ ${exit_code} -eq 0 ]; then
        echo "${1} is a valid url"
    else
        echo "Sorry, ${1} is NOT a valid url"
    fi

Invoking the script and passing in both valid and invalid urls

$ ./bar.sh https://www.google.com
https://www.google.com is a valid url

$ ./bar.sh https://www.not-a-valid-website.com
Sorry, https://www.not-a-valid-website.com is NOT a valid url

5. Zero 0

Variable	Usage
$0	Stores the name of the script that is currently being executed.

Take script bar.sh

#!/bin/bash

echo "This is the name of this shell script : $0"

$ ./bar.sh
This is the name of this shell script : ./bar.sh

Just running in the terminal, you get :

$ echo $0
-bash

In essense, $0 holds the name of the currently executing script in bash.

You can see more on special bash parameters from the Bash reference manual

Why I started writing code

Seun Agbede — Fri, 08 Jan 2021 11:10:52 +0000

It's been roughly 10 months since I started teaching myself to code. Funny enough, I recall a conversation I had with a friend around the time I set out on this journey. I had just been exposed to some HTML and was explaining to him how excited I was about it. His response to my elation was - "don't worry, that's how it starts". He was absolutely right! That was just the beginning of what has been my dive into front end development.

So what really got me going?

Simply, the realisation that I was falling out of love with what I had been doing. I had reached a plateau. I had reached a place in my role as a graphic designer where everything just felt flat. I realised I had lost a bit of passion and on most days, I dragged myself through work. I had lost the zeal and excitement I once had. More troubling was the fact that I couldn't place a finger on why this was the case. This went on for a few months until I was randomly asked to complete a task by a colleague. I was asked to fill in a destination link for an <a> tag on a landing page. I recall doing a quick search and learning about the href attribute in the process. I remember feeling anxious while figuring it out but also super excited when I got it done. I felt alive again and somehow, solving that "big problem" got me all fired up.

That was when it hit me!

I stopped learning

At last, I could finally place it! It became clear why I was losing enthusiasm. I had stopped learning new things. I was no longer playing to my strengths or taking on projects requiring new skills. This was the reason I was slowly getting into a rot.

Incidentally, around the same time, I stumbled upon this video from Harvard Business Review's instagram page. In the video, Whitney Johnson explains the concept of the S curve of learning and how it can be used to understand people's change processes. At this point I was convinced the universe was trying to tell me something. The S curve of learning looks like this and is categorised into three parts.

The Inexperience phase -> characterised by slow growth, occasional frustration.
The Engagement phase -> characterised by exhilaration, learning and confidence.
The Mastery phase -> characterised by dissatisfaction, boredom and the longing to do something new.

I realised I was in the third phase of this curve as my growth and enthusiasm had started to dwindle. I needed to move onto the next S curve of learning where I would tackle different types of problems and feel the excitement of learning new things again. I needed to disrupt myself.

The last few months have been exciting and often frustrating. Learning more about front end development has exposed me to a universe I didn't even know existed. I know a lot more now, but somehow the more I know, the more I know I don't know.

I am glad I started writing code.