DEV Community: Rosebella Wandere

Building a Data Analyst Agent with Google ADK.

Rosebella Wandere — Mon, 21 Sep 2026 08:50:39 +0000

Lessons in Agentic Workflows

At the recent Build with Google AI event in Kisumu, the core focus centered around a fundamental shift: moving from single-prompt chat completion to Agentic Workflows.

Instead of asking one LLM to solve a complex problem in a single turn, agentic patterns split tasks across specialized, autonomous units coordinated by an orchestrator.

To explore this hands-on, I built a Data Analyst Agent using the Google Agent Development Kit (ADK). Here's a quick look at the build, the bugs I bumped into, and the concepts behind them.

What is Google ADK?

Google's Agent Development Kit (ADK) is an open-source, code-first Python framework for building and testing AI agents. It gives you:

Agents: Individual units with specific roles and instructions.
Tools: Custom functions (SQL execution, Python scripts, APIs) that agents invoke autonomously.
Orchestration: Dynamic routing loops to chain multiple agents together.
Development UI & Tracing: A local server (adk web) to monitor API calls, inspect payloads, and debug agent reasoning in real time.

Crucial Concept: Model Context Protocol (MCP)

A key concept when building agentic systems is the Model Context Protocol (MCP). MCP serves as a standardized bridge between AI models and external data sources or execution environments.

Rather than hardcoding custom integrations for every database or API, MCP gives agents a uniform interface to securely read context, access files, and call tools across different systems.

The Build & How I Fixed the Roadblocks

I instantiated the agent in agent.py using standard ADK imports:

from google.adk import Agent

data_agent = Agent(
    name="data_analyst",
    model="gemini-2.5-flash",
    instruction="You are an expert Data Analyst AI...",
)

During local testing in the ADK web UI, I hit two quick configuration bumps:

1. Requesting a Non-Existent Model (`404 NOT_FOUND`)

The Issue: The agent attempted to contact a model string that didn't map to a valid Vertex AI endpoint (gemini-1.5-flash), causing the platform to reject the request.
The Fix: I updated the model configuration to a valid target identifier: gemini-2.5-flash.

2. A Malformed Resource String (`400 INVALID_ARGUMENT`)

The Issue: A formatting slip left a space in the string ("gemini-2.5 flash" instead of a hyphen), breaking the API URL parser.
The Fix: I removed the stray space across .env and agent.py.

Finalizing the Credentials

After fixing the config files, I refreshed my local session using gcloud auth application-default login. Re-running adk web gave a clean 200 OK status, allowing the agent to successfully process data requests and generate summaries.

Key Takeaways

Watch Configuration Syntax: Model names must exactly match active provider endpoints; minor typos break API routing.
Standardize Tools with MCP: Leveraging protocols like MCP makes connecting agents to external databases and environments seamless.
Use Local Tracing: Running local inspection interfaces (adk web) drastically speeds up finding API-level bugs.

Why Algorithms Matter

Rosebella Wandere — Mon, 07 Sep 2026 14:01:17 +0000

Why Algorithms Matter: What a Sorting Project Taught Me About Programming

When I started learning programming, I thought most problems could be solved by just writing enough code. Eventually I realized something important: the hardest part isn't always writing the code , it's deciding what the code should do. That's where algorithms come in.

While working on a sorting project recently (a Push-Swap implementation, where you sort numbers using two stacks and a limited set of operations), I had to think hard about different ways to sort data, how those approaches scale, and how to work within strict constraints. What caught my attention was the algorithmic thinking behind it, and that's what I want to share.

What Exactly Is an Algorithm?

An algorithm is a step-by-step procedure for solving a problem. Say you have 5 2 8 1 3 and you need 1 2 3 5 8. Getting there is straightforward in principle, but there are many ways to do it:

Repeatedly find the smallest value and place it.
Compare neighboring values and swap them.
Divide the problem into smaller pieces and merge the results.
Process the digits or bits of each number instead of comparing whole values.

