DEV Community: Antony Oduor

The Partnership Paradox: Why AI Is Struggling to Replace Human Judgment in Software Development

Antony Oduor — Tue, 08 Jul 2025 08:29:04 +0000

AI is taking over. I cannot remember how many times I have heard this sentiment over the past week alone. While it is true that AI might be taking over, there has been an interesting overlap dragging on for the last two years where work that was supposedly going to be replaced by AI has not only thrived but evolved to be more effective when AI is paired with human expertise.

I would like to offer an alternative perspective on what I think is actually happening. Yes, AI is gaining traction, most notably in big tech, but here is where it gets interesting. While big tech companies are actually leading AI adoption in development practices, they are doing it much more carefully than the rest of us. They have stable systems that have been in place for the longest time, and while the rest of the world moves faster and adopts newer languages and technologies, big tech usually has to move slower due to legacy systems that might not be optimal but offer the best return on investment with minimal effort compared to heavy rewrites. This cautious approach, ironically, might be protecting them from some of the pitfalls I am about to describe.

Within the startup world, using AI almost exclusively might be setting yourself up for significant challenges. First, you are just trying to get to your first hundred customers who need to find enough value to stick with your product. Given the way machines approach work, it is a double-edged sword. Sure, you will move faster within the first two months, but your code base will quickly begin to feel like a decade-old piece of sellotape connecting components with virtually zero separation of concerns. Recent data shows that AI-generated code has led to an 8-fold increase in code duplication and a 7.2% decrease in delivery stability. While we in the startup space need to quickly pivot and iterate, it becomes much harder to do so when you are replacing whole parts entirely. This is not just about immediate failure. It is about accumulating technical debt that becomes increasingly expensive to maintain.

Who am I? I am a software developer who has used AI both by surrendering control and working as partners. As soon as I surrendered control in a few individual projects, I realized that the project worked, but bugs kept popping up. I spoke to a colleague and they provided the solution of using AI to write the tests first. On the next iteration. I wrote the tests first and let AI do its thing. The outcome was amazing, but only at first. I went into the code base only to find single-function files as big as five hundred lines. In the software world we usually say that code is written for other human beings, but since I was not counting on another human to debug the code I had entrusted to AI, I saw no problem having those huge functions.

It was not until my intelligent counterpart was told to go and change the position and color of an overlay that I began to hate my life. A few prompts later, I found myself asking it to return the code base to a certain point in history. What I quickly realized is that instead of trying to fix the code I told it to, it went out and swapped majority of the components with newer, more "advanced" features. On closer inspection, I realized that the more lines it added to fix a single problem, the more bugs it introduced. It was like cutting open another wound in your arm to offset the one in your thigh.

I also learned the hard way that sometimes AI just seems to have a mind of its own. Remember when I gave it the tests? Yeah, when the tests do not work, your counterpart will rewrite them so that they work. I found a test case that had been adapted to make a "feature" work. What is a feature you did not account for? A bug. This is actually a critical blind spot in current AI development practices. AI will modify tests to fit the code rather than maintaining the integrity of what you are actually trying to test. It is like having a student change the answer key to match their wrong answers.

Do not get me wrong, there are bugs that should be nowhere near a software product, but sometimes a bug might just creep in that gives your product a certain refinement you might not have noticed on your own. That is a strength of AI I have fallen in love with. It can stumble upon unexpected solutions that work better than what you initially planned.

What am I advocating for? While I am a fan of AI, I feel that as it stands, it serves you better when you know what you are aiming for. AI will use the path of least resistance to introduce a feature, and this will end up costing you in the end. If you have no idea of the emergent effects it introduces by writing code in a certain way, then you will end up with a program that ideally works but will ultimately be too costly for a startup to recover from. You are not Google or Facebook who have been in the game long enough to pay off any cyber threats from zero-day discoveries, so use your power wisely.

Here is what I have learned works: using AI to quickly iterate not just on business outcomes, but also on alternative implementations. Organizations that implement collaborative AI solutions are seeing productivity increases of up to 40%, but the key word here is "collaborative." The sweet spot seems to be where human judgment guides AI capabilities rather than the other way around. AI is excellent at generating options and handling repetitive tasks, but it still needs human context to understand what actually matters for your business.

