POV: You connected an AI agent to your industrial ops data and it gave wrong answers to even the most basic questions.

Why?

AI needs context. Your database architecture matters, and split data won’t cut it.

TigerData puts everything in one PostgreSQL + TimescaleDB instance for you, and lets the schema do the work.

Close the AI agent readiness gap by querying through MCP.

Learn more.

Click Here to Read More

Motivation

Claude Code has a feature that 90% of developers either ignore or use wrong.

It’s called Skills.

And it’s the difference between a $200/month autocomplete and an autonomous teammate that actually knows your codebase, your conventions, and your deployment process.

I’ve built dozens of skills across my projects. Most of them started as a single markdown file. That was the mistake. In this article I will tell you exactly what really works.

Let’s start.

Skills Are Folders, Not Files

This is the #1 misconception.

Most devs create a SKILL.md, write 20 lines of instructions, and call it a day. That’s like writing a README and calling it a codebase.

A skill is a directory. SKILL.md is just the entry point.

The real power is in the supporting files. Scripts Claude can execute. Reference docs it reads on demand. Templates it fills in. Config files it checks.

Claude only loads supporting files when it needs them. This is called progressive disclosure. Your main prompt stays lean. The details live in files Claude discovers as it works.

The Frontmatter Controls Everything

Every SKILL.md starts with YAML frontmatter between --- markers. This is where you configure how the skill behaves.

Here’s a real example:

This skill only runs when you type /deploy. It runs in an isolated subagent so it doesn’t pollute your conversation. And Claude can only use Bash and Read without asking permission. Total control.

Here’s the full reference of the available fields:

The three invocation modes:

• Default (no flags): Both you and Claude can invoke it. Description is always in Claude’s context.

• disable-model-invocation: true: Manual only via /name. Description is hidden from Claude’s context. Use for deploy, send-email, anything with side effects.

• user-invocable: false: Hidden from the / menu, but Claude can still invoke it automatically. Use for background knowledge like style guides and conventions.

Your Description Is the Trigger

This one cost me hours of debugging.

I had a skill that worked perfectly when I invoked it manually with /deploy. But Claude never picked it up on its own. I’d say “deploy this to staging” and Claude would just... wing it.

The problem was my description.

When Claude starts a session, it scans every skill’s description field to build a map of what’s available. Vague descriptions = invisible skills. Your brilliant skill just sits there, unused.

The fix is simple: Write your description for the model, not for humans. Include the trigger words someone would actually say. Be specific about WHEN to use it.

One line. That’s the difference between discoverable and disabled skills.

Three Biggest Mistakes In Skills

Stating the obvious.

Claude already knows how to code. If your skill just says “write clean functions and use meaningful variable names,” you’re wasting tokens.

Focus on what pushes Claude out of its defaults. The frontend-design skill exists because Claude defaults to Inter font and purple gradients every single time. That’s the kind of thing worth correcting.

No Gotchas section.

This is the highest-signal content in any skill. Period.

Every time Claude makes a mistake using your skill, add it to the Gotchas section. Over time, this section becomes incredibly valuable.

Instructions instead of scripts.

When I started giving Claude actual scripts to compose instead of prose instructions to follow, everything changed.

Without scripts, Claude reconstructs boilerplate every single turn. With scripts, it orchestrates. It calls your deploy script, your test runner, your healthcheck. It spends its intelligence on decisions, not on remembering how your CI pipeline works.

CLAUDE.md vs Subagents vs Skills

These three get confused all the time. Here’s how they’re different:

CLAUDE.md is your project’s always-on context. Conventions, rules, preferences. It loads into every session automatically. The downside: it’s always in your context window, eating tokens whether you need it or not.

Subagents are specialized workers that run in their own context window. They have custom system prompts, restricted tool access, and can even use a different model. When Claude delegates to a subagent, the work happens in a separate context. Your main conversation stays clean.

Skills are the sweet spot. They load on demand based on the description trigger. They’re folders with progressive disclosure. And they can run in a subagent context with context: fork if you want isolation.

When to use what:

• CLAUDE.md: Rules that apply to EVERY conversation. Keep it lean.

• Subagents: Heavy, isolated tasks. Code review that shouldn’t pollute your main context. Research across a large codebase.

• Skills: Everything else. Reusable capabilities with their own files, scripts, and configuration.

Make Your Skills Portable

Where you store a skill determines who can use it:

Personal skills (~/.claude/skills/) follow you across every project on your machine. Most people don’t know this exists. Anything you use across repos belongs here.

Team sharing: check skills into .claude/skills/ in your repo. Everyone gets them via git pull.

Cross-tool portability: Claude Code skills follow the Agent Skills open standard (agentskills.io). The same SKILL.md works in Cursor, Gemini CLI, JetBrains Junie, Amp, and 10+ other tools. Write once, use everywhere.

💡 Working across multiple machines? Symlink ~/.claude/skills/ to a git-synced dotfiles repo.

Where to Find Skills

You don’t have to build everything from scratch. Here’s where to find production-ready skills:

Anthropic’s Official Skills Repo

The skills that power Claude’s document capabilities (PowerPoint, Excel, Word, PDF) are open-sourced here. Plus creative, dev, and enterprise examples. You can register the entire repo as a Claude Code plugin marketplace and install skills directly.

ClawHub

Community marketplace for Agent Skills. Browse what others have built, install with one command, publish your own. Works with Claude Code directly.

Awesome Claude Skills

Curated list of community skills, organized by category. Good starting point to see what’s possible.

Awesome Claude Skills (Composio)

Another solid collection with a focus on integrations and automation skills.

Agent Skills Spec

The open standard itself. If you want to understand the format deeply or build skills that work across Claude Code, Cursor, Gemini CLI, and other tools.

Bonus: Let Claude Build Your Skills

Don’t want to write skills from scratch? Anthropic built a Skill Creator skill that does it for you.

It’s in their official skills repo (github.com/anthropics/skills). Install it, then tell Claude what you want: “I need a skill that deploys to staging.” It will:

1. Interview you about what the skill should do

2. Write the SKILL.md with proper frontmatter

3. Create test prompts and run them

4. Show you the results for evaluation

5. Iterate until the skill works reliably

6. Optimize the description field for better triggering

It even runs benchmarks to measure how well your skill performs across different prompts. And it optimizes descriptions to combat “undertriggering,” which is Claude’s tendency to not use skills even when they’d be useful.

This is the fastest way to go from “I want a skill for X” to a production-ready skill.

Summing up

Your first skill doesn’t need to be perfect.

Start with a folder. Write a specific description. Add one gotcha.

Then grow it every time Claude gets something wrong.

That’s how every great skill starts. And that’s how you turn Claude from a smart autocomplete into a teammate that actually knows how you work.

Craft Better Software with Skills.

What’s your Claude Code setup? Reply and let me know. I read every response.

Promote Yourself to 36,000+ subscribers by sponsoring this newsletter.

Treat your app like an Orchid: A beautiful flower that needs sunlight and a bit of water 🌸.

Most “AI builders” make you grow your app in their pot. Same stack. Same limits. Same rules. And on their databases. Orchids is different:

• It’s your build space, set up your way.

• Build anything, Web app, mobile app, Slack bot, Chrome extension, Python script, whatever.

• Bring your own AI subscriptions so you’re not paying twice.

• Plug in the database you already use and trust.

• Use any payment infra you want.

Try Orchids.app and build it the way you were meant to

Get Started Today!

Motivation

Most developers use Claude Code like a chatbot. They type a prompt, it changes their code, then that’s it.

That’s 10% of what it can do.

I've been using Claude Code daily on production Rust, Python and JavaScript codebases across several repositories with millions of lines of code. After months of trial and error, I found 5 features that completely changed how I work with it.

Let’s start.

1. Nested CLAUDE.MD Files

Most developers create one CLAUDE.md and forget about it. But Claude Code has a loading system that’s way smarter than that.

When you start a session, Claude walks UP the directory tree and loads every CLAUDE.md it finds. Then it lazily loads CLAUDE.md files in subdirectories only when you touch files there.

Why this matters: In a monorepo, if you’re working in frontend/, you get the root-level conventions plus the frontend-specific rules. You never get backend/CLAUDE.md polluting your context.

Context is precious. Claude’s loading system protects it automatically.

Here’s what to put in each level:

• 👉 Root CLAUDE.md — coding standards, commit format, architecture overview, common gotchas

• 👉 Component CLAUDE.md — framework-specific patterns, testing setup, naming conventions for that area

• 👉 CLAUDE.local.md — your personal preferences. Add it to .gitignore so teammates don’t inherit your quirks.

Here are a few lines as example from a Claude.MD file for a project i work on:

The secret is simple: short, opinionated and actionable Claude.MD files.

2. Skills Turn Repetitive Work Into One-Slash Triggers

Every developer has workflows they repeat. Reviewing PRs. Running debug steps. Generating tests.

Claude Code lets you save these as skills. They are markdown files that you trigger with a / slash.

If you’ve seen older tutorials mention .claude/commands/, that still works. But Claude recently merged commands into skills.

Skills are the recommended path going forward because they support things commands couldn’t: supporting files (templates, scripts, examples), auto-discovery by Claude, and control over who can invoke them.

Here’s one I use constantly:

Save it. Now /security-review gives you a full security audit. Every time.

The key advantage of skills: Claude can auto-discover them. If the description matches what you're asking, Claude loads the skill automatically.

💡 Pro tip: Add context: fork to the frontmatter (block between --- markers). This runs the command in an isolated context, so it doesn’t pollute your main conversation:

To create new skills use the skill creator skill. It also helps iteratively improving them.

You can build skills for anything:

• Analyzing server logs

• Generating test suites

• Running common debug steps

• Creating documentation

One file. One slash. Done.

3. Subagents Give You Parallel Brains

This is where Claude Code gets seriously powerful.

A subagent runs in a completely fresh context. Separate memory. Separate tools. Separate conversation. It’s like having a second engineer working alongside you.

Claude Code ships with built-in agents:

• Explore: uses Haiku (fast + cheap), read-only. Perfect for codebase research

• Plan: read-only research mode. Designs before coding

• Bash: runs terminal commands in isolation

