DEV Community: max

The Debugging Checklist I Run Before Asking Anyone for Help

max — Mon, 02 Feb 2026 08:56:59 +0000

Last Tuesday I spent 40 minutes convinced my API was broken. Requests were timing out, the logs looked fine, and I was drafting a message to a friend who knows the codebase when I realized the bug was in my .env file. I had a trailing space after a database URL. A trailing space.

Forty minutes. For a space character.

I should have caught it in under five. I have a process for this. I just skipped it because I was tired and figured this one would be obvious. It was not obvious. They never are when you skip the process.

So here is the actual checklist I run through before I message a coworker, open a Stack Overflow tab, or do anything that involves another human looking at my dumb mistake. This is not theory. This is the stuff that lives in my hands at this point.

Step 1: Confirm the Bug Exists Where You Think It Does

Most debugging advice is useless because it assumes you already know where the bug is. That is a massive assumption. Half the time, the bug is not even in the file you are staring at.

Before doing anything else, prove to yourself that the system is actually broken in the way you think it is. Not "it feels broken" or "the output looks wrong." Run a request manually. Check the actual response body. Look at the actual database row. Hit the actual endpoint with curl.

I cannot tell you how many times I have been debugging the wrong thing entirely. The frontend is showing stale cached data and the API is fine. The test is failing because the test setup is wrong, not because the code is wrong. The deploy did not actually go out yet.

Stop assuming. Verify.

Step 2: Check What Changed

This is the highest-value question in all of debugging and most people skip it.

Was this working before? When did it stop? What changed between then and now?

git log --oneline -20
git diff HEAD~5

Look at your recent commits. Check if someone else merged something. Look at your environment variables, your config files, your dependencies. Did a package update? Did someone change a shared resource? Did your database get migrated?

If you can narrow it down to "it broke after this specific change," you have just eliminated 95% of the codebase from your investigation. That is not a small thing.

Step 3: Read the Actual Error Message

I know this sounds condescending. I promise it is not.

I have watched developers, including myself, glance at an error message, get the gist of it, and then go off debugging based on their interpretation of what the error probably means. Then they spend an hour chasing the wrong thing because the error message was quite specific and they just did not read the whole thing.

Read it. The whole thing. Including the stack trace. Including the part after the first line. Including the "caused by" section at the bottom that everyone scrolls past.

If there is a line number, go to that line. If there is a file path, open that file. If there is an error code, look up that specific code. Not the category. The specific code.

Step 4: Reproduce It Reliably

If you cannot make the bug happen on command, you are not ready to debug it. You are guessing.

Strip away everything you can. If the bug happens in a web app, can you trigger it from a unit test? From a curl command? From a REPL? The fewer moving parts between you and the bug, the faster you will find it.

Here is the thing though. If you cannot reproduce it, that IS the clue. Intermittent bugs are almost always one of three things: race conditions, state leaking between tests, or something environment-specific. That narrows your search enormously.

Step 5: Add Logging at the Boundaries

Not everywhere. At the boundaries.

Log what goes into the function and what comes out. Log what the database query returns. Log what the external API sends back. You are trying to find the exact point where the data goes from correct to incorrect.

print(f"INPUT:  {user_id}, {payload}")
result = do_the_thing(user_id, payload)
print(f"OUTPUT: {result}")

Yeah, print debugging. I know. I have a debugger. I know how to use breakpoints. But nine times out of ten, a few strategic print statements find the bug faster than stepping through code because they let me see the data flow across multiple function calls at once instead of one frame at a time.

I am not saying debuggers are bad. I am saying the fastest path to the bug is usually the one with the least setup.

Step 6: Question Your Assumptions

This is the hard one.

By the time you have been staring at a bug for 20 minutes, you have built a mental model of what is happening. That mental model is probably wrong in at least one way, and that wrong assumption is probably why you have not found the bug yet.

Force yourself to question the things you "know":

Are you sure this code is actually being executed? Add a log and check.
Are you sure that variable contains what you think it does? Print it.
Are you sure the database has the data you expect? Query it directly.
Are you sure you are hitting the right server? Check the URL. Check it again.
Are you sure the config file you are editing is the one the app is reading?

That last one has bitten me at least four times. Editing a .env file in one directory while the process is reading from a completely different one.

Step 7: Isolate With Binary Search

If you have a big chunk of code and you know the bug is in there somewhere, do not read every line hoping to spot it. That works sometimes. It is slow every time.

Comment out half the code. Does the bug still happen? If yes, it is in the other half. If no, it is in the half you commented out. Repeat.

This works for more than just code. It works for config files, for SQL queries, for CSS stylesheets, for request payloads. Anything where you have a blob of stuff and the problem is somewhere inside it.

Step 8: Search for the Exact Error

I do this later in the process than most people recommend, and here is why: if you Google the error message before understanding your own code, you will find a Stack Overflow answer that looks relevant, apply the fix blindly, and either introduce a new bug or mask the original one.

But once you have done steps 1 through 7 and you actually understand the shape of the problem? Then searching is incredibly effective because you can evaluate whether a solution actually applies to your situation.

Put the error in quotes. Include the specific library or framework version. Filter to results from the last year or two. Old answers for old versions will ruin your afternoon.

Step 9: Rubber Duck It (Seriously)

I used to think this was silly advice from people who had never debugged anything serious. I was wrong.

The act of explaining the problem out loud, or writing it out as if you are going to post it somewhere, forces you to organize your understanding. And the gaps in your understanding become obvious when you try to articulate them.

I write the Stack Overflow question. Title, description, what I have tried, what I expected, what actually happened. I would estimate 30% of the time, I find the answer while writing the question. The other 70%, I at least have a well-structured question ready to post.

Step 10: Let a Second Brain Look at It

I was pretty skeptical about AI coding tools for a while. Thought it was all hype. Then sometime in mid-2024 I pasted a module into Claude on a whim, mostly to prove to a friend it would not find anything useful. It caught a race condition I had been missing for weeks. A subtle one too, where two async handlers were writing to the same object and the outcome depended on which one resolved first. I had been staring at that code for days.

Now this is a regular step in my process. Not the first step. Not a replacement for actually understanding the problem. But once I have done the work above and I am genuinely stuck, I will paste in the relevant code with a specific description of what is going wrong. Not "review this code" but "this function returns the wrong total when called with concurrent requests and I suspect it is a state mutation issue, here is my evidence."

The key word there is specific. Vague questions get vague answers, from humans and AI alike.

The Whole List, Condensed

Confirm the bug is real and is where you think it is
Check what changed recently
Read the complete error message
Reproduce it reliably
Log at the boundaries
Question your assumptions
Binary search to isolate
Search with context
Rubber duck it
Let a second brain look

I do not always do all ten. Sometimes step 2 solves it instantly. Sometimes I jump straight to step 5 because I have a hunch. The point is not rigid adherence. The point is that when I am stuck, I have a concrete next action instead of staring at the screen hoping for insight.

The developers I respect most are not the ones who never get stuck. They are the ones who get unstuck fast. And they get unstuck fast because they have a process, not because they are smarter.

I ended up documenting a lot of my debugging prompts and workflow patterns for AI-assisted development in a Claude Code Prompt Pack I put together for myself. It includes the exact prompt structures I use for bug hunting, code review, and the kind of targeted analysis that actually surfaces real issues. Figured I might as well share it since I was already maintaining it anyway.

What I Wish Someone Told Me Before I Went Freelance

max — Sun, 01 Feb 2026 09:02:04 +0000

I was sitting on the floor of my apartment in April of my first year freelancing, staring at TurboTax telling me I owed the IRS $14,000 I did not have. Not "I'd prefer not to spend this" money. I literally did not have it. I had been freelancing for about nine months at that point, cashing checks and spending like I was still getting a W-2 with taxes already pulled out.

That moment rewired my entire understanding of what it means to work for yourself.

The Money Is Not What You Think It Is

My first freelance client paid me $40/hr for a React app. I remember texting a friend about it like I had won something. Forty bucks an hour. That is over 80 grand a year if I bill full-time. I was making about $95k at my salaried job, but $40/hr felt different. It felt like more.

It was not more.