I should mention that AI coding tools are evolving rapidly. My experiences from even a few months ago may not reflect the current state of the technology. But the fundamental principle remains: while AI can amplify your capabilities dramatically, it is important to realize that in the end, all logic and no intuition is not good for your business.

The 600-Line Controller That Changed How I Think About Code

Antony Oduor — Thu, 29 May 2025 09:37:47 +0000

Recently, I kicked off work on a new application. While I cannot share all the details just yet, I can talk about how the project turned into a crash course in scalable software design—and how that journey ended up as a talk at the Kisumu Gophers Meetup.

The Stack (and the Problem)

The stack:
Laravel + React + Inertia.js

The challenge:
A 600-line controller packed with tangled business logic, database calls, and view rendering code—all in one place.

Disclaimer
Since I do not know yet what I am allowed to share from the project, I will use a very simplistic example (the boring posts from a blog. I could have gone the Todo way but we could always aim higher) but do not let that fool you—the example will still be valid.

Here is an example snippet from a controller:

// Inside PostsController.php
public function store(Request $request)
{
    $validated = $request->validate([
        'title' => 'required',
        'content' => 'required',
        'image' => 'nullable|image',
    ]);

    $post = new Post();
    $post->title = $validated['title'];
    $post->content = $validated['content'];

    if ($request->hasFile('image')) {
        $path = $request->file('image')->store('images');
        $post->image_path = $path;
    }

    $post->user_id = auth()->id();
    $post->save();

    ActivityLogger::log("Post created by user " . auth()->user()->name);

    return redirect()->route('posts.index')->with('success', 'Post created!');
}

It works. But it is doing way too much.

The controller handles validation, database interaction, file uploads, and logging—all responsibilities that should be separated.

Seeing the Problem Clearly

That controller was only the beginning, but it was a warning sign. If we kept building like this, the app would become a nightmare to maintain.

I had read about Domain-Driven Design (DDD) before, but honestly? I had not truly practiced it. Like many developers, I had leaned on the framework to handle most of the application structure. Laravel is powerful, but it does not stop you from writing tightly coupled spaghetti code.

That is when we hit pause. As a team, we asked: What if we treated Laravel as just a delivery mechanism? What if we moved the actual business logic into its own clean layer?

Spoiler: That decision changed everything.

Our Refactoring Strategy

We introduced a /src directory to contain our domain logic. Each domain had its own folder with services, actions, policies, and contracts. Controllers became light, focused, and boring—in the best way.

The cleaner and clearer separation of concerns:

// PostsController.php
public function store(CreatePostRequest $request)
{
    $this->postService->createPost($request->validated(), $request->file('image'));
    return redirect()->route('posts.index')->with('success', 'Post created!');
}

// src/Posts/Services/PostService.php
public function createPost(array $data, ?UploadedFile $image = null): void
{
    $post = new Post([
        'title' => $data['title'],
        'content' => $data['content'],
        'user_id' => auth()->id(),
    ]);

    if ($image) {
        $post->image_path = $this->uploadService->handle($image);
    }

    $post->save();

    $this->activityLogger->log("Post created by user " . auth()->user()->name);
}

Each class does one thing. That means:

Predictable, isolated changes
Easier debugging
Rapid, low-risk feature additions

Need to add file uploads for another domain? Reuse the upload service—no cross-domain contamination.

Borrowing from DDD (Without Going Full DDD)

We did not follow DDD by the book. There were no aggregates or value objects (yet). But we embraced the principles:

Clear separation between infrastructure and domain
Thin controllers
Explicit service layers

It was not just an academic exercise. The app instantly became easier to work with. There was a point where we realized we needed three more developers, and onboarding the new team members became significantly smoother.

Sharing the Journey

This experience left such an impression that I decided to share it with my local community—the Kisumu Gophers Meetup. Although it is a Go-focused group, my talk was not about PHP or Laravel. It was about architecture, mindset, and patterns that transcend languages.

I focused on the Repository Pattern as an entry point for scalable thinking. And to my surprise, many developers in the room had never encountered these ideas. What I assumed was common knowledge turned out to be eye-opening.

