DEV Community: Lamka Joy

Writing SQL in Go Without Losing Type Safety: An Introduction to sqlc

Lamka Joy — Thu, 22 Oct 2026 09:27:35 +0000

One thing I've been exploring after GopherCon Africa 2026 is how Go developers work with databases. That's where I came across sqlc, a tool that makes writing database code in Go a little more interesting.

So, what does it actually do?

What is sqlc?

When building an application, you might write SQL queries to fetch or insert data into a database. You then need Go code to execute those queries and work with the results.

Usually, this means writing some extra code to connect the two.

sqlc generates Go code from your SQL queries, allowing you to write the SQL yourself while getting generated Go functions with defined types.

In simple terms, you write the query, and sqlc helps handle the Go code around it.

How does it work?

Imagine we're building an application that stores information about farmers.

We might have a farmers table and want to retrieve a farmer using their ID.

First, we write the SQL query:

-- name: GetFarmer :one
SELECT id, name
FROM farmers
WHERE id = ?;

The comment tells sqlc how to name the generated function and indicates that the query should return one row.

After configuring sqlc and running its code-generation command, it generates Go code that lets us call the query through a function rather than writing all the database-access code ourselves.

For example, the generated function might be used like this:

farmer, err := queries.GetFarmer(ctx, farmerID)
if err != nil {
return err
}

fmt.Println(farmer.Name)

This is an illustrative usage example; the exact function signature depends on your database driver and sqlc configuration.

Why would you use it?

A few things make sqlc useful:

Type safety: Generated code uses Go types for query parameters and results, helping catch certain mistakes at compile time.

Less repetitive code: You can spend less time manually writing code to scan database results into Go values.

SQL stays readable: You write and maintain your queries directly instead of hiding them behind an abstraction.

Of course, sqlc doesn't eliminate every possible database error. A query can still fail at runtime, and you still need to design your database and write correct SQL.

My takeaway

What I find interesting about tools like sqlc is how they help connect two things developers work with regularly: SQL and Go.

Instead of choosing between writing SQL yourself and having convenient Go code to work with its results, sqlc lets you do both.

I'm still exploring the Go ecosystem, and it's interesting discovering the tools that make everyday development a little easier.

Have you ever used sqlc in a Go project, or do you prefer writing your database-access code manually?

Domain-Driven Design in Go: Writing Code Around the Problem

Lamka Joy — Thu, 22 Oct 2026 09:19:23 +0000

At GopherCon Africa 2026, one of the concepts that caught my attention during the Go workshop was Domain-Driven Design (DDD).

The idea is simple: your code should reflect the problem you're trying to solve, not just the technology you're using.

But what does that actually mean when you're writing Go?

Let's use a simple example.

*What is Domain-Driven Design?
*
DDD is an approach to software development that focuses on understanding the business problem before deciding how to build the solution.

Imagine we're building a smart irrigation system to help farmers determine when their crops need water.

Our application might involve sensors, a database, and an API. But those are just the technical components.

The actual problem we're solving revolves around farms, soil conditions, and irrigation decisions.

DDD encourages us to model these concepts in our code.

What does this look like in Go?

Go gives us structs and methods that we can use to represent concepts from our problem domain.

For example, imagine we're working with soil moisture readings:

package main

import "fmt"

type SoilMoisture struct {
Percentage float64
}

func (s SoilMoisture) NeedsWater() bool {
return s.Percentage < 30
}

func main() {
soil := SoilMoisture{Percentage: 25}

if soil.NeedsWater() {
    fmt.Println("The soil may need watering.")
}

}

Here, SoilMoisture represents a concept in our application, while NeedsWater() expresses a simple rule related to it.

The 30% threshold is illustrative. A real irrigation system would need to consider factors such as soil type, crop requirements, and sensor readings before making a recommendation.

The interesting part is that the rule is connected to the concept it describes. We're not hiding it inside a database query or an HTTP handler.

It's a small example, but it demonstrates how we can make our code reflect the problem we're solving.

Why does this matter?

As applications grow, mixing business rules with database operations and HTTP handlers can make changes harder to manage.

Separating these responsibilities can help us:

Maintain our code: Changes to one component are less likely to affect unrelated parts.

Test business rules: We can test important behaviour without always needing a database or external service.

Understand the application: Code becomes easier to navigate when its structure reflects the problem we're solving.

Of course, DDD involves more than structs and methods. Understanding the business domain and using its language consistently are also important.

And not every project needs a complicated architecture. Sometimes, a simple structure is all you need.

What did I get from all this?

One thing I'm learning is that writing software isn't just about making features work. It's also about how we organise our code so we can understand and maintain it as the application grows.

DDD encourages us to start with the problem, identify the concepts that matter, and let that understanding guide our design.

I'm still exploring these concepts, but it's interesting to see how a little thought about structure can make a difference in how we build software.

Good code isn't necessarily code with more layers. Sometimes, it's code that represents the problem clearly.

Attending GopherCon Africa opened my mind to a whole new set of possibilities. I'm realising just how much there is to learn beyond simply getting code to work.

