DEV Community: Bede E. Hampo

HTTPS Isn’t Optional, It’s the Boundary of Your System

Bede E. Hampo — Fri, 23 Jan 2026 04:00:00 +0000

Most developers think of HTTPS as a checkbox.

Something you enable because every tutorial tells you to. Something that’s “probably already handled somewhere.”

That’s understandable.

But HTTPS isn’t a feature you add. It’s the line that decides whether your system is private or exposed.

If your API accepts HTTP traffic, even briefly, you’ve already given up more control than you realise.

“It’s Internal” Feels Safe, Until It Isn’t

A lot of us rely on the idea of internal systems.

But internal doesn’t mean isolated.

Your requests still move through load balancers, proxies, monitoring tools, shared networks, and logs you don’t actively think about every day. If any part of that path can see plaintext traffic, then sensitive data is visible long before it reaches your code.

Nothing dramatic happens. No alarms go off.

That’s what makes it dangerous.

What HTTPS Actually Gives You

We often talk about HTTPS as “encryption,” but that’s only part of the story.

HTTPS gives you confidence about three things:

You know who you’re talking to.
You know the request wasn’t changed along the way.
You know only the right parties can see the data.

Once those guarantees exist, everything else starts to make sense. Tokens, API keys, sessions, and cookies all assume this foundation is already there.

Without HTTPS, those mechanisms don’t really protect you — they just make leaks harder to notice.

Why Adding HTTPS Later Rarely Works

It’s tempting to think, “We’ll lock it down once the system stabilises.”

In practice, systems harden around their early assumptions. Logs are created, integrations form, and tooling adapts to whatever behaviour exists first.

By the time HTTPS is added, unsafe paths are already trusted. The risk doesn’t disappear — it just becomes invisible.

How Experience Changes the Question

Early in our careers, we ask:

Does this work?

With experience, the question shifts:

Where can this be seen, copied, or altered?

That’s why more experienced engineers care deeply about where TLS terminates, how traffic enters the system, and which layers are allowed to see requests in clear text.

The goal is simple: HTTP should never reach your application.

The Quiet Rule Behind Secure Systems

If traffic isn’t encrypted, your system isn’t really under your control.

Everything else you build sits on top of that decision.

Most API Breaches Don’t Hack You, They Walk In

Bede E. Hampo — Mon, 19 Jan 2026 04:00:00 +0000

Most API breaches occur because systems trust valid requests too readily, rather than because attackers break in.

Common wrong belief: If authentication works, the API is secure. Uncomfortable truth: Attackers usually don’t bypass security; they use it correctly and abuse what you forgot to question.

Most developers imagine API breaches as dramatic events: broken encryption, stolen secrets, brute-force attacks. That image is comforting because it suggests security is about blocking outsiders.

In real systems, the majority of API incidents involve valid tokens, correct headers, and expected flows. The attacker isn’t fighting the system. They’re cooperating with it.

Why? Because APIs are built on trust layers:

You trust the identity provider.
You trust the token.
You trust that authorised users will behave reasonably.

That last assumption is where things collapse.

An API doesn’t think in intent. It evaluates rules. If a request matches the rules, it passes. It doesn’t ask why the data is requested, how often, or whether the access pattern makes sense. Those are human assumptions, and systems don’t enforce what you don’t define.

This is why breaches often look boring in postmortems:

User accessed data they were allowed to see.
No rate limit was triggered.
No authentication failure occurred.

Everything worked.

The mistake wasn’t missing HTTPS or OAuth. It was believed that authentication equals safety. It doesn’t. Authentication only answers who. It says nothing about should, scope, frequency, or impact.

Senior engineers learn this the hard way: security failures are often the result of design failures. They happen when systems are permissive by default and restrictive only in theory.

If your API trusts tokens more than it understands behaviour, it’s not secure, it’s polite.

And politeness is expensive at scale.

This is the difference between writing code and building systems.