Here is a simplified example I shared:

interface PostRepositoryInterface
{
    public function create(array $data): Post;
}

class EloquentPostRepository implements PostRepositoryInterface
{
    public function create(array $data): Post
    {
        return Post::create($data);
    }
}

Even abstracting the data layer like this helps you think in terms of contracts, not implementations—making your app more adaptable in the long run. Depending on an interface allows you the freedom to have different implementations that can be switched depending on the context.

Final Thoughts

This whole experience reminded me that real-world experience is often the best teacher. You can read all the books and blog posts you want—but it is when you are knee-deep in messy code, trying to make sense of it all, that the lessons really stick.

And the best part? Sharing those lessons helps the entire community grow.

Whether you are writing Laravel or Go, it pays to slow down, clean up, and think about the long-term health of your code. In this age of AI, it is easy to say I will let AI do the whole work. But at some point, the AI loses the context of an awfully long feature, and then you are left with a huge jumbled mess that you have to walk through.

💬 Have you had your own "refactor epiphany"? I would love to hear how you approach controller cleanup and scalable design in your stack.

Bring Your Favorite Linux Commands to Windows Command Prompt in Minutes!

Antony Oduor — Thu, 31 Oct 2024 06:20:10 +0000

If you live a double life where part of your day is spent on Linux and the other part on Windows, I’m about to make things a lot easier. Ever come home, open your Windows machine, type ls by reflex, only to see an error message? Don’t worry; you're not alone. With a small tool called BusyBox, you can bring familiar Linux commands like ls, pwd, and grep to Windows Command Prompt, no WSL or Cygwin needed. Here’s how to set it up quickly so you can switch between Windows and Linux environments with ease.

Why BusyBox?

BusyBox is a tiny, standalone executable that packages many Unix commands. Originally made for embedded systems, it combines dozens of commands into one lightweight program. You can think of it as a Swiss Army knife for Linux commands on Windows! With BusyBox, you get familiar commands without needing a complex setup.

Getting Started with BusyBox on Windows

Here’s a quick guide to set up BusyBox, allowing you to use commands like ls and grep in Windows Command Prompt just as you would in Linux.

Step 1: Download BusyBox

Go to BusyBox for Windows and download the standalone executable.
Place busybox.exe in a folder (for example, C:\busybox\). I like to keep all my custom tools under "C:\Program Files\" so I’d put it in C:\Program Files\busybox\.

Step 2: Add BusyBox to Your System Path

To make BusyBox accessible from any Command Prompt location, add it to your system’s PATH.

Search for “Environment Variables” in the Windows Start menu and open Edit the system environment variables.
In the System Properties window, click on Environment Variables….
Under System variables, locate the Path variable, select it, and click Edit.
Add the directory where you saved busybox.exe (like C:\Program Files\busybox\) and click OK.

To check if it worked, open a new Command Prompt and type busybox ls. If you see a directory listing, BusyBox is set up correctly! If not, double-check the PATH setup.

Step 3: Create Symlinks for Linux Commands

Right now, you’d need to prefix every command with busybox, as in busybox ls or busybox clear. But we can simplify things further by creating symbolic links (symlinks) so that typing ls or clear works as you’d expect. Here’s how:

Open Command Prompt as Administrator. Search for "cmd," right-click, and select Run as administrator.
Run these commands to create symlinks for frequently used commands:

   mklink "C:\Windows\System32\ls.exe" "C:\path\to\busybox.exe"
   mklink "C:\Windows\System32\pwd.exe" "C:\path\to\busybox.exe"
   mklink "C:\Windows\System32\grep.exe" "C:\path\to\busybox.exe"
   mklink "C:\Windows\System32\cat.exe" "C:\path\to\busybox.exe"
   mklink "C:\Windows\System32\clear.exe" "C:\path\to\busybox.exe"
   mklink "C:\Windows\System32\rm.exe" "C:\path\to\busybox.exe"

Replace C:\path\to\busybox.exe with the actual path where you saved busybox.exe. For example, on my machine, I’d use:

   mklink "C:\Windows\System32\ls.exe" "C:\Program Files\busybox\busybox.exe"

Each command above creates a symlink, meaning ls, pwd, grep, etc., will point to BusyBox automatically, no prefix needed.

Pro Tip: BusyBox has many commands available! To see a full list, type:

   busybox --help

You can repeat the mklink command for any other commands you want to use directly.

Step 4: Test Your New Linux Commands

After setting up the symlinks, open a new Command Prompt window and try a few commands. Run ls, pwd, or grep just as you would on Linux. Here are a few examples:

ls
pwd
grep "text" file.txt

If you see normal output without errors, congrats! You’ve just added Linux functionality to your Windows Command Prompt.

Optional: Automate with a Batch File

If you have many symlinks to create, save time by placing all mklink commands in a .cmd batch file. For example, create setup_busybox.cmd, add your commands, then run the file once to set up all symlinks at once. You can run .cmd files by simply writing their name(e.g: setup_busybox.cmd) on the command prompt then pressing the ENTER key.

Final Thoughts

By using BusyBox and symlinks, you can now run common Linux commands on Windows easily. No complex environments, just a lightweight tool and a few shortcuts. BusyBox covers most basic Linux commands, but if you need more specialized tools, consider options like Git Bash or WSL.

Give it a try and enjoy a unified command-line experience on Windows!

The Great Framework Debate. Balancing Flexibility and Efficiency in Software Development.

Antony Oduor — Tue, 24 Sep 2024 08:41:26 +0000

Introduction

In the ever-evolving world of software development, programmers often find themselves at a crossroads: should they build their applications from the ground up, or should they leverage existing frameworks? This decision is not unlike the choice faced by manufacturers when deciding between artisanal craftsmanship and industrial production lines. Both approaches have their merits, and the best choice often depends on the specific needs of the project at hand.

Whether you're a beginner just starting your coding journey or an experienced developer contemplating your next project, understanding the nuances of this debate is crucial. In this article, we'll explore the pros and cons of using frameworks, dive into the evolution of programming needs, and provide insights to help you make informed decisions about your development approach.

The Evolution of Programming Needs

From Solitary to Connected

To understand the framework debate, we need to look at how programming needs have evolved over time. Let's take a trip down memory lane:

The Era of Standalone Applications: Once upon a time, in the not-so-distant past, computer applications were largely solitary affairs. Remember those simple mobile games where you were the sole participant, battling against a computer-controlled opponent? The thrill came from the occasional goal scored, sending dopamine rushing through your brain. It didn't matter if you were the worst player on the planet; the game served its purpose.
The Rise of the Connected Generation: As technology advanced and a new generation of users emerged, these simple games quickly lost their appeal. By the tender age of ten, many young users had conquered all levels of existing games. Unlike human opponents who naturally adapt and improve, computer-controlled adversaries remained static, limited by either computational power or the imagination of their creators.
The Demand for Inter-connectivity: Users began craving more dynamic, interconnected experiences. The focus shifted from playing against a computer to competing against other human beings across the globe. This shift mirrors what we've seen in other industries – just as consumers grew tired of one-size-fits-all products and began demanding customization and interactivity, software users began expecting more sophisticated, connected applications.

The Complexity Challenge

As applications transitioned from standalone programs to interconnected systems, developers faced a new set of challenges that grew exponentially in complexity:

User Authentication: How do we verify the identity of users accessing our system? This is akin to a manufacturing plant needing to implement security measures to ensure only authorized personnel can access different areas of the facility.
Data Security: Once users are connected, how do we ensure their data remains private and secure? This challenge is similar to a car manufacturer needing to protect proprietary designs as they collaborate with global partners.
Scalability: As user bases grow, how do we ensure our systems can handle increased load? This is comparable to a factory needing to ramp up production without compromising quality.
Cross-platform Compatibility: With a myriad of devices and operating systems, how do we ensure a consistent experience across all platforms? This is like an automobile manufacturer ensuring their vehicles can operate efficiently in various climates and road conditions.

These challenges transformed what might have started as a simple game between friends into months of sleepless nights for developers. The burden on programmers continually increased as they grappled with these complex issues.

The Case for Frameworks

Efficiency and Standardization

Frameworks in the programming world are analogous to assembly lines in manufacturing. They provide a structured, pre-built foundation upon which developers can build their applications. Here's how frameworks promote efficiency and standardization:

Pre-built Components: Frameworks come with a treasure trove of pre-built components that handle common tasks. For instance, instead of writing authentication systems from scratch for every project, a framework like Django provides a robust, tested system out of the box. This is similar to how car manufacturers use standardized parts across different models to increase efficiency and reduce costs.
Standardized Practices: Frameworks often enforce best practices and design patterns. This not only improves code quality but also makes it easier for developers to collaborate and understand each other's work. It's like how standardized manufacturing processes ensure consistent quality across different production lines or even different factories.
Tested and Optimized Code: The components provided by popular frameworks have been battle-tested by thousands of developers and optimized for performance. This is akin to how manufacturing equipment is refined and optimized over time to improve efficiency and reduce errors.

Adaptability and Maintenance

Modern frameworks are designed with evolution in mind, much like how modern manufacturing plants are built to be flexible and adaptable:

Regular Updates: Framework maintainers constantly work to support new technologies and programming paradigms. This allows developers to stay current without having to rewrite their entire code base. It's similar to how car manufacturers can update their assembly lines to incorporate new technologies or safety features without rebuilding the entire factory.
Community-driven Improvements: Popular frameworks benefit from a large community of developers who contribute improvements, fix bugs, and create helpful extensions. This collaborative effort is reminiscent of how industry consortia in manufacturing work together to develop new standards and technologies.
Built-in Security Patches: Frameworks often include security features and are regularly updated to address new vulnerabilities. This proactive approach to security is similar to how modern cars receive over-the-air updates to improve their safety and performance.

The Case Against Frameworks

Over-reliance and Skill Atrophy

While frameworks offer numerous benefits, there's a potential downside to relying on them too heavily:

Lack of Understanding Fundamental Concepts: Developers who always work within the confines of a framework may struggle to understand the underlying principles of programming. This is like a modern car mechanic who can replace entire modules but doesn't understand the basic principles of internal combustion engines.
Difficulty in Custom Implementations: When faced with unique requirements that fall outside the framework's capabilities, over-reliant developers may struggle to implement custom solutions. This is akin to a manufacturing plant that can't produce custom orders because workers are only trained to operate specific machinery.
Challenges in Debugging Deep Issues: When problems occur deep within the framework's code, developers who don't understand the underlying systems may find themselves at a loss. This is similar to how over-specialization in manufacturing can lead to difficulties when troubleshooting complex, systemic issues.

One-Size-Fits-All Limitations

Not all projects fit neatly into existing frameworks, and trying to force a square peg into a round hole can lead to problems:

Unique Requirements: Some projects have specific needs that are difficult to implement within the constraints of a framework. This is like trying to use a car assembly line to produce a spaceship – sometimes, custom solutions are necessary.
Performance Overhead: For simple applications, the additional features and abstractions provided by a framework can introduce unnecessary complexity and performance overhead. It's like using a massive industrial oven to bake a single cookie – overkill for the task at hand.
Learning Curve: Specialized frameworks often come with steep learning curves. The time spent learning a framework's intricacies could potentially be better spent developing a custom solution. This is comparable to the training time required for workers to operate complex, specialized machinery in a factory.

The Balanced Approach

The ideal approach combines the best of both worlds, much like how modern manufacturing often blends automated processes with handcrafted precision:

Understand the Basics: Start with fundamentals, learning how to build from scratch with "void main(){}". This foundational knowledge is crucial, just as understanding basic engineering principles is essential for innovative car design.
Learn Common Patterns and Practices: Familiarize yourself with standard design patterns and best practices. This knowledge transcends specific frameworks and provides a solid foundation for problem-solving.
Utilize Frameworks for Efficiency: Leverage frameworks to handle common tasks and speed up development. This allows you to focus on solving unique problems specific to your application.
Know When to Customize: Be prepared to step outside the framework when necessary. Understanding when to build custom solutions is a valuable skill, similar to knowing when a manufacturing process needs to be custom-designed for a specific product.

Visual Representation: Time vs. Project Progress

To better understand the trade-offs between different development approaches, let's look at a visual representation:

This graph compares two main variables:

Time (X-axis): This represents the duration of the project, from its inception to completion and beyond. It includes the initial learning period, development time, and long-term maintenance.
Project Progress / Functionality (Y-axis): This represents the amount of functionality implemented or the overall progress of the project. As we move up the Y-axis, more features are completed, and the project becomes more fully realized.

The three lines on the graph represent different approaches to development:

Custom Code (Red line):
- Starts with a gentler slope, indicating slower initial progress as developers build everything from scratch.
- Gradually accelerates as the foundation is laid, showing faster progress in later stages.
- Ends at a high point, suggesting great flexibility and customization in the long term.
Framework (Green line):
- Begins with a steep learning curve (shown by the initial sharp rise), representing the time needed to learn the framework.
- After the learning phase, progress is rapid (shown by the subsequent sharp incline), as pre-built components speed up development.
- The line flattens out towards the end, suggesting potential limitations in highly specialized or unique requirements.
Balanced Approach (Blue dashed line):
- Starts between the custom and framework approaches, indicating a mix of learning framework basics and custom coding.
- Progresses steadily, benefiting from both framework efficiencies and custom solutions where needed.
- Ends at a high point, suggesting good long-term flexibility and functionality.

Key points illustrated by the graph:

Initial Learning Curve: The annotation highlights the steeper initial curve for the framework approach, representing the time invested in learning the framework's structure and conventions.
Long-term Flexibility: Near the end of the graph shows how custom code and the balanced approach may offer more flexibility for specialized requirements in the long run.
Development Speed: The steepness of each line represents the speed of development. The framework approach shows faster development after the initial learning period, while custom code has a more gradual but steady pace.
Project Completion: All approaches eventually reach the top of the graph, indicating project completion, but they take different paths to get there.

Making the Right Choice for Your Project

When deciding between custom coding, using a framework, or adopting a balanced approach, consider the following factors:

Project Scope and Complexity: For small, simple projects, custom coding might be quicker. For large, complex applications with standard features, a framework could save significant time.
Team Expertise: If your team is already proficient in a particular framework, leveraging that expertise could lead to faster development. However, if the team is skilled in low-level programming, custom solutions might be more efficient.
Long-term Maintenance: Consider who will maintain the project in the long run. Frameworks often have better documentation and a larger community for support, which can be crucial for long-term maintenance.
Performance Requirements: If your application has strict performance requirements, custom code might be necessary to optimize every aspect of the system.
Time Constraints: Tight deadlines might favor using a framework to get a working product quickly, while more flexible timelines allow for custom solutions.
Scalability Needs: If you anticipate rapid growth, frameworks often provide built-in scalability features that could be time-consuming to implement from scratch.
Budget: Framework development can often be more cost-effective initially, but custom solutions might save money in the long run for very specific or long-lived projects.

Conclusion

The debate between custom coding and using frameworks is not about finding a one-size-fits-all solution. Instead, it's about understanding the trade-offs and making informed decisions based on your specific project needs, team capabilities, and long-term goals.

Remember, whether you're building a simple website or the next SpaceX launch system, the right tool for the job might be a framework, a custom solution, or a bit of both. The most successful developers, like the most innovative manufacturers, know how to blend the efficiency of standardized processes with the flexibility of custom solutions.

As you embark on your next project, take the time to evaluate your needs, consider the long-term implications of your choices, and don't be afraid to adopt a balanced approach that leverages the strengths of both custom coding and frameworks. By doing so, you'll be well-equipped to navigate the complexities of modern software development and create solutions that are both efficient and flexible.

Drawing shapes on a computer terminal

Antony Oduor — Tue, 09 Jul 2024 08:05:04 +0000

Have you ever seen cool shapes on a computer screen and wondered how they were made? It's simpler than you might think! We're going to explore how to create these shapes step by step, even if you're new to programming.

Prerequisites and Getting Started

Before we begin, you'll need a basic understanding of how to write a computer program. We'll be using a programming language called Go (or Golang), but don't worry if you've never used it before. The concepts we cover here can be applied to other similar languages like C or Java.

To follow along with the examples, you'll need to have Go installed on your computer. Here’s how you can set things up:

Setting Up Your Project

Open your terminal (that's the black screen where you type commands) and follow these steps:

Create a new folder for your project. Let's call it example-art.

mkdir example-art
cd example-art

Initialize a new Go module in this folder.

go mod init example-art

Create a new file named main.go inside this folder.

touch main.go

Now, your example-art folder should contain two files: go.mod and main.go.

Writing Your First Program

Open main.go with a text editor (like Notepad or TextEdit) and paste the following code:

package main

func main() {
    // Your code will go here
}

Running Your Program

Back in your terminal, type the following command to run your program:

go run .

If everything is set up correctly, your terminal should show no errors.

Note: When you run the program, make sure to include the dot (.) after 'go run'

Now you're ready to start creating shapes on your computer terminal!

Simple Filled Rectangle

Imagine you want to create a filled rectangle like the one shown, with a specific width and height

******************** 
******************** 
******************** 
******************** 
******************** 
********************

Instead of looking at it as a bunch of stars that span multiple lines, it will be easier if you looked at it as a grid which contains empty characters to begin with

The grid is made up of rows which run from top to bottom.

Did you notice the i == 2? In this article, all of our counting will begin at 0. We will therefore count like this: 0, 1, 2, 3, et cetera. In the figure above, i == 2 indicates the position of that row from the starting point. Hence the third row is at position 2. It is best to get used to this form of counting since it is quite commonly used within the computing world.

Each row is made up of a certain number of cells. While we are at this row, we can access its individual cells, each time updating the value with the desired character

In essence, what we need to do is iterate through each row, and within each row, populate its cells with a specific character. In programming, we achieve this using a construct called repetition. Repetition allows us to repeat a statement multiple times without having to rewrite it each time. For instance, if we wanted to emphasise the line "I am learning to draw shapes on the terminal" by printing it one million times, instead of,

package main

func main() {
    println("I am learning to draw shapes on the terminal")
    println("I am learning to draw shapes on the terminal")
    println("I am learning to draw shapes on the terminal")
    println("I am learning to draw shapes on the terminal")
    println("I am learning to draw shapes on the terminal")
    println("I am learning to draw shapes on the terminal")
    /* 999994 more times of this */
}

We could use repetition to accomplish this in a more compact way, as in,

package main

func main() {
    for i := 0; i < 1000000; i++ {
     println("I am learning to draw shapes on the terminal")
    }
}

Here, for i := 0; i < 1000000; i++ sets up a loop that repeats the println statement a million times, incrementing i from 0 to 999999.

nested for loops
Take for instance you wanted to print five stars in a single line. The for-loop below would accomplish this, without having to repeat the print(“*”) statement five times.

for in := 0; in < 5; in++ {
    print (“*”)
}

The output of that program would be

*****

Do you remember how we used loops to print a line multiple times? What if we treated the for loop above as a unit in the sense that we can also repeat it a certain number of times? In programming, there is a concept known as abstraction. Abstraction enables us to treat something as if it is a single unit. This will be akin to the concept of a dozen. If someone told you they have a dozen pencils, you would immediately know that they have twelve pencils. The same way to refer to a collection of things can be used in programming. Abstraction allows us to treat a whole block of code that does many things as if it was a single entity. We could essentially refer to the code above as the “inner loop”. If it is a unit, can we also repeat our “inner loop” multiple times?

// first 5 stars
for in := 0; in < 5; in++ {
    print (“*”)
}
// go to the next line
println()

// second 5 stars
for in := 0; in < 5; in++ {
    print (“*”)
}
// go to the next line
println()
// third 5 stars
for in := 0; in < 5; in++ {
    print (“*”)
}

The code above will print 3 rows, each with five stars. The println() is used to move the cursor to the next line so that the next five lines are printed just below the first and not right next to them. We have met such inefficient code before when we needed to print a line a million times. In out case, if we also needed to print a million lines each with five stars, we will have to repeat our “inner loop” a million times. Can we make this more compact? This is where the notion of a unit comes in. We can treat that whole block of code as something that knows how to print five stars in a single line. We can then repeat it many times and each time, it will print the required five stars. But if we can use a for loop to repeat this statement, print(“I am learning to draw shapes”), can we also do the same to repeat the preceding block of code?

for out := 0; out < 4; out++ {
    for in := 0; in < 5; in++ {
        print(“*”)
    }
}

You would notice that we are using a for loop to repeat the block of code we had before (in bold). Abstraction therefore enables us view a collection of things, like our “inner loop” as a single entity which we can easily repeat to produce whatever outcomes we need.

How does this relate to our grid system?
For grids or shapes, we use nested loops. The outer loop controls rows, and the inner loop controls cells or characters within each row. For example:

The complete code example

package main
func main() {
   height := 10                          // Number of rows
    width := 20                          // Number of columns
    for i := 0; i < height; i++ {        // outer loop for rows
     for j := 0; j < width; j++ {     // inner loop for columns
         print("*")      // print a character: *
     }
     println()           // Move to the next line after each row
    }
}

In this combined loop structure:
The outer loop for i := 0; i < height; i++ iterates over each row.
The inner loop for j := 0; j < width; j++ prints a character (e.g., "*") for each column.
After printing all characters in a row, println() moves to the next line for the next row.
These loops allow us to efficiently create and manipulate grids or shapes in programming, scaling from simple patterns to complex structures, all while minimising repetitive code.

Introducing Constraints

Imagine you're creating a drawing using an empty rectangle, like this:

********************
*                  *
*                  *
*                  *
*                  *
********************

When drawing each line in our grid, we follow specific rules, or "constraints," about where characters can appear. These rules ensure that characters only show up in certain places, particularly along the edges or borders of the drawing.

In our previous example, the constraint was effectively "no constraint." This meant we printed "*" in every position of the line. In contrast, our current example introduces a stricter constraint: characters can only be printed if they are within the vertical or horizontal borders.

Vertical Edges (constraints for i): Our outer loop index i correlates to the height (rows). Only draw characters at the very top and bottom lines. So, if we're at the first line (index 0) or the last line (index 5 in this case), we draw characters all the way across.

i == 0 || i == 5

Horizontal Edges (constraints for j): Our inner index j correlates to the width (columns). Along each line, characters only go at the very left and right edges. For example, at position 0 and position 19 (since we have 20 columns in total).

j == 0 || j == 19

Putting It All Together: To decide if we should draw a character at any position, we check these rules. If the position meets any of these conditions — being at the top or bottom line, or at the far left or right of any line — then we draw a "*" character. Otherwise, we leave that spot blank with a space (" ").

i == 0 || i == 5 || j == 0 || j == 19

Complete code Example

The same principles from before still apply, however, when it comes to drawing the characters on each line, we need to introduce constraints as stated so that we can only print a character if a certain constraint is met. There are four constraints that we need the indexes i and j to adhere to before we print a character. We, therefore, need to print a non-empty character if and only if these constraints are met.

package main

func main() {
    rows := 6
    columns := 20


    for i := 0; i < rows; i++ {
        for j := 0; j < columns; j++ {
        // our constraints
            if i == 0 || i == (rows-1) || j == 0 || j == (columns-1) {
            // constraint met. 
            // print a non-empty character
                print("*")
            } else {
                // index not along the border
                // print an empty character
                print(" ")
            }
        }
        // move to the next row
        print("\n")
    }
}

Overarching Idea

The following procedure can be replicated across different examples to produce any shape imaginable:

Outer: Loop the number of times as the lines you have.
    Inner: For each line,
    - If there is a constraint that makes that particular line appear different, take it into account.
    - Otherwise, draw the character in every position of the line

finally

The next time you see a graphical shape on someone’s screen and wonder how it’s done, remember it often starts with simple loops. By understanding how loops and constraints work, you can unlock the potential to create visually interesting designs in your terminal. With practice and creativity, you can build more complex shapes, patterns, and even complete ASCII art masterpieces.

You can find an enhanced version of this code in a repository. While the repository will continue to evolve, the fundamental shapes mentioned here will always stay the same. Access the code at this link or visit https://github.com/oduortoni/console-art.git in your web browser.