Self-employment tax alone eats about 15% off the top before you even get to income tax. Then there is health insurance, which went from "something my employer handles" to "$480/month for a plan with a deductible so high it barely qualifies as insurance." No 401k match. No paid vacation. No sick days. When I finally did the real math, I was making less per hour than my salaried job.

Nobody told me to do that math before I quit.

You Will Get Screwed on an Invoice

This is not a maybe. This is a when.

I did some work for a small agency early on. Good communication during the project. Friendly people. Delivered everything on time. Sent a $6,800 invoice and then just... nothing. For four months. Emails got vague. "We're processing it." "Accounting is backed up." "Let me check on that."

I had no contract. No late fees clause. No kill fee. Nothing.

I got the money eventually. Took a borderline-aggressive email and some very uncomfortable phone calls. But that experience taught me something that all the freelancing advice blogs skip over: the absence of a contract does not just mean you lack legal protection. It means the client does not take the engagement seriously. A contract is not a legal document. It is a psychological one. It tells the client "this person runs a real business" instead of "this person will probably let it slide."

Get a contract. Put late fees in it. Put a kill fee in it. Put a clause that says work stops if payment is 15 days late. I do not care if it feels awkward. Being broke for four months because you were too polite feels worse.

The Freedom Thing Is Real but Weird

Yeah, you can work from anywhere. You can take a Tuesday off. You can work at 2am if that is when your brain decides to cooperate.

But nobody warns you about the guilt.

Every hour you are not working, you are not billing. Every afternoon you spend at the park with your dog, some part of your brain is calculating how much money you just did not make. Salaried workers do not have this problem. They get paid whether they stare at their screen productively or spend 45 minutes in a meeting that should have been a Slack message. Freelancers internalize every unbilled hour as a personal failing.

It took me almost two years to stop feeling guilty about not working on a Saturday. Two years. And I still catch myself doing the math sometimes.

Nobody Prepares You for the Admin Work

I became a freelance developer because I wanted to write code. What I actually spend my time on:

Writing code: maybe 60%
Chasing invoices, doing bookkeeping, tracking expenses: 15%
Writing proposals, scoping projects, handling client communication: 15%
Figuring out taxes, quarterly estimates, insurance, retirement accounts: 10%

That last 40% is the job nobody tells you about. And if you are bad at it, the 60% does not matter because you will either go broke or burn out managing chaos.

After the $14k tax situation, I built myself a spreadsheet system to track income, set aside tax money automatically, and flag when quarterly payments were due. My accountant actually complimented it, which might be the saddest professional achievement of my life. But it kept me from ever being surprised by a tax bill again.

Most Freelancing Advice Is Terrible

I need to say this because it drove me nuts when I was starting out.

The internet is full of freelancing content that boils down to "charge what you're worth" and "just raise your rates." As if the problem is that freelancers have not considered making more money. Thanks. Revolutionary stuff.

Here is what actually matters and nobody wants to talk about: the first year sucks. You will underprice yourself. You will take bad clients because you need the money. You will say yes to projects you should say no to. You will work weekends not because you are passionate but because you quoted 40 hours and the project is going to take 70.

That is normal. It is not a failure of mindset or hustle or whatever other nonsense the LinkedIn crowd is selling. It is the learning curve of running a business when nobody taught you how to run a business.

The Part Where I Tell You to Do It Anyway

Four years in, I bill at roughly three times what that first client paid me. I pick my clients. I take time off without asking permission. Last month I worked four-day weeks the entire month and nobody noticed or cared.

But I want to be honest: the first 18 months were genuinely hard. Not "character building" hard in the way people romanticize. Hard in the "I might need to go get a real job again" way. The tax disaster. The unpaid invoice. A month where I had zero clients and zero income and started refreshing LinkedIn job listings out of panic.

Would I do it again? Every time. But I would do it differently. I would start with a contract template, a real accounting system, and six months of savings instead of three. I would charge more from day one even if it meant fewer clients. I would set aside 30% of every payment for taxes before I touched a cent of it.

Most importantly, I would stop reading advice from people who have been freelancing for six months and already have a course about it.

I put together a Freelance Developer Business Kit a while back. It started as the spreadsheet system I built after the IRS situation and grew into contract templates, rate calculators, and the quarterly tax workflow I actually use. I go back and forth on whether to even mention it in posts like this, but it would have saved me a lot of pain in year one and I figure someone reading this is about to make the same mistakes I did.

14 Linux Command-Line Tricks That Made Me Mass-Delete My Bash Aliases

max — Fri, 30 Jan 2026 21:59:55 +0000

I have been using the terminal daily for over a decade. I thought I knew my way around. Then a coworker shared a one-liner that did in 3 seconds what my janky shell script did in 40 lines. I mass-deleted half my aliases that week.

Here are the tricks that did it. Some of these are genuinely obscure. Others are hiding in plain sight in tools you already use every day.

1. Process Substitution (The One That Changes Everything)

You probably know pipes. You might know redirects. But process substitution is the thing most developers never learn, and it is absurdly powerful.

diff <(sort file1.txt) <(sort file2.txt)

The <(...) syntax runs a command and presents its output as if it were a file. This means you can use it anywhere a filename is expected. Want to diff two remote files without downloading them first?