But the real power is building your own:

The word "PROACTIVELY" in the description is key. It tells Claude to automatically spawn this agent when it needs to explore code. No manual trigger needed.

Here’s what happens:

1. You ask Claude to implement a feature

2. It spawns the researcher agent (Haiku, read-only, cheap)

3. Researcher explores the codebase and reports back

4. Main agent writes code with full context

Fast model for research. Smart model for writing. Right brain for the right job.

4. Install 3 MCP Servers, Not 15

MCP (Model Context Protocol) servers connect Claude Code to external tools. Databases. Browsers. Documentation APIs.

The temptation is to install everything. Don’t.

A Reddit thread with 682 upvotes said it best:

“Went overboard with 15 MCP servers thinking more = better. Ended up using only 4 daily.”

Every MCP server eats context. More servers = more tool descriptions loaded = less room for your actual code.

Here are the 3 that actually earn their context cost:

👉 Context7 : fetches up-to-date library docs. Prevents Claude from hallucinating APIs that were deprecated two versions ago.

👉 Playwright : browser automation. Claude can screenshot, click, fill forms, and verify UI changes actually work.

👉 Chrome DevTools : connects to your real Chrome browser. Claude sees the actual console errors and DOM your users see.

Configuration is simple. Put .mcp.json in your project root and commit it:

✅ Pro tip: Auto-approve trusted servers in settings to skip the permission prompt every session.

Less servers. More focus. Better output.

5. Putting It All Together

Skills can spawn agents. Agents can carry their own preloaded knowledge. When you combine these two ideas, you get safe, parallel, fully autonomous workflows.

Here’s what it looks like in an example. Two files:

The skill:

The agent:

Here’s why this combo matters:

• isolation: worktree : the agent works in its own isolated copy of the repo. Your working directory stays clean. You can run multiple /implement in parallel on different features.

• permissionMode: acceptEdits : the agent auto-approves file edits. No clicking “allow” 50 times.

• disable-model-invocation: true : Claude never triggers this on its own. You control when a full implementation kicks off.

• skills: [coding-standards, testing-patterns] : the agent gets your coding standards injected into its context at startup. Every implementation follows your conventions without you repeating them.

• maxTurns: 50 : the agent stops if it spirals. No infinite loops burning tokens.

The skill is the trigger with safety rails. The agent is the worker with execution config.

Now /implement "add CSV export for users" spawns an agent in its own isolated directory that researches, codes, tests, and commits. Autonomously.

This is the difference between using Claude Code as a chatbot and using it as an engineering system.

Stop Using Claude Code at 10%

None of these features are hidden. They’re all documented. But most developers never set them up.

Here’s my challenge: start with CLAUDE.md today. Even a 10-line file with your project’s conventions will change what Claude Code produces.

Then add one skill. Then one subagent. Layer it up.

The developers who treat Claude Code as a configurable system, not a chat window, will Craft Better Software.

What’s your Claude Code setup? Reply and let me know. I read every response.

Promote Yourself to 36,000+ subscribers by sponsoring this newsletter.

Treat your app like an Orchid: A beautiful flower that needs sunlight and a bit of water 🌸.

Most “AI builders” make you grow your app in their pot. Same stack. Same limits. Same rules. And on their databases. Orchids is different:

• It’s your build space, set up your way.

• Build anything, Web app, mobile app, Slack bot, Chrome extension, Python script, whatever.

• Bring your own AI subscriptions so you’re not paying twice.

• Plug in the database you already use and trust.

• Use any payment infra you want.

Try Orchids.app and build it the way you were meant to

Get Started Today!

Motivation

OpenClaw hit 200k users in 1 month.

That’s insane.

For comparison: React needed more than 10 years to reach similar adoption.

This alone tells you OpenClaw isn’t “just another tool”.

It’s a new computing primitive: an AI assistant that can research markets, write code, analyze data, and orchestrate real workflows.

Yet most people don’t know how to set one up and run it properly in a secure, persistent, and deterministic way.

Here’s how I use OpenClaw in practice:

Installing OpenClaw

Start with the official guide and keep it simple: Getting Started

A Mac mini is a great always-on local setup, but a VPS works just as well. Hetzner is a solid option, though most providers are fine.

I strongly recommend running OpenClaw in Docker. It keeps instances isolated, makes scaling easier, and lets you rebuild instead of debug when something breaks.

Once it’s running, stop tuning. The real gains come from configuration, not installation.

Identity: Fix The “Agreeable AI” Problem First

Most LLMs are annoying. They constantly agree, apologize and tell you “you’re absolutely right”, even when you’re clearly wrong.

That’s not intelligence. That’s flattery.

This is why identity is the very first thing I set up. I use the identity principles shared by the creator of OpenClaw. They force your agent to:

• challenge your assumptions

• push back

• optimize for correctness instead of politeness

Copy the text below and tell your OpenClaw. It will make a hell of a difference:

Security: Treat It Like Production Code

OpenClaw moves fast. There are more than 4k issues and 5k PRs, and a lot of contributions are AI-generated. That’s normal at this speed, but it increases risk.

This doesn’t mean “don’t use OpenClaw”. It means wrap it in hard boundaries.

Here is my ultimate OpenClaw security checklist:

• Don’t make the gateway public

• Pairing is required to avoid anonym access

• Use scoped filesystem (no root access)

• Set up a private VPN with Tailscale for secure access

• Run command “openclaw security audit“ regularly

💡Bonus tip: Ask your bot to daily audit its own security. It will set up a cron job checking for configuration drift and reports it. Self-auditing agents catch mistakes before attackers do.

Memory Persistence with ClawVault

By default, OpenClaw stores memory as markdown: MEMORY.md for long-term context, daily logs for session notes. It also vector-searches these files and prompts the agent to save important context before conversations get compacted.

Out of the box, this already works, but only enough to get started.

The key discipline I follow: if it’s not written down, it doesn’t exist.

To achieve it, I use ClawVault, a local memory system that adds:

• Hybrid search (keyword + semantic) over all stored memories

• Typed memory buckets (decisions, preferences, lessons, facts)

• A wake/sleep lifecycle where each session hands off context to the next, so the agent never starts blind

• Periodic reflection passes that turn raw notes into durable insight

Result: memory compounds instead of decaying.

Backup: Assume Failure, Don’t Hope For Stability

My OpenClaw backs itself up to GitHub every 2 hours. Server dies? Spin up a new one, full memory restored. Want to migrate to a stronger machine? Spin up a new server, copy the memory, fully restored. Generated junk in memory along the way? Roll back to a clean snapshot.

Here is how it works:

How to do it? It’s easy! Just create a GitHub repo and tell this to your OpenClaw instance:

Do this from day one!

Models: Specialisation Beats Loyalty

Not all models are good at the same things.

I use Claude Opus 4.6 as my daily driver because it’s strong at reasoning, tool use, and coding.

For specialised work, I let OpenClaw spawn sub-agents using other models like Gemini 3.1 Pro or Kimi k2.5.

To reduce costs, and if you have a powerful server, you can run LLMs locally, for example Qwen or other models via Ollama.

The key idea is simple: use the right brain for the right job.

Skills: Where OpenClaw Becomes Leverage

OpenClaw skills are markdown files that contain instructional code to help agents perform specific tasks. Most skills can be found at ClawHub, and I highly recommend you to create skills for your own contexts too.

Here are one of the most useful skills I use daily:

• GitHub skill – repos, issues, PRs, code search from OpenClaw

• Exa Web Search – structured web / code search

• Playwright Scraper – scraping complex sites

• Playwright MCP – full browser automation

• SuperDesign - full high quality web app design

• YouTube Watcher - Get full transcription from youtube video

• Skill Creator - to make custom skills for your specific tasks

Skills are what turn OpenClaw from a chatbot into an smart AI assistant.

Conclusion

OpenClaw isn’t magic. But if you define identity, enforce security, structure memory, automate backups, choose models intentionally and invest in skills, then it becomes something far more interesting than an AI tool.

It becomes a system, a 24/7 working, never-tired, always-motivated AI assistant.

2026 is the year of AI agents and all great developers already leveraging it to Craft Better Software.

Turn any selfie into a professional photoshoot, in seconds. Upload your photos, choose your styles, and receive dozens of high-quality headshots.

Perfect for CVs, LinkedIn, business portfolios, and all your social media profiles.

Subscribe now and get 12 FREE Christmas-style photos, just in time for the holidays.

Start Now

Motivation

Coding as we knew it is dead. Two years ago, AI helped me name variables. Today, it writes 90% of my code.

If you’re still against AI at this point, you’re falling behind.

Top developers don’t use AI as fancy autocomplete. They use agents, clear specs, and modern models to solve real problems fast.

That mindset shift is already non-negotiable.

In this issue, I’ll show you the Vibe Coding Stack for 2026. Practical tools. Clear use cases. Pro-level tactics.

And at the end, I’ll show you one bonus tool that cuts deployments and CI effort to almost zero.

Let’s start.

Claude Code

I tried Copilot, Cursor, Windsurf, Tabnine, Codeium, everything. Claude Code is the one that makes me feel like I actually have an engineering partner.

6 Ways to Get the Most Out of Claude

1. Use the VS Code extension

Install the Claude Code extension and open separate windows for different parts of your project. It gives Claude direct context from the actual code you’re editing.

2. Create a Claude.md file

This acts as Claude’s onboarding sheet for AI. Include project goal, tech stack, repo layout, conventions & rules like TDD, naming or commit style.

By using a Claude.md file, you will stop repeating instructions.

💡 Pro tip: Consider using nested Claude.md files so Claude can navigate your codebase and pull in richer context as it works.

3. Use the flow: Explore → Plan → Code

Instead of saying this to AI:

“Implement X”

Say this:

“Explore existing solution → make a plan → implement.”

This leads to fewer mistakes, cleaner code and better architecture decisions. AI starts behaving like a senior engineer thinking before typing.

You should also switch on Plan Mode (Shift+tab) before starting a bigger task.

4. Use /clear often

Context is Claude’s strength, but also its weakness. Over time, conversations drift. Details blur. Costs go up.