A Thought on Online Subscriptions and Payment Systems: Reimagining the Future

Bede E. Hampo — Sun, 16 Feb 2025 01:32:06 +0000

As technology and digital transformation continue to evolve, there’s an increase in the number of online platforms and services available to us. Many of these services offer free versions, but to unlock the full suite of features, we often find ourselves forced into subscribing to premium packages.

However, there's an inherent flaw in the way these services charge us: the subscription model. While some platforms charge annually or monthly, many of us are paying for services we use only occasionally—sometimes even only once or twice a month. Yet, the full monthly or yearly fee remains the same. This system feels inefficient and, frankly, quite unreasonable, as we end up paying for resources we rarely use.

The Problem with Traditional Subscription Models

Let’s break it down. Think of all the platforms you use regularly. You’ve probably inputted your card details on many of them, regardless of how often you use the service. Even if you use a service only once a month, you’re still paying a full subscription fee—whether that’s monthly or yearly.

For example, I use design software, cloud platforms, and professional networks, each with its subscription model. For each service, I have to input my card details and pay the full fee for the month or year, even if I don’t use it frequently. The question is: why am I paying for access I don’t fully utilize?

This model makes little sense when you consider that other services charge based on usage, like utilities or mobile data. Why can’t these platforms do the same?

A New Way: Pay-Per-Use Instead of Subscriptions

Imagine a centralized platform that could solve this issue. Instead of signing up with each service and repeatedly entering your card details, you could fund a single account on this platform. This would act as a gateway to all the services you use.

Here’s the catch: rather than being charged monthly or annually, you’d only be charged based on what you use. Just like paying for data usage on your mobile plan, you would pay for the exact amount of service you consume.

How the Centralized Payment System Would Work

Fund Once, Use Everywhere: You will add your payment details to this central platform once. This means no more repeatedly inputting card details every time you sign up for a new service.

Pay-Per-Use: Instead of a fixed subscription fee, the service would charge you based on actual usage.

Universal Currency System: Rather than charging you in a specific currency (USD, GBP, etc.), the platform would use points. These points would represent the value of a service and could be translated into the currency of your choice.

Centralized Rating System: Here’s the best part: the platform would feature a centralized rating system that varies depending on the strength of the currency in your country. This ensures fairness and inclusivity for everyone, no matter where they’re located. Whether you’re in a country with a stronger or weaker currency, the system would ensure you pay a fair price that corresponds to your purchasing power.

For example, a service that costs 100 points in the UK would still cost 100 points in Nigeria, but the conversion to your local currency would vary based on local exchange rates. This helps eliminate disparities due to currency strength while maintaining a fair, points-based pricing model.

The Benefits of This Model
Eliminating Unnecessary Subscriptions: You no longer have to commit to a monthly or yearly subscription for services you don’t use regularly. This can reduce costs and prevent wasted payments.

More Flexibility and Control: By paying for services as you use them, you have more control over your expenses. If you’re not using a service, you’re not paying for it.

Inclusivity: The system’s currency adjustments based on the strength of your local currency ensure that users from different countries aren’t at a disadvantage. It also removes the issue of needing multiple currencies or dealing with fluctuating exchange rates.

Simplifying Payments: The centralized payment system eliminates the need for multiple payment inputs, streamlining your interactions with various platforms.

Well....it is just a thought for now.

TIPS & SECRETS TO MY YOUNGER SELF

Bede E. Hampo — Fri, 20 Sep 2024 08:49:53 +0000

There's a popular saying: "A man's morning starts when he wakes up." While true, it doesn't negate the fact that others may have risen before you. This speaks to the reality that we are all moving through life at different velocities but within our unique time zones. As a software engineer, I've come to realize that this also applies to our learning journeys.

I’m a firm believer in learning by doing. It's not just about getting things right—it’s about making mistakes, fixing bugs, and navigating errors. This is what we call experiential learning, and it’s proven to be the most effective way to grow as a software engineer. The process of getting your hands dirty with real projects, and solving real problems, is where the real mastery begins.

However, I often wonder—what if we had access to certain insights earlier on? How much smoother, more productive, and even more profitable could our journey have been? There's so much that matters in the tech industry that goes beyond just writing good code. Professionalism, understanding industry trends, and knowing what truly matters in your career can make all the difference.

That's why I've made it my mission to share these crucial lessons. I’ve also been fortunate to invite seasoned professionals to discuss their experiences, providing insights that could help others avoid common pitfalls and accelerate their growth.
No matter where you are on your journey, remember—you're in your time zone. Keep pushing forward, learning from your successes and mistakes alike. The road to mastery is one paved with experience, and there’s no substitute for the knowledge gained along the way.

Speakers
Emmanuel Idoke - Senior Software Engineer
Funmi Adebanji - Senior QA Engineer
Izuchukwu Udechukwu - Business Consultant

To hear directly from our speakers, click the link below to watch the full episode.
https://youtu.be/Nwyy1g9B2Rg?si=h7ZIdhjXf3Cuf49Y
Don’t forget to drop your points and experiences in the comments, like, and share!

Tutorial Hell - The Escape Routes

Bede E. Hampo — Mon, 02 Sep 2024 06:28:58 +0000

Introduction

In the ever-evolving field of software development, many engineers find themselves caught in a perpetual loop of learning, unable to break free from an endless cycle of tutorials and courses. This common challenge, often referred to as "tutorial hell," can stem from various factors. In this episode, we delve into our personal experiences with tutorial hell, exploring its causes and sharing practical strategies for overcoming it. Our goal is to help engineers break free from this cycle, develop productive learning habits, and ultimately save time and energy while fostering growth and development in their careers.

Host - Bede E. Hampo, Senior Software Engineer
Guest 1 - Ajayi Michael, Senior Software Engineer
Guest 2 - Ademola Thompson, Backend Engineer

What is tutorial Hell

In our discussion on tutorial hell, we each offered unique perspectives. For me, tutorial hell represents undirected or misguided learning paths that lack clear direction. Mr. Thompson, our guest speaker, defines it as an over-reliance on tutorial content to accomplish tasks. This often leads to a lack of confidence in executing tasks independently, even when one has a general idea of what needs to be done.
Mr Ajayi, on the other hand, describes it as a stage where individuals have moved past the initial challenge of committing to learning but struggle to apply their knowledge to projects that differ from those covered in tutorials. As a result, they find themselves perpetually searching for the next tutorial to guide them through their next project.

Common Cause Of Tutorial Hell

A common reason I found myself stuck in tutorial hell was self-doubt—feeling inadequate or believing I didn’t know enough. I recall searching for internship roles and constantly encountering new skills listed in job descriptions that I didn’t possess. Even without understanding the practical use of these skills, I would dive into learning them, often without a clear purpose.

Mr. Thompson pointed out that this issue often stems from an unstructured learning path and a lack of a clear vision or end goal. This can lead to jumping from one exciting technology or framework to another, resulting in a broad but superficial understanding. This approach can hinder one's ability to tackle complex problems effectively. He also noted that when individuals are tasked with building a solution, such as an e-commerce website, they may search the internet for a step-by-step guide. They often get stuck if they can’t find a resource that matches their exact requirements.

Mr Ajayi added that many tutorials are designed to present a perfect, error-free solution. However, experiencing and overcoming bugs and errors is crucial for building an engineer's confidence. Many tutorials promote the idea of "more typing, less thinking," but in reality, coding is about 70% thinking and 30% typing. Learners must understand that striving for perfection is less valuable than gaining practical experience through debugging and problem-solving.

Hints

To truly grow as an engineer, becoming comfortable with reading and writing documentation is essential. Patience with documentation—whether you're reviewing existing docs or creating your own—is a key skill for development and continuous learning. Embracing this practice not only enhances your understanding of the technologies you work with but also contributes to more effective problem-solving and knowledge-sharing within the engineering community.

How To Avoid Tutorial Hell

Mr. Thompson shared a few proven strategies to help break free from tutorial hell. When tutoring, he assigns exercises that differ from those he uses to explain similar topics, encouraging his mentees to apply their knowledge in new and challenging ways. He also emphasizes the importance of reading and understanding error messages, guiding his mentees on how to search for solutions rather than simply providing the answers. This approach has been tested to build confidence and the ability to solve complex problems independently. Additionally, he encourages engineers to engage in project-based learning—working on projects related to the topics they’ve learned, but different from the examples provided in tutorials. He likens tutorials to crutches, which are meant to assist you in walking, but the ultimate goal is to walk on your own, and that’s where project work becomes crucial.

Mr. Ajayi, on the other hand, stresses the importance of having a mentor. A mentor isn’t just someone who teaches you; they guide you, understanding your end goals and drawing from their industry experience to steer you in the right direction. This guidance can make your journey smoother and save a lot of energy. In situations where finding a mentor isn’t possible, he recommends learning through apprenticeship. Apprentices tend to learn more quickly and confidently because they gain practical experience, learn from their mistakes, and observe best practices firsthand. He also advises students to focus on crash courses and then channel their energy into projects. These projects offer focused learning and improve knowledge retention. His key advice: learn like an apprentice—pick the project before learning a new technology.

Level Up Your Backend Engineering with Self-Directed Learning

Bede E. Hampo — Wed, 05 Jun 2024 08:54:34 +0000

Ever feel the pressure to find answers instantly online? A common debate amongst engineers is whether to seek out solutions online or directly ask a colleague. While I value the collaborative nature of our field, there's immense power in self-directed learning for backend engineers.

Here's why:

Sharpen Your Research Skills: The internet is a vast landscape of resources. Sifting through countless sources hones your ability to identify high-quality information and become an expert scavenger of knowledge.
Become a Debugging Master: The process of troubleshooting online resources mirrors debugging complex systems. You learn to analyze, identify inconsistencies, and find the optimal solution – a valuable skill for any backend engineer.
Unplanned Discoveries: The beauty of the web is its interconnectedness. Your initial search might lead you down a rabbit hole of valuable knowledge you never anticipated. This fosters a growth mindset and keeps your skillset evergreen.

Collaboration is Key, But Prioritize Self-Learning:

Leverage the expertise of your network! But before seeking immediate help, consider these steps:

Exhaustive Search: Dedicate focused time to online research. Pay attention to the credibility of sources and identify patterns in successful solutions.
Deepen Understanding: If you encounter a particularly complex concept, prioritize finding clear and concise resources before seeking clarification.
Seek Help Strategically: If you've genuinely exhausted your options, then reach out to a colleague. Frame your questions thoughtfully, highlighting the specific areas where you're stuck.

The True Mark of a Backend Mastermind:
The ability to learn quickly and independently is a hallmark of a successful backend engineer. By honing your research skills and embracing self-directed learning, you'll transform yourself into an unstoppable problem-solving machine.

Let's discuss this in the comments below! What are your favourite resources for staying ahead of the curve?

Conventional backend system Vs ML backend system

Bede E. Hampo — Mon, 03 Jun 2024 09:03:25 +0000

One significant difference I've noticed in exploring machine learning in the backend compared to a traditional backend system can be likened to cooking a meal. In a conventional backend system, you have all the necessary ingredients, know the recipe, and have a clear idea of the expected result. In contrast, building an ML backend system is like having the ingredients and understanding the expected results, but not having a recipe.

Software Engineers Learn More from Failures than Wins: A Perspective

Bede E. Hampo — Sun, 02 Jun 2024 00:06:08 +0000

In the world of software engineering, success stories often dominate discussions, but it’s the failures that truly shape and hone an engineer’s skills. While wins provide validation and motivation, failures offer invaluable lessons that drive growth and innovation. Here’s why failures are so crucial in the learning process for software engineers:

Uncovers Weaknesses: Failures expose underlying weaknesses in code, architecture, or development processes that often go unnoticed during successful projects. For instance, a failed deployment might reveal gaps in the continuous integration pipeline or highlight insufficient test coverage.
Encourages Problem-Solving Skills: When a project fails, engineers must dissect the issue, understand its root cause, and devise a solution. This process of troubleshooting and debugging enhances critical thinking and methodical problem-solving abilities.
Promotes Innovation: Failures push engineers out of their comfort zones, encouraging them to explore new technologies, tools, or methodologies. A failed approach might lead to the discovery of more efficient or effective alternatives, fostering innovation.
Teaches Resilience and Adaptability: The frequent uncertainties in software development teach engineers resilience. They learn to cope with setbacks and adapt quickly, which is essential in a rapidly evolving industry.
Enhances Understanding of Systems: Failures often provide a deeper understanding of the systems and technologies involved. For example, a memory leak issue might lead to a deeper knowledge of memory management, which is crucial for designing robust software.
Improves Collaboration and Communication: Resolving failures often requires collaboration, improving communication skills and teamwork. Engineers learn to articulate problems clearly, listen to diverse perspectives, and work together to find solutions.
Build a Culture of Continuous Improvement: Embracing failure fosters a culture of continuous improvement. Organizations that see failure as a learning opportunity encourage their engineers to take calculated risks and innovate without fear of blame.

Embracing failure not as a setback but as a stepping stone is crucial for continuous learning and growth in the ever-evolving field of software engineering. By learning from their mistakes, software engineers can improve their skills, innovate, and contribute to building more resilient and efficient systems.

The Surprising Benefits of Eliminating Toxicity"

Bede E. Hampo — Wed, 15 May 2024 04:18:01 +0000

The beautiful and honest truth is that if toxicity and negative attitudes are eliminated from the workplace, even those who were the architects of the toxicity will benefit massively. Let’s swallow our pride, heal from our trauma, and strive to be better. Let the heaven we hope to see someday start with our immediate environment.

Motivation is the wrong reason.

Bede E. Hampo — Sat, 04 May 2024 18:09:22 +0000

I had the privilege of speaking as a guest speaker at the Re-inventing Self in Tech programme. It was an honour because it provided me with the opportunity to discuss key areas often overlooked in the EduTech sector: 1. Motivation; 2. Building Systems; and 3. Experiential Learning.

Motivation: While it's commendable, I firmly believe that motivation alone isn't sufficient to embark on or sustain a tech career. This is because motivation is primarily driven by inherently inconsistent emotions. What happens when you encounter boredom, lack daily motivation, struggle with understanding a concept, or face challenges securing an internship or job? Motivation can only offer temporary drive. You need something more stable, a more substantial reason.

Building Systems: Certain systems foster growth and the development of positive habits; mere wishing for success isn't enough. Building a system requires self-understanding and honesty about your strengths and weaknesses. With a better grasp of yourself, you can research industry skill trends and identify sustainable skills. Seek professional advice from experienced individuals at adplist.org and utilise roadmap.sh to understand the requirements for acquiring those skills. Additionally, understand your learning patterns and seek a mentor, friends, or a supportive community to hold you accountable on your journey.

Experiential Learning: Believe me, you'll likely forget about 70% of what you learn within a week. That's why I discourage beginners from immediately purchasing courses. Once you understand the roadmap to your desired career, utilise a crash course and start applying your collective knowledge to build something first. After engaging in at least three to four challenging projects, you can then look for a well-structured course to purchase. With this approach, anything you learn from those courses will stick much better. Remember, the power lies in utilising knowledge, not simply possessing it. Learn through doing.