How do you approach structuring your Go projects?

Your Go Code Works. But Is It Efficient?

Lamka Joy — Wed, 21 Oct 2026 15:13:25 +0000

At GopherCon Africa 2026, one of the things that caught my attention during the Go workshop was profiling.

It got me thinking about something: we spend so much time making sure our code works, but how often do we stop to ask whether it's working efficiently?

So, I did a little more reading, and here's what I learned.

So, what is profiling?

Simply put, profiling helps you understand what's happening inside your application while it's running.

Is your code using too much CPU? Is it consuming more memory than necessary? Is something slowing it down?

Instead of guessing, profiling helps you investigate what's actually happening.

And apparently, Go has a tool for this called pprof.

Why should we care?

Imagine building an application that works perfectly during development. Then more users start using it, and suddenly, things get slower.

Your first instinct might be to start changing things until performance improves. But what if you're fixing the wrong thing?

That's where profiling comes in. It helps you identify potential bottlenecks so you can focus on the parts of your code that actually need attention.

And here's the part I found particularly interesting: small improvements can have a bigger impact than we think.

If an application is wasting resources, fixing the problem could improve performance and potentially reduce infrastructure costs, especially at scale.

It's a reminder that software development isn't just about getting things to work. It's also about understanding how they work.

Where does pprof come in?

Go's pprof tooling helps developers investigate different aspects of an application's performance.

For example:

CPU profiling helps identify where processing time is being spent.
Memory profiling helps you understand how your application uses memory.
Goroutine profiling helps you investigate what your goroutines are doing.

You don't necessarily need to know everything about profiling to appreciate why it matters. Even understanding what these tools can help you investigate is a good starting point.

Of course, profiling doesn't automatically fix your code. You still need to understand what the results mean, make changes, and check whether those changes actually helped.

My biggest takeaway?

Sometimes, improving software isn't about adding more features or rewriting everything.

Sometimes, it's about looking at what you already have and asking, "Could this be working better?"

I'm still learning Go, and profiling is one of those concepts that reminded me how much there is to explore beyond simply writing code that works.

One thing's for sure: I'll be paying more attention to what happens behind the scenes from now on.

If you've worked with Go before, have you used pprof? I'd love to hear about your experience!

Further reading

Profiling Go programs
Go diagnostics

Git Real: From Faking Conflicts to Surviving Real Ones

Lamka Joy — Mon, 20 Jul 2026 08:44:33 +0000

Let’s be honest: learning Git as a beginner can feel like absolute hell.
In the beginning, you’re memorizing commands like magic spells such as git add, git commit -m "fixed stuff", git push, without really understanding what’s happening behind the curtain. You hear developers talk about branches, rebasing, and merge conflicts as if they're everyday occurrences, but until you hit those hurdles yourself, it all feels abstract.

Recently, while working on projects at my developer program, I went from intentionally trying to break Git just to see what a conflict looked like, to unintentionally manifesting a full-blown merge conflict in my very next project. Here is what that journey taught me about navigating Git, resolving conflicts, and surviving the dangerous lure of the force push.

The Weird World of "Ghost" Conflicts
During one of our early team assignments, we were specifically instructed to practice handling merge conflicts. A conflict happens when Git cannot automatically reconcile differences between two commits, typically because two people modified the exact same line in the exact same file in contradictory ways.

I set up my separate branches, made edits on both sides, prepared my mind for chaos, and executed the merge. To my complete surprise, everything merged smoothly without a single warning or conflict marker. It was baffling to say the least.Then now I actually had to go out of my way to force a failure just so I could learn how to solve one. I had to manually edit identical lines across both branches to finally trigger those infamous angle-bracket conflict markers. At the time, it felt like a controlled laboratory experiment, but as every developer quickly learns, real software projects rarely stay inside the lab for long.

Be Careful What You Wish For: Manifesting a Real Conflict
Fast forward to my next project. I was working on a web application, feeling confident, and pushing code across different features when suddenly an actual merge conflict halted my build. It felt as though I had manifested the very nightmare I was trying to simulate earlier.

Unlike my rehearsed test, this was real code that I could not afford to lose. The initial shock quickly dissolved once I realized that a merge conflict is not a system failure, but rather Git asking for human judgment. Instead of making risky assumptions about which code matters more, Git pauses and hands control back to you.

To resolve a conflict without relying on structured step-by-step checklists, you simply treat the file like any other code review. You open the conflicted file, locate the section flagged by the markers, and evaluate both versions side by side. Once you choose the ground truth—whether that means keeping your local changes, accepting the incoming branch's changes, or manually combining both into a better solution—you erase the leftover conflict markers. Staging the modified file and executing a standard commit seals the resolution, leaving the repository clean and ready for deployment.

Rebase vs. Merge: Keeping History Clean
As branching becomes second nature, developers inevitably encounter git rebase as an alternative to git merge. While standard merges preserve every historic branch intersection by creating a dedicated merge commit, they can leave your commit history looking like a chaotic subway map.