The “/clear” command acts as a reset button, refreshes context, reduces hallucinations and saves a big amount of tokens.

5. Build custom slash commands

Store reusable workflows inside .claude/commands/.

Examples:

• “Generate tests for this module”

• “Analyze logs and summarize errors”

• “Rewrite this according to our style guide”

You turn repeated tasks into one-word triggers. That’s how real leverage compounds.

6. Give Claude screenshots

A picture says more than 1000 words. Paste UI bugs, logs, diagrams and console errors. Claude interprets visuals instantly.

Less explaining. Better insight. Faster fixes.

Cursor

I use Claude and Cursor side-by-side, but for different purposes.

Claude Code is perfect when I need a one-shot solution: spinning up multiple terminal sessions, running commands in parallel, or analyzing a full codebase quickly.

Cursor is the opposite, it’s built for working in small, iterative increments. It helps you refine code gradually, one change at a time.

In 2025, developers don’t get paid for writing code anymore. AI writes code. Your real job now is reviewing, improving, and ensuring correctness.

Cursor is the best review-centric AI tool available today.

Tips to Get Maximum Leverage

Configure rules

Rules provide system-level instructions to Cursor agents. They are persistent context, preferences, or workflows for your projects.

You can easily create them by using “New Cursor Rule“ command.

Optionally, you can also nest them. Nested rules automatically attach when files in their directory are referenced.

Example:

---
alwaysApply: true
---

# Function Design Rules
- Prefer pure function with no side effects
- Use intention-revealing names relating to the business domain  
- Limit the number of params in functions
- Reduce nesting with a return early
- Avoid boolean flag parameters
- Use comments sparingly

@productService.ts

Best practices to write great rules:

• Keep rules under 500 lines

• For each rule, configure rule type about when to apply

• Provide concrete examples or referenced files

• Avoid vague guidance. Write rules like clear internal docs

• Reuse rules when repeating prompts in chat

Use .cursorignore + cursorIndexing

What you hide matters more than what you show to AI.

• generated code

• node_modules

• API clients

• build artifacts

Why? Because Cursor reads everything and tries to be consistent with everything.

The smaller the context, the better its judgment.

Terminal AI Is Insanely Good

You don’t need to memorize complex CLI and Git commands anymore. The built-in terminal AI is my favorite.

You can ask AI for CLI commands like

• List my five most recent git branches

• Show me which processes are using port 3000

• Check logs of the most recently started docker container

• Git stash only the staged files

It feels like magic. Try it!

Command-K for surgical edits

This is Cursor’s secret weapon. Use it when you know exactly what needs to change.

How to use:

1. Select the code snippet

2. Press Command + K

3. Tell Cursor what to change

Example:

“Make all fonts smaller except the main paragraph.”

No searching. No grepping. No scrolling through 50 files.

Just one precise modification.

BugBot

Bugbot is an LLM-based review tool, to review pull requests and identify bugs, security issues, and code quality problems. So far it helped me to find missed null checks, detect wrong iteration boundaries or fix wrongly handled async code.

BugBot is powerful, but for real code review, I use something even better.

Let’s jump to that next.

CodeRabbit

Everyone is building the next AI review tool. Most are sloppy. But my absolute favourite is CodeRabbit.

Tips to get the most out of CodeRabbit:

• Talk to CodeRabbit via GitHub PRs

• Install VS Code extension for quick one-click fixes

• Use the CLI version to make it work with Claude Code

• Use MCP servers to connect to Figma, Confluence and internal wikis

• Create custom review instructions

And the cool thing is that the basic review features of CodeRabbit are free to use.

Start using CodeRabbit for FREE

The Ultimate Vibe Coding Flow

AI won’t work. Unless you know how to use it.

This is how we vibe code in 2025 in nine steps:

1. Draft a prompt

2. Let Claude Code refine it with context

3. Feed the new prompt back in

4. Say: “Analyze. Make a plan. Then implement.”

5. Review with CodeRabbit CLI

6. Apply fixes provided by CodeRabbit

7. Review code yourself

8. Test the hell out of it

9. Ship. Iterate.

AI won’t replace software engineers.

But an engineer using AI will.

The Vibe Coding Tech Stack