diff <(curl -s https://api.example.com/v1/config) <(curl -s https://api.example.com/v2/config)

Or compare two branches of a JSON config:

diff <(git show main:config.json | jq -S .) <(git show dev:config.json | jq -S .)

Once you internalize this, you stop creating temp files forever.

2. xargs -P: Instant Parallelism

Most people know xargs. Almost nobody uses the -P flag.

find . -name '*.png' | xargs -P 8 -I {} optipng {}

That -P 8 runs 8 processes in parallel. Compressing 200 images? This turns a 10-minute job into a 1-minute job. It works with anything:

cat urls.txt | xargs -P 10 -I {} curl -sO {}

Ten parallel downloads, no scripting, no background jobs to manage.

3. The Curly Brace Expansion Nobody Uses Fully

You have probably done mkdir -p src/{components,utils,hooks}. But brace expansion goes deeper than most realize.

Rename a file without typing the path twice:

mv /long/annoying/path/config.json{,.bak}

That expands to mv /long/annoying/path/config.json /long/annoying/path/config.json.bak.

Sequence expressions:

echo {01..12}       # 01 02 03 04 05 06 07 08 09 10 11 12
echo {a..z..3}      # a d g j m p s v y
mkdir day-{01..31}  # 31 directories in one shot

Nested expansion for combinatorial generation:

echo {api,web}-{dev,staging,prod}
# api-dev api-staging api-prod web-dev web-staging web-prod

4. Column Selection With cut and awk That Actually Makes Sense

Stop writing janky loops to parse columnar output.

# Get just PIDs of processes matching 'node'
ps aux | awk '/node/ {print $2}'

# Grab the 3rd field from a CSV
cut -d',' -f3 data.csv

# Get last field regardless of how many fields exist
awk '{print $NF}' file.txt

The $NF trick is the one that saves you the most time. NF means "number of fields" so $NF is always the last column. No more counting fields.

5. The `!!` and `!$` History Shortcuts

You forgot sudo:

apt install something
# Permission denied
sudo !!

!! repeats the entire last command. But !$ is even more useful -- it grabs the last argument of the previous command:

mkdir -p /some/deeply/nested/new/directory
cd !$

No retyping, no reaching for the mouse to copy-paste a path.

6. The `column` Command: Instant Pretty Tables

You have data that looks like garbage:

echo -e "name,age,city\nalice,30,nyc\nbob,25,sf" | column -t -s','

Output:

name   age  city
alice  30   nyc
bob    25   sf

Pipe any CSV, TSV, or delimited output through column -t and it becomes readable. I use this daily for quick data inspection.

7. `comm`: The Set Operations Tool You Never Knew Existed

Want lines that are only in file A, only in file B, or in both? comm does set operations on sorted files.

comm -23 <(sort file1.txt) <(sort file2.txt)   # Only in file1
comm -13 <(sort file1.txt) <(sort file2.txt)   # Only in file2
comm -12 <(sort file1.txt) <(sort file2.txt)   # In both files

Notice the process substitution from trick #1. These compose beautifully together. The flags suppress columns: -2 suppresses "only in file2", -3 suppresses "in both". So -23 gives you "only in file1."

This is how I diff environment variable lists between servers, compare package versions, and find missing translations.

8. `tar` Can Stream Over SSH

Forget scp for directories. This is faster and does not require disk space on either side for intermediary files:

tar czf - /local/directory | ssh user@remote 'tar xzf - -C /remote/path'

The - means stdin/stdout. You are creating a tar stream, piping it over SSH, and extracting on the other side in real time. No temp files, no zipping then transferring then unzipping.

9. `tee` For When You Need Both

Want to see output AND save it to a file?

long-running-build 2>&1 | tee build.log

But the real power move is using tee mid-pipeline to debug what is flowing through:

cat access.log | tee /dev/stderr | grep 'ERROR' | wc -l

This prints the full stream to stderr (so you see it) while the pipeline continues to count errors. Invaluable when a pipeline is giving unexpected results and you need to see the intermediate data.

10. `grep -c` and `sort | uniq -c | sort -rn`: The Analysis Pipeline

This three-command pipeline is the most underrated data analysis tool on any system:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

This gives you the top 20 most frequent values in column 1. Change the awk field number and you can instantly answer questions like:

What IPs hit us most? ($1)
What endpoints are hottest? ($7)
What status codes dominate? ($9)

You can answer questions that would take an Elasticsearch query or a Python script in under 5 seconds with this pattern.

11. `watch`: Auto-Refresh Any Command

watch -n 2 'kubectl get pods | grep -v Running'

This re-runs the command every 2 seconds and shows you the output. Add -d to highlight what changed between refreshes. I use this constantly for monitoring deployments, watching disk space during big operations, and tracking build progress.

12. Redirect stderr and stdout Independently

Most devs know 2>&1. Fewer know you can send them to completely different places:

command > output.log 2> errors.log

Or discard errors while keeping output:

find / -name 'config.yml' 2>/dev/null

Or swap them entirely (stdout becomes stderr and vice versa):

command 3>&1 1>&2 2>&3

That last one uses file descriptor 3 as a temp swap variable. It is the kind of thing that looks unhinged until you need it, and then you really need it.

13. `rsync --dry-run`: Preview Before You Wreck

rsync -avhn source/ destination/

The -n flag is --dry-run. It shows you exactly what rsync would do without doing it. I run this before every significant file sync. The one time it saves you from overwriting production assets pays for the habit permanently.

14. Trap: Clean Up After Yourself

tmpfile=$(mktemp)
trap 'rm -f "$tmpfile"' EXIT

# Use $tmpfile however you want
# It gets cleaned up automatically when the script exits

The trap builtin runs a command when the shell receives a signal. EXIT fires when the script ends for any reason -- normal exit, error, even Ctrl+C. No more orphaned temp files cluttering /tmp.

The Pattern

Notice that none of these tricks require installing anything. They are all built into standard Linux distributions and have been for decades. The command line is not a relic. It is a composable toolkit where every piece connects to every other piece through text streams.

The developers who move fastest in the terminal are not typing faster. They are combining these primitives in ways that eliminate entire categories of manual work.

I keep a set of cheatsheets pinned next to my monitor for exactly these kinds of tricks -- organized by tool, with flags, examples, and real-world patterns I actually use. I put together a CLI Cheatsheet Bundle that covers the commands, pipelines, and workflows that took me years to collect. If you want to shortcut the process of building this muscle memory, it is all there.

Stop Getting Useless AI Code Reviews (Here's How to Actually Catch Bugs)

max — Fri, 30 Jan 2026 21:59:49 +0000

You paste your code into Claude or ChatGPT. You type "review this code." You get back a polite essay about how your variable names could be more descriptive and maybe you should add some comments.

Congratulations, you just wasted 45 seconds getting feedback your linter already gives you for free.

The dirty secret of AI-assisted code review is that most developers are asking the wrong questions. They treat the AI like a junior dev doing a drive-by review instead of what it actually is: an infinitely patient analyzer that can check your code against hundreds of failure modes simultaneously -- if you tell it to.

Let me show you how to get reviews that actually find bugs.

The Problem: Generic Prompts, Generic Reviews

Here is a prompt I see developers use constantly:

Review this code and let me know if you see any issues.

And here is what you get back: a surface-level scan that mentions code style, suggests renaming a variable from x to something_more_descriptive, and tells you to add error handling "where appropriate." None of that prevents a 3am production incident.

The AI is not being lazy. It is responding to the scope you gave it, which is "everything and nothing." When you say "any issues," the model optimizes for breadth. It gives you a little bit about style, a little about performance, a little about readability. It covers the easy stuff because you did not tell it to dig deeper.

Technique 1: The Targeted Review

Instead of asking for a general review, pick a specific failure category and go deep.

Before:

Review this Python function for issues.

After:

Review this Python function exclusively for error handling gaps.

For each gap you find:
1. What input or condition triggers the failure
2. What happens when it fails (crash, silent corruption, wrong result)
3. A concrete fix with code

Ignore style, naming, and performance. I only care about
ways this function can break at runtime.

[paste function]

The difference is night and day. The first prompt gets you "consider adding a try-except block." The second gets you "if user_data is None, line 14 throws an AttributeError because you call .get() on a NoneType; here is the guard clause you need."

Run separate passes for separate concerns. One pass for error handling. One for security. One for performance. Three focused reviews beat one unfocused review every time.

Technique 2: Give the AI a Threat Model

Context changes everything. Watch what happens when you tell the AI who is using your code.

Before:

Check this API endpoint for security issues.

After:

This is a public-facing REST endpoint that accepts user input.
It is deployed behind an API gateway but has no rate limiting yet.
Authentication is handled via JWT tokens passed in the Authorization header.
The endpoint writes to a PostgreSQL database using parameterized queries.

Assume the attacker is an authenticated user trying to:
- Access other users' data
- Escalate their permissions
- Cause denial of service
- Exfiltrate data through the response

Review this endpoint code. For each vulnerability found,
rate it Critical/High/Medium/Low and show the exploit scenario.

[paste code]

Now instead of getting "make sure you sanitize inputs" (thanks, very helpful), you get findings like: "An authenticated user can modify the user_id parameter to access other users' records because line 23 uses the request parameter instead of extracting the ID from the JWT token. This is a Critical IDOR vulnerability."

That is a finding you can actually act on.

Technique 3: The Before/After Diff Review

This one is underused. Instead of reviewing a whole file, give the AI the change and let it focus on what is new.

I'm modifying this function to add caching. Review ONLY my changes
for correctness. Here is the original:

python
def get_user(user_id: str) -> User:
return db.query(User).filter(User.id == user_id).first()


Here is my updated version:

python
_cache = {}

def get_user(user_id: str) -> User:
if user_id in _cache:
return _cache[user_id]
user = db.query(User).filter(User.id == user_id).first()
_cache[user_id] = user
return user


Specifically check for:
1. Cache invalidation problems
2. Thread safety issues
3. Memory leak potential
4. Cases where stale data causes bugs

This is where AI code review genuinely shines. It will immediately flag that the cache never invalidates, that a module-level mutable dict is not thread-safe in a multi-worker setup, and that deleted or updated users will serve stale data forever. Those are three real bugs you might not catch in a self-review because you are focused on whether the caching logic itself works.

Technique 4: The Adversarial Edge Case Finder

This is my favorite technique for functions that handle user input or complex business logic.

Here is a function that calculates shipping costs.
Your job is to break it. 

Find inputs that produce:
- Wrong results
- Crashes or exceptions  
- Infinite loops or hangs
- Negative or nonsensical values

For each breaking input, show:
1. The exact input values
2. What the function returns or throws
3. What it SHOULD do instead

[paste function]

Telling the AI to "break" your code activates a completely different analytical mode than asking it to "review" your code. Review mode is polite and surface-level. Break mode is adversarial and thorough. It will try zero, negative numbers, None values, absurdly large inputs, unicode strings where you expected ASCII, empty collections, and every other edge case you forgot about.

Technique 5: The Production Failure Premortem

This one saves you from the bugs that only show up at scale.

This code works in my tests. Imagine it is running in production
with 10,000 requests per minute. What breaks?

Consider:
- Race conditions
- Memory pressure
- Database connection exhaustion  
- Cascading failures if a dependency goes down
- What happens during deployment (old and new code running simultaneously)

[paste code]

Most developers test the happy path at low volume. This prompt forces the AI to simulate production conditions mentally and identify the failure modes that only emerge under load, during deployments, or when external services degrade. The deployment scenario alone -- old code and new code running side by side -- catches schema migration issues that are invisible in single-instance testing.

The Meta-Technique: Iterate, Don't Restart

When the AI gives you a review, do not just read it and move on. Push back.

Good findings. Now assume those are all fixed.
What is the NEXT most subtle bug you can find?
Dig deeper -- look for logic errors, off-by-one mistakes,
and assumptions that hold in tests but not in production.

The first pass catches the obvious stuff. The second pass, when you explicitly tell it to go deeper, catches the subtle stuff. I have found legitimate production bugs on the third iteration of this loop that I would never have caught manually.

Why This Works

All of these techniques share the same underlying principle: specificity creates depth.

A vague prompt gives the AI permission to be vague back. A specific prompt with a defined scope, a threat model, a failure category, and a required output format forces the AI to do actual analysis instead of pattern-matching against common review feedback.

The difference between "review this code" and a well-structured review prompt is the difference between a rubber stamp and a genuine code audit. Same AI, same code, completely different results.

Skip the Trial and Error

It took me months of daily iteration to figure out which prompt structures consistently surface real bugs versus generic noise. If you want to shortcut that process, I put together a Claude Code Prompt Pack with 50+ battle-tested prompts covering code review, security audits, debugging, architecture analysis, performance optimization, and more. Each prompt includes the template, usage notes, and tips on how to iterate for deeper results. It is the reference I wish I had when I started using AI for serious code work.

7 Financial Mistakes That Almost Killed My Freelance Dev Career (Don't Repeat Them)

max — Fri, 30 Jan 2026 21:54:02 +0000

I made $92,000 in my first year of freelancing. I also nearly went broke.

If that sounds contradictory, congratulations -- you already understand more about freelance finances than I did when I quit my full-time job and started taking client work. Turns out, making money and keeping money are two completely different skills. And nobody teaches the second one in a coding bootcamp.

Here are the seven financial mistakes that nearly tanked my freelance career, and exactly how I fixed each one.

1. Not Tracking Expenses (Then Getting Wrecked at Tax Time)

My first year, I kept zero records. I bought software subscriptions, a new monitor, a coworking membership, courses, domain names -- all from a mix of personal cards and PayPal. When my accountant asked for my business expenses in March, I spent an entire weekend digging through bank statements, email receipts, and PayPal transaction logs.

I found about $6,200 in deductible expenses. My accountant estimated I probably missed another $2,000 to $3,000 worth. At a 30% effective tax rate, that's roughly $800 I lit on fire by being too lazy to keep a spreadsheet.

The fix: Log every business expense the day it happens. It takes 30 seconds. I use a simple spreadsheet with columns for date, vendor, amount, category, and whether it's deductible. At tax time, I just hand over the sheet.

2. Undercharging Because I Was Scared of Hearing "No"

My first freelance rate was $50/hour. I picked it because it felt like a lot more than my salaried equivalent, and I was terrified that a higher number would scare clients away.

Here's what I didn't account for: self-employment tax (15.3%), health insurance ($400/month), no paid vacation, no employer 401k match, software and hardware costs, and all the unbillable hours spent on invoicing, email, proposals, and marketing. After all that, my effective rate was closer to $28/hour. Less than my old job.

The clients who would have said no to $100/hour were never going to be good clients anyway. The ones who said yes at $50 were the ones who expected 24/7 availability, scope-creeped constantly, and haggled over every invoice.

The fix: Calculate your minimum viable rate. Take your desired annual income, add 30% for taxes, add your business expenses, add your benefits costs, then divide by the number of billable hours you'll realistically work (hint: it's not 2,080 -- more like 1,200-1,400). The number will probably be higher than you expect. Charge it anyway.

3. Invoicing Late (Or Worse, Inconsistently)

For my first six months, I would finish a project and then... forget to invoice. Sometimes for weeks. I once found a completed project that I hadn't invoiced for 40 days. The client paid eventually, but that's 40 days of my cash flow I donated to their treasury department.

Worse, I had no consistent format. Some invoices were PDFs I made in Google Docs. Some were plain text emails. One was literally a Slack message that said "hey, you owe me $3,200 for the API work." Shockingly, that one took the longest to get paid.

The fix: Invoice the day you deliver. Not the day after. Not next Monday. The day you deliver. Use a consistent numbered format (INV-2026-001, INV-2026-002) so you can track what's outstanding. Include clear payment terms, your payment details, and a line-item breakdown. Clients pay professional-looking invoices faster because they look like they came from a real business, not a guy who might forget to follow up.

4. Not Saving for Taxes (The Classic Freelancer Trap)

April of year one was a bloodbath. I owed $14,000 in federal taxes, plus state. I had about $3,000 in my checking account. I ended up on an IRS payment plan, which is exactly as fun as it sounds.

When you're employed, taxes are invisible. Your paycheck arrives pre-shrunk. When you're freelance, every payment hits your account looking fat and happy, whispering "spend me." Then Q1 estimated taxes roll around and suddenly you're doing math you don't like.

The fix: The moment a client payment lands, move 25-30% into a separate savings account. Don't touch it. That's the government's money -- you're just holding it temporarily. Pay estimated taxes quarterly (April 15, June 15, September 15, January 15). Yes, it hurts every time. It hurts a lot less than a surprise $14,000 bill plus penalties.

5. Not Tracking Billable vs. Non-Billable Hours

I tracked hours for client work, obviously. But I didn't track all the time I spent on proposals that went nowhere, emails, bookkeeping, marketing, chasing late payments, and upgrading my dev environment.

When I finally tracked everything for a month, I discovered that only about 60% of my working hours were billable. That means my effective hourly rate was 60% of whatever I was charging. A $100/hour freelancer who's only billable 60% of the time is actually making $60/hour before taxes and expenses.

The fix: Track all your hours for at least one month, categorized by billable client work, sales and proposals, admin and bookkeeping, and professional development. This gives you your real billable ratio, which you need for setting rates that actually sustain a business. If your ratio is below 65%, you either need to raise your rates or find ways to reduce admin overhead.

6. No Client Pipeline (Feast or Famine Cycle)

For my first 18 months, my revenue looked like an EKG readout. $12,000 one month. $2,000 the next. $0 the month after that. Then $15,000 when I panic-landed a big project.

The pattern was always the same: get a client, bury myself in the work, deliver, look up, realize I have no pipeline, spend three weeks scrambling for the next gig while my savings drain. Repeat.

The fix: Even when you're busy, keep your pipeline warm. Dedicate at least 2-3 hours per week to business development -- responding to leads, maintaining referral relationships, creating content, or following up with past clients about upcoming needs. The best time to find your next client is when you don't need one yet, because desperation is not a negotiation strategy.

7. Treating It Like a Job Instead of a Business

This one took me the longest to learn. I was thinking like an employee: do the work, get paid, repeat. I wasn't thinking about profit margins, client lifetime value, which types of projects were most profitable, or which clients were silently eating my margins through scope creep and slow payments.

Once I started tracking real metrics -- revenue per client, average project profitability, days-to-payment, effective hourly rate after expenses -- I realized that two of my five clients were generating 80% of my profit, and one was actually costing me money when I factored in all the unpaid revision cycles.

I fired the unprofitable client. My income went up.

The fix: Look at your freelance practice as a business, not a series of gigs. Track the numbers. Know which clients and project types are profitable. Know your monthly overhead. Know your effective rate. Make decisions based on data, not gut feel.

The Common Thread

Every single one of these mistakes has the same root cause: I didn't have systems.

I was a great developer. I could ship code, debug production issues at 2am, architect scalable systems. But I was running a business on vibes. No tracking, no dashboards, no process.

The fix wasn't complicated. It was a spreadsheet. A few hours of setup, a few minutes of daily maintenance, and suddenly I could see where my money was coming from, where it was going, and what I owed in taxes -- all in real time. No more surprises.

After three years of refining my system, I've turned it into a kit that any freelance developer can use from day one: a client and project tracker, an invoice generator, an income and expense dashboard, and a tax prep summary -- all connected so data flows between them automatically. I've packaged it as the Freelance Developer Business Kit. It's the system I wish I'd had before I donated $800 to the IRS in missed deductions and learned what a quarterly estimated payment was the hard way.

Don't make the same mistakes I did. Your code is solid. Make sure your business is too.

Docker Commands You Keep Googling (A Cheatsheet for the Rest of Us)

max — Fri, 30 Jan 2026 21:53:58 +0000

I have mass-deployed Kubernetes clusters. I have written multi-stage Dockerfiles that would make a build engineer weep with joy. And yet, at least once a week, I open a browser tab and type "docker remove all stopped containers" like it is the first time I have ever touched a terminal.

You do it too. We all do it. Docker's CLI is powerful, but it was clearly designed by someone who thought consistency was optional. Some commands use container, some use ps, some have flags that mean entirely different things depending on context.

So here is the article I wish existed three years ago: the Docker commands that experienced developers actually forget, organized by the real-world situations where you need them.

Situation 1: "Something Is Eating All My Disk Space"

You get a disk space alert, or your laptop starts wheezing. Nine times out of ten, Docker is hoarding old images, stopped containers, and orphaned volumes like a digital packrat.

See how much space Docker is consuming:

docker system df

This gives you a breakdown by images, containers, volumes, and build cache. The output will probably horrify you.

The nuclear option -- reclaim everything:

docker system prune -a --volumes

This removes all stopped containers, all networks not used by at least one container, all images without at least one container associated to them, and all volumes not used by at least one container. It is the rm -rf of Docker. Use it on your dev machine, not in production. Obviously.

The surgical approach -- clean up one category at a time:

# Remove stopped containers only
docker container prune

# Remove dangling images (untagged layers)
docker image prune

# Remove ALL unused images, not just dangling ones
docker image prune -a

# Remove unused volumes (careful -- this includes data)
docker volume prune

I run docker system df every Monday morning. It is a surprisingly effective habit for keeping your dev environment from bloating to 50GB of stale Alpine images.

Situation 2: "What Is Actually Running Right Now?"

You are trying to start a service and port 3000 is already taken. Or something is chewing CPU. Time to investigate.

# What containers are running?
docker ps

# What containers exist, including stopped ones?
docker ps -a

# Just give me the IDs (useful for scripting)
docker ps -q

# Real-time resource usage for all running containers
docker stats

# Resource usage for a specific container
docker stats my-container-name

The docker stats command is underrated. It gives you a live-updating table with CPU percentage, memory usage, network I/O, and disk I/O for every running container. It is basically htop for Docker and it is built in. No extra tools needed.

Finding which container grabbed your port:

docker ps --format "table {{.Names}}\t{{.Ports}}" | grep 3000

That --format flag with Go templates is one of Docker's best-kept secrets. You can customize the output of almost any list command instead of parsing walls of text.

Situation 3: "The Container Crashed and I Need to Know Why"

The container started, ran for 3 seconds, and died. The classic.

# View logs for a stopped or running container
docker logs my-container

# Follow logs in real-time (like tail -f)
docker logs -f my-container

# Show only the last 50 lines
docker logs --tail 50 my-container

# Show logs with timestamps
docker logs -t my-container

# Show logs since a specific time
docker logs --since 2h my-container

The --since flag accepts human-readable durations like 2h, 30m, or 10s. That alone saves me from scrolling through 10,000 lines of health check output to find the one error that matters.

If logs are not enough, inspect the container's state:

# See exit code, error message, environment, mounts, everything
docker inspect my-container

# Just the exit code
docker inspect --format='{{.State.ExitCode}}' my-container

# Just the error message
docker inspect --format='{{.State.Error}}' my-container

Exit code 137 means it was killed (usually OOM). Exit code 1 means your application crashed. Exit code 0 means it exited normally, and if that was not intentional, your entrypoint script is probably finishing without starting a long-running process.

Situation 4: "I Need to Get Inside This Container"

Something is wrong and you need to poke around inside the running container.

# Open a bash shell in a running container
docker exec -it my-container bash

# If bash is not installed (common in Alpine images)
docker exec -it my-container sh

# Run a single command without opening a shell
docker exec my-container cat /etc/hosts

# Run as root (when the container runs as non-root)
docker exec -u root -it my-container bash

The -u root trick is one I forget constantly. Many production images run as a non-root user for security, which means apt-get install and similar debugging commands will fail. Switching to root inside the container lets you install curl, netcat, or whatever else you need to debug with.

For containers that already crashed and will not start:

# Create a new container from the same image with a shell
docker run -it --entrypoint sh my-image:latest

Overriding the entrypoint lets you poke around the filesystem even if the normal startup command fails immediately.

Situation 5: "Docker Compose Is Doing Something Weird"

Compose has its own set of commands that overlap with but are not identical to regular Docker commands. This is where my memory fails me most often.

# Start everything in the background
docker compose up -d

# Rebuild images AND start (when you changed a Dockerfile)
docker compose up -d --build

# Start only one specific service
docker compose up -d postgres

# Stop everything but keep volumes
docker compose down

# Stop everything AND destroy volumes (full reset)
docker compose down -v

# View logs for one service
docker compose logs -f api

# Run a one-off command in a service container
docker compose exec api python manage.py migrate

# Run a one-off command in a NEW container
docker compose run --rm api python manage.py shell

The difference between exec and run in Compose trips people up. exec runs a command in an already-running container. run spins up a new container for the command. Use exec for quick commands against your running stack. Use run for tasks that might mess up the running container's state, like database migrations during development.

Situation 6: "I Need to Move an Image Without a Registry"

You are working offline, or you need to transfer an image to a machine that cannot reach your registry. This comes up more often than you would expect.

# Save an image to a tar file
docker save -o myapp.tar myapp:latest

# Load an image from a tar file
docker load -i myapp.tar

Two commands. I Google them every single time. The asymmetry of save/load versus the export/import pair (which works on containers, not images) is exactly the kind of design choice that keeps Stack Overflow in business.

Situation 7: "Network Debugging Between Containers"

Containers cannot talk to each other. The dreaded connection refused or could not resolve host.

# List all Docker networks
docker network ls

# See which containers are on a network
docker network inspect bridge

# Create a custom network (containers can resolve each other by name)
docker network create my-network

# Connect a running container to a network
docker network connect my-network my-container

# Test connectivity from inside a container
docker exec -it my-container ping other-container

Here is the thing that bites everyone at least once: containers on the default bridge network cannot resolve each other by container name. You need a custom network for that. Create one, attach your containers to it, and name resolution works automatically. I have seen senior engineers waste hours on this.

The Commands I Actually Have Memorized

After years of Docker usage, these are the only commands that live permanently in my muscle memory:

docker ps -- what is running?
docker logs -f -- what is it saying?
docker exec -it ... bash -- let me look inside
docker compose up -d -- start everything
docker compose down -- stop everything

That is five commands. Everything else, I look up. And honestly, that is fine. The goal is not to memorize every flag. The goal is to know what is possible and find the right command quickly when you need it.

Stop Googling the Same Commands

If you are tired of the browser-tab-per-Docker-question workflow, I put together a CLI Cheatsheet Bundle covering Docker, Git, and Linux commands in a single searchable reference. Every command includes the flags you actually use, organized by real-world scenario instead of alphabetical order. It is the kind of thing you keep open in a second monitor and wonder how you worked without it.

Why Your AI Prompts Suck (And the Framework That Fixes Them)

max — Fri, 30 Jan 2026 10:37:07 +0000

Most developers use AI tools the same way they'd ask a coworker: vaguely. And they get vague answers back.

"Hey, can you review this code?"
"Can you help me debug this?"
"Write me some tests."

The AI responds with something generic, you get frustrated, and you go back to doing it manually. Then you tell your friends AI coding tools are overhyped.

The problem isn't the AI. It's the prompt.

The SCOC Framework

After testing hundreds of prompts across Claude, ChatGPT, and GitHub Copilot, I noticed a pattern. The prompts that consistently produce useful output all share four properties. I call it SCOC:

Structure
Context
Output format
Constraints

Let me break each one down.

S - Structure

Bad:

Review my code and tell me if there are any issues.

Good:

Review this code for:

Bugs and runtime errors

Security vulnerabilities

Performance issues

Edge cases not handled

Why the difference matters: the structured prompt creates four parallel evaluation paths. The AI literally checks each category separately instead of doing a single pass and mentioning whatever jumps out first.

Without structure, you get a review that fixates on whitespace while missing a SQL injection vulnerability.

C - Context

Bad:

Why doesn't this work?

Good:

This function should return user data from the database but returns None.
It worked yesterday before I updated the ORM.
Using Python 3.11, SQLAlchemy 2.0, PostgreSQL 15.

Context is the single biggest lever. The same code snippet produces completely different analysis depending on whether you say "this is a hobby project" vs "this handles financial transactions in production."

Three types of context that matter most:

What it should do (expected behavior)
What changed (when did it break?)
What environment (language version, framework, OS)

O - Output Format

Bad:

Give me test cases for this function.

Good:

Give me test cases for this function in Jest format.
Use descriptive test names that explain the scenario.
Group by: happy path, edge cases, error conditions.

If you don't specify the output format, the AI guesses. Sometimes it gives you pseudocode when you want real code. Sometimes it gives you a wall of text when you want a checklist.

Useful output formats:

Checklist - for review tasks, test planning
Ranked list - for debugging (most likely cause first)
Code - specify the language, framework, and test runner
Table - for comparisons, trade-off analysis
Step-by-step - for debugging walkthroughs

C - Constraints

Bad:

Refactor this function.

Good:

Refactor this function.

Don't change the public API or return type.

Keep it under 30 lines.

Preserve all existing behavior.

Constraints prevent the AI from going off the rails. Without them, a refactoring prompt might rename your function, change its signature, add unnecessary abstractions, or "optimize" it by changing behavior.

The most important constraints:

Don't change behavior - for refactoring
Rate by severity - for security reviews
Maximum length - for documentation
Specific format - for code output

Putting It Together

Here's a real example using SCOC:

Without SCOC:

Help me debug this. It's not working.

Result: Generic advice about checking logs and restarting the server.

With SCOC:

Help me debug this issue systematically.

[CONTEXT]
Expected: API returns user profile with avatar URL
Actual: Returns 500 error on /api/users/:id
Changed: Updated the User model to add avatar field
Stack: Node.js 20, Express 4, Prisma ORM, PostgreSQL

[STRUCTURE]
Analyze for:
1. Database schema mismatches
2. ORM configuration issues
3. Missing migrations
4. Null handling problems

[OUTPUT]
Rank causes by probability. For each:
- What to check
- How to verify
- How to fix

[CONSTRAINTS]
- Focus on the avatar field change as the likely cause
- Don't suggest unrelated refactoring

Result: Identifies that the Prisma schema wasn't regenerated after adding the avatar field, provides the exact command to run, and explains why the 500 error occurs (Prisma trying to select a column that doesn't exist in the database yet).

That's the difference between 30 seconds and 30 minutes.

Common Mistakes

1. Too much code, not enough context
Pasting 500 lines with "what's wrong?" is like handing a doctor your entire medical history and saying "fix me." Point them to the symptom.

2. Not specifying the output format
If you want Jest tests, say Jest. If you want a checklist, say checklist. Don't make the AI guess.

3. No constraints
Every refactoring prompt should include "preserve existing behavior." Every review prompt should include severity ratings. Every debugging prompt should include "rank by likelihood."

4. Starting over instead of iterating
If the first response is 80% right, don't rewrite the prompt from scratch. Say "good, but also check for X" or "focus more on the security aspect."

The Real Skill

Prompt engineering isn't about memorizing magic phrases. It's about clearly communicating what you want, what you know, and what format you need the answer in.

The developers who get the most out of AI tools aren't using secret techniques. They're just being specific.

If you want to skip the learning curve, I put together a collection of 50+ tested developer prompts using the SCOC framework - covering code review, debugging, documentation, testing, architecture, security, and performance. Each one is copy-paste ready with usage notes and pro tips.

How I Track Finances as a Freelance Developer (No Accounting Degree Required)

max — Fri, 30 Jan 2026 09:17:35 +0000

My first year freelancing, I didn't set aside a dollar for taxes. Not one. I'd come from a salaried job where all that stuff just happened automatically, and some part of my brain figured it would keep happening. It did not keep happening.

April rolled around and I owed the IRS $14,000 I didn't have. I ended up on a payment plan, which if you've never done that, is a special kind of humbling. You get letters. They're not friendly letters.

That tax bill is the reason this spreadsheet system exists. Not because I'm organized. Because I got my ass kicked and needed to make sure it didn't happen again.

QuickBooks is Probably Overkill for You

Every freelance finance article says the same thing: get QuickBooks, get FreshBooks, get Wave. And look, those are fine tools if you're running a landscaping company with employees and inventory and purchase orders.

You're a developer. You don't have inventory. You probably don't have employees. You have a laptop, some subscriptions, and clients who may or may not pay you on time.

QuickBooks is overkill for most solo devs and you'll spend more time setting it up than it saves you. I know because I tried. Spent an entire Saturday configuring categories and chart of accounts, then never opened it again.

What I actually needed was dead simple: am I making money, who owes me, and how much do I owe the IRS this quarter?

So I built it in Google Sheets.

The 4-Sheet System

Four sheets. They talk to each other with formulas. The whole thing takes about two minutes a day to maintain.

Sheet 1: Client and Project Tracker

Every project gets a row.

Field	Why It Matters
Client + Contact	So I know who to chase about late payments
Rate (hourly or fixed)	Compares against actual time spent
Estimated vs Actual Hours	Reveals if I'm undercharging
Total Invoiced vs Paid	Shows outstanding balance instantly
Status	Active / Completed / On Hold

The number that changed how I price projects: effective hourly rate. For fixed-price work, it's just total paid / actual hours. I quoted $5,000 for a project once, thought it'd take 40 hours. It took 100. My effective rate was $50/hr. That's a hell of a wake-up call when you think you're charging $150.

Conditional formatting does the rest. Red means someone owes me money for 30+ days. Green means done and paid. You'd be surprised how motivating it is to turn rows green.

Sheet 2: Invoice Tracker

Field	Notes
Invoice number	Sequential: INV-2026-001, 002, etc.
Amount + Tax	Auto-calculated
Date Sent	When I emailed it
Due Date	Net 30 from send date
Status	Sent / Paid / Overdue
Days to Pay	Auto-calculated

That "Days to Pay" column is the most important column in the whole system.

I had a client "forget" to pay a $6,800 invoice for four months. Four months. I didn't have a contract with late fees, didn't have a system that flagged it, and honestly didn't even notice for the first six weeks because I was buried in other work. I got the money eventually, but that experience was the reason I started tracking payment speed religiously. Now I know which clients pay in a week and which ones drag it past 45 days, and that data factors into whether I take them on again.

Sheet 3: Income and Expense Dashboard

Two sections, nothing fancy.

Income log: Every payment, tagged by client and category (client work, product sales, consulting).

Expense log: Every business expense, tagged by categories that actually map to IRS Schedule C lines:

Software and Tools (GitHub, AWS, Figma, etc.)
Hardware and Equipment
Home Office
Professional Development
Marketing
Subcontractors

The dashboard auto-generates charts and one number I care about more than any other: effective hourly rate including non-billable time.

If I billed 120 hours at $150/hr but worked 160 hours total counting admin, marketing, and learning, my real rate is $112.50. That's the actual number. The other one is a fantasy.

Sheet 4: Tax Prep Summary

This is the sheet that exists because of the $14k mistake.

It auto-populates from the other three sheets. Quarterly income, deductible expenses, estimated self-employment tax at 15.3%, estimated federal and state. And the one number I actually need: what to send the IRS this quarter.

Before this system, I'd either overpay estimates and tie up cash I needed, or underpay and get hit with penalties. Now I'm within 5% every quarter. My accountant actually complimented the organization, which is probably the only compliment I've ever gotten from an accountant.

Two Minutes a Day

Log hours. Log expenses. Mark payments received.

That's it. The dashboard handles everything else. I do it at the end of the day before I close my laptop. If I skip a day, I do two days the next morning. The key is not letting it pile up, because once you're behind a month on this stuff, you're right back to the weekend-before-taxes scramble.

What a Year of Data Taught Me

I was undercharging for fixed-price work. My effective rate on fixed projects was 40% below my hourly rate. Forty percent. I was underestimating scope every single time. Raised my fixed quotes by 30% and started padding estimates by 20%. Still occasionally get burned but it's way better.

Software expenses are a slow bleed. I was spending $340/month on subscriptions. Cancelled the ones I barely touched and saved $120/month. That's $1,440 a year on tools I wasn't using.

Some clients cost you money. One client paid 45+ days late every time, wanted endless revisions, and my effective rate with them was literally half my normal rate. I didn't renew. Best decision I made all year.

Tax prep went from a full weekend to five minutes. When everything is categorized throughout the year, quarterly prep is just reading the summary and writing a check. That alone is worth maintaining the system.

Why Sheets and Not Some App

Free. Customizable. Works on my phone. My accountant can view it. No vendor lock-in. No loading screens.

Yeah, the initial setup takes a few hours. Building the formulas and conditional formatting isn't trivial. That's the one real downside.

The Formulas

If you want to build your own, these are the ones that matter:

Effective Hourly Rate:
= Total Paid / Actual Hours

Monthly Profit:
= SUMIFS(income, month, currentMonth) - SUMIFS(expenses, month, currentMonth)

Outstanding Balance:
= Total Invoiced - Total Paid

Quarterly Tax Estimate:
= (Quarterly Net Income * 0.153) + (Quarterly Net Income * Federal Rate)

Days to Pay:
= Date Paid - Date Sent

Average Client Lifetime Value:
= AVERAGEIFS(Total Paid, Status, "Completed")

I built this system for myself after the IRS payment plan situation. Used it for a couple years, kept refining it. Other dev friends kept asking for a copy, so I eventually cleaned it up with a setup guide and put it on Gumroad. It's the Freelance Developer Business Kit if you want to skip the setup hours. Or build your own. I genuinely don't care either way, just track your damn finances.

The Git Commands I Use Every Day (and the Ones I Always Forget)

max — Fri, 30 Jan 2026 09:11:04 +0000

I force pushed to main once. Second month at my first real dev job. Just sat there watching Slack light up while the senior engineer scrambled to fix what I'd done. He was cool about it. We're still friends. I still feel the shame.

That was the day I stopped treating Git like something I'd "figure out eventually" and started actually learning the commands. Seven years later, I still Google half of them. Not because I'm bad at Git. Because Git has roughly 150 commands with thousands of flag combinations and whoever designed the CLI was apparently allergic to consistency.

So I keep a cheatsheet. Here's what's actually in it.

Commands I Use Every Single Day

You already know these:

git status                    # What changed?
git add .                     # Stage everything
git commit -m "message"       # Commit
git push                      # Ship it
git pull                      # Get latest
git checkout -b feature-name  # New branch
git log --oneline             # Quick history

That covers maybe 80% of my day. The other 20% is where things get annoying.

Commands I Use Weekly (but Can Never Remember the Flags)

Stashing with a message

git stash push -m "WIP: refactoring auth"  # Named stash
git stash list                              # What did I stash?
git stash pop                               # Apply and remove
git stash apply stash@{2}                   # Apply specific one

I forget the push -m syntax every single time. Plain git stash works but then you end up with a list of unnamed stashes and zero idea what's in any of them. Future you will hate past you for this.

Interactive add

git add -p   # Stage individual hunks

This is genuinely the most underused Git command. It lets you stage parts of a file instead of the whole thing. If you've ever had a messy working directory and wanted clean, logical commits instead of one giant "WIP" commit, this is how you do it.

Most people don't know it exists. I didn't for years.

Viewing diffs properly

git diff                      # Unstaged changes
git diff --staged             # What's about to be committed
git diff HEAD                 # Everything since last commit
git diff main..feature        # Branch comparison

I mix up --staged and --cached every time. They're the same thing. --staged is just the modern alias. Why Git has two flags that do the same thing is beyond me, but here we are.

Commands I Look Up Every Time

Undoing the last commit

This one is a pain in the ass to remember because there are three different ways to do it and they all do different things.

# Keep changes (just undo the commit)
git reset --soft HEAD~1

# Discard everything (nuclear option)
git reset --hard HEAD~1

# Undo but create a new "undo" commit (safe for shared branches)
git revert HEAD

Reset rewrites history. Never use it on shared branches. I learned this the hard way (see: the force push story above). Revert creates a new commit that undoes the old one. Safe for shared branches. Use revert if anyone else has pulled that code.

Cherry-picking

git cherry-pick abc123f       # Apply one commit to current branch

I use this maybe twice a month. The syntax is dead simple and I still look it up every time.

Finding what broke things

git bisect start
git bisect bad                # Current commit is broken
git bisect good abc123f       # This older commit was fine
# Git checks out a middle commit - test it, then:
git bisect good               # or git bisect bad
# Repeat until Git finds the breaking commit
git bisect reset              # Done, go back to normal

git bisect is magic. Binary search through your commit history. For a 1000-commit range, it finds the exact commit that broke things in about 10 steps. I wish I'd known about this earlier. Would have saved me a lot of 2am git log scrolling.

Cleaning up merged branches

# Delete local branch
git branch -d branch-name

# Delete remote branch
git push origin --delete branch-name

# Remove stale remote tracking branches
git fetch --prune

Just run git fetch --prune regularly. Your branch list is probably a mess right now. Go look. I'll wait.

The reflog (your safety net)

git reflog                    # Show everything you've done
git checkout -b recovery abc123f  # Recover "lost" commits

Even after a hard reset, your commits aren't truly gone for about 30 days. The reflog tracks every HEAD movement. This is the command that would have saved me from that force push panic at my old job if I'd known it existed at the time. I didn't. The senior dev did, though. That's how he bailed me out.

How I Actually Remember Things

I don't.

The few commands I've memorized are the ones I type 10+ times a day. Everything else, I look up. The trick isn't memorizing all of this. It's having a reference you can search in 5 seconds instead of opening 12 Stack Overflow tabs.

I keep mine organized by what I'm trying to do, not alphabetically by command name. Because when something's broken at 11pm, I'm not thinking "what's the syntax for revert," I'm thinking "how do I undo this commit without destroying everything."

I ended up putting together a Developer CLI Cheatsheet Bundle based on my own reference doc. Git, Docker, Linux, organized by workflow. Honestly built it for myself first and figured other people probably have the same 30-tabs-open problem.

10 Claude Prompts That Save Me Hours Every Week as a Developer

max — Fri, 30 Jan 2026 09:09:47 +0000

I thought AI coding tools were bullshit.

Not in a loud, Twitter-argument way. More like a quiet eye-roll every time someone on a podcast said "and then I just asked the AI to refactor it." Yeah, sure you did. I'm sure that went great.

Then sometime around mid-2024, I was three weeks into a freelance project and there was a bug I could not find. The logic looked right. The tests passed. But every few hundred requests, the whole thing would just... silently drop data. I was losing my mind. On a whim, I pasted the module into Claude with a prompt I'd been tinkering with and asked it to look for concurrency issues.

It found a race condition in under ten seconds. A race condition I had been staring past for weeks.

I didn't mass-convert to the Church of AI that day. But I did shut up about it being useless. And over the months since, I've built up a set of prompts that I actually use every day. Not cute demos. Not "look what AI can do" parlor tricks. Just prompts that save me real time on real work.

Here are the ones I keep coming back to.

The one I use before I ship anything

Most developers ask AI to "review my code" and wonder why the feedback is garbage. No constraints, no focus, just "hey look at this." You wouldn't walk up to a senior dev and say "look at this" with zero context. Same thing here.

This is what I actually paste in before I push:

I'm about to ship this code. Give me a quick sanity check:
1. Any obvious bugs?
2. Will this break in production?
3. What's the one thing I probably forgot?

[paste code]

That third question does an unreasonable amount of heavy lifting. Turns out AI is weirdly good at catching the thing you stopped thinking about two hours ago because you got tunnel vision.

Debugging (but make it structured)

I learned the hard way that "fix this" is the worst possible prompt. You get back a confident, plausible, completely wrong answer. Then you waste twenty minutes implementing it before realizing the AI hallucinated the root cause.

Help me debug this issue systematically.

Expected behavior: [what should happen]
Actual behavior: [what's happening]
Error message: [paste error]
Code: [paste relevant code]

Walk me through:
1. Most likely causes (ranked by probability)
2. How to verify each hypothesis
3. The fix for the most probable cause

The key is "ranked by probability." Without that, you get a grab bag of five theories with no sense of which one to try first. With it, you get a differential diagnosis. I've had this nail the issue on the first guess more times than I expected.

Security audit

Perform a security audit on this code. Check for:
- SQL injection vulnerabilities
- XSS attack vectors
- Authentication/authorization flaws
- Sensitive data exposure
- Input validation issues

Rate each finding as Critical/High/Medium/Low.

[paste code]

The severity rating is the whole trick. Without it you get a wall of text where a missing CSRF token and a hardcoded database password look equally important.

The error message translator

Short one. When you get some cryptic stack trace from a library you didn't write:

Explain this error in plain English and tell me how to fix it:

[paste full error + stack trace]

Context: I was trying to [what you were doing]

That context line matters more than you'd think. "I was trying to deploy to Kubernetes" and "I was running tests locally" are completely different debugging paths, and without that one line the AI will guess wrong half the time.

Code review that doesn't suck

I have strong feelings about this one. The default AI code review experience is terrible. You paste code, it says "looks good, maybe add some comments." Useless.

This prompt forces it to actually look:

Review this code for:
1. Bugs and potential runtime errors
2. Security vulnerabilities
3. Performance issues
4. Code style and readability
5. Edge cases not handled

Provide specific line references and concrete suggestions.

[paste code]

The numbered list prevents it from fixating on one category. Without it, you'll get ten nitpicks about variable naming and zero actual bug reports. The "specific line references" part is what makes the feedback actionable instead of vague.

Test cases

Look, I know writing tests after the fact sucks. I do it anyway because production incidents at 2am suck more. But brainstorming what to test is the part that takes forever, and this is where AI genuinely shines.

Brainstorm test cases for this feature:

Feature: [describe it]
Inputs: [what it accepts]
Outputs: [what it produces]

Generate cases for:
- Normal usage
- Edge cases
- Invalid inputs
- Concurrency if applicable

Format as a checklist.

I don't use the generated tests as-is. I use the list as a "did I forget anything" check. And yeah, I almost always forgot something.

Breaking up long functions

This function is too long. Help me break it into smaller functions:
1. Identify logical sections
2. Suggest descriptive function names
3. Show the refactored code
4. Ensure behavior doesn't change

Step 4 is doing the important work. Skip it and the AI will "improve" your code by quietly changing behavior. I've been bitten by that.

Query optimization

Optimize this database query:

Query: [paste SQL]
Table schemas: [paste schemas]
Current execution time: [if known]

Provide:
- Optimized query
- Suggested indexes
- Explanation of improvements

If you don't include the schemas it'll suggest indexes on columns that don't exist. Ask me how I know.

The "works on my machine" prompt

Every developer's favorite sentence. This one has saved me from an embarrassing amount of Docker-related yelling.

This code works locally but fails in production/CI/Docker.

Local environment: [describe]
Production environment: [describe]
Error in production: [paste error]

What environment differences could cause this?
Give me a checklist to verify.

Environment bugs are a pain in the ass because the code looks correct. It IS correct. It's everything around the code that's wrong. The checklist format keeps you from randomly changing config values and hoping something sticks.

Documentation (the chore I actually outsource now)

Write documentation for this function:
- Purpose and description
- Parameters with types
- Return value
- Exceptions that can be thrown
- Usage example
- Edge cases to be aware of

Use your preferred doc format.

[paste function]

This is the one prompt where I mostly just take the output and paste it in. Not much creativity needed for JSDoc. I'd rather spend my brain on the actual code.

The pattern across all of these

You probably noticed: every prompt that works well has structure, context, and constraints. You tell the AI what to look at, how to format the answer, and what not to do.

Most people write prompts like they're texting a friend. "Hey can you look at this code?" That's why the answers are mid.

Fifteen seconds of prompt structure is the difference between a useful answer and a twenty-minute detour.

I've been collecting these for about six months now. These ten are the ones I reach for daily, but I've got around 40 more that cover architecture decisions, performance profiling, caching strategies, threat modeling, that kind of thing. I cleaned them all up and put them on Gumroad if you want the full set. Or don't. These ten will get you pretty far on their own.

DEV Community: max

The Debugging Checklist I Run Before Asking Anyone for Help

Step 1: Confirm the Bug Exists Where You Think It Does

Step 2: Check What Changed

Step 3: Read the Actual Error Message

Step 4: Reproduce It Reliably

Step 5: Add Logging at the Boundaries

Step 6: Question Your Assumptions

Step 7: Isolate With Binary Search

Step 8: Search for the Exact Error

Step 9: Rubber Duck It (Seriously)

Step 10: Let a Second Brain Look at It

The Whole List, Condensed

What I Wish Someone Told Me Before I Went Freelance

The Money Is Not What You Think It Is

You Will Get Screwed on an Invoice

The Freedom Thing Is Real but Weird

Nobody Prepares You for the Admin Work

Most Freelancing Advice Is Terrible

The Part Where I Tell You to Do It Anyway

14 Linux Command-Line Tricks That Made Me Mass-Delete My Bash Aliases

1. Process Substitution (The One That Changes Everything)

2. xargs -P: Instant Parallelism

3. The Curly Brace Expansion Nobody Uses Fully

4. Column Selection With cut and awk That Actually Makes Sense

5. The !! and !$ History Shortcuts

6. The column Command: Instant Pretty Tables

7. comm: The Set Operations Tool You Never Knew Existed

8. tar Can Stream Over SSH

9. tee For When You Need Both

10. grep -c and sort | uniq -c | sort -rn: The Analysis Pipeline

11. watch: Auto-Refresh Any Command

12. Redirect stderr and stdout Independently

13. rsync --dry-run: Preview Before You Wreck

14. Trap: Clean Up After Yourself

The Pattern

Stop Getting Useless AI Code Reviews (Here's How to Actually Catch Bugs)

The Problem: Generic Prompts, Generic Reviews

Technique 1: The Targeted Review

Technique 2: Give the AI a Threat Model

Technique 3: The Before/After Diff Review

Technique 4: The Adversarial Edge Case Finder

Technique 5: The Production Failure Premortem

The Meta-Technique: Iterate, Don't Restart

Why This Works

Skip the Trial and Error

7 Financial Mistakes That Almost Killed My Freelance Dev Career (Don't Repeat Them)

1. Not Tracking Expenses (Then Getting Wrecked at Tax Time)

2. Undercharging Because I Was Scared of Hearing "No"

3. Invoicing Late (Or Worse, Inconsistently)

4. Not Saving for Taxes (The Classic Freelancer Trap)

5. Not Tracking Billable vs. Non-Billable Hours

6. No Client Pipeline (Feast or Famine Cycle)

7. Treating It Like a Job Instead of a Business

The Common Thread

Docker Commands You Keep Googling (A Cheatsheet for the Rest of Us)

Situation 1: "Something Is Eating All My Disk Space"

Situation 2: "What Is Actually Running Right Now?"

Situation 3: "The Container Crashed and I Need to Know Why"

Situation 4: "I Need to Get Inside This Container"

Situation 5: "Docker Compose Is Doing Something Weird"

Situation 6: "I Need to Move an Image Without a Registry"

Situation 7: "Network Debugging Between Containers"

The Commands I Actually Have Memorized

Stop Googling the Same Commands

Why Your AI Prompts Suck (And the Framework That Fixes Them)

The SCOC Framework

S - Structure

C - Context

O - Output Format

C - Constraints

Putting It Together

Without SCOC:

With SCOC:

Common Mistakes

The Real Skill

How I Track Finances as a Freelance Developer (No Accounting Degree Required)

QuickBooks is Probably Overkill for You

The 4-Sheet System

Sheet 1: Client and Project Tracker

5. The `!!` and `!$` History Shortcuts

6. The `column` Command: Instant Pretty Tables

7. `comm`: The Set Operations Tool You Never Knew Existed

8. `tar` Can Stream Over SSH

9. `tee` For When You Need Both

10. `grep -c` and `sort | uniq -c | sort -rn`: The Analysis Pipeline

11. `watch`: Auto-Refresh Any Command

13. `rsync --dry-run`: Preview Before You Wreck