Rebasing solves this visual clutter by taking your branch's unique commits and replaying them individually on top of another target branch. This process rewrites history to present a clean, linear story of development. However, because rebasing alters existing commit hashes, it introduces a vital rule of thumb: you should never rebase commits that have already been pushed to a shared public repository, as it disrupts the history for everyone else on the team.

Playing with Fire: The Infamous Force Push
This historical rewriting brings us to one of the most dangerous commands in a developer's toolkit: git push --force. When you rebase a local branch that was previously pushed upstream, Git will reject a standard push command because your local history no longer aligns with the remote server's records.

Executing a force push instructs the remote repository to discard its current state and forcibly accept your local history. If a teammate pushed code to that remote branch in the meantime, their hard work gets completely wiped out without warning. To prevent accidental data loss, experienced developers favor using --force-with-lease instead. This safer option acts as an automatic guardrail, refusing to overwrite the remote repository if anyone else has updated it since your last pull.

Conclusion
Mastering Git commands like checkout, rebase, and reset requires making mistakes and stepping through uncomfortable terminal errors. Yet, once you get the hang of it, Git transforms from an intimidating chore into an indispensable superpower. It provides a safety net that allows you to experiment freely, recover from mistakes, and collaborate seamlessly across teams. The initial learning curve may be steep, but emerging on the other side as a confident developer makes every struggle worth it.

From Terminal to Container: The Evolution and Dockerization of an ASCII Art Web Application.

Lamka Joy — Mon, 20 Jul 2026 08:26:38 +0000

Being a software developer just looks like a journey of learning something new everyday. Recently, I embarked on this exact progression with a project called ascii-web art. What began as a simple command-line interface (CLI) application written in Go evolved into an interactive web service, which was ultimately packaged inside a Docker container. Through this process, I gained firsthand experience in web development, containerization, and did research on the foundational principles of container orchestration with Kubernetes.

Phase 1: Building in the Terminal
The initial iteration of the project was a pure terminal application. The core logic read plain text input from the command line, parsed each character, and mapped it to corresponding ASCII banner characters stored in template files such as standard, shadow, or thinkertoy.

While building a CLI application was an excellent way to practice core programming logic, algorithms, and file parsing in Go, it had inherent limitations in terms of usability:

Execution required direct access to a command terminal and the underlying source code environment.

Formatting and visual output depended heavily on the user's local terminal dimensions and font settings.

Non-technical users could not easily interact with or benefit from the tool.

To overcome these barriers and make the program accessible to a wider audience, the next logical step was bringing the application to the web.

Phase 2: Transitioning to the Web
Transitioning the project to a web application meant wrapping the core ASCII generation logic inside an HTTP server using Go's standard library.

Instead of accepting command-line arguments, the application served a web interface containing a clean HTML form. Users could enter their desired text, choose an ASCII font style, and submit the request. The Go backend received the POST request, processed the string through the ASCII generator, and rendered the rendered banner dynamically on the web page.

While this solved the user-accessibility problem, it introduced a common software engineering challenge: environment dependency, commonly summarized as the "works on my machine" problem. Running the application required anyone pulling the project to have Go installed, correctly configure their local environment, and manage directory dependencies for templates and banner files.

Phase 3: Containerization with Docker
To make the application truly portable and self-contained, we containerized it using Docker.

At its core, Docker wraps application code along with its specific runtime, system libraries, configuration files, and dependencies into a single, standardized unit known as a Docker Image. When executed, this image runs inside an isolated environment called a Docker Container. Because the container carries its own lightweight runtime environment, it guarantees that the application runs identically regardless of the underlying host operating system—whether Linux, macOS, or Windows.

The Dockerfile Blueprint
To containerize ascii-web art, we authored a Dockerfile at the root of the project to serve as the build recipe:

Phase 4: Beyond Single Containers—Understanding Kubernetes
Working with Docker naturally opens the door to broader infrastructure questions: How do you manage, scale, and maintain hundreds of containers in a production environment across multiple server nodes?

This is where Kubernetes (K8s) comes into play. While Docker excels at packaging and running individual containers on a single host, Kubernetes is a container orchestraPhase 3: Containerization with Dockertion platform designed to automate management at scale. It handles essential operational needs including:

Autoscaling: Spinning up additional instances of a container during traffic spikes.

Self-Healing: Automatically restarting or replacing containers that crash or fail health checks.

Load Balancing: Distributing network traffic across multiple container instances to maintain uptime and performance.

In essence, Docker provides the container, and Kubernetes provides the system to manage an entire fleet of them.

Conclusion
The journey of building and containerizing ascii-web art highlighted the practical value of modern software architecture patterns. Moving from a CLI utility to a web application made the software accessible to end-users, while wrapping it in a Docker container made it instantly deployable for developers and systems administrators alike. Understanding containerization—along with the foundational concepts of orchestration tools like Kubernetes—provides a strong foundation for building portable, scalable, and resilient cloud-native applications.with Kubernetes.