DEV Community: Dishon Oketch

🌿 Git Mastery: The Complete Developer Guide

Dishon Oketch — Sat, 23 May 2026 17:42:25 +0000

From your first commit to advanced branching strategies — everything you need to version control like a pro

Why Git?

Every file you've ever accidentally deleted, every "final_v3_REAL_final.js" you've created — Git is the solution to all of that. It's a distributed version control system that tracks every change to your codebase, lets you experiment without fear, and enables teams of hundreds to collaborate without stepping on each other.

Git isn't just a tool — it's the backbone of modern software development. GitHub, GitLab, Bitbucket — they're all built on top of it.

Here's the mental model before we dive in:

Repository (repo) → A project tracked by Git (the .git folder)
Commit → A snapshot of your files at a point in time
Branch → An independent line of development
Remote → A copy of the repo hosted elsewhere (GitHub, GitLab, etc.)
Working tree → The files you're currently editing
Staging area (index) → Where you prepare changes before committing

Prerequisites

Git installed: git-scm.com
A terminal you're comfortable with
(Optional) A GitHub account for remote repos

Verify your install:

git --version
# git version 2.x.x

Part 1: First-Time Setup

Before your first commit, tell Git who you are. This info is embedded in every commit you make.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Set your default editor (VS Code shown here)
git config --global core.editor "code --wait"

# Set default branch name to 'main'
git config --global init.defaultBranch main

# Verify your config
git config --list

These settings live in ~/.gitconfig and apply to every repo on your machine. You can override them per-repo by dropping the --global flag.

Part 2: Starting a Repository

From scratch

mkdir my-project && cd my-project
git init
# Initialized empty Git repository in .git/

From an existing remote

git clone https://github.com/user/repo.git

# Clone into a specific folder name
git clone https://github.com/user/repo.git my-folder

# Clone only the latest snapshot (faster for large repos)
git clone --depth 1 https://github.com/user/repo.git

Part 3: The Core Workflow — Stage, Commit, Repeat

This is the heartbeat of Git. Everything else builds on it.

Working Tree  →  Staging Area  →  Repository
  (edit)           (git add)       (git commit)

Checking status

git status              # What's changed? What's staged?
git status -s           # Short format: M = modified, A = added, ? = untracked

Staging changes

git add file.js             # Stage a specific file
git add src/                # Stage an entire directory
git add .                   # Stage everything in the current directory
git add -p                  # Interactive: stage changes chunk by chunk

Pro tip: git add -p is one of Git's most underused features. It lets you review and selectively stage individual hunks of changes — perfect for keeping commits focused and atomic.

Committing

git commit -m "feat: add user authentication"

# Stage all tracked files and commit in one step
git commit -am "fix: correct typo in error message"

# Open your editor for a detailed commit message
git commit

Writing good commit messages

Follow the Conventional Commits format:

<type>(<scope>): <short summary>

<optional body>

<optional footer>

Common types: feat, fix, docs, refactor, test, chore

# Good
git commit -m "feat(auth): add JWT refresh token rotation"
git commit -m "fix(api): handle null response from payment gateway"
git commit -m "docs: update README with Docker setup instructions"

# Bad
git commit -m "stuff"
git commit -m "fix"
git commit -m "asdfgh"

Part 4: Viewing History

git log                          # Full log
git log --oneline                # Compact: one commit per line
git log --oneline --graph        # ASCII branch graph
git log --oneline --graph --all  # Include all branches

# Filter by author
git log --author="Jane"

# Filter by date
git log --since="2 weeks ago"
git log --after="2024-01-01" --before="2024-06-01"

# Search commit messages
git log --grep="authentication"

# See what changed in each commit
git log -p

# Show stats (files changed, insertions, deletions)
git log --stat

Inspecting a specific commit

git show abc1234              # Show commit details + diff
git show abc1234:src/app.js   # Show a file as it was at that commit

Comparing changes

git diff                      # Unstaged changes vs last commit
git diff --staged             # Staged changes vs last commit
git diff main feature-branch  # Diff between two branches
git diff abc1234 def5678      # Diff between two commits

Part 5: Branching — Git's Superpower

Branches are cheap and fast in Git (just a pointer to a commit). Use them liberally.

git branch                    # List local branches
git branch -a                 # List local + remote branches
git branch feature/login      # Create a new branch
git switch feature/login      # Switch to it
git switch -c feature/login   # Create AND switch in one command

# Old syntax (still works everywhere)
git checkout -b feature/login

Merging branches

# Switch to the branch you want to merge INTO
git switch main

# Merge feature branch
git merge feature/login

# Merge with a commit even if fast-forward is possible (preserves history)
git merge --no-ff feature/login

Fast-forward vs merge commit:

Fast-forward (linear history):
main: A → B → C → D → E
                        ↑ feature merged cleanly

Merge commit (preserves branch context):
main: A → B → C → M
                ↗   ↑ merge commit
feature:    D → E

Use --no-ff when you want a clear record that a feature branch was merged.

Deleting branches

git branch -d feature/login    # Delete (safe — won't delete unmerged branches)
git branch -D feature/login    # Force delete
git push origin --delete feature/login  # Delete remote branch

Part 6: Rebasing — A Cleaner History

Rebase rewrites commit history by replaying your commits on top of another branch. The result is a clean, linear history.

git switch feature/login
git rebase main

Before rebase:

main:    A → B → C
feature:     D → E

After git rebase main:

main:    A → B → C
feature:         D' → E'   (commits replayed on top of C)

Interactive rebase — rewrite history

This is the power tool. Use it to clean up commits before merging:

git rebase -i HEAD~3    # Interactively edit the last 3 commits

In the editor that opens, you can:

Command	What it does
`pick`	Keep the commit as-is
`reword`	Keep but edit the commit message
`squash`	Combine with the previous commit
`fixup`	Like squash but discard this commit's message
`drop`	Delete the commit entirely
`edit`	Pause to amend the commit

⚠️ Golden Rule of Rebasing: Never rebase commits that have been pushed to a shared remote branch. Rebase rewrites history — doing it on shared branches causes pain for everyone.

Part 7: Working with Remotes

git remote -v                           # List remotes
git remote add origin https://github.com/user/repo.git   # Add a remote
git remote rename origin upstream       # Rename a remote
git remote remove origin               # Remove a remote

Pushing and pulling

# Push local branch to remote
git push origin main

# Push and set upstream tracking (then you can just use `git push`)
git push -u origin main

# Pull = fetch + merge
git pull origin main

# Pull with rebase instead of merge (cleaner)
git pull --rebase origin main

# Fetch remote changes without merging
git fetch origin
git fetch --all    # Fetch all remotes

Tracking branches

Once you've set an upstream with -u, Git knows which remote branch your local branch corresponds to:

git push      # Pushes to tracked remote branch
git pull      # Pulls from tracked remote branch
git branch -vv  # Shows tracking info for all branches