I use these AI-powered tools across all languages (f.e.: Rust, C#, JS/TS, Bash), but my preferred tech stack is the following:

AI performs best on this stack, because it’s trained on it more than anything else.

One prompt can add a full feature: UI → backend → DB → tests.

Deployment takes under 1 minute with Vercel. Environments are one-click. CI is automatic, no setup, no YAML hell.

And Vercel gives you built-in visual reviews, so every UI change can be reviewed before shipping.

This stack removes 90% of traditional DevOps.

You focus on shipping. AI handles the rest.

Conclusion

In 2025, the work of writing code is automated. The real advantage is knowing how to review, refine, and guide code creation.

Claude, Cursor, and CodeRabbit are bleeding-edge AI tools that turn you from an “AI user” into an “AI supervisor.”

Once you master that shift, you move from writing code to shaping systems, and Craft Better Software.

Code reviews are essential. But they’re also slow, inconsistent, and time-consuming.

That’s why I use CodeRabbit: an AI-powered assistant that reviews your pull requests automatically. It leaves meaningful comments like a real teammate would, catching common issues and improving overall software quality.

But like any tool, its impact depends on how you use it.

Here are the best tips to turn CodeRabbit into a real productivity booster for your team:

How CodeRabbit works

As a saying goes: “To use a tool better, understand it better.“

With CodeRabbit, internally, every review starts cloning your repo into a secure, sandboxed environment. It builds full codebase awareness, understanding dependencies, structure, and cross-file patterns, so reviews feel context-aware instead of “out of the blue.”

It even looks at past PRs and linked issues (from Jira, Linear, GitHub, or GitLab) to infer the WHY behind a change, not just the WHAT. This extra layer of understanding helps CodeRabbit write more meaningful, relevant review comments.

Configure CodeRabbit

Most teams just install CodeRabbit and leave defaults on.

That’s fine, but if you want to maximize it, you need to configure it.

Create a “.coderabbit.yaml“ in your repo and customize:

• Ignore WIP and draft branches to reduce noise

• Set review tone (chill or assertive) for better communication style

• Add path_filters to exclude files like generated code or test snapshots

• Integrate with famous projet managers like Jira or Linear, so CodeRabbit understands the intent behind each PR

• Enable chat & knowledge base for richer discussions

Here you can find the docs for the config: CodeRabbit YAML template

💡 - Another powerful feature is to set custom review instructions based on path patterns. By doing so you can set different instructions based on different parts of your app, such as APIs, tests or business domain layer.

You can do it under the path_instructions field in coderabbit.yaml file:

Avoid Big Pull Requests

The bigger the context, the higher the chance of missing bugs, slowing reviews, or getting irrelevant AI comments.

Small PRs are clarity. They’re focus. They help humans reason better, and make CodeRabbit’s AI analysis sharper.

If your PRs read like a novel, split your work into smaller chunks!

Get AI Review Your Code Before PR

AI reviews shouldn’t start only after a PR is created.

You can use CodeRabbit directly inside your IDE (like in VS Code) to review code before committing. This gives you early feedback on logic, style, and structure, without waiting for CI.

You use Claude Code in terminal?! There’s also a CodeRabbit CLI for that.

The good thing is that CodeRabbit offers one-click fixes by using AI.

Catch issues before your teammates do.

Talk to CodeRabbit via PRs

Most developers miss this feature: you can chat with CodeRabbit.

Don’t like a suggestion? Ask it to explain, adjust, or rewrite.

Need a fix but not ready to commit? Ask CodeRabbit to create a GitHub or Jira issue.

You can even teach it your organization’s standards over time, it learns and improves, just like a real teammate.

Integrate to MCP servers

Connect CodeRabbit to your existing tools using the Model Context Protocol (MCP) to make reviews smarter and more context-aware.

CodeRabbit automatically calls relevant MCP tools during analysis to gather context and enrich its comments.

For example:

• Requirements live in Linear

• Design specs live in Figma

• Architecture decisions stored in Confluence

• Security standards in internal wikis

This way, CodeRabbit doesn’t just review code, it understands the bigger picture behind every change.

Use Your Critical Thinking

CodeRabbit is fast, not infallible.

Use it as a first-pass reviewer, it catches common issues like null checks, naming, or code smells.

Then have humans focus on architecture, readability, and intent.

The best practice is use your critical thinking:

Final Thoughts

CodeRabbit turns code reviews from a chore into a competitive advantage.
It’s fast, consistent, and learns your project over time.

If you want to try it out, there’s a free version and a Pro tier (free for open-source projects).

It works very well with Claude Code CLI too → Link

Once configured properly, CodeRabbit doesn’t just review code. It also helps you craft better software.

CodeRabbit CLI is an AI code review tool that runs directly in your terminal. It provides intelligent code analysis, catches issues early, and integrates seamlessly with AI coding agents like Claude Code, Codex CLI, Cursor CLI, and Gemini to ensure your code is production-ready before it ships.

• Enables pre-commit reviews of both staged and unstaged changes, creating a multi-layered review process.

• Fits into existing Git workflows. Review uncommitted changes, staged files, specific commits, or entire branches without disrupting your current development process.

• Reviews specific files, directories, uncommitted changes, staged changes, or entire commits based on your needs.

• Supports programming languages including JavaScript, TypeScript, Python, Java, C#, C++, Ruby, Rust, Go, PHP, and more.

• Offers free AI code reviews with rate limits so developers can experience senior-level reviews at no cost.

• Flags hallucinations, code smells, security issues, and performance problems.

Supports guidelines for other AI generators, AST Grep rules, and path-based instructions.

Get Started Today

Motivation

Most engineers waste hours with poor debugging practices. Endless usage of “console.log” and guesswork.

But debugging is where real engineering happens.

It’s not just about killing bugs. It’s about thinking clearly, questioning assumptions, and preventing future defects.

When done right, debugging makes you sharper, faster, and more creative as a developer.

Today I collected my favorite 5 practices to master debugging:

1. Write Clean Bug Reports

Fixing bugs starts with a clean bug report. Yet 99% of developers don’t know how to write one.

But it’s the best way to speed up debugging.

Here’s the difference:

❌ Bad bug report:

✅ The template I use in my team:

When you create a bug report, the goal is simple: make the bug easily reproducible.

2. Prompt AI smartly

Have you ever struggled with AI fixing your code? Most developers just throw endless prompts like “Fix this bug”.

But as the saying goes: Garbage in, garbage out.

If you struggle with AI fixing your code, try this prompt instead:

“Reflect on 5–7 different possible sources of the problem, narrow it down to the 1–2 most likely ones, and add logs to validate the assumptions before moving on to the actual code fix.”

Works like magic.

3. Write a Failing Test for the Bug

My favorite way to fix a bug is to use Test-Driven Development.

If you find a bug, do the following:

• Write a failing test to reproduce the bug

• Find the bug in the code by debugging your test

• Make the failing test pass by fixing the bug

• Clean up the code if needed

This practice will force you to pinpoint what exactly the bug is and it’s also easy to tell when you fixed it since you have a passing test.

As a bonus, your bug won’t come back again as you covered with a test.

4. Take a 20-minute Walk

Taking a short walk is one of the most underrated yet powerful ways to fix a bug.

Why?

Because walking is scientifically proven to improve problem-solving and creativity. It resets your brain and lets you see the issue with a fresh perspective.

Magically, this works almost every time. Try it.

5. Use Git Bisect

Git Bisect is a standard GIT tool that helps you find the commit that introduced a bug. It works by performing a binary search between a known good commit and a known bad commit.

Git Bisect requires only two pieces of information before it can start the bug hunt:

• A commit where the behavior is definitely good

• A commit where the bug is present

Here’s how to use and automate it

1. Put your test in a script. The script must exit 0 when the bug is absent (good), and non-zero when the bug is present (bad).

2. Make it executable:

3. Run bisect with your script:

Git will checkout each candidate commit, run your script, and stop on the first bad commit.

As a result: you have the commit that introduced the bug. Cool isn’t it?

Conclusion

Bugs aren’t obstacles. They’re signals. They show you where to think deeper, where to get sharper, where to grow.

Master debugging, and you won’t just ship cleaner code, but you’ll build the mindset of a true software crafter.

CodeRabbit CLI is an AI code review tool that runs directly in your terminal. It provides intelligent code analysis, catches issues early, and integrates seamlessly with AI coding agents like Claude Code, Codex CLI, Cursor CLI, and Gemini to ensure your code is production-ready before it ships.

• Enables pre-commit reviews of both staged and unstaged changes, creating a multi-layered review process.

• Fits into existing Git workflows. Review uncommitted changes, staged files, specific commits, or entire branches without disrupting your current development process.

• Reviews specific files, directories, uncommitted changes, staged changes, or entire commits based on your needs.

• Supports programming languages including JavaScript, TypeScript, Python, Java, C#, C++, Ruby, Rust, Go, PHP, and more.

• Offers free AI code reviews with rate limits so developers can experience senior-level reviews at no cost.

• Flags hallucinations, code smells, security issues, and performance problems.

Supports guidelines for other AI generators, AST Grep rules, and path-based instructions.

Get Started Today

Motivation

Every developer can write working code.
But not every developer can write clean code.

Clean code is code that:

• tells the story of the business,

• can be read like prose,

• and can be changed with confidence.

Over the years, I’ve collected 100 practical tips that help you craft better software that doesn’t just work today, but stays readable, testable, and maintainable for years.

Here’s the full list 👇

✨ Clean Namings

1. Use intention-revealing names

2. Capture business knowledge

3. Avoid encoding and technical details

4. Use pronounceable names

5. Use searchable names

6. Avoid noise and redundant words

7. Use strong words

8. Don’t use abbreviations

9. Be consistent with concepts and vocabulary

10. Use is/has/should/can prefix for booleans

11. Avoid negative names for booleans

12. Use naming conventions within your project

13. Boolean names should be adjectives

14. Class names should be nouns or noun-phrases

    

⚡ Clean Functions

15. Function names should be verbs or verb-phrases

16. Keep functions small and concise

17. Avoid too many function arguments

18. Max number of lines in a function: 8–10

19. Avoid passing booleans as parameters

20. Strive for no side effects

21. Use enums as flags

22. Use empty lines to separate logic

23. If it takes more than 3 seconds to figure out what a function does, refactor it

🏗 Clean Classes

24. A class should have only one main responsibility

25. Avoid large classes (~100+ lines can be a smell)

26. Strive for one public function per class

27. Create small private functions for single tasks

28. Order functions based on execution flow

💬 Clean Comments

29. Avoid comments as much as possible

30. Don’t state the obvious

31. Don’t use them extensively (nobody will read them)

32. Replace comments with good naming

33. Use comments only for explaining why

34. Use comments for revealing implicit behavior

35. Use comments for API doc generation\

✅ Clean Tests

36. Use descriptive test names (scenario-based)

37. Use Given/When/Then or Should/When templates

38. Structure tests with Arrange / Act / Assert

39. Avoid logic (if, for, while) in tests

40. Couple a test with one behavior

41. Use meaningful test data

42. Hide irrelevant test data

43. Write clean assertions that describe domain behaviors

44. Create deterministic tests

45. Remove duplication with parameterized tests

46. Prefer fakes for mocking out 3rd party code

🔑 F.I.R.S.T Principle for Tests

47. Tests should be fast

48. Tests should be independent

49. Tests should be repeatable

50. Tests should be self-validating

51. Tests should be thorough (happy paths, edge cases, negative cases, security, illegal input)

🔀 Git Commits

52. Commit early & push often

53. Write meaningful commit messages explaining the reason

54. Use the imperative mood in commit messages

55. Use present tense

56. Add a link reference to the related story, task, or bug

🕳 Code Smells

57. Avoid magic numbers

58. Avoid magic strings

59. Avoid long conditions

60. Avoid global variables

61. Avoid long parameter lists

62. Don’t overuse primitives — model your domain with rich types

63. Avoid deeply nested logic

64. Reduce cyclomatic complexity

65. Hard-to-test logic is a smell to fix

🎨 Formatting

66. Set up team standards

67. Use automated formatters

68. Set a max width for lines

69. Don’t use horizontal alignment

70. Don’t break indentation

71. Declare variables close to their usage

📐 Core Principles

72. Don't repeat yourself (DRY): remove knowledge duplication

73. Keep it simple (KISS): simple code beats both complex and clever code

74. You ain't gonna need it (YAGNI): don't produce code that is not needed in your current context

75. Tell, don't ask: bundle data and functions together

76. Single Responsibility Principle (SRP): organize logic into modules with one reason to change

77. Liskov Substitution Principle (LSP): a subtype should be able to replace its base type without altering the program

78. Interface Segregation Principle (ISP): split large interfaces into small and more specific ones

79. Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules. Both should depend on abstractions.

80. Favor composition over inheritance: inheritance leads to tight coupling, composition gives more flexibility

81. Divide and Conquer: break down a problem into smaller sizes to manage complexity

82. High cohesion: group related code together. It helps you to find logic easier and makes your code easy to maintain

83. Low coupling: your modules should independent of other modules. By doing so, you can easier make changes to internals without breaking other modules

🛠 Extra Tips

84. Use a solid IDE with refactoring tools

85. Master your IDE hotkeys

86. Use feature-based folder structure

87. Pair programming helps keep code clean

88. Delete unused code — it’s a liability

89. Write code for humans, not just machines

90. Readability > cleverness

91. Favor readability over efficiency

92. Always leave the code cleaner than you found it

93. Test early, test often

94. Refactor early, refactor often

95. Do real-time code reviews instead of just PR reviews

96. Use the “rule of three” to remove duplication

97. Avoid using NULL — it’s a code smell

98. Working code ≠ clean code

99. You can’t have clean code without tests

100. Write code that reads like well-written prose

Conclusion

Clean code is not a checklist. It’s a mindset.

It’s the discipline of choosing clarity over cleverness.
It’s the habit of leaving the codebase better than you found it.
It’s the commitment to future teammates, and to your future self.

Because in the end:

Working code delivers features.

Clean Code builds lasting software.

Code reviews are critical but time-consuming. CodeRabbit acts as your AI co-pilot, providing instant Code review comments and potential impacts of every pull request.

Beyond just flagging issues, CodeRabbit provides one-click fix suggestions and lets you define custom code quality rules using AST Grep patterns, catching subtle issues that traditional static analysis tools might miss.

CodeRabbit has so far reviewed more than 10 million PRs, installed on 1 million repositories, and used by 70 thousand Open-source projects. CodeRabbit is free for all open-source repo's.

Get Started Today

Motivation

I stopped using Cursor. I moved fully to Claude Code.

After trying both side by side with my team, the conclusion was clear:

👉 Claude Code feels 10x better for real development work.

It’s not just about faster results. Claude Code has many useful features I am a big fan of. It’s like pairing with a senior engineer who never gets tired.

Here are 6 practical tips we use in my team to get the most out of Claude Code:

1. Use the VS Code extension

First of all, install the Claude Code extension. It works with VS Code, Cursor, and Windsurf too. The extension itself is very simple, but it helps you start Claude Code quickly. The nice part is that you can open several windows at once in your IDE, each can be focused on a different part of your project.

2. Create a Claude.md file

Give Claude a foundation by creating a Claude.md file in your repo.

Think of Claude.md as onboarding docs for your AI teammate. Instead of repeating yourself in every prompt, Claude stays aligned and consistent. The result: fewer misunderstandings, more consistent code, and smoother collaboration.

Add the following details:

• The project’s main goal

• The tech stack you use

• Folder structures

• The software practices you follow (TDD, clean code, commit rules, etc.)

💡 Pro tip: Consider using nested Claude.md files so Claude can navigate your codebase and pull in richer context as it works.

3. Explore ➝ Plan ➝ Code

Most devs jump straight to “Hey Claude, implement this feature”

That works, but it’s shallow. I found a better rhythm:

• Ask Claude to explore the existing solution first.

• Then have it plan the change.

• Finally, let it implement.

This layered approach produces code that’s better thought-out, easier to maintain, and often catches edge cases you didn’t think of.

It genuinely feels like working with an engineer who pauses, thinks, and then writes. That’s why I call it the closest thing to AGI coding right now.

4. Use /clear often

Context is Claude’s strength, but also its weakness. Over time, conversations drift. Details blur. Costs go up.

That’s when /clear becomes your friend.

I use it like hitting the reset button:

• It sharpens Claude’s focus

• Reduces hallucinations

• And saves a surprising amount of tokens

It’s like closing and reopening your IDE when things feel “stale.”

Simple habit, huge difference in output quality.

5. Build custom slash commands

One of Claude’s hidden superpowers: custom commands.

They let you create repeatable workflows for things like:

• analyzing server logs

• running common debug steps

• generating test and documentation

You define them once inside .claude/commands/. After that, you can trigger them instantly with a simple slash command.

Think of it as reusable macros for your AI teammate. Productivity on autopilot.

6. Give Claude screenshots

A picture says more than 1000 words.

I am continuously pasting screenshots into Claude: error messages, diagrams, even UI snippets. Claude reads and interprets them with surprising accuracy.

Suddenly, you don’t waste time describing the shape of a bug or the layout of a system. You just show it.

Better input = better output.

Final Thought

Claude Code isn’t just another coding assistant. It is the cutting edge of AI.

Once you start treating Claude like a real teammate - giving it onboarding, resetting when needed, and letting it think in steps - the results feel like magic, helping you to craft better software.

AI won't replace software engineers, but an engineer using AI will.

As someone who’s reviewed thousands of pull requests, I can confidently say that CodeRabbit gets it right.

It doesn’t just flag lint rules. It understands your code structure using AST, explains the “why” behind each suggestion, and summarizes complex changes clearly for both reviewers and authors.

Top 5 reasons why you should try CodeRabbit and use it every day:

• Context-aware reviews: It knows how your changes impact the full system, not just the diff.

• Security and performance insights: Detects issues like vulnerabilities and slow patterns (e.g. sequential DB calls).

• Custom team learning: Learns from your feedback and adapts reviews to your team's coding standards.

• PR summaries and diagrams: Generates clear explanations, changelogs, and sequence diagrams.

Open source friendly: Free forever for public repos. No catch. CodeRabbit Pro is free forever.

Try CodeRabbit on your next PR -> no card needed, no BS. Just better reviews.

Motivation

Clean code isn't just for production code. Your tests deserve the same care. And when it comes to tests, nothing matters more than assertions. They’re the most important part of your tests. The final word, the “proof” that your system works.

Yet in many codebases, I see poorly written assertions. Sloppy assertions kill readability, bury bugs, and make tests hard to maintain.

Here are 5 tips for writing clean, expressive assertions that future-you and your teammates will thank you for.

Assert One Behaviour Per Test

Every test should verify a single, observable behavior. That doesn’t mean one physical assertion. It means one logical assertion. Sometimes, confirming one behavior might require multiple assertion lines, and that’s totally fine.

But if your test is checking multiple unrelated outcomes, it's doing too much. This hides intent and makes failures harder to diagnose. Keep each test focused on one behavior.

Rule of thumb: When in doubt, split your tests into multiple test cases.

Capture Domain Knowledge with Extract Method

Tests can teach, but only if they speak the language of your domain. One of my favorite techniques is to extract logic-heavy conditions into well-named helper functions.

Software is ultimately about solving problems in a specific business domain. Capturing that domain makes your code more expressive and meaningful.

Let each test tell a story:

Use Fluent Assertion Libraries

Think of your tests as documentation. They must be clear, readable, and concise. If your assertions are not fluently readable English sentences, then you are doing it wrong.

Fluent assertion libraries like FluentAssertions or AssertJ help you write tests that read like natural language. This not only improves readability but also helps express intent more clearly.

For example, the following assertion is hard to read and leads to a generic failure message:

❌ Assert.True(orders.contains(orderWithId(42)))

But the following assertion reads like plain English, and expresses exactly what you're checking:

✅ orders.shouldContain(orderWithId(42));

Fluent assertions also make debugging faster by showing meaningful output when tests fail.

Avoid Logic In Assertions

Avoid logic in your test code!

• if-else statements

• for and while loops

• switch cases

They can lead to bugs in your tests.

Once you feel the need for logic, it's a smell that you test more than one thing. You can get rid of test logic by splitting up your test into multiple test cases. Tests should be the simplest part of your code base.

Assert Outcomes, Not Implementation

Focus on what the system does, not how it does it. When tests are tightly coupled to implementation details, they become fragile. Every internal refactor risks breaking tests, even when the behavior hasn't changed. That’s a maintenance nightmare.

Instead, write tests that assert observable outcomes. Focus on what happens, not how it happens.

Bad example - asserting implementation:

❌ mockRepo.Verify(r => r.Save(It.IsAny<Order>()), Times.Once);

Good example - asserting outcome:

✅ order.Status.Should().Be(OrderStatus.Confirmed);

If your implementation changes but the behavior stays the same, your tests should still pass. That’s how you build confidence.

Conclusion

Assertions are the heartbeat of your tests. They prove and document if your system works. Clear, focused assertions make your tests readable, reliable, and resilient to change.

Avoid testing internals, skip the logic, and speak the language of your domain.

Sloppy assertions = unreadable tests

Clean assertions = living documentation

Write code for humans to read, not just for machines to execute.

Sponsorships

There are still a few sponsorship slots available for the coming months. If you want to sponsor this newsletter, apply here:

Apply for Sponsorship

I was always skeptical about AI’s impact on code quality. When the AI hype took off in 2023, I tried a few tools, but most gave low-quality suggestions, often worse than a junior developer.

Fast forward to 2025, things have significantly changed. AI can now catch bugs, suggest improvements, and help you write cleaner, safer, more maintainable code.

One tool that truly stands out is CodeRabbit, the AI code reviewer.

How to Use CodeRabbit

CodeRabbit's usage is dead simple. You open a PR. Wait a few seconds. Then you get a full code review with:

• ✅ A detailed PR summary

• ✅ Auto-generated sequence diagrams

• ✅ Smart comments: from nitpicks to security flags

• ✅ Clean code suggestions for best practices

Code Rabbit also explains why different issues matter, helping you grow as a developer while improving your code.

Here are 5 real examples of how CodeRabbit helped me apply clean code principles in action. And at the end of the article, I’ll share a few bonus features that made me a real fan of it.

Let’s dive in. 👇

Inconsistent Naming

Don't use different terms for the same concept.

• ❌ getUser

• ❌ fetchOrder

• ❌ retrieveProduct

It makes your code inconsistent, confusing yourself and your colleagues. Instead, use one word per concept in the entire codebase:

• ✅ getUser

• ✅ getOrder

• ✅ getProduct

CodeRabbit flags inconsistent code to keep your codebase cohesive:

SQL Injection Risks

SQL injection is one of the most dangerous and most common security flaws in modern applications. It happens when attackers trick your database into executing malicious code.

The fix: always use parameterized queries. But in big codebases, we can easily miss this. Thankfully, CodeRabbit scans for unsafe query patterns and flags potential issues:

Testing Too Many Things At Once

Don't test multiple things in one test. It's called the Eager Test. It's an anti-pattern.

The problem is, that when the test fails, it's hard to know the reason. To fix it, just split up your test into multiple test cases. The rule is simple: one single behavior per test.

CodeRabbit easily recognizes eager tests and proposes how to fix them:

Missing Edge Test Cases

Many developers write tests only for the happy paths. But the nastiest bugs lie in the edge and corner cases. CodeRabbit suggests where edge cases are missing and even recommends adding tests. Optionally, you can reply to CodeRabbit and instruct it to add the missing test.

It greatly helps to achieve high code and behavior coverage for your projects.

SRP Violation

The Single Responsibility Principle (SRP) says that every piece of code should have only one reason to change. When a class or function does too many things, any change in one part can break the others, making the code fragile and hard to work with.

The fix is to split your code so each part does one clear job and only changes for one clear reason. CodeRabbit spots these violations and explains the reasoning clearly:

Extra Features I love in CodeRabbit

Smart Summaries by CodeRabbit

One of the standout features of CodeRabbit is its pull request summary generation.

It quickly scans the diff and explains what changed in plain English. This is especially helpful when reviewing large PRs or catching up on a teammate’s work after a break. It’s like having a junior developer summarize the changes for you, instantly.

Auto-Generated Sequence Diagrams

CodeRabbit will also auto-generate sequence diagrams for you, helping you visualize how methods and components interact. This is great for onboarding new developers or documenting legacy systems without manually drawing diagrams. It turns abstract logic into a clear, structured visual.

As a bonus, it generates diagrams as 'Diagram as Code,' so you can easily version and persist them in your repository.

Chats and Learnings

One of CodeRabbit’s most powerful features is its ability to chat. You can teach it your organization’s code quality standards, and if you don’t like a suggestion, simply discuss it with CodeRabbit and ask for a better fix. Not ready to resolve an issue? Ask it to create a GitHub or Jira ticket for later. Over time, it becomes your coding assistant. Smart, helpful, and always in sync with your workflow.

20+ Dev Tools Integration

CodeRabbit seamlessly integrates with 20+ essential tools, from linters and formatters to advanced security scanners. It runs them automatically, then enhances the results with AI-powered reasoning for faster, smarter, and more thorough reviews.

It also picks up issues from tools like Codacy and Sonar and suggests inline fixes. Best of all, it cuts through the noise, surfacing only what truly needs your attention.

Privacy First

In the age of AI, data privacy isn’t optional, especially for enterprises. CodeRabbit treats it as a core value. Every pull request is reviewed in a secure, ephemeral sandbox environment, ensuring your code is never stored or retained in the cloud.

Augmented Code Reviews

If that’s not enough, you can even augment CodeRabbit’s code review capabilities using AST Grep rules, allowing you to define custom coding standards and catch common mistakes. Or if you are not that familiar with creating AST grep rules, you can simply choose from the many pre-written rules crafted by the CodeRabbit team.

Conclusion

CodeRabbit isn’t just another review bot. It actually helps you write better code, not by spitting out generic advice, but by pointing out real issues and explaining why they matter.

It’s helped me write cleaner, more consistent code, avoid security pitfalls like SQL injection, and improve my tests.

What I like most is that it brings clean code principles into day-to-day work. Using CodeRabbit leads to practical, helpful feedback that makes you a better developer.

Try CodeRabbit on your next PR. 14-days FREE trial. No card needed.

Try CodeRabbit for FREE

As someone who’s reviewed thousands of pull requests, I can confidently say that CodeRabbit gets it right.

It doesn’t just flag lint rules. It understands your code structure using AST, explains the “why” behind each suggestion, and summarizes complex changes clearly for both reviewers and authors.

Top 5 reasons why you should try CodeRabbit and use it every day:

• Context-aware reviews: It knows how your changes impact the full system, not just the diff.

• Security and performance insights: Detects issues like vulnerabilities and slow patterns (e.g. sequential DB calls).

• Custom team learning: Learns from your feedback and adapts reviews to your team's coding standards.

• PR summaries and diagrams: Generates clear explanations, changelogs, and sequence diagrams.

Open source friendly: Free forever for public repos. No catch. CodeRabbit Pro is free forever.

Try CodeRabbit on your next PR -> no card needed, no BS. Just better reviews.

Motivation

The software job market in 2025 is brutal. One job post can attract hundreds of applicants. Ghosting is the norm. And even highly skilled devs are struggling to land interviews.

I keep getting the same question from my readers:

“How can I stand out and actually get hired in tech today?”

So I put together this no-fluff guide to help you rise above the noise.

Here are 6 battle-tested strategies to increase your chances and become the dev companies want to hire.

Craft a Banger CV

Recruiters spend 5–7 seconds skimming your CV. That’s it. So forget writing your life story. Your CV should sell you in seconds.

Here’s what works:

• Keep it max 2 pages, clean and easy to read

• Tailor it to each job posting

• Start with a strong profile summary (show impact, not fluff)

• Prioritize recent and relevant experiences

• Skip skill bars or percentages, they're meaningless

• Highlight impact and results, not just tasks

• Mention only unusual hobbies (skip “reading” and “traveling”)

Pro tip: Treat your CV like a landing page. If it doesn’t hook them fast, it’s ignored.

LinkedIn = Your Digital Interview

Companies will Google you. Your LinkedIn is usually the first thing they’ll see. And guess what? A weak profile can kill your chances, even if your CV is amazing.

Here’s how to make your LinkedIn work for you:

• ✅ Use a clean, professional photo

• ✅ Add a compelling headline

  • F.e.: Senior React Dev | Built scalable UIs at X

• ✅ Write a short, punchy About section

• ✅ Feature top projects or articles

• ✅ Get endorsements and referrals

• ✅ Comment on posts, share your thoughts, be visible

And save the rants and memes for Facebook or X. LinkedIn is where hiring happens.

Build a Strong Online Presence

Would you hire someone who barely exists online? Neither would most companies.

Your online presence = proof of who you are.

• 🎯 A GitHub full of real projects

• 🎯 A blog or personal site

• 🎯 A few solid LinkedIn posts

• 🎯 Contributions to open-source

• 🎯 A short portfolio reel or case study

You don’t need to be famous. You just need to show up.

Your network is your net worth. Every comment, share, or connection could lead to a job offer.

Learn AI or Get Left Behind

AI isn’t hype anymore. It’s the new reality. The devs who know how to use AI tools will replace those who don’t. Period.

Here’s why doubling down on AI will boost your job chances:

• It 10x’s your productivity

• It shows you’re curious and adaptable

• It shows humility and you’re willing to learn new tools

Don’t just say you “know ChatGPT.” Show how you’ve used AI in real projects for:

• Speeding up debugging

• Improving test coverage

• Writing documentation faster

Learn Skills Most Devs Ignore

AI gives you code in seconds. But that doesn’t mean you’re job-ready. To stand out in 2025, sharpen these 2 underrated but essential skills:

Testing

• Understand the testing pyramid

• Write end-to-end tests that reflect user behavior

• Embrace regression testing and beta feedback loops

Great devs test. The best ones test like users.

Code Review

Code review is the new code writing. With AI spitting out code fast, reviewing well becomes a power skill.

Learn to:

• Spot bad patterns

• Ask the right questions

• Suggest clear improvements

• Catch AI hallucinations and silent bugs

By doing so you will beat all vibe-coders and AI ninjas.

Prepare Smart, Not Just Hard

Don’t waste months grinding LeetCode if you don’t even understand the company you’re applying to.

Study the company. Prepare like a pro:

• ✅ Learn their product

• ✅ Check their tech stack

• ✅ Read recent blog posts

• ✅ Prepare questions related to their work

While others bring textbook questions, you bring well-prepared curiosity.

Final Words

Getting hired in 2025 takes more than just skills. You need clarity, strategy, and presence. It’s not about being the best dev. It’s about showing you’re the right dev for the team.

If you want to sponsor this newsletter, apply here:

Apply for Sponsorship

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

Writing software is hard. But reading it shouldn’t be. Clean code isn’t just prettier. It’s easier to change, easier to test, and easier to trust.

When your classes are small, focused, and intention-revealing, your whole codebase becomes easier to work with. Clean classes lead to clean code.

Here are 6 quick principles I live by that help write clean classes:

Use Nouns for Naming

Classes represent things - or things that do things - so name them using nouns or noun phrases. Avoid using verbs for classes. This makes it easier for others to quickly understand the responsibilities of your classes.

Write code for humans to read, not just for machines to execute.

Avoid Getters and Setters

Getters and setters are evil. Period. Here’s 3 reasons why:

1. Violate the “Tell, Don’t Ask” principle: Don’t ask for the information you need to do the work. Ask the object that has the information to do the work for you.

2. Violate the “Encapsulation” principle: Objects should own their behavior and protect their own state.

3. Exposes implementation details: If we want to access one object from inside another, we're depending on how that object is built. If internals change, our code breaks and we have to fix it.

Hide internal state, and only expose what’s necessary. Keep fields private, and expose them via clear, intention-revealing methods.

❌ player.setHealth(100)

✅ player.increaseHealth(20)

The only exceptions are classes that are purely data-transfer objects (DTOs).

Expose a Single API

If your class isn’t coordinating others (i.e., it’s not a service or orchestrator), keep the API tight. A class should act like a tool: one entry point, one clear responsibility. It means one public method, and optionally many other private methods.

If you expose multiple public methods that do unrelated things, it's a strong signal that your class is doing too much. It’s time to split it into smaller, more focused classes.

Arrange Methods by Call Order

Nothing is worse than scrolling up and down in the code to understand the logic flow. Order class methods by how they’re called. This makes your code read like a story:

Small change, big difference.

Favor Composition Over Inheritance

Avoid using inheritance for code reuse. When we start learning programming, inheritance seems like a cool way to reuse functions and remove duplications.

But after a time, we realize it just leads to tight coupling and fragile code bases. Use composition instead. It will make the design more flexible.

Only use inheritance if there’s a clear is-a relationship between your domain objects.

Use Functions in JavaScript

JavaScript is a functional-first language at its core. It treats functions as first-class citizens. So try to stick with functions, instead of classes.

Functions are lightweight, composable, and easier to test. They don't carry hidden state or lifecycle baggage like classes often do.

For most use cases like data transformation, business logic, or even configuration, simple, pure functions are clearer and more maintainable.

Don’t Create Test for All Classes

Avoid creating a test class for each production class:

❌ XTest for XClass

❌ YTest for YClass

❌ ZTest for ZClass

It couples your tests to the implementation details. It makes them fragile. Fragile tests frequently break during refactoring. If your tests break during refactoring then they don't have much value.

Instead, you should test your internal classes via the public APIs. By doing so you end up with a robust test suite that aids refactoring.

Conclusion

Clean classes are the foundation of readable, maintainable software. They make your codebase a joy to work with, and easy to reason about.

To learn more Clean Code and testing best practices, check out my recently launched TDD course which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The most essential Clean Code tips

• The two schools of testing with the 5 types of mocks

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access

Are you ready to master Clean Code, Testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

“Legacy code is simply code without tests.” - Michael C. Feathers

Most legacy code isn’t bad code. It’s just untested. Untested code is scary. You can’t change it with confidence. You fear breaking things. It slows down development.

But there’s a way out of this trap. A proven strategy I’ve used in both startups and corporate environments to turn messy legacy code into clean, testable, and maintainable systems.

Here’s my 6-step approach to refactoring legacy code;

The Ultimate Refactoring Strategy

1. Break Dependencies

2. Characterization testing

3. Approval testing

4. Property-based testing

5. Functional testing to reach 100% coverage

6. Refactor the code

Step 1: Break Dependencies

Legacy code is hard to test. Your first goal isn’t to add tests everywhere.
Your first goal is to make your code testable. Dependencies are the #1 reason code is hard to test. External calls like APIs, databases, or message queues make testing hard.

The first step is to look for places in the code where you can change behavior without changing structure. Look at this code:

It has the FileReader dependency hardly coupled. Our goal is to break this dependency and use test doubles - mocks, stubs, fakes - with dependency injection:

Your goal should be to break all the dependencies in your legacy code, with two important notes:

• If the dependency is fast → use the real one, it leads to more realistic tests

• If the dependency is essential for testing business logic → use the real one, it leads to more meaningful tests

Step 2: Characterization Testing

Before refactoring, you need to understand legacy code. The goal of characterization testing is not about finding bugs. The goal is to understand behaviors.

Use characterization tests when:

• The code is too complex to reason about

• There is no documentation

• There are no existing tests

Let’s say you have this code snippet you don’t know anything about:

The best way to figure out is to write characterization tests around it.

Steps:

1. Write a test that calls the legacy code

2. Add an assertion you think should fail.

3. Execute test to observe behavior

   
   It will likely result in an error like:

Expected formattedText to be <null>, but found "plain text".

4. Update the test to capture the behavior

5. Repeat this cycle with new tests until you fully understand the code.
   
   By doing so you both learn about the business logic and document behaviours with automated tests.

Step 3: Approval testing

Writing assertions for complex objects is painful. Approval testing makes it easier. Instead of checking every field manually, you capture the full output once, then compare future runs against it.

How it works:

1. Generate output from your code

2. Approve it as correct (store it in a file)

3. On future runs → compare new output vs approved

Example of a normal unit test:

Problems with this test:

• Hard to maintain

• If data structure changes → 5 places to update.

• Tiresome to write assertions for large data structure

Here is the same test with an approval test:

Just one line. It asserts the whole data structure in a text format. On the first run, it generates a file like this:

• ExportToXml_Should_Work.received.txt

When you approve it manually, then it becomes:

• ExportToXml_Should_Work.approved.txt

Then in any future run, you just compare the new received vs approved. If there is a change, you probably broke some functionality.

This practice works perfectly for outputs like JSON, HTML, or text reports. You can find approval testing libraries in almost any programming language, check them out!

⚠️ A word of caution

Approval tests are temporary tools. They often lead to fragile tests. They slow you down in the long run. Once your code is clean, refactored, and covered by solid functional tests, delete most of them without regret.

Step 4: Property-based testing

This is my favorite type of testing. Why? Because bugs don’t hide in the happy paths. They hide in the edge and corner cases.

Property-based testing helps you generate a large number of test cases with random inputs, then verifies that certain behaviors always hold true no matter what.

It’s super handy because it captures the key behaviors of your app - the things that should never break when you refactor.

To learn more about property testing, I wrote a full article on this topic, click here to read more.

Step 5: Go for 100% coverage

Aim for ~100% code and behavior coverage. Why so strict? Because anything less leaves room for bugs when you refactor your code. You want maximum confidence. You want a test suite you fully trust. Sure, 100% coverage is almost impossible. But your goal should be to get as close to that as possible.

Use tools like:

• Code Coverage → shows what lines of code are uncovered

• Mutation Testing → shows what behaviors are untested (even if your code is covered)

Run these tools iteratively and keep adding functional tests until you maximize the coverage results. To learn more about Mutation Testing, check out my recent article about it.

Step 6: Refactor with Confidence

Now the fun part: With a solid test suite in place, you can confidently refactor your code.

Here are 6 tips you can use to refactor your code:

• Do aggressive refactoring at small scales

• Master the refactoring hotkeys of your IDE

• Turn comments into well-named components

• Follow the Rule of Three to remove duplications

• Don't mix refactoring with changing behavior

• Use TDD to make refactoring a core part of development

Conclusion

Refactoring legacy code isn’t hard. It just takes the right techniques and a bit of risk management to do it safely.

If you want to learn more about Mutation Testing and Test-Driven Development, check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The power of Mutation Testing

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access

Are you ready to master Clean Code, Testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

Most developers are bad at testing. Not because testing is hard, but because they keep making the same mistakes over and over again.

I’ve helped many teams and developers, and I’ve seen the same 6 mistakes pop up every single time.

The good news? If you avoid these, I guarantee you will be better than 90% of developers out there. Let’s get started!

❌ Mistake #1: Testing Too Late

✅ Do shift-left testing instead

Tests aren’t just for verification. They’re powerful tools for learning, understanding, and designing software. This is what shift-left testing is all about: moving testing earlier in the development process.

The earlier you test, the easier, faster, and cheaper it becomes to fix issues.
It leads to higher quality, faster feedback, and more confidence.

Remember: the earlier you test, the better everything gets.

❌ Mistake #2: Focusing on Code Coverage

✅ Use Mutation Testing instead

Code coverage is NOT a quality metric. You can have 100% coverage with terrible tests and zero assertions. Coverage helps detect untested areas of the code, but it doesn't tell anything about the tested areas. It gives you a false sense of security.

How can we measure the quality of our tests then?

The answer is: Mutation Testing. It is a technique that makes small changes to your code and then runs your tests. It is expected that at least one of your tests will fail. If not, it might indicate that your tests do not fully cover your code.

Code coverage won’t tell you how good your tests are. Mutation Testing will.

❌ Mistake #3: Testing Implementation Details

✅ Test behaviors via public APIs

I get this question a lot: How do you write tests for private functions?

Answer: You don't

They are implementation details. If you couple your tests to implementation details then they become fragile and break during refactoring. If your tests often break, they lose their value.

Don't couple your tests to code structure.

Couple them to the behaviors of the public APIs

❌ Mistake #4: Focusing Only on Clean Code

✅ Focus on Clean Tests as well

Most developers obsess over clean production code: naming, structure and SOLID principles.

But then they treat tests like second-class citizens:

• Cryptic method names

• Copy-pasted setups

• Insufficient assertions

The result? Tests become fragile, hard to read, and impossible to trust.

Clean code dies fast without clean tests. Your test suite should be your safety net, not a trap. Clean tests are simple, readable, and tell a story. They give you confidence to refactor, move fast, and stay in control.

If your tests feel like a burden, it's time to clean them up.

❌ Mistake #5: Doing Test-last

✅ Do test-first with TDD

Test-first beats test-last development every time:

• Test-first is fun - test-last feels like a chore

• Test-first helps you design code - test-last only verifies code

• Test-first puts your API under pressure - test-last just accepts it

• Test-first shows if a test is meaningful - test-last can lead to false positives

• Test-first helps ensure uniqueness - test-last often causes duplication

Test-Driven Development (TDD) is the ultimate form of test-first. It lets you design your code by writing automated tests that shape your software.

❌ Mistake #6: Testing Only Within Your Team

✅ Test together with your users

Developers tend to forget the most important testing type. It is not security, integration or performance testing.

It's beta testing:

• It's where your software meets reality

• It's where your customers interact with your product

• It's where you get real-time feedback

It's not about finding bugs. It's about learning the domain and shaping the software with the customer together.

Clean code helps you build the software right.

Beta testing helps you build the right software.

Do it every week.

Conclusion

The best way to build confidence in your code is to test it well. If you want to master testing, Test-Driven Development and Mutation Testing check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The power of Mutation Testing

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access

Are you ready to master Clean Code, Testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

AI changes the game. It spits out code in seconds. But that makes your ability to review code more important than ever.

Our focus often shifts from writing code to reviewing it. Reviewing code efficiently is the new superpower in the era of AI.

In this article, I will share 5 tips on how I review code in my team:

Drop the Ego, Comment with Kindness

The first rule of code reviews is to be kind. Always critique the code itself, never the coder. Be clear about your feedback on the code quality, but gentle and supportive toward the individual.

Encouragement is also powerful, so always leave at least one positive comment to boost morale and foster a culture of continuous improvement.

Focus on The Meat

When I start reviewing a PR, I immediately look for the most important part of the change. For example, what's the new API endpoint or the core piece of business logic.

Ask yourself: "Why is this change needed?" When you know the WHY, reviewing becomes easy. Never review code in isolation. Always think bigger: Is it easy for users? Is it secure? Will it perform well under load?

This simple shift in thinking will level up your reviews instantly.

Nitpick Like a PRO

Most developers hate nitpicks in code reviews. But when done right, they are excellent tools to improve quality. Here are 5 tips on how I nitpick in my team:

• Prefix your comment with "Nit:"

• Use it for small improvements like namings or typos

• Suggest, never command

• Offer examples to clarify your point

• Approve the PR if you have only nitpicks - don't block

Now compare these two examples:

❌ Change that function name, it's bad

✅ Nit: I would rename that function to express business knowledge. For example: findAvailableFlights

Small change, big difference.

Find Missing Tests with Mutation Testing

My favorite part of reviewing my colleagues' code is running mutation tests on their PRs. I quickly clone their PR branch and do the testing locally. My goal is to find missing tests—and I always do. That's the power of Mutation Testing.

Mutation Testing will tell you how good your tests are. It reveals exactly where you're missing tests or assertions.

This single habit has greatly improved our team's confidence in delivering reliable software.

Do Real-Time Review With Pair Programming

Real-time feedback always beats delayed code reviews. Pair and Mob programming let your team spot mistakes immediately. You don't need to wait for slow PR reviews. This saves your team lots of time and prevents costly bugs.

Plus, coding together helps everyone learn faster. Junior developers level up quickly, and seniors become better mentors. It's teamwork at its best—more collaboration, fewer bottlenecks, and a happier, stronger team overall.

Conclusion

In the age of AI, code reviews matter more than ever. AI can generate code and tests, but it's still your responsibility to ensure correctness through strong reviews and Mutation Testing.

If you want to learn Mutation Testing and Test-Driven Development, check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The power of Mutation Testing

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

You are not paid to write code. You are paid to solve problems. Half of the solution is understanding the problem. When it comes to producing quality software, you need to focus on two things:

• doing the right thing

• doing the thing right

In this particular order.

Our code should reflect the business problem it solves. When it uses clear names, a clean structure, and focuses on the domain, it’s easier to discuss, maintain, and improve it.

In this article, I’ll share 3 tips on naming, structure, and testing to help you focus on WHAT the code does—not HOW it does it.

Avoid Names With Technical Jargon

Avoid using names with technical jargon. DTOs, flags, and records are all related to specific solutions on the computer.

Instead, use names that speak about the problem. If a name contains technical terms, it is probably focusing on HOW.

Clean code focuses on WHAT.

Use Screaming Architecture

If you look at your application and you only see folders like these:

Then your app doesn't tell anything about the problem it solves. It's driven by technology instead of the domain. If you want to add a new feature, you need to add files to all these places. Features are mixed, leading to maintenance hell.

Now look at this folder structure:

It is called screaming architecture. It is easy to navigate, with clear domain separations. If you want to add a new feature, you just add a new main directory. It has better discoverability and results in a low entry curve for new developers.

A clean folder structure is like a well-organized room; everything has its place, and it's easy to find what you need. Your folder structure should communicate the domain, not the technology.

Write Behaviour-Driven Tests

Many developers get this wrong about Unit Tests:

• ❌ A class is not a unit

• ❌ A function is not a unit

• ❌ A module is not a unit

The "unit" does not refer to code structure. It refers to a single, observable business behavior.

The strength of the Chicago School of Test-Driven Development lies in prioritizing behavior over isolated components. It focuses on the WHAT, not the HOW. It leads to robust tests that support refactoring.

Don't write tests when you create a new class. Write tests when your system has a new behavior.

Conclusion

Clean code is not focused on implementation details. It is focused on solving the domain with clean naming, expressive folder structure and behavior-driven tests.

To learn how to write clean code and behavior-driven tests with the Chicago School of TDD, check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The two schools of testing with the 5 types of mocks

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

Mistakes are the best teachers. There is nothing better than the lessons you gain from failures. Each failure brings disappointment—but it also leads to invaluable growth.

If I could, I wouldn't trade any of my failures—because they've made me a better developer. In this post, I’ll share my five biggest mistakes and how you can avoid them.

Burning Out

I used to work 60-70 hours per week for two years until I burned out. It took me another two years to recover. Never again. When you experience burnout, you lose motivation for work, creativity, and even things you once enjoyed.

Here are 5 things I do to prevent burnout:

• ✅ Ditch alcohol

• ✅ Learn to say No

• ✅ Sport 5 times per week

• ✅ 7-8 hours of sleep at night

• ✅ Mandatory rest day on Sundays

Don't forget that your health is your most important asset. A healthy person wants 1000 things. An unhealthy person wants only one thing: to be healthy.

Ignoring Test-Driven Development

Test-Driven Development (TDD) didn’t click for me from day one. At first, I saw it as a useful but non-essential practice. In retrospect, that was a mistake—I should have adopted it from the very beginning.

Now, I can’t live without TDD. It makes me a better developer in every sense. It’s the gold standard way for writing code, incorporating best practices like clean code, continuous refactoring, and confident shipping.

I don’t always write code. But when I do, I use TDD.

Avoiding Networking

In the digital age, your network is your net worth. Success is not a solo journey—it’s a team effort. Early in my career, I didn’t prioritize networking, and looking back, that was a mistake.

Opportunities don’t just come to you—you create them through networking. Many of my job offers, conference appearances, and friendships are thanks to the network I built.

Don’t forget: A handshake can open more doors than a resume ever will.

Chasing The Latest Tech

Early in my career, I was emotionally attached to my code. But I’ve since realized that code is a liability, not an asset—the only bug-free code is the one that doesn’t exist.

Frameworks and languages are just tools. True expertise comes from timeless, language-agnostic practices like:

• Extreme Programming

• Continuous Delivery

• Test-Driven Development and Test-first mindset

• Pair and Mob programming

• Clean and Pragmatic Architecture

Master these, and you’ll gain far more than by chasing the latest shiny tech.

Over-engineering

Over-engineering kills momentum. Engineers love complex solutions, but complexity isn’t a badge of honor—it’s a liability.

• If a simple function would work, don’t overcomplicate it with a Lambda or Azure Function just because you can

• If WordPress is enough for a simple static site, don’t build it with React or Angular

Future-proofing is valuable, but trying to predict every scaling issue and edge case upfront is a waste of time. Build what’s needed today, iterate when necessary, and keep shipping fast.

Conclusion

Mistakes are inevitable—but they shape us into better developers. You can build a long-lasting engineering career with a healthy lifestyle, language-agnostic skills, and Extreme Programming practices like TDD.

If you want to master TDD, check out my newly launched, complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The two schools of testing with the five types of mocks

• How to use TDD to design high-quality software

• How to test legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

Booleans are one of the simplest constructs in programming, yet it can often make code more complex and less straightforward. Booleans have only two possible values (true or false), yet I often see them poorly named and misused in many codebases.

In today’s article, I’ve gathered 4 naming and 2 usage tips relating to booleans. By applying these principles, you can avoid common pitfalls and Craft Better Software.

1️⃣ Avoid Negative Names

Negative boolean variables lead to double negatives, making your code harder to read and understand.

❌ if (!isNotActive)

✅ if (isActive)

The same happens in natural language: you use only one negative, because a double negative is just an affirmative sentence. Why would it be different with code?

You should write code that reads like natural language.

2️⃣ Use Adjectives

Don't use verbs or nouns in your boolean variable names. Booleans represent states, so they should be named with adjectives or short descriptive phrases instead.

❌ if (sendEvent)

✅ if (eventIsSent)

3️⃣ Use Present Tense

Boolean variables should describe the current state rather than past states. Using past or perfect tenses adds noise, making boolean variables wordy and less concise.

❌ if (hasBeenPaid)

✅ if (isPaid)

4️⃣ Use Is/Has/Should/Can Prefixes

One of my favorite tricks when naming booleans is to use prefixes. Consider using the following:

• is – for states (e.g., isActive)

• has – for ownership (e.g., hasSubscription)

• should – for expected behavior (e.g., shouldRetry)

• can – for capabilities (e.g., canEdit)

5️⃣ Avoid Boolean As Parameters

Using boolean flags in function parameters can be confusing and difficult to review. Instead, use enums to make your code self-documenting.

❌ Bad Examples:

bookFlight(customer, true);
bookFlight(customer, false);

✅ Good Examples:

bookFlight(customer, Discount.Applied);
bookFlight(customer, Discount.NotApplied);

Enums also help make your code open for changes. By extending the enum type with a new value, you can easily add new functionality without breaking the API.

6️⃣ Reduce Nesting With a Return Early

Using many IF-ELSE statements with booleans can easily lead to unreadable code. Avoid using nested IF statements.

Instead, invert the conditions and use guard clauses. It will make your code easier to follow. As a bonus, you will get rid of the ELSE statements:

Conclusion

Booleans are one of the most frequently used variable types. And if they are used right, they can greatly improve code quality.

To improve code quality further, Test-Driven Development is my favorite tool. If you want to master TDD, check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The two schools of testing with the 5 types of mocks

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get Instant Access

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Class is NOT a Unit

Many people believe that a "unit" in unit tests means a single function or class. That’s a dangerous myth.

When we define units based on code structure, we create fragile tests that break during refactoring. When our tests break during refactoring, they don’t have much value.

This mindset comes from the London School of TDD, which isolates classes with heavy mocking, often at the cost of test stability.

The Problems with Small Units

One of the biggest pitfalls in unit testing is thinking smaller is always better. But you end up with:

• 🚨 Excessive test doubles – Mocking everything leads to brittle tests

• 🚨 Tests per class – If your test structure mirrors your code, class changes can often break your tests, even when behavior stays the same

• 🚨 Encapsulation violations – Testing private methods ties tests to implementation details, again leading to fragile tests.

So What is a UNIT?

A unit isn’t a class or function—it’s a single, observable business behavior exposed through public APIs. This approach comes from the Chicago School of TDD, which prioritizes testing behavior over isolated components.

Here are 3 tips on how I write quality unit tests:

• ✅ Focus on how the system behaves from the outside, not how it is implemented internally.

• ✅ Target public entry points and write tests at the highest level possible

• ✅ Keep your tests fast by using mocks and fakes at the edge of your system

Public APIs

A public API is the set of methods, functions, or interfaces that other parts of the system or external users use to interact with the system.

For example, in a Web API, the HTTP methods serve as the public interface. I write my unit tests against this public API, while mocking only slow external dependencies.

By doing so, it doesn’t matter how I implement my Web API or whether I use CQRS, DDD patterns, or anything else—these are irrelevant to the tests, and that’s exactly the goal.

Frameworks Don’t Define Unit Tests

Frameworks and dependencies don’t define unit tests. There are many misconceptions like:

• ❌ A Cucumber test is not a unit test

• ❌ A JUnit or NUnit test is always a unit test

• ❌ A test uses external dependencies is not a unit test

They are all incorrect.

• ⚠️ If you're using JUnit but your tests are slow, they’re not unit tests.

• ⚠️ If you're using Cucumber and your tests are fast, they might be unit tests.

• ⚠️ If your app has a stable dependency where you can write fast tests for, they can still be unit tests.

The framework doesn’t matter—only the test’s speed, scope, and isolation do.

Conclusion

Unit testing is about verifying behavior, not code structure. Behavior-driven tests lead to a robust test suite that supports refactoring.

To learn more about writing high-level tests with the Chicago School of TDD, check out my recently launched complete TDD course, which includes:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• The two schools of testing with the 5 types of mocks

• Using TDD to design high-quality software

• Testing legacy code

• Refactoring best practices

Get Instant Access

Are you ready to master clean code, testing and Test-Driven Development (TDD)?

I recently launched a complete TDD course containing everything you need to craft high-quality software.

Now there is a 50% OFF for the course

Get instant access by clicking here.

Get Instant Access

Motivation

Git has been the backbone of modern software development since 2005, empowering teams to collaborate, track changes, and manage code efficiently.

But here’s the truth: A messy commit history makes troubleshooting hard.

Commit messages are your best tool for documenting the reason for change in your code. Writing them well saves time, avoids confusion, and keeps your codebase clean. Here are five tips on how I write commits in my team:

1. Explain the WHY

In a Git commit message, you should specify not only what you have done, but also WHY you have done that. It will make it easier to track changes over time and fix issues.

2. Use the imperative mood

The imperative mood means writing commit messages as if giving a command or instruction. This keeps your commit history clean and consistent:

3. Use present tense

Present tense is the right choice because commits represent changes that are always applicable—they can be checked out, merged, reverted, or cherry-picked at any time.

A properly written Git commit message should complete this sentence:

4. Add link reference to task

If you use project management tools such as Jira, GitLab, or Azure DevOps, consider including the reference ID in your commit message. This links the commit directly to the relevant task, making it easier for your team to understand the broader context of the update.

5. Summarize the WHAT, not the HOW

A commit message should clearly explain WHAT the change does, rather than describing HOW it does it. The how is already visible in the code diff, but the why and what provide essential context.

The same goes for file names—you don’t need to include them in the commit message since Git already records them in its history.

Conclusion

Clear and structured commit messages are a part of internal software quality. Another powerful way to improve software quality is to apply Test-Driven Development (TDD). It helps you write high-quality code, better and faster.

To master TDD, I recently launched my complete course, including:

• The fundamentals of Test-Driven Development

• Three real-world TDD examples in C#, TypeScript and Rust

• Using TDD to design high-quality software

• The two schools of testing with the 5 test doubles

• Testing legacy code

• Refactoring best practices

Get instant access by clicking here.

Get Instant Access