DEV Community: Paul Owuor

Architecture Beyond the Hype: The Hidden Costs of Deconstructing the Monolith

Paul Owuor — Wed, 23 Sep 2026 19:37:33 +0000

Architecture Beyond the Hype: The Hidden Costs of Deconstructing the Monolith

In 2014, microservices transitioned from an internal architectural pattern practiced by a handful of tech giants into an industry-wide imperative. The narrative was clean and persuasive: monolithic architectures were slow to test, impossible to scale cleanly across sprawling organizations, and prone to catastrophic, single-point failures. Divide your domain into discrete services, give each bounded context its own database, and teams would ship independently at unprecedented velocity.

A decade later, a substantial fraction of engineering organizations discovered that instead of eliminating their technical debt, they merely distributed it over an unreliable network.

When you decompose a system across process and physical boundaries, you do not just change where code executes. You fundamentally swap predictable, in-memory function calls and local ACID guarantees for partial failures, split-brain realities, eventual consistency, and the unforgiving physics of distributed networks.

Before splitting your next service—or if you are currently navigating the friction of an overly granular architecture—it is critical to evaluate the true operational taxes that distributed systems demand, and how to rigorously decide whether you actually need them.

The Illusion of Decoupling

The most common justification for decoupling components into independent services is developer independence: Service A can deploy without Service B knowing or caring.

In practice, operational coupling frequently survives the architectural split, masquerading as independent services that are secretly glued together by runtime dependencies.

1. Temporal Coupling and Cascading Outages

In a monolithic application, if Component A invokes a function in Component B, that invocation takes nanoseconds. If Component B takes slightly longer to compute, Component A waits in memory, bounded by a thread or coroutine pool.

Across network boundaries, that same invocation introduces an uncontrollable variable: the network transit time, queue depth at the remote reverse proxy, serialization overhead, and the current saturation of the downstream host.

If downstream Service B encounters high CPU load or a transient database connection spike, Service A’s client connections begin backing up. In a naive system without aggressively tuned timeouts, bulkhead isolation, and circuit breakers, Service A exhausts its own socket descriptors or request worker pool waiting for Service B. Within seconds, a localized performance dip in an auxiliary service cascades upward, taking down user authentication, checkout flows, and static catalog lookups simultaneously.

You have not decoupled your systems; you have created a distributed monolith that shares failure domains across a network cable.

2. Schema Drift and Semantic Contracts

In a shared codebase, a breaking interface change is immediately visible. The compiler or test suite flags every caller that fails to provide the new argument, and static analysis catches regressions before code merges to the main branch.

In distributed microservices, contracts are enforced at runtime across HTTP APIs, gRPC protobufs, or message schemas. Even with contract testing frameworks, versioning strategies frequently break down in the wild:

Field deprecations require multi-stage deployments spanning weeks.
Serializers disagree on the handling of nulls, missing keys, or timestamp formats.
A client team makes assumptions about side-effects that the upstream service alters in a patch release.

The operational overhead shifts from running a compiler to coordinating multi-repository release schedules, maintaining backwards compatibility layers indefinitely, and hunting down silent schema mismatches in staging environments.

The Distributed Data Dilemma

Software engineering is fundamentally the manipulation of state. The hardest problems in computing do not concern compute; they concern state consistency, durability, and coordination. Monolithic architectures abstract these challenges by leaning heavily on relational databases that provide ACID properties out of the box.

The moment you declare "each microservice owns its private database," you abandon the single most powerful tool in modern software engineering: the atomic transaction.

The Myth of the Easy Distributed Transaction

In a single database, debiting an account and creating an audit record is trivial: you begin a transaction, execute two statements, and commit. The database engine's write-ahead log ensures that either both events persist across power failures, or neither does.

When the ledger belongs to Service A and the audit record belongs to Service B, a simple state update requires distributed transaction mechanics:

Two-Phase Commit (2PC): While theoretically sound, 2PC creates a synchronous coordination lock. If the coordinator or any participant stalls during the prepare phase, locks are held open, throughput drops to near-zero, and system availability plummets. In high-scale web environments, 2PC is almost universally avoided due to its severe latency penalty and fragility.
The Saga Pattern: Most teams pivot to orchestrating sagas—a sequence of local transactions where each step triggers the next via asynchronous messaging, paired with compensating transactions to undo prior steps if a downstream phase fails.

Sagas sound straightforward on a whiteboard. In production, compensating actions are notoriously leaky abstractions:

What happens if a compensating refund fails mid-execution?
What happens when the user observes an intermediate state (the money was deducted, but the inventory was not yet reserved) and cancels their order in the UI before the saga resolves?
How do you reconstruct the exact state of an order when three out of four asynchronous steps executed, but network partitions delayed the fourth by twenty minutes?

You are suddenly forced to re-implement isolation and atomicity primitives within your own business logic—areas where relational database engines have spent forty years optimizing edge cases.

The Reporting and Aggregation Tax

Monolithic relational databases allow you to join disparate tables with index-backed efficiency. Need to display an administrative view combining user status, recent payments, risk scores, and shipping tracking? A single query resolves it in milliseconds.

In a microservices ecosystem, that single query is impossible. Your application must either:

Scatter-Gather at the API Gateway: Issue four concurrent HTTP or RPC requests to four discrete services, wait for the slowest response, and assemble the payload in memory. This multiplies your latency by the $p99$ tail of your downstream dependencies and turns your gateway into a high-memory choke point.
Event-Driven Materialized Views: Stream CDC (Change Data Capture) or domain events from all four services into a unified read model stored in an analytical or document database.

While the materialized view pattern works, the hidden cost is immense: you must now manage message streaming infrastructure, partition keys, event deduplication, out-of-order event delivery, and the engineering overhead of debugging reconciliation errors when the read store silently falls out of sync with the systems of record.

The Operational Balance Sheet

Transitioning to distributed services is not simply an architectural choice; it is an organizational restructuring that demands specialized operational tooling. Every divided boundary extracts an infrastructural dividend that must be paid continuously.

Observability Under Partitioning

Debugging an issue in a unified process space is straightforward: stack traces pinpoint the exact line of execution, and logs can be correlated by process thread.

In a distributed environment, a simple user action might traverse an edge proxy, an API gateway, an authentication service, three intermediate orchestration layers, and two asynchronous worker queues. If an error occurs:

Correlation IDs are mandatory: Every boundary must strictly extract, propagate, and log a unified tracing context.
Distributed Tracing infrastructure: You must deploy, maintain, and budget for massive telemetry ingest platforms to trace spans across systems.
Log Aggregation Volume: Debugging requires aggregating terabytes of structured logs across dozens of ephemeral container clusters, where finding signal in the noise requires complex query mechanics and significant operational cost.

Without world-class observability, mean time to resolution (MTTR) climbs exponentially. Engineers spend hours arguing which service caused a dropped request rather than resolving the underlying bug.

Local Development Friction

One of the most immediate casualties of microservice proliferation is the developer onboarding experience.

When a system fits into a single repository, getting started is straightforward: clone the repo, run a script to seed a local database, and run the development server. Feedback loops are tight; running integration test suites takes seconds.

When a system spans twenty services, running the application locally becomes untenable:

Does an engineer run all twenty services in a heavyweight local container runtime, turning their laptop fans into jet engines and consuming all available RAM?
Do they rely on mock services, which inevitably drift from production behavior and invalidate local testing?
Do they share remote development environments in the cloud, introducing network lag, shared-state conflicts, and high monthly cloud bills?

When local test velocity degrades, developers stop running comprehensive tests before opening pull requests. Quality assurance shifts rightward into shared staging environments or production itself, directly undermining the development velocity the architecture was supposed to unlock.

When Microservices Are Actually Justified

Despite these formidable challenges, microservices are not inherently flawed. They are an advanced engineering solution to a very specific set of problems. The mistake most teams make is adopting them to solve code organization problems rather than scaling problems.

Microservices earn their operational tax under specific conditions:

1. Massive Organizational Scale (Conway's Law)

The primary beneficiary of microservices is not the computer; it is the human organization.

When an engineering department grows beyond 100 to 150 engineers, a monolithic codebase becomes an organizational bottleneck. Merge queues stretch for hours, deployment schedules require cross-team coordination meetings, and a bad commit from one sub-team blocks releases for the entire company.

At this threshold, microservices serve as organizational firewalls. They allow completely autonomous business units—with their own product managers, on-call rotations, and release cadences—to iterate rapidly without stepping on each other's code. You trade infrastructure efficiency for organizational decoupling. If your entire engineering department can sit in a single conference room, this tradeoff will actively harm your productivity.

2. Disparate Hardware and Runtime Requirements

A service split makes architectural sense when components have fundamentally incompatible computational profiles:

An ingestion engine requiring massive network I/O and low-latency memory handling.
A CPU-bound machine learning inference service needing GPU-accelerated instances and specialized system libraries.
A core transactional API requiring high-memory, standard compute instances.

Forcing these wildly different workloads into a single deployment artifact forces you to provision your entire fleet to satisfy the highest common denominator, driving up infrastructure costs. Here, physical decoupling provides immediate operational and financial returns.

3. Asymmetric Scaling Demands

If 98% of your system's traffic hits a public-facing read-heavy endpoint (such as a search index or real-time catalog), while your administrative and reporting dashboards receive minimal use, scaling the entire monolithic application horizontally wastes compute resources.

Extracting that specific high-throughput slice into an independently scalable service running on dedicated auto-scaling pools is a surgical, cost-effective optimization.

The Pragmatic Alternative: The Modular Monolith

If an engineering team has not reached hyper-scale, how do you avoid the maintenance traps of both a chaotic, tangled codebase and the crippling complexity of premature microservices?

The answer lies in the Modular Monolith.

A modular monolith preserves the deployment simplicity and transactional guarantees of a single binary while strictly enforcing logical domain boundaries within the code structure:

Explicit Module Boundaries: Business logic is segmented into discrete domain packages. A domain module exposes only high-level interfaces to other packages; internal entities, database tables, and utility functions remain private.
Zero Cross-Domain Database Joins: Even within a shared relational database, modules restrict their queries strictly to the tables they own. If the Billing domain needs information from the User domain, it must request it through the User domain’s internal Go, Rust, or TypeScript interface, rather than issuing a raw SQL query that joins the tables directly.
Internal Event Busses: For asynchronous side-effects—such as sending a welcome email after account creation—modules publish internal events across an in-memory channel or event dispatcher rather than invoking methods directly.

By structuring a monolith with rigorous internal boundaries, you retain single-command deployments, painless local development, atomic database transactions, and zero-latency in-memory execution.

Most importantly, you preserve your architectural optionality. If a specific domain module eventually outgrows the monolith due to team size or extreme scaling demands, extracting it into an independent microservice is straightforward: the boundaries, interfaces, and data models are already cleanly separated.

You extract the service when you have empirical data proving the necessity, rather than guessing your architectural requirements ahead of time.

Architectural Maturity Is Knowing What Not to Build

Architecture is not about finding the "correct" pattern; it is the deliberate practice of evaluating tradeoffs. Every design decision is an explicit agreement to accept one set of problems in exchange for another.

Microservices solve scale: scale of teams, scale of divergent workloads, and scale of organizational complexity. But they demand a high price in operational complexity, consistency challenges, and infrastructure management.

Engineering excellence is not defined by how many moving parts you can stitch together across an AWS region. It is measured by your ability to deliver reliable, maintainable business value with the minimum amount of complexity required. Before you break apart your next system, ensure the problem you are solving is large enough to justify the world you are about to inherit.

Learning JavaScript by Breaking Things

Paul Owuor — Sun, 13 Sep 2026 19:29:07 +0000

Learning JavaScript by Breaking Things

There’s a particular kind of confidence you get from writing code that works.

Then there’s the much more useful kind you get from writing code that doesn’t work — and figuring out why.

That’s where I am right now.

My journey at Zone01 Kisumu has increasingly become less about learning syntax and more about learning how to think like a developer.

And the current Piscine JavaScript phase has been making that very obvious.

JavaScript has a way of humbling you

A task can look ridiculously simple:

“Write a function that does X.”

You write it.

You run the tests.

It fails.

You stare at the code.

You swear the code is correct.

You run it again.

It fails in a completely different way.

Eventually, you discover that the problem wasn't the function itself. Maybe it was how you handled an edge case. Maybe you misunderstood what the test expected. Maybe your assumptions about JavaScript were simply wrong.

And that's the interesting part.

I'm starting to realize that programming isn't primarily about knowing what to type.

It's about developing the ability to ask:

What exactly is happening here?

The small things are teaching me a lot

We've been working with concepts like:

ES modules
Higher-order functions
Promises and asynchronous JavaScript
Error handling
Timeouts and retries
File manipulation
HTTP servers
JSON
Basic authentication
Objects and functions
Testing and debugging

None of these concepts are particularly mysterious on their own.

The challenge is putting them together and making them behave exactly as expected.

A test failing because a URL contains hello+world instead of hello%20world can teach you more about how a system actually works than reading ten pages of documentation.

At least, that's how it feels sometimes. 😅

I'm learning to stop guessing

One of the biggest changes I've noticed in myself is how I approach errors.

Earlier, an error message could feel like something standing between me and the solution.

Now I try to treat it as evidence.

If something says:

ReferenceError: something is not defined

the useful question isn't:

“Why is JavaScript being annoying?”

It's:

“Where is this value supposed to come from, and what assumption did I make about its scope?”

That shift sounds small.

It isn't.

It's changing how I debug.

The goal isn't to memorize JavaScript

There are far too many methods, APIs, quirks, and edge cases to memorize everything.

What matters more is becoming comfortable navigating unfamiliar problems.

Read the error.

Inspect the code.

Check the documentation.

Write a smaller test.

Make a hypothesis.

Test it.

Break it again.

Repeat.

That's becoming the real curriculum.

From “I know this” to “I can figure this out”

I think that's one of the most valuable things Zone01 has been teaching me.

There's a difference between saying:

“I know JavaScript.”

and saying:

“Give me a JavaScript problem and I'll figure it out.”

I'm much more interested in becoming the second person.

There are still plenty of moments where I get stuck.

There are still bugs that make absolutely no sense for the first 30 minutes.

There are still tests that seem personally offended by my code.

But I'm getting better at staying with the problem.

And maybe that's the point.

Not becoming someone who never gets stuck.

Becoming someone who knows what to do when they are stuck.

Still learning. Still debugging. Still breaking things.

And, hopefully, getting a little better every day.

Zone01 #JavaScript #WebDevelopment #SoftwareDevelopment #LearningToCode #DevJourney

Learning to Learn: The Biggest Lesson I've Gained at Zone01 Kisumu

Paul Owuor — Wed, 29 Jul 2026 00:36:24 +0000

Learning to Learn: The Biggest Lesson I've Gained at Zone01 Kisumu

When most people think about learning software engineering, they picture classrooms, lectures, and hours of note-taking.

That wasn't my experience.

My journey at Zone01 Kisumu has been different. Instead of being told exactly what to do, I've been challenged to find answers, solve problems, and learn through building.

At first, that was intimidating.

Today, I realize it has been one of the most valuable learning experiences I've ever had.

There Are No Step-by-Step Instructions

One of the first things I noticed was that nobody hands you the solution.

You're given a project.

You're given documentation.

You're given teammates.

The rest is up to you.

That can feel overwhelming, especially when you're used to structured tutorials.

But that's also how real software engineering works.

Developers don't always have someone standing beside them explaining every error message or writing every function.

They investigate.

They experiment.

They learn.

Google Became My Classroom

Early in my journey, I thought asking for help immediately was the fastest way to solve problems.

Now, my first instinct is different.

I search documentation.

I read official guides.

I experiment.

I fail.

I try again.

This habit has made me a far more independent learner than I ever expected.

One of the greatest skills a developer can have isn't memorizing syntax—it's knowing how to find reliable information.

Debugging Is Part of the Job

Some of my biggest breakthroughs have come after hours of debugging.

At first, I viewed bugs as failures.

Now I see them as feedback.

Every bug teaches something:

A missing validation
A misunderstanding of a concept
A wrong assumption
A better way to structure code

The more I debug, the more confident I become.

Not because I make fewer mistakes—but because I know how to solve them.

Learning With Other Developers

One of the best parts of Zone01 Kisumu is the peer-to-peer learning model.

There are no competitors.

Everyone is learning.

Everyone gets stuck.

Everyone has something to contribute.

I've learned that explaining a concept to someone else often deepens my own understanding more than simply reading about it.

Software engineering is a collaborative profession, and learning to communicate technical ideas is just as important as learning to write code.

Projects Teach More Than Tutorials

Throughout my journey, I've worked on projects that required me to think critically rather than simply follow instructions.

Each project introduced new concepts, new challenges, and new opportunities to improve.

More importantly, they taught me how different parts of software development come together to solve real problems.

Building projects forces you to think about architecture, debugging, testing, version control, teamwork, and problem-solving all at once.

That's something no tutorial can fully replicate.

Growth Happens Outside Your Comfort Zone

There were plenty of moments when I questioned whether I was making progress.

Some projects felt impossible.

Some bugs took hours—or even days—to solve.

But every difficult challenge became another lesson.

Looking back, the problems that once seemed impossible are now things I can solve with confidence.

That realization has been incredibly motivating.

My Biggest Takeaway

If there's one lesson I'll carry with me throughout my career, it's this:

Learning how to learn is more valuable than learning any single programming language or framework.

Technology changes.

Frameworks evolve.

Languages rise and fall.

But curiosity, persistence, and the ability to solve problems will always remain valuable.

Final Thoughts

My journey at Zone01 Kisumu is still ongoing, and I know there's much more to learn.

Every project presents new challenges.

Every challenge presents new lessons.

And every lesson brings me one step closer to becoming the software engineer I aspire to be.

If you're beginning your own journey into software engineering, don't be discouraged by difficult projects or frustrating bugs.

Embrace them.

They aren't obstacles—they're part of the process.

Keep learning.

Keep building.

And remember that becoming a developer isn't about having all the answers—it's about never stopping the search for them.

Have you experienced a learning environment that completely changed the way you approach software development? I'd love to hear your story in the comments.

Happy coding! 🚀

Tags: #beginners #career #programming #softwareengineering #learning #webdev #golang #opensource

What I Learned at the Backend Frameworks Mini-Conference

Paul Owuor — Mon, 06 Jul 2026 22:32:00 +0000

As a software engineering apprentice at Zone01 Kisumu, I'm constantly looking for opportunities to learn beyond the projects and challenges I work on every day.

Recently, I attended the Backend Frameworks Mini-Conference, an event focused on backend development, modern frameworks, APIs, databases, deployment, and career opportunities in backend engineering.

The experience reinforced several lessons that every aspiring backend developer should understand.

Backend Development Is More Than Writing APIs

When many beginners think about backend development, they often imagine creating endpoints and connecting databases.

While those are important skills, the conference highlighted a broader picture.

Backend engineers are responsible for building systems that are:

Reliable
Scalable
Secure
Maintainable

A backend application isn't just code that works today. It's code that can continue serving users as traffic grows, requirements change, and new features are added.

This perspective changed how I think about the projects I build.

Frameworks Are Tools, Not Solutions

One of the biggest takeaways for me was understanding that frameworks are simply tools.

Whether you're working with Go, Node.js, Java, Python, or another ecosystem, the framework itself won't solve architectural problems.

Good software engineering comes from understanding:

System design
Data flow
Security principles
Performance considerations
Maintainability

Choosing a framework should be based on project requirements rather than popularity.

This was a valuable reminder because developers often spend too much time debating technologies instead of focusing on solving real problems.

APIs Are the Language of Modern Applications

Nearly every modern application relies on APIs.

The conference discussions emphasized how APIs allow different systems to communicate and work together seamlessly.

As someone interested in backend engineering, this reinforced the importance of understanding:

REST principles
Request and response handling
Authentication and authorization
Error handling
Documentation

Building a good API isn't just about functionality; it's about creating a reliable experience for other developers who will use it.

Security Must Be Considered Early

Security was another topic that stood out.

Many beginner developers focus on getting applications working before thinking about security.

However, the conference emphasized that security should be built into applications from the start.

Some key areas discussed included:

Input validation
Authentication
Authorization
Secure data handling
Protecting sensitive information

A secure application is not an optional feature—it's a requirement.

Learning From the Community Matters

Perhaps the most valuable part of the conference wasn't the technical presentations.

It was the opportunity to interact with other developers, learners, and industry professionals.

Software engineering can sometimes feel like a solitary activity, especially when you're spending hours debugging code.

Events like this remind us that there is an entire community of people facing similar challenges, learning similar concepts, and growing together.

Conversations with other developers often provide insights that cannot be found in documentation alone.

How This Connects to My Journey

At Zone01 Kisumu, much of the learning process is project-based.

We're encouraged to solve problems independently, collaborate with peers, and continuously improve our technical skills.

The Backend Frameworks Mini-Conference complemented this learning approach perfectly.

Many of the concepts discussed during the event connected directly to challenges I've encountered while building backend projects, working with APIs, debugging applications, and learning Go.

It reminded me that becoming a backend engineer is not about mastering a single language or framework.

It's about developing the mindset required to build reliable systems and solve real-world problems.

Final Thoughts

The conference left me with a renewed appreciation for backend engineering.

Technology will continue to evolve, and new frameworks will emerge. But the fundamental principles of software engineering remain the same:

Understand the problem.
Choose the right tools.
Build secure and reliable systems.
Never stop learning.

I'm grateful to Zone01 Kisumu and the event organizers for creating opportunities like this for aspiring developers.

The journey continues, and I'm excited to keep learning, building, and growing as a backend engineer.

Have you attended a tech conference or meetup that changed the way you think about software development? I'd love to hear about your experience in the comments.

backend #golang #webdev #softwareengineering #career #beginners #api #programming #zone01 #learninginpublic

Why Learning to Debug Made Me a Better Developer Than Writing Code

Paul Owuor — Mon, 15 Jun 2026 02:26:20 +0000

Why Learning to Debug Made Me a Better Developer Than Writing Code

When I first started learning software engineering, I thought success would come from writing lots of code quickly.

I was wrong.

The biggest growth in my journey didn’t come from writing code — it came from debugging broken code.

At first, debugging felt frustrating. I would run my program, get an error, and feel stuck. Sometimes the error message made no sense. Other times, everything looked correct, yet the program still failed.

I used to think bugs were signs that I wasn’t good enough.

Over time, that mindset changed.

Debugging Changed How I Think

Working on backend and algorithm-heavy projects taught me something important: bugs are not the enemy — they are feedback.

Every bug tells a story.

A nil pointer might reveal missing validation.
A failing test might expose flawed logic.
An unexpected output might uncover assumptions you didn’t realize you made.

Debugging forced me to slow down and think like an engineer.

Instead of asking:

“Why isn’t this working?”

I started asking:

“What exactly is happening inside my program?”

That small mindset shift changed everything.

The Real Skill: Problem Decomposition

One of the hardest things about programming is that systems are complex.

A single bug could come from:

Incorrect input handling
Broken business logic
State mutation
Race conditions
API failures
Environment configuration

You can’t solve all of that at once.

I learned to break problems into smaller questions:

Is the input correct?
Is this function returning what I expect?
Where does the output change?
What assumptions am I making?

That process made debugging manageable.

And honestly, it made me a better thinker outside programming too.

Tools That Help Me Debug Better

Here are some practices that improved my debugging:

1. Reading Error Messages Carefully

I used to ignore error messages and panic.

Now I read them line by line.

The answer is often already there.

2. Logging Everything

Print statements still save lives.

Sometimes you just need visibility into what your code is doing.

3. Using Git Properly

Version control makes experimentation safer.

You can try bold fixes without fear.

4. Taking Breaks

Some bugs disappear after stepping away for 10 minutes.

Fresh eyes matter.

What I Tell New Developers

If you’re learning to code and constantly hitting bugs, that’s normal.

Debugging isn’t a side skill.

It is software engineering.

The developers who grow fastest aren’t always the ones who write code fastest.

They’re often the ones who investigate problems patiently and systematically.

So the next time your code breaks, don’t panic.

A bug might just be your next lesson.

And sometimes, fixing one bug teaches more than writing 500 lines of code.

From Operations Support to Software Engineering: My Journey Into Tech

Paul Owuor — Sat, 23 May 2026 18:11:17 +0000

A year ago, I was mostly handling support and operational tasks. Today, I’m building backend projects in Go, debugging algorithms, working with Git daily, and learning how real software systems are designed.

The transition hasn’t been easy.

There were moments when I spent hours fixing a single bug, struggled to understand stack operations in Push-Swap, or stared at terminal errors that made absolutely no sense at first. But every project taught me something important: consistency matters more than perfection.

One thing I’ve learned during my journey at Zone01 Kisumu is that software engineering is less about “knowing everything” and more about learning how to solve problems step by step.

Some lessons that changed my mindset:

Debugging is a skill, not a sign of failure
Reading documentation is part of being a developer
Git and terminal skills are just as important as coding
Small daily improvements compound over time
Building projects teaches faster than watching tutorials

Projects I’ve worked on recently:

Push-Swap algorithm project in Go
ASCII Art Web application
HTTP servers and web handlers
Stack operations and sorting logic
Git workflows and debugging practices

I’m currently focused on:

Backend engineering
Go development
AI/Data-related opportunities
Remote software engineering roles

To anyone transitioning into tech from another field:
Keep building.
Keep breaking things.
Keep learning.

Your first breakthrough might be one project away.

100DaysOfCode #golang #backend #softwareengineering #beginners #webdev #programming #opensource #devops #careerchange