All of these produce the same result. What makes algorithms interesting is how they get there and that difference has real consequences for performance.

The Same Problem, Very Different Solutions

A simple sorting approach is Bubble Sort: repeatedly compare neighboring elements and swap them if they're in the wrong order.

For 5 2 8 1:

5 2 8 1  → compare 5,2 → 2 5 8 1
2 5 8 1  → compare 5,8 → 2 5 8 1
2 5 8 1  → compare 8,1 → 2 5 1 8

Keep repeating until nothing needs swapping. It works, but its worst-case time complexity is O(n²), which gets expensive fast as n grows. This raises a real developer question: if two algorithms solve the same problem, which one should you choose?

Complexity Changes Everything

Say Algorithm A runs in O(n²) and Algorithm B runs in O(n log n). For small inputs, the difference barely matters. At n = 1,000, though:

n²        = 1,000,000
n log₂n  ≈    10,000

That's a huge gap in work done. This is why understanding time complexity matters. Correct code can still be a poor solution if it doesn't scale.

Big O Isn't About Exact Seconds

One common misunderstanding is that Big O tells you exactly how many seconds an algorithm takes. It doesn't, instead it describes how the amount of work grows relative to input size.

O(1) — constant time. Work doesn't grow with input size.

value := numbers[0]

O(n) — linear time. Double the input, roughly double the work.

for _, number := range numbers {
    // process number
}

O(n²) — quadratic time. Double the input, and the work can roughly quadruple.

for i := 0; i < n; i++ {
    for j := 0; j < n; j++ {
        // work
    }
}

O(log n) — logarithmic time. Binary search is the classic example: instead of checking every element, you eliminate half the remaining search space each step (1,000,000 → 500,000 → 250,000 → ... → 1). The core idea: don't just make progress, eliminate unnecessary work.

Selection Sort: Simple but Expensive

Selection Sort repeatedly finds the smallest remaining element and moves it into place. For 4 2 7 1 5, you find 1, move it to the front, then find the next smallest, and so on.

It's easy to understand and implement, but it performs roughly n²/2 comparisons, still O(n²). For small collections that's often fine. For large ones, it's a sign to look for something better. Lesson: the simplest algorithm isn't always the best one.

Divide and Conquer

Merge Sort is a classic divide-and-conquer algorithm: split the data into smaller pieces, sort those, then merge them back in order.

[8 3 5 1 4 2]
   /       \
[8 3 5]   [1 4 2]
 /   \      /   \
...  ...  ...  ...
   \       /
    merge
      |
[1 2 3 4 5 8]

Merge Sort runs in O(n log n) in both the average and worst cases.This is a meaningful improvement over quadratic sorts like bubble sort and selection sort for large datasets, though it typically needs extra memory for merging.

Radix Sort and Binary Representation

One of the more interesting algorithms I ran into is Radix Sort. Unlike Bubble or Merge Sort, it doesn't compare elements directly, it sorts based on their representation, digit by digit or bit by bit.

For binary Radix Sort, take 2, 3, 4, 5:

Process one bit position at a time, starting from the least significant bit. Partition the numbers by whether that bit is 0 or 1, then move to the next bit, and the next. After processing all bit positions, the numbers end up sorted.

The key idea: instead of comparing whole numbers, you can process a small part of their representation at each stage. This works because integers have structure you can exploit, you don't always need direct comparisons to organize data.

On complexity: for n numbers with k bits (or digits) each, binary/digit Radix Sort does roughly O(nk) work. k here is the number of bits (or digits) needed to represent the largest value for fixed-size integers (like 32-bit ints), k is a constant, so the sort behaves close to linear in n. But k isn't free: for arbitrarily large or variable-length keys, it matters, and Radix Sort also needs extra space for the buckets/counting step. It's not "always better" it's a good fit for specific kinds of data.

Algorithms Have Trade-Offs