Part 8: Undoing Things

This is where most developers get nervous. Don't be — Git almost never truly deletes anything.

Amending the last commit

# Fix the last commit message
git commit --amend -m "correct message"

# Add a forgotten file to the last commit
git add forgotten-file.js
git commit --amend --no-edit   # Keeps the original message

Unstaging files

git restore --staged file.js    # Unstage (keep changes in working tree)
git restore file.js             # Discard working tree changes (DESTRUCTIVE)

Reverting commits (safe — creates a new commit)

git revert abc1234       # Creates a new commit that undoes abc1234
git revert HEAD          # Revert the last commit
git revert HEAD~3..HEAD  # Revert the last 3 commits

Use revert on shared branches — it's non-destructive.

Resetting (rewrites history — be careful)

git reset --soft HEAD~1   # Undo last commit, keep changes STAGED
git reset --mixed HEAD~1  # Undo last commit, keep changes UNSTAGED (default)
git reset --hard HEAD~1   # Undo last commit, DISCARD all changes

The escape hatch: reflog

Even after a hard reset, Git keeps a log of where HEAD has been. You can recover "lost" commits:

git reflog              # See the full history of HEAD movements
git reset --hard abc1234  # Jump back to any previous state

Part 9: Stashing — Save Work Without Committing

Need to switch branches but you're mid-feature? Stash it.

git stash                       # Stash all uncommitted changes
git stash push -m "wip: login form validation"  # With a label

git stash list                  # See all stashes
git stash pop                   # Apply most recent stash and remove it
git stash apply stash@{2}       # Apply a specific stash (keep it in the list)
git stash drop stash@{0}        # Delete a specific stash
git stash clear                 # Delete all stashes

# Stash including untracked files
git stash -u

# Create a branch from a stash
git stash branch feature/wip stash@{0}

Part 10: Tags — Marking Releases

git tag                          # List all tags
git tag v1.0.0                   # Lightweight tag (just a pointer)
git tag -a v1.0.0 -m "Release 1.0.0"   # Annotated tag (recommended)

git push origin v1.0.0           # Push a specific tag
git push origin --tags           # Push all tags

git tag -d v1.0.0                # Delete local tag
git push origin --delete v1.0.0  # Delete remote tag

Annotated tags store extra metadata (tagger name, date, message) and can be signed. Use them for releases.

Part 11: The .gitignore File

Tell Git which files to never track:

# Dependencies
node_modules/
vendor/

# Build output
dist/
build/
*.min.js

# Environment & secrets
.env
.env.local
*.pem
*.key

# OS files
.DS_Store
Thumbs.db

# Editor files
.vscode/
.idea/
*.swp

Apply a gitignore to already-tracked files:

# If you added .env to .gitignore but already committed it:
git rm --cached .env
git commit -m "chore: remove .env from tracking"

Find pre-made .gitignore templates for your stack at gitignore.io.

Part 12: Branching Strategies

Git Flow

Best for projects with scheduled releases:

