DEV Community: Bernadette Akinyi

How Software Actually Talks to Software

Bernadette Akinyi — Wed, 16 Sep 2026 18:40:31 +0000

If you've built anything beyond a script that only talks to itself, you've probably used an API — even if you didn't fully know why it worked. I want to break down what's actually happens, because once it clicks, a huge chunk of modern software development starts making sense.

What Actually is an API??

Well, it stands for Application Programming Interface for starters.
Simply it lets software talk to each other without needing to know how they work internally.

This isn't limited to "frontend talking to backend." Frontend-to-backend is just the most familiar. This basically means APIs can talk to other APIs and other backends and totally different software. For instance, using a banking app to make a purchase on an online store.

Most web APIs today are REST APIs; they use standard HTTP methods to represent actions on resources:

Method	Purpose	Example
`GET`	Retrieve data	Get a user's profile
`POST`	Create new data	Register a new user
`PUT`	Replace existing data	Update a full profile
`PATCH`	Partially update data	Update just an email
`DELETE`	Remove data	Delete a user account

Data is usually exchanged as JSON; a lightweight human readable text format.

{
  "city": "Kisumu",
  "temperature": 24.5,
  "condition": "Partly cloudy"
}

The API does not store the JSON; it is just the format in which data travels in for one request or response

Let's call a public API and map the response into a clean data structure:

from dataclasses import dataclass
import requests

# Step 1: Define the shape of the data we expect back.
# This is our data model — think of it as a blueprint for one "weather record."
@dataclass
class WeatherData:
    city: str
    temperature: float
    condition: str

# Step 2: Write a function that makes the actual API call.
def get_weather(city: str) -> WeatherData:

    url = f"https://api.example.com/weather?city={city}"
    response = requests.get(url)          # the actual HTTP request
    response.raise_for_status()           # raise an error if the request failed
    data = response.json()                # parse the JSON body into a Python dict

    return WeatherData(
        city=data["city"],
        temperature=data["temp_c"],
        condition=data["condition"]
    )

# Step 3: Use it.
weather = get_weather("Kisumu")
print(f"{weather.city}: {weather.temperature}°C, {weather.condition}")

The WeatherData does not know or care how it was fetched as you can see from the snippet. It just describes the shape of the data.
response.json() translates the JSON text into a Python dictionary you can use.
raise_for_status() matters because APIs fail, rate limits, bad request and downtime can occur. Always handle that instead of assuming success.

Once you understand APIs as contracts for communication, not as data containers, a lot of architecture decisions become intuitive: why we version APIs, why rate limiting exists, why error handling isn't optional, and why good API design makes or breaks a developer's experience using your system.

All software engineers are authors, but not all authors are software engineers.

Bernadette Akinyi — Mon, 07 Sep 2026 17:37:39 +0000

Before there is a website, there is nothing.

Just an idea.

Maybe it's scribbled on a piece of paper. Maybe it's sitting in someone's head. Maybe it's just a sentence:

"I want to build something that helps people."

Then someone starts writing.

Not with a pen, but with code.

A few lines become a page. A page becomes a navigation bar. The navigation bar leads somewhere else. That page leads somewhere else. A button triggers an action. A form collects information. An API connects one thing to another.

And suddenly, there is a story.

This is why I've started thinking about software engineers differently.

All software engineers are authors, but not all authors are software engineers.

An author writes a story that takes a reader from one point to another.

A software engineer does something surprisingly similar: they create experiences that take users from one state to another.

The difference is that a software engineer doesn't always know which chapter the user will read next.

The user chooses.

It is an act of creation.

You start with nothing but an idea, and through thousands of small decisions, you create something that didn't exist before.

You write the structure.

You write the rules.

You write the interactions.

You write the experience.

And eventually, someone else comes along and experiences the story you wrote.
They may never see your code.

They may never know your name.

They may never realise how many decisions went into the button they just clicked.

But they experience it.

And perhaps that's what makes software engineers authors.
We don't just write stories.
We write stories that people can interact with.

VIBE CODER?

Bernadette Akinyi — Fri, 31 Jul 2026 18:12:14 +0000

HEY TECHIE 🌸

I have always believed, for quite a long while, that there was no point in vibe coding. My thought process was, "Why prompt it when I can do it myself ?" The whole idea was that if I built it from scratch, it would be more fulfilling to me because I made it. I mean, there's nothing wrong with that, but I limited myself from exploring this new, not-so-new wave dynamic.

You might wonder where that got me; funny enough, I've been stuck in tutorial hell and staying a novice. Never really getting to level up as much as I would like. The ideas, innovations- I had them all; the problem was they were limited to just my mind because I kept waiting for when I would be perfect and ready.

So, yesterday, abruptly, I joined a machine learning group where I basically study, and there was an ongoing hackathon they had been working on and only about ten hours left before the deadline. Did I sign up for the hackathon? I did. Did I regret my decision? At first, I kept thinking about what I had got myself into and that I would make a fool of myself. I stayed up late, whipping my AI to get to work and give me something, and when it generated so much, I realised I was not familiar with the concepts I witnessed at that moment, and I shut down my laptop and went to sleep, giving up on the whole idea.

"Even if you are not ready for the day, it cannot always be night." — Gwendolyn Brooks

And morning came; I absolutely did not want to turn up, but I did anyway. Throughout, I kept thinking of how maybe I should just not do it and decided to get my whipper friends, if I may. Email after email, credit exhaustion after exhaustion and in less than three hours my Idea had come to life, not perfect, but it came to life. It was so beautiful being able to do something in such a small amount of time, and an idea could be presented.

I did present my idea, obviously not really understanding what went on technically for the most part, but I did learn quite a lot in such a short time frame. Presenting my idea and having people give me insights on feature recommendations I did not consider, the business aspects and technical suggestions really opened my mind and as much as I keep learning, I will venture into vibe coding and whip the hell out of it.

I'd love to hear about your experiences. Do you think it's worth venturing into, or do you prefer building everything from scratch? Let me know your thoughts! 🌸

Building IRIS: An Adaptive Accessibility Companion

Bernadette Akinyi — Sun, 26 Jul 2026 09:42:03 +0000

Hey Techie 🌸

Before I continue my go series, I wanted to share a personal project that I'll be working on alongside my learning.

What is IRIS?

IRIS is an adaptive accessibility companion meant to help people with invisible disabilities navigate the media in ways preferable to them.

Most websites and systems are one-size-fits-all and do not take user preferences into account in depth. The assumption is that every user views technology the same way, and that's not true at all. This is where IRIS shines her glory.

The goal of creating IRIS is that it adapts to the user's needs rather than the user adapting to it. She will be able to personalise things like text-to-speech, colour themes, layouts, and other accessibility features based on their needs.

As I continue learning Go and backend development, I'll also be sharing the progress of building IRIS, from designing the database and API to developing the backend and, eventually, the complete application.

I look forward to sharing my progress and the challenges I will face and having discussions with you, my dear techie friends 🌸

Slices Beyond the Basics

Bernadette Akinyi — Thu, 23 Jul 2026 15:45:59 +0000

Hey Techie! 🌸

Welcome to my Go series! I'll be sharing what I'm learning in ways that make sense to me, the mistakes I make and the "aha!" moments that help everything click. Whether you're learning Go too or just curious about it, I hope you'll pick up something along the way.

Feel free to add any insights or experiences in the comments.

Today's topic is... drumroll, please! Slices. Let's dive in!

So, what exactly is a slice?

When I first came across slices in Go, I thought they were another name for arrays. Turns out, they're not!

A slice is a dynamic view into an underlying array. It is internally represented by a small data structure called a slice header. Instead of storing the elements themselves, the slice header stores a pointer to the underlying array, along with its length and capacity. This realization helped me understand why modifying a slice can also modify the original array.

Another interesting and convenient thing is how flexible slices are compared to arrays which are fixed size. Slices can grow using functions like append() or be resliced to work with a smaller portion of the underlying array. This flexibility is one of the reasons slices are used so frequently in Go.

A little heads up, I used AI to clean up my grammar and typos. The technical ideas and thoughts in this article are 100% my own.