Time complexity isn't the only thing that matters. You should also weigh memory usage, implementation complexity, stability, and how well an algorithm fits your actual data.

Algorithm       Average Complexity
----------------------------------
Bubble Sort     O(n²)
Selection Sort  O(n²)
Merge Sort      O(n log n)
Quick Sort      O(n log n)*
Radix Sort      O(nk)

Quick Sort's worst case is O(n²), depending on pivot choice and implementation.

There's no algorithm that wins in every situation, the "best" one depends on context.

Constraints Can Change the Best Algorithm

If you can use any operation you want, sorting is straightforward. Now imagine you're given two stacks, a limited set of operations, no direct indexing, and a goal of minimizing the number of moves that's roughly the Push-Swap problem. Suddenly the "best" algorithm isn't the one with the best theoretical complexity; it's the one that respects the constraints you actually have.

This happens constantly in real software:

Limited memory → pick a memory-efficient algorithm.
Huge dataset → pick something that scales well.
Low latency requirement → optimize the critical path.
Limited bandwidth → reduce the data you transfer.

Constraints aren't just restrictions, they help determine the solution.

Greedy Thinking

A greedy algorithm makes the best-looking choice at each step, without looking ahead. This doesn't always produce a globally optimal result, but for the right class of problems, it does. Recognizing when greedy thinking is appropriate is a skill on its own, and it shows up well beyond sorting in scheduling, resource allocation, shortest-path problems, and compression. At its core, it's a decision-making pattern: look at the current state, pick the best local option, move to the next state, repeat.

Algorithmic Thinking Over Memorization

You don't need to memorize every sorting algorithm. What matters more is asking the right questions when you face a problem:

What's the input? Numbers, strings, graphs, objects, files?
What's the output? What exactly counts as "correct"?
What constraints exist? Memory, time, allowed operations, input size?
What patterns exist in the data? Sorted already? Bounded values? Repeats?
How does the solution scale? What happens at 10 items vs. 1,000,000?
Can you reduce unnecessary work? Often the most important question of all.

Why This Matters Beyond Sorting

You might think: "I build web apps, why do I need sorting algorithms?" The thinking behind them applies everywhere.

If your API searches records, you can scan everything, or use an appropriate data structure and search strategy. If your app recalculates the same expensive result repeatedly, you can compute it every time, or cache it. If you're processing millions of records, you can reach for a quadratic approach, or look for something closer to O(n log n).

The language, framework, or database might change. The core question remains: how do you solve this efficiently, given your constraints?

Algorithms Make You Think Before You Code

Without algorithmic thinking, development can turn into: hit a problem, start coding, something breaks, add more code, add another condition, add another loop, hope it works.

Algorithmic thinking pushes a different process instead: understand the constraints, model the problem, choose a strategy, analyze the complexity, implement, test, optimize if needed. It's a stronger habit, and it pays off even outside classic algorithm problems.

You Don't Need the "Best" Algorithm

It's also easy to over-optimize. Not every problem needs the most sophisticated solution. If you have ten elements, an O(n²) approach might be completely fine. If you have ten million, it's worth thinking harder.

The useful question isn't "what's the fastest algorithm?" it's "what's the appropriate algorithm for this problem?" That's a much more practical engineering mindset.

Final Thoughts

Working through a sorting problem reminded me that algorithms aren't just academic exercises, they're a way of thinking. They teach you to break problems down, recognize patterns, understand constraints, measure complexity, and weigh trade-offs.

Knowing how to write code lets you make a program work. Understanding algorithms lets you ask a better question: will this still work well when the problem gets much bigger? That's the difference between writing code and engineering a solution.

What Happens Behind the Code?

Rosebella Wandere — Mon, 10 Aug 2026 06:28:43 +0000

Compilers vs. Interpreters: What Really Happens Behind the Code?

As developers, we spend a lot of time writing code, but how often do we stop to think about what actually happens after we write it?