main          ←── stable production code
develop       ←── integration branch
feature/*     ←── new features (branch from develop)
release/*     ←── release prep (branch from develop)
hotfix/*      ←── urgent fixes (branch from main)

GitHub Flow

Simpler — best for continuous deployment:

main          ←── always deployable
feature/*     ←── branch from main, PR back to main, deploy

Trunk-Based Development

Best for mature teams with strong CI/CD:

main          ←── everyone commits here (short-lived branches only)

Choose the strategy that matches your team size and release cadence. GitHub Flow is the right default for most teams.

Git Commands Cheat Sheet

# Setup
git config --global user.name "Name"
git config --global user.email "email"

# Start
git init
git clone <url>

# Daily workflow
git status
git add .
git commit -m "message"
git push
git pull

# Branches
git switch -c feature/name
git merge feature/name
git rebase main
git branch -d feature/name

# Inspection
git log --oneline --graph --all
git diff
git show <commit>

# Undo
git restore --staged <file>
git revert <commit>
git reset --soft HEAD~1
git reflog

# Remote
git remote add origin <url>
git fetch --all
git push -u origin main

Common Pitfalls & How to Avoid Them

❌ Committed secrets or credentials

# Remove a file from ALL history (nuclear option)
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch path/to/secret.env" \
  --prune-empty --tag-name-filter cat -- --all

# Then force push and rotate your credentials immediately
git push origin --force --all

Better: use git-secrets or gitleaks to prevent it happening in the first place.

❌ Merge conflicts

# When a merge conflict occurs, Git marks the file:
<<<<<<< HEAD
  your changes
=======
  incoming changes
>>>>>>> feature/login

# After resolving manually:
git add resolved-file.js
git commit   # or git rebase --continue if rebasing

❌ Pushed to the wrong branch

git revert HEAD           # If others may have pulled it
git push origin --force   # Only if no one else has the commits

❌ `git pull` creates ugly merge commits

# Use rebase by default
git config --global pull.rebase true

Wrapping Up

Here's what you've learned:

Setup — configuring Git globally for clean commit attribution
Core workflow — stage, commit, push — the heartbeat of Git
Branching — creating, merging, and deleting branches with confidence
Rebasing — rewriting history for a cleaner log
Remotes — pushing, pulling, fetching, and tracking
Undoing — revert, reset, restore, and the reflog safety net
Stashing — saving work-in-progress without a commit
Tags — marking releases with annotated tags
Branching strategies — Git Flow vs GitHub Flow vs Trunk-based
Common pitfalls — handling conflicts, secrets, and wrong-branch pushes

Git rewards practice. The commands that seem scary now (rebase -i, reflog, reset --hard) become second nature once you've used them a few times in a safe environment.

What's Next?

GitHub Actions — automate CI/CD triggered by Git events
Signed commits — verify your identity with GPG keys
git bisect — binary search your history to find which commit introduced a bug
Worktrees — check out multiple branches at once in different directories

Found this useful? Drop a ❤️ and follow for more. Got a Git horror story or a tip I missed? Share it in the comments.

🐳 How to Run Any Project in Docker: A Complete Guide

Dishon Oketch — Sat, 23 May 2026 17:28:39 +0000

From zero to containerized in minutes — no "works on my machine" excuses

Why Docker?

You've probably heard it before: "It works on my machine." Docker exists to make that phrase obsolete.

Docker lets you package your application and all its dependencies — runtimes, libraries, config files — into a single, portable unit called a container. That container runs identically on your laptop, your teammate's Windows machine, a CI server, or a cloud VM.

Before we dive in, here's the quick mental model:

Image → A blueprint (like a class in OOP)
Container → A running instance of an image (like an object)
Dockerfile → The recipe for building an image
Docker Compose → A tool to orchestrate multiple containers together

Prerequisites

Docker Desktop installed (includes Docker Compose)
Basic terminal familiarity
A project to containerize (we'll use examples for Node.js, Python, and a generic approach)

Verify your install:

docker --version
# Docker version 26.x.x

docker compose version
# Docker Compose version v2.x.x

Part 1: The Anatomy of a Dockerfile

A Dockerfile is a plain text file with instructions Docker reads top-to-bottom to build your image.

# 1. Base image — what you're building ON TOP OF
FROM node:20-alpine

# 2. Set the working directory inside the container
WORKDIR /app

# 3. Copy dependency files first (for layer caching)
COPY package*.json ./

# 4. Install dependencies
RUN npm install

# 5. Copy the rest of your source code
COPY . .

# 6. Expose the port your app listens on
EXPOSE 3000

# 7. The command to run when the container starts
CMD ["node", "server.js"]

Key Instructions Explained

Instruction	Purpose
`FROM`	Sets the base image. Always the first instruction.
`WORKDIR`	Sets the working directory for subsequent commands. Created if it doesn't exist.
`COPY`	Copies files from your host into the image.
`RUN`	Executes a command during the build phase (installs packages, compiles code).
`ENV`	Sets environment variables available at runtime.
`EXPOSE`	Documents which port the app uses (informational; doesn't actually publish).
`CMD`	The default command when the container starts. Only one per Dockerfile.
`ENTRYPOINT`	Like CMD, but harder to override — use for "always run this".

Pro tip: Order your Dockerfile from least-to-most frequently changed. Docker caches each layer, so stable layers (like installing dependencies) won't re-run unless they change.

Part 2: Dockerizing a Node.js Project

Project structure

my-app/
├── src/
│   └── index.js
├── package.json
├── package-lock.json
└── Dockerfile

Dockerfile

FROM node:20-alpine

WORKDIR /app

# Copy lockfile and package.json first for cache efficiency
COPY package*.json ./
RUN npm ci --only=production

COPY src/ ./src/

EXPOSE 3000
CMD ["node", "src/index.js"]

Build and run

# Build the image and tag it
docker build -t my-node-app .

# Run it, mapping host port 8080 → container port 3000
docker run -p 8080:3000 my-node-app

Visit http://localhost:8080 — your app is running inside Docker.

Part 3: Dockerizing a Python Project

FROM python:3.12-slim

WORKDIR /app

# Install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Note the --host 0.0.0.0: By default, many dev servers bind to 127.0.0.1 (localhost inside the container). You must bind to 0.0.0.0 to accept connections from outside the container.

Part 4: Docker Compose — Running Multiple Services

Real projects rarely have just one service. You need a database, a cache, maybe a background worker. Docker Compose lets you define and run all of them together.

Example: Node.js app + PostgreSQL + Redis

# docker-compose.yml
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:password@db:5432/mydb
      - REDIS_URL=redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    volumes:
      - .:/app              # Mount source code for hot reload
      - /app/node_modules   # Prevent host node_modules from overwriting

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 5s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Run everything with one command

# Start all services in the background
docker compose up -d

# View logs
docker compose logs -f app

# Stop everything
docker compose down

# Stop and remove volumes (wipes database data)
docker compose down -v

Part 5: Environment Variables & Secrets

Never hardcode secrets in your Dockerfile or Compose file. Use a .env file:

# .env  (add this to .gitignore!)
POSTGRES_PASSWORD=supersecret
API_KEY=abc123

Docker Compose automatically picks up .env in the same directory:

services:
  app:
    environment:
      - API_KEY=${API_KEY}
  db:
    environment:
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

For production, use Docker Secrets, Vault, AWS Secrets Manager, or your platform's secret management.

Part 6: Development vs Production Configurations

Use multiple Compose files to separate concerns:

my-app/
├── docker-compose.yml          # Base config
├── docker-compose.dev.yml      # Dev overrides (hot reload, debug ports)
└── docker-compose.prod.yml     # Prod overrides (replicas, logging)

docker-compose.dev.yml — adds hot reload:

services:
  app:
    volumes:
      - .:/app
    command: npm run dev
    environment:
      - NODE_ENV=development

docker-compose.prod.yml — tightens things up:

services:
  app:
    restart: always
    environment:
      - NODE_ENV=production
    deploy:
      replicas: 2

Run with merged configs:

# Development
docker compose -f docker-compose.yml -f docker-compose.dev.yml up

# Production
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

Part 7: Useful Docker Commands Cheat Sheet

Images

docker images                    # List all local images
docker pull nginx:alpine         # Pull image from Docker Hub
docker rmi my-app                # Remove an image
docker image prune               # Remove unused images

Containers

docker ps                        # List running containers
docker ps -a                     # List all containers (including stopped)
docker stop <container_id>       # Gracefully stop a container
docker rm <container_id>         # Remove a stopped container
docker logs -f <container_id>    # Tail logs from a container
docker exec -it <id> sh          # Open a shell inside a running container

Debugging

# Open an interactive shell in a running container
docker exec -it my-app-container sh

# Run a one-off command
docker run --rm -it node:20-alpine node --version

# Inspect a container's config, network, volumes
docker inspect <container_id>

# Check resource usage
docker stats

Part 8: The .dockerignore File

Just like .gitignore, .dockerignore prevents files from being copied into your image. This keeps images small and builds fast.

node_modules
.git
.env
*.log
dist
coverage
.DS_Store
README.md
docker-compose*.yml

Without this, COPY . . would copy your entire node_modules (hundreds of MB) into the image — even though you're running npm install inside it anyway.

Part 9: Multi-Stage Builds (Advanced)

Multi-stage builds let you use a heavy build image and copy only the artifacts into a lean production image.

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build          # Produces /app/dist

# Stage 2: Production
FROM node:20-alpine AS production
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=builder /app/dist ./dist   # Only copy built output
EXPOSE 3000
CMD ["node", "dist/server.js"]

The final image contains no TypeScript compiler, test libraries, or source files — just what's needed to run. This can shrink image size from 1GB+ → under 200MB.

Common Pitfalls & How to Avoid Them

❌ App can't connect to the database

Inside a Docker network, containers talk to each other by service name, not localhost.

// ❌ Wrong
const db = new Client({ host: 'localhost' })

// ✅ Correct (use the Compose service name)
const db = new Client({ host: 'db' })

❌ Changes not reflected after rebuild

Docker caches layers. Force a full rebuild:

docker compose build --no-cache

❌ Container exits immediately

Check the logs:

docker logs <container_id>

The most common cause: your CMD is wrong, or the process crashes on startup.

❌ Port already in use

Either stop the conflicting service or change the host port mapping:

ports:
  - "3001:3000"   # Map to 3001 on host instead

Wrapping Up

Here's what you've learned:

Dockerfile basics — FROM, COPY, RUN, CMD and layer caching
Building & running individual containers with docker build / docker run
Docker Compose for multi-service setups (app + database + cache)
Environment variables and keeping secrets out of your images
Dev/prod split using multiple Compose files
Multi-stage builds for lean production images
Debugging techniques when things go sideways

Docker has a learning curve, but once it clicks, you'll never want to go back to "just run it locally". Your entire team gets identical environments, onboarding new developers takes minutes instead of hours, and deployments become deterministic.

What's Next?

Docker volumes — persisting data beyond the container lifecycle
Docker networks — custom networking between containers
Kubernetes — orchestrating containers at scale
GitHub Actions + Docker — CI/CD pipelines that build and push images automatically

Found this helpful? Drop a ❤️ and follow for more DevOps and backend content. Got questions? Ask in the comments — I read every one.

The Death of "Just Write the Code": How AI-Native Development Is Reshaping What It Means to Be a Developer

Dishon Oketch — Mon, 18 May 2026 01:36:37 +0000

You're not losing your job to AI. But the developer who knows how to work with AI might.

I used to spend 40 minutes writing a database migration script. Last Tuesday, I described what I needed in two sentences, reviewed the output, caught one edge case, fixed it, and shipped. Total time: 8 minutes.

That's not a flex — it's a signal. Something fundamental is shifting in how we build software, and if you're a mid-level developer, you're sitting right at the epicenter of that shift.

What "AI-Native Development" Actually Means

It's not just "using Copilot to autocomplete your for loops."

AI-Native Development is a philosophy where AI is a first-class participant in your entire software lifecycle — from architecture decisions to writing code, generating tests, reviewing PRs, and even maintaining legacy systems. Instead of writing every line and occasionally asking AI to fill in the blanks, you express intent and let AI generate the implementation.

Think of it like the shift from Assembly to high-level languages. Nobody said "C developers aren't real programmers." The abstraction layer just moved up. It's moving again.

The Old Loop vs. The New Loop

The old dev loop:

Understand the requirement
Design a solution in your head
Look up docs / StackOverflow
Write the code
Debug it
Write tests (maybe)
Ship

The AI-native dev loop:

Understand the requirement (still you)
Design a solution in your head (still you)
Describe the solution clearly to an AI
Review, critique, and refine the output
Catch edge cases the AI missed (your experience matters here)
Ship faster

Notice what didn't go away: your understanding of the problem. What changed is where your time goes.

Where Mid-Level Devs Win (and Where We Can Get Lazy)

Here's the honest take: AI-native tooling is a power multiplier — and that cuts both ways.

Where it genuinely helps us

Boilerplate and scaffolding — CRUD endpoints, form validation, DTO mapping. The stuff that's correct but boring. AI eats this for breakfast. Let it.

Unfamiliar territory — Need to write a Dockerfile for the first time? Integrate a payment gateway you've never touched? AI gets you to a working first draft faster than any tutorial.

Test coverage — Generating unit tests for existing functions is something AI does remarkably well. You describe the behavior, it writes the cases. You review for correctness.

Code review assistance — Pasting a PR diff and asking "what could go wrong here?" often surfaces things you'd catch on a second read at 9am but miss at 5pm on a Friday.

Where we can get lazy (and why it matters)

Understanding what you ship. If you paste AI output without reading it, you own the bugs and you didn't learn anything. The developer who can't explain their own code in a review is a liability.

Architecture decisions. AI is excellent at implementation. It's mediocre at knowing why your system is structured the way it is, what technical debt exists, and what your team's conventions are. That context lives in your head.

Security and edge cases. AI-generated code can be subtly wrong in ways that only show up in production. SQL injections, race conditions, incorrect null handling — always review with a skeptic's eye.

A Real Example: From Intent to Shipped

Let's say you're building a Go API and need rate limiting per user.

Old approach: Google "Go rate limiting middleware," read three blog posts, pick one approach, adapt the code, test it.

AI-native approach:

You write:

"I need a rate limiting middleware for a Gin API in Go. It should limit requests per authenticated user (user ID from JWT claims), allow 100 requests per minute, use a sliding window algorithm, and return a 429 with a Retry-After header when the limit is hit. Use an in-memory store for now."

You get a working draft in seconds. Then your job becomes:

Does this sliding window implementation actually work correctly?
What happens when the server restarts? (In-memory store resets — is that acceptable?)
Is the JWT parsing consistent with the rest of the codebase?
Are there any race conditions in the store?

That last part — the critique — is where your experience lives. A junior dev might not know to ask those questions. You do.

The Skills That Are Getting More Valuable

The AI wave isn't making developers irrelevant. It's shifting what skills are premium.

Getting less scarce	Getting more valuable
Writing boilerplate code	System design & architecture
Memorizing syntax	Clear technical communication
Looking up APIs	Code review & critique
Writing basic CRUD	Security & edge case thinking
First-draft implementations	Knowing what to build (and what not to)

Notice that most of the "more valuable" column is things that come with experience. AI can write code. It can't replace the developer who has shipped broken code to prod at 2am and knows exactly what to look for next time.

Tools Worth Knowing Right Now

If you're not already using these, start:

GitHub Copilot / Cursor — In-editor AI that goes beyond autocomplete. Cursor in particular treats your entire codebase as context.
Claude / ChatGPT for architecture — Describe a system design problem and workshop it. Genuinely useful for rubber-ducking at scale.
Codeium — Free Copilot alternative, solid for open-source projects.
Aider — AI pair programmer in your terminal, works directly with your git repo.
Claude Code — Agentic coding tool that can read, edit, and run code in your project autonomously.

What This Means for Your Career

If you're a mid-level developer, the honest advice is this: don't resist the shift, but don't outsource your thinking.

The developers who will struggle are those who either:

Refuse to use AI tools and get outpaced on speed, or
Use AI as a crutch and stop developing real understanding

The sweet spot — and where the most interesting work is — is being the person who can direct AI effectively, critique its output sharply, and own the architecture decisions that no prompt can make for you.

That's not a lesser form of programming. It might actually be a more demanding one.

Final Thought

The best analogy I've heard: AI-native development is like having a very fast, very literal junior developer who never gets tired, never gets offended by feedback, and occasionally makes confident mistakes.

Your job isn't to compete with that junior dev. Your job is to be the senior who knows when the work is good, when it's subtly broken, and what to build next.

That role isn't going anywhere.

What's your experience been with AI tools in your day-to-day dev work? Drop a comment — I'm curious whether others are finding the same patterns or running into completely different ones.

Frontend Frameworks: Which One, When, and Why It Actually Matters

Dishon Oketch — Sat, 09 May 2026 18:54:12 +0000

There's a question most developers quietly struggle with but rarely ask out loud:

"Which framework should I use — and why?"

Not because they don't care. But because the answer seems obvious until you actually have to make the decision. Then suddenly every blog post, every YouTube video, every Twitter thread is telling you something different.

This article is about cutting through that noise. It's inspired by a Frontend Frameworks Mini-Conference held at LakeHub, organized by Zone01 Kisumu — where we spent a full day tracing the real story of frontend development, from the beginning.

The Beginning: Vanilla JavaScript

Before frameworks, there was just JavaScript. Raw. Unstructured. Completely yours to mess up.

Early web pages were mostly static HTML with a little JavaScript sprinkled on top for basic interactions — form validation, toggling visibility, that kind of thing. It worked. Mostly.

But as the web grew more ambitious — dynamic content, user interactions, real-time updates — writing plain JavaScript became painful. You'd write the same patterns over and over. Managing the DOM directly was tedious and error-prone. Cross-browser compatibility was a nightmare.

Something had to give.

Enter jQuery: The First Real Revolution

In 2006, jQuery arrived and changed everything.

It wasn't a framework in the modern sense — more of a utility library. But what it did was radical for its time: it gave developers a consistent, readable API to manipulate the DOM, handle events, and make AJAX calls, regardless of which browser the user was on.

// Without jQuery
document.getElementById('btn').addEventListener('click', function() {
  document.getElementById('message').style.display = 'block';
});

// With jQuery
$('#btn').on('click', function() {
  $('#message').show();
});

Cleaner. More expressive. And it worked everywhere.

jQuery dominated the web for years — and honestly, it still powers a massive chunk of the internet today. That's not a legacy problem. That's a testament to how well it solved real problems at the time.

But the web kept evolving. Single Page Applications (SPAs) became the expectation. Users wanted desktop-like experiences in the browser. And jQuery, powerful as it was, wasn't designed for that scale of complexity.

Why Modern Frameworks Became Essential

When you're building a small website, managing the DOM directly is fine. When you're building a complex application with dozens of components, shared state, real-time data, and multiple developers — it becomes chaos.

Modern frameworks emerged to solve specific, concrete problems:

1. State Management

Keeping your UI in sync with your data is harder than it sounds. Change a value somewhere, and every part of the UI that depends on it needs to update. Do this manually across a large codebase and you'll lose your mind. Frameworks automate this.

2. Component Reusability

Write a button once. Use it everywhere. Style it consistently. Pass it different props. Modern frameworks made the concept of reusable UI components a first-class citizen.

3. Declarative UI

Instead of telling the browser how to update the DOM step by step, you describe what the UI should look like for a given state — and the framework figures out the rest.

// Declarative (React)
function Greeting({ isLoggedIn }) {
  return <h1>{isLoggedIn ? 'Welcome back!' : 'Please sign in.'}</h1>;
}

Much easier to reason about than imperative DOM manipulation.

4. Developer Experience

Tooling, hot reloading, component devtools, ecosystem support — modern frameworks brought a professional development experience that scales with your team.

The Main Players (and What They're Actually For)

React

Built by Meta. The most widely used. Technically a library, not a full framework — it handles the view layer and leaves the rest to you (routing, state management, etc.). Great for large-scale, interactive applications. Huge ecosystem. High demand in the job market.

Best for: Complex SPAs, applications with lots of dynamic state, teams that want flexibility.

Vue

The approachable one. Gentler learning curve than React, more opinionated than React, but less opinionated than Angular. Often praised for its clear documentation.

Best for: Teams transitioning from jQuery or simpler setups, projects that need a balance of structure and flexibility.

Angular

Built by Google. A full framework with strong opinions about everything — routing, forms, HTTP, state. Verbose, but everything has a place. TypeScript by default.

Best for: Large enterprise applications, teams that prefer convention over configuration.

Svelte

The new-school approach. No virtual DOM — Svelte compiles your components to vanilla JS at build time. Smaller bundle sizes, faster runtime performance.

Best for: Performance-critical applications, developers who want to write less boilerplate.

Alpine.js

The underrated one. Minimal. No build step required. Add it via a script tag and you're done. Handles lightweight interactivity directly in your HTML.

Best for: Adding sprinkles of interactivity to server-rendered pages without pulling in a full SPA framework.

When (and When Not) to Use a Framework

This is the part most tutorials skip. And it's arguably the most important.

Use a framework when:

You're building a complex, interactive application
Multiple developers are working on the same codebase
You need component reusability at scale
You have significant client-side state to manage
You're building a Single Page Application

Don't use a framework when:

You're building a simple marketing site or blog
The interactivity needed is minimal
Performance and bundle size are critical constraints
You or your team aren't ready for the overhead
A simpler tool (Alpine.js, vanilla JS, even jQuery) solves the problem cleanly

Choosing a framework is not about following hype. It's about solving the right problem with the right tool.

A 400MB React app for a landing page with one contact form is not impressive engineering. It's overengineering. Modern web development has a talent for turning a button into a philosophical crisis — don't let it.

How to Actually Choose

Ask these questions before reaching for a framework:

What is the complexity of the UI? Simple or highly interactive?
Who is on the team? What do they already know?
What is the performance requirement? Does bundle size matter?
What does the ecosystem need to support? Do you need SSR, SSG, routing?
What is the maintenance horizon? Will this be around in 5 years?

There is no universally correct answer. React is not always better than Vue. Alpine.js is not inferior to React — it's just for a different job.

Beyond the Framework: How to Actually Think

The most valuable thing you can develop as a frontend engineer isn't knowledge of any specific framework. Frameworks come and go.

What lasts:

Understanding how the browser works — the DOM, events, rendering
JavaScript fundamentals — closures, async/await, the event loop
Component thinking — breaking UIs into reusable, composable pieces
State management patterns — regardless of which tool implements them
Performance awareness — knowing what makes pages fast or slow

If your fundamentals are strong, picking up a new framework is just learning syntax. If your fundamentals are weak, no framework will save you.

Final Thought

The evolution from Vanilla JS to jQuery to React to Svelte isn't a story of old tools being bad. It's a story of problems getting bigger and tools rising to meet them.

Every framework exists because someone hit a real wall with what came before. Understanding why a tool was built is the fastest way to understand when you should reach for it.

So next time someone asks "should I learn React or Vue?" — the real answer starts with: what are you trying to build?

This article was inspired by the Frontend Frameworks Mini-Conference hosted by Zone01 Kisumu at LakeHub, Kisumu. Zone01 is a peer-to-peer, project-based coding school — part of the global 01Edu network.

Concurrency in Go: Goroutines and Channels Explained with Real Examples

Dishon Oketch — Thu, 30 Apr 2026 11:37:16 +0000

Concurrency in Go: Goroutines and Channels Explained with Real Examples

If you've been coding in Go for a while, you've probably heard the phrase "Don't communicate by sharing memory; share memory by communicating." Today, we're going to break that down — no fluff, just real code and real use cases.

What Is Concurrency?

Concurrency is the ability to handle multiple tasks at the same time — or at least, appear to. It doesn't mean things literally run in parallel (though they can). It means your program can juggle multiple things without waiting for each one to finish before starting the next.

Think of a chef preparing a meal: while the pasta boils, they chop vegetables and stir the sauce. That's concurrency.

Go makes concurrency a first-class citizen of the language through two core concepts: goroutines and channels.

Goroutines: Lightweight Threads

A goroutine is a function that runs concurrently with other functions. You launch one with the go keyword.

package main

import (
    "fmt"
    "time"
)

func greet(name string) {
    fmt.Printf("Hello, %s!\n", name)
}

func main() {
    go greet("Alice") // runs concurrently
    go greet("Bob")   // runs concurrently
    go greet("Carol") // runs concurrently

    time.Sleep(1 * time.Second) // give goroutines time to finish
}

Output (order may vary):

Hello, Bob!
Hello, Alice!
Hello, Carol!

Notice the order isn't guaranteed — that's concurrency in action.

⚠️ The time.Sleep hack is just for demonstration. In real code, use sync.WaitGroup or channels to coordinate.

WaitGroups: The Right Way to Wait

package main

import (
    "fmt"
    "sync"
)

func greet(name string, wg *sync.WaitGroup) {
    defer wg.Done() // signal that this goroutine is done
    fmt.Printf("Hello, %s!\n", name)
}

func main() {
    var wg sync.WaitGroup

    names := []string{"Alice", "Bob", "Carol"}

    for _, name := range names {
        wg.Add(1) // tell the WaitGroup to expect one more
        go greet(name, &wg)
    }

    wg.Wait() // block until all goroutines call Done()
    fmt.Println("All done!")
}

sync.WaitGroup is your best friend when you want to fire off goroutines and wait for all of them to complete.

Channels: Goroutines Talking to Each Other

A channel is a typed pipe through which goroutines send and receive values. Think of it as a conveyor belt between workers.

ch := make(chan int)     // unbuffered channel of ints
ch := make(chan int, 5)  // buffered channel with capacity 5

Simple Example: Passing a Value

package main

import "fmt"

func square(n int, ch chan int) {
    ch <- n * n // send result to channel
}

func main() {
    ch := make(chan int)

    go square(9, ch)

    result := <-ch // receive from channel (blocks until value arrives)
    fmt.Println("9 squared is:", result)
}

Buffered vs Unbuffered Channels

Unbuffered Channel

Sending blocks until someone receives.

ch := make(chan string)
ch <- "hello" // 🚫 DEADLOCK — no one is receiving yet!

Buffered Channel

Sending only blocks when the buffer is full.

ch := make(chan string, 3)
ch <- "first"   // OK
ch <- "second"  // OK
ch <- "third"   // OK
ch <- "fourth"  // 🚫 BLOCKS — buffer is full

Real Example: Fetching Data Concurrently

Imagine you're fetching user profiles from an API — one at a time is slow. Let's do it concurrently.

package main

import (
    "fmt"
    "sync"
    "time"
)

type UserProfile struct {
    ID   int
    Name string
}

// Simulates an API call
func fetchProfile(id int, ch chan<- UserProfile, wg *sync.WaitGroup) {
    defer wg.Done()
    time.Sleep(100 * time.Millisecond) // simulate network delay

    ch <- UserProfile{
        ID:   id,
        Name: fmt.Sprintf("User_%d", id),
    }
}

func main() {
    ch := make(chan UserProfile, 10)
    var wg sync.WaitGroup

    userIDs := []int{1, 2, 3, 4, 5}

    for _, id := range userIDs {
        wg.Add(1)
        go fetchProfile(id, ch, &wg)
    }

    // Close channel once all goroutines are done
    go func() {
        wg.Wait()
        close(ch)
    }()

    // Collect results
    for profile := range ch {
        fmt.Printf("Fetched: ID=%d, Name=%s\n", profile.ID, profile.Name)
    }
}

This fetches all 5 profiles concurrently instead of sequentially — roughly 5x faster.

Select: Listening on Multiple Channels

select lets a goroutine wait on multiple channel operations at once — like a switch for channels.

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(1 * time.Second)
        ch1 <- "one"
    }()

    go func() {
        time.Sleep(2 * time.Second)
        ch2 <- "two"
    }()

    for i := 0; i < 2; i++ {
        select {
        case msg1 := <-ch1:
            fmt.Println("Received from ch1:", msg1)
        case msg2 := <-ch2:
            fmt.Println("Received from ch2:", msg2)
        }
    }
}

This is especially useful for timeouts:

select {
case result := <-ch:
    fmt.Println("Got result:", result)
case <-time.After(3 * time.Second):
    fmt.Println("Timed out!")
}

Common Pitfalls to Avoid

1. Goroutine Leaks

If a goroutine is blocked on a channel that nobody ever reads from, it runs forever.

// BAD: goroutine blocks forever
ch := make(chan int)
go func() {
    ch <- 42 // no one reads this
}()

Always make sure every goroutine has a way to exit.

2. Race Conditions

Two goroutines writing to the same variable without synchronization = undefined behaviour.

// BAD
counter := 0
go func() { counter++ }()
go func() { counter++ }()

Use sync.Mutex or channels to protect shared state.

var mu sync.Mutex
mu.Lock()
counter++
mu.Unlock()

3. Closing a Closed Channel

Closing an already-closed channel causes a panic. Only close from the sender side, and only once.

Quick Reference

Concept	Use When
`go func()`	You want to run something concurrently
`sync.WaitGroup`	You want to wait for multiple goroutines
Unbuffered channel	You need tight synchronization between goroutines
Buffered channel	You want to decouple sender and receiver
`select`	You're waiting on multiple channels or implementing timeouts
`sync.Mutex`	You're protecting shared mutable state

Wrapping Up

Go's concurrency model is elegant once it clicks. The key ideas:

Goroutines are cheap — you can spin up thousands
Channels are how goroutines communicate safely
Don't share memory to communicate — let channels do the talking
Watch out for leaks, race conditions, and double closes

The best way to get comfortable is to build something: a web scraper, a concurrent file processor, a worker pool. Pick one and run with it.

Are you using goroutines in your current project? What patterns have you found most useful? Drop a comment below 👇

Your Guide Into the Development World: A Roadmap for Absolute Beginners

Dishon Oketch — Sun, 26 Apr 2026 10:13:43 +0000

Your Guide Into the Development World: A Roadmap for Absolute Beginners

You've decided you want to code. Maybe you saw someone build a cool app, maybe you want a career change, maybe you're just curious. Whatever brought you here — welcome. This guide is written for you.

First, Let's Kill a Myth

You don't need to be a math genius to become a developer. You don't need a Computer Science degree. You don't need an expensive laptop or a fast internet connection. What you need is curiosity, consistency, and a willingness to feel stuck sometimes — because being stuck is literally part of the job.

Even senior engineers Google things every single day.

What Even Is a Developer?

A developer (or programmer, or software engineer — terms often used interchangeably) is someone who writes instructions that computers understand to solve problems or build things.

Those instructions are called code, and they're written in programming languages like Python, JavaScript, Go, or dozens of others.

When you use an app on your phone, visit a website, or use an ATM — a developer built that. That's the scope of what this field touches.

The Different Paths You Can Take

The development world isn't one lane — it's a highway with multiple routes. Here's a high-level map:

🖥️ Frontend Development

You build what users see and interact with — websites, mobile interfaces, dashboards.

Tools you'll use: HTML, CSS, JavaScript, React, Vue

You'll love it if: You care about design, user experience, and making things look great.

⚙️ Backend Development

You build what happens behind the scenes — databases, APIs, business logic, servers.

Tools you'll use: Python, Go, Node.js, Java, PostgreSQL, MySQL

You'll love it if: You like solving logic problems and don't mind working without a visual result.

🔀 Full-Stack Development

You do both frontend and backend. Most self-taught developers end up here eventually.

📱 Mobile Development

You build apps for phones — Android, iOS, or cross-platform.

Tools you'll use: Swift (iOS), Kotlin (Android), Flutter, React Native

🤖 DevOps / Cloud Engineering

You manage infrastructure — the servers, pipelines, and tools that keep applications running.

Tools you'll use: Linux, Docker, Kubernetes, AWS, GitHub Actions

🔐 Cybersecurity / Security Engineering

You find and fix vulnerabilities. You think like an attacker to defend systems.

💡 You don't have to choose right now. Most people start with web development (frontend or backend) because there are more resources and jobs available. You can always pivot later.

Where Do You Start?

Step 1: Pick One Language and Stick With It

The biggest mistake beginners make is jumping between languages every time they hit a wall. Don't.

Pick one and go deep:

JavaScript — best if you want to build websites (runs in the browser and on servers)
Python — best if you're drawn to data, automation, or AI
Go — great if you're already in an environment like Zone01 and want performance and simplicity

There is no wrong choice. Every language teaches you programming fundamentals that transfer everywhere.

Step 2: Learn the Fundamentals (They Apply Everywhere)

No matter what language you choose, these concepts are universal:

Variables — storing data
Data types — strings, integers, booleans, arrays
Conditionals — if, else, switch
Loops — for, while
Functions — reusable blocks of code
Error handling — what to do when things go wrong

Once you can write a program that takes input, processes it, and produces output — you're coding.

Step 3: Build Something (Anything)

Reading tutorials without building is like reading a recipe without cooking. You'll understand nothing until your hands are on the keyboard.

Here are beginner project ideas by level:

Level 1 — You just started

A calculator
A number guessing game
A to-do list (command-line version)

Level 2 — You know the basics

A simple blog or portfolio website
A weather app using a public API
A quiz app

Level 3 — You're getting serious

A URL shortener
A REST API for a simple store
A chat app

The goal isn't to build something impressive. The goal is to get stuck, solve it, and learn from that.

Step 4: Learn Version Control (Git)

Git is how developers track changes to their code and collaborate with others. It is not optional — every team uses it.

Start with:

git init          # start tracking a project
git add .         # stage your changes
git commit -m "my first commit"   # save a snapshot
git push          # upload to GitHub

Create a free account on GitHub and put every project there — even the messy ones. It becomes your portfolio.

Step 5: Get Comfortable With the Terminal

The terminal (also called the command line or shell) is a text-based interface for talking to your computer. Most development work happens there.

Essential commands to know:

ls          # list files in current directory
cd folder   # change into a folder
mkdir app   # create a new folder
touch file.go  # create a new file
cat file.go    # print file contents
rm file.go     # delete a file

Don't memorize them — just use them until they become muscle memory.

The Emotional Side Nobody Talks About

You Will Feel Dumb. That's Normal.

Every developer — junior, senior, 10 years in — regularly sits in front of a bug they can't figure out. The difference between a beginner and an expert isn't that experts don't get stuck. It's that they've learned how to get unstuck.

When you're stuck:

Read the error message carefully — it's usually telling you exactly what's wrong
Search it on Google (copy the error, paste it in)
Check Stack Overflow and GitHub issues
Ask someone — in a Discord server, at a bootcamp, or online

There's no shame in asking. Collaboration is how this industry works.

Imposter Syndrome Is Real

At some point you'll think: "Everyone else knows more than me. I don't belong here."

Everyone feels this. It doesn't mean you're not good enough. It means you're growing.

Progress Is Not Linear

Some days you'll build three features. Some days you'll spend 4 hours debugging one missing semicolon. Both days are valid developer days.

Resources to Get You Started

Free platforms to learn:

freeCodeCamp — full curriculum, project-based
The Odin Project — excellent for web dev
CS50 by Harvard — best free intro to CS, period
Go Tour — if you're going the Go route
Exercism — practice problems with mentorship

Build in public:

Share your projects on GitHub
Write about what you're learning on dev.to (yes, like this article!)
Join communities — Discord servers, local meetups, coding bootcamps like Zone01

Your First Week Challenge

Here's a simple plan to get going this week:

Day	Task
Day 1	Install your language and run "Hello, World!"
Day 2	Learn variables, data types, and `if` statements
Day 3	Learn loops and functions
Day 4	Build a number guessing game
Day 5	Push it to GitHub
Day 6	Read someone else's beginner code and try to understand it
Day 7	Rest. Seriously.

You Don't Need to Know Everything to Start

The development world is vast. There will always be a new framework, a new language, a new tool. You will never know it all — and that's not the goal.

The goal is to build things that solve problems. And you can start doing that with very little knowledge.

So open your terminal. Write your first line of code. Google the error. Ask for help. Build something ugly. Improve it. Repeat.

That's how every developer — every single one — started.

Are you just getting into development? What's the biggest thing holding you back? Drop a comment — let's talk about it 👇

Tags: #beginners #programming #webdev #career #codenewbie

Essential DevTools Every Go Developer Should Know

Dishon Oketch — Thu, 23 Apr 2026 02:16:44 +0000

Essential DevTools Every Go Developer Should Know

Go ships with a powerful standard toolchain that many developers underestimate. Beyond writing code, knowing your tools is what separates a developer who fights their environment from one who moves efficiently through it. This article walks through the essential Go dev tools — what they do, when to use them, and why they matter.

1. `go run` — Fast Feedback Loop

go run main.go

go run compiles and executes a Go program in a single step without producing a binary artifact. Internally, it compiles to a temporary directory and runs the resulting binary. It's not for production — it's your rapid iteration tool during development.

For multi-file packages:

go run .

2. `go build` — Producing Binaries

go build -o bin/myapp .

Go compiles to a statically linked binary by default — no runtime, no VM, no dependencies on the host system. This makes deployment straightforward: copy the binary and run it.

You can cross-compile for different OS/architectures using environment variables:

GOOS=linux GOARCH=amd64 go build -o bin/myapp-linux .

This is particularly powerful for building Linux binaries from a Mac or Windows machine.

3. `go fmt` — Enforced Code Style

go fmt ./...

Go enforces a single, non-negotiable code style via go fmt. There are no style debates in Go teams — the formatter decides. It uses tabs for indentation and has strict rules on spacing, braces, and imports.

Most editors run this on save via gopls. You should also enforce it in CI to reject unformatted code.

4. `go vet` — Static Analysis

go vet ./...

go vet performs static analysis to catch bugs the compiler won't flag — mismatched Printf format verbs, incorrect struct tags, unreachable code, suspicious composite literals, and more.

It's lightweight and fast. Run it before every commit. In CI, a failing go vet should block a merge.

5. `go test` — Built-in Testing Framework

Go has testing built into the standard library — no third-party framework needed.

go test ./...                        # Run all tests
go test -v -run TestFunctionName ./... # Run a specific test with verbose output
go test -race ./...                  # Run with race condition detector
go test -cover ./...                 # Show test coverage

Test files follow the _test.go naming convention. The race detector (-race) is particularly valuable — it instruments memory accesses at runtime to detect concurrent data races, which are otherwise very hard to catch.

6. `gopls` — The Go Language Server

gopls is the official Go language server implementing the Language Server Protocol (LSP). It powers editor features like:

Intelligent autocompletion
Go-to-definition and find-references
Inline diagnostics and error highlighting
Automatic imports management
Refactoring (rename, extract function)

It integrates with VS Code (via the Go extension), Neovim (via nvim-lspconfig), GoLand, and most modern editors. For VS Code, installing the official Go extension is all you need — gopls is bundled and managed automatically.

7. Delve (`dlv`) — The Go Debugger

go install github.com/go-delve/delve/cmd/dlv@latest

Delve is the standard debugger for Go. It understands Go's runtime, goroutines, and data structures — unlike GDB, which doesn't handle Go well.

dlv debug main.go        # Start debugging
dlv test ./pkg/...       # Debug tests

Common commands inside the Delve REPL:

break main.main       # Set breakpoint
continue              # Run until breakpoint
next                  # Step over
step                  # Step into
print variableName    # Inspect a variable
goroutines            # List all goroutines

Delve integrates with VS Code's debug panel, so you can set breakpoints and inspect state visually without touching the CLI.

8. `golangci-lint` — Unified Linting

go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
golangci-lint run ./...

golangci-lint runs multiple linters in parallel under a single binary. It includes staticcheck, errcheck, gosec, gocritic, and many others. Running each separately would be slow and painful — this bundles them efficiently.

Configure it via .golangci.yml at the root of your project:

linters:
  enable:
    - errcheck
    - gosimple
    - staticcheck
    - unused
    - govet

This is the standard linting tool used in professional Go CI pipelines.

9. `air` — Live Reload

go install github.com/air-verse/air@latest
air

air watches your project for file changes and automatically rebuilds and restarts your application. Essential for web server or API development where you'd otherwise be manually stopping and restarting on every change.

Configure it via .air.toml:

[build]
  cmd = "go build -o ./tmp/main ."
  bin = "./tmp/main"
  include_ext = ["go", "html", "env"]

10. `go mod` — Module and Dependency Management

Go modules are the built-in dependency management system, introduced in Go 1.11 and now the standard.

go mod init github.com/username/myapp  # Initialize module
go get github.com/some/package         # Add dependency
go mod tidy                            # Remove unused, add missing
go mod vendor                          # Vendor dependencies locally

Dependencies are declared in go.mod and locked with checksums in go.sum. No separate package manager, no node_modules-style chaos.

Putting It All Together: A Practical Workflow

# During development
air                          # Live reload running in background

# Before committing
go fmt ./...                 # Format
go vet ./...                 # Static analysis
go test -race -cover ./...   # Tests with race detection and coverage
golangci-lint run ./...      # Lint

# Building for production
GOOS=linux GOARCH=amd64 go build -o bin/myapp .

Summary

Tool	Purpose
`go run`	Run without producing a binary
`go build`	Compile to a static binary
`go fmt`	Enforce standard code formatting
`go vet`	Static analysis for common bugs
`go test`	Run tests, coverage, race detection
`gopls`	Language server for editor intelligence
`dlv` (Delve)	Debugger with goroutine awareness
`golangci-lint`	Unified multi-linter
`air`	Live reload during development
`go mod`	Module and dependency management

Go's tooling is opinionated by design — and that's a feature, not a limitation. The less time you spend configuring your environment, the more time you spend building. Master these tools early and they'll stay with you throughout your Go career.

Suggested Dev.to tags: #go #golang #devtools #beginners

DEV Community: Dishon Oketch

🌿 Git Mastery: The Complete Developer Guide

Why Git?

Prerequisites

Part 1: First-Time Setup

Part 2: Starting a Repository

From scratch

From an existing remote

Part 3: The Core Workflow — Stage, Commit, Repeat

Checking status

Staging changes

Committing

Writing good commit messages

Part 4: Viewing History

Inspecting a specific commit

Comparing changes

Part 5: Branching — Git's Superpower

Merging branches

Deleting branches

Part 6: Rebasing — A Cleaner History

Interactive rebase — rewrite history

Part 7: Working with Remotes

Pushing and pulling

Tracking branches

Part 8: Undoing Things

Amending the last commit

Unstaging files

Reverting commits (safe — creates a new commit)

Resetting (rewrites history — be careful)

The escape hatch: reflog

Part 9: Stashing — Save Work Without Committing

Part 10: Tags — Marking Releases

Part 11: The .gitignore File

Part 12: Branching Strategies

Git Flow

GitHub Flow

Trunk-Based Development

Git Commands Cheat Sheet

Common Pitfalls & How to Avoid Them

❌ Committed secrets or credentials

❌ Merge conflicts

❌ Pushed to the wrong branch

❌ git pull creates ugly merge commits

Wrapping Up

What's Next?

🐳 How to Run Any Project in Docker: A Complete Guide

Why Docker?

Prerequisites

Part 1: The Anatomy of a Dockerfile

Key Instructions Explained

Part 2: Dockerizing a Node.js Project

Project structure

Dockerfile

Build and run

Part 3: Dockerizing a Python Project

Part 4: Docker Compose — Running Multiple Services

Example: Node.js app + PostgreSQL + Redis

Run everything with one command

Part 5: Environment Variables & Secrets

Part 6: Development vs Production Configurations

Part 7: Useful Docker Commands Cheat Sheet

Images

Containers

Debugging

Part 8: The .dockerignore File

Part 9: Multi-Stage Builds (Advanced)

Common Pitfalls & How to Avoid Them

❌ App can't connect to the database

❌ Changes not reflected after rebuild

❌ Container exits immediately

❌ Port already in use

Wrapping Up

What's Next?

The Death of "Just Write the Code": How AI-Native Development Is Reshaping What It Means to Be a Developer

What "AI-Native Development" Actually Means

The Old Loop vs. The New Loop

Where Mid-Level Devs Win (and Where We Can Get Lazy)

Where it genuinely helps us

Where we can get lazy (and why it matters)

A Real Example: From Intent to Shipped

❌ `git pull` creates ugly merge commits

1. `go run` — Fast Feedback Loop

2. `go build` — Producing Binaries