Understanding how computers work behind the scenes is not just theoretical knowledge. It can help us understand why programs behave the way they do, where errors come from, and how to approach debugging more effectively.

Compiler vs. Interpreter

At a high level, both compilers and interpreters help a computer understand and execute the code we write, but they do it differently.

A compiler translates the entire program into machine code before the program is executed.

An interpreter, on the other hand, translates and executes the program as it runs, rather than producing the complete machine-code program beforehand.

A simple way to understand it

Imagine you have a book written in French, but you only understand English.

With a compiler, you would translate the entire book first. Once the translation is finished, you can sit down and read the English version without having to stop and translate every sentence.

With an interpreter, you would translate the book sentence by sentence while reading it. You translate one sentence, read it, then move on to the next sentence.

The first approach requires more preparation upfront, but once the translation is complete, reading can be much faster.

This is a simple analogy for why compiled programs can generally have better execution performance as much of the translation work has already been done before the program runs.

Understanding this distinction has become particularly interesting to me as a go lang beginner.
Go is a compiled language. When I write Go code, the Go compiler translates the source code into machine code that the computer can execute.
For example:
go build main.go
This compiles the Go program and produces an executable file.
I can then run that compiled program without having to translate the source code every time it executes.
Compared with an interpreted language, this gives compiled languages some important advantages:

Faster execution: The translation into machine code happens before execution.
Early error detection: The compiler can catch many errors before the program runs.
Efficient execution: The computer executes compiled machine code directly rather than repeatedly interpreting the source code.
Standalone executables: Go can compile programs into executable binaries that can be distributed and run on compatible systems.

Interpreted languages also have their own advantages, particularly when it comes to flexibility and rapid development. However, because interpretation happens during execution, there can be additional runtime overhead compared with already-compiled code.

Why Does This Matter to Developers?

Understanding concepts such as compilation, interpretation, memory, processes, and execution gives developers a better mental model of what happens between writing code and seeing the result.

This can make debugging easier because instead of treating errors as random problems, we can start reasoning about where and why something went wrong.

Learning to code is not just about learning syntax or memorizing functions.
I am beginning to realize that becoming a better developer also means understanding what happens underneath the code we write.
As I continue learning Go, concepts like compilers and interpreters are helping me connect the code I write with what the computer is actually doing behind the scenes.
And I think that understanding is just as important as knowing how to write the code itself.

Git is Much bigger than I ever Imagined

Rosebella Wandere — Wed, 29 Jul 2026 08:40:07 +0000

Over the past few days, I've been diving deep into Git, and one thing surprised me the most:

Git is much bigger than I thought.

Like many beginners, I used to think Git was mainly about commands like:
git clone
git pull
git push
git branch
git merge
git status

They're important, but they're only scratching the surface.
Working through a comprehensive Git project pushed me beyond the everyday commands. I learned about branching strategies, merge conflicts, rebasing, tags, remotes, bare repositories, reflog and even explored what actually lives inside the .git directory.

One of the biggest eye-openers was exploring the .git folder. Before this project, it was just a hidden directory I never paid attention to. Now I understand it's the heart of every Git repository. It stores commits, trees, blobs, references, configuration, and everything Git needs to track a project's history.

Another fascinating discovery was Git Reflog. I had no idea Git keeps a record of where your branches and HEAD have been, making it possible to recover work that seems "lost." That completely changed how I think about mistakes in Git.

One of my biggest takeaways was realizing how Git enable teams to collaborate efficiently. Understanding merges, rebases, conflict resolution, branch tracking, remotes and shared repositories has given me much greater confidence in contributing to collaborative software projects.

This journey reminded me that learning Git isn't about memorizing a handful of commands. It's about understanding how Git works under the hood and knowing which tool to use for different situations.

I'm still learning, but I can already see how this knowledge will make me a better developer and teammate.

What's one Git feature you discovered much later than you wish you had?