DEV Community: lixy

The Paycheck Math to Run Before You Resign

lixy — Tue, 15 Sep 2026 03:56:08 +0000

My last employer owed me 1,731 dollars for vacation I never took, and I only know the number because a coworker told me to check. The final pay stub listed it as one line among others, and I had nearly signed off without reading it. Developers switch jobs often enough that this math should be routine, yet almost nobody runs it before the exit interview.

So here it is: the three calculations that decide what your last paycheck contains, with worked numbers you can replicate in a spreadsheet in about ten minutes.

Your salary has a daily rate, and it decides the last check

Salaried employees are paid for the week, not the day. When you leave mid pay period, somebody in payroll has to convert your salary into a daily rate before the partial period can be paid. The standard conversion runs through the workweek: annual salary divided by 52, then by 5 working days. Divided by 260, in other words.

At 72,000 dollars a year, that is 276.92 dollars per day. Resign effective the 15th of the month, with semi-monthly pay, and payroll counts your workdays from the 1st to the 15th, weekends excluded, then multiplies. Eleven workdays at 276.92 comes to 3,046.15 dollars.

Here is the part that surprises people. A full semi-monthly check at that salary is 3,000 dollars, so the partial check is larger than a full one. The first half of that particular month held more workdays than the fixed halves of the year assume. Proration follows the calendar you actually worked, not the neat slices your salary was quoted in.

Knowing your daily rate before you resign means you can predict the last check to the dollar, which means you can spot the week the payroll system forgot. A colleague's first final-check draft was missing three days, and the correction took one email because he could show the arithmetic instead of a feeling.

Unused PTO is cash on the table

The 1,731 dollars from my opening line was a PTO payout, and the number is not arbitrary. Vacation accrues as you work. With a 120-hour annual allowance and monthly accrual, leaving after 8 full months gives you 120 divided by 12, times 8, which is 80 hours accrued. Take 30 of them during the year and 50 hours remain.

Then the balance converts to cash. For salaried staff the hourly equivalent is annual salary divided by 2,080, the standard 40 hours times 52 weeks. At 72,000 dollars that is 34.62 an hour, and 50 hours pays 1,731 dollars. The whole calculation is three divisions and a subtraction.

One warning before you bank on it: whether that payout arrives at all depends on your state. There is no federal requirement to pay out unused vacation. California, Colorado, Illinois, Massachusetts and a handful of other states treat accrued PTO as wages that must be paid. Elsewhere, a use-it-or-lose-it policy in the handbook can legally zero out your balance on your last day. Know which group your state is in before you choose between burning your remaining days in the notice period and cashing them out.

When the money has to show up

The final check also has a legal deadline, and the deadlines vary more than most people expect. In California, with at least 72 hours of notice, it is due on your last day, and without notice within 72 hours after it. Miss it and the employer owes waiting-time penalties that accrue at a full day of wages per day, capped at 30 days. Oregon is nearly as strict. Most states, including Texas, simply require payment by the next regular payday, which can leave you waiting two weeks.

Hourly readers get one extra line of protection: overtime earned in the prior period that had not yet been paid must ride on the final check, not the one after it.

Run the numbers before the exit interview

Exit weeks are rushed. You are handing over repos, writing docs nobody will read, and sitting through goodbyes. The one hour you spend on this math beforehand is the difference between signing a correct final check and chasing payroll from your new job.

All three calculations are pro rata at heart: a salary sliced into days, an allowance sliced into months, a balance converted at an hourly rate. If you want to check your own figures without building the spreadsheet, the free pro rata calculator does the divisions, and the prorated final paycheck guide covers the state deadlines and the full worked examples, including what else belongs on the check besides salary.

Your last paycheck is the one document at a job you will never get corrected by asking nicely in a standup. Read it before you sign, and make sure the arithmetic was on your side.

The Invoice Math Most Freelance Developers Learn Too Late

lixy — Tue, 08 Sep 2026 02:42:37 +0000

My first invoice had no payment terms at all. It said the amount, my bank details, and nothing about when payment was due. The client paid after 47 days. I remember checking the account every morning for a week and a half, wondering whether asking about it would seem pushy.

That was the year I learned that payment terms are not paperwork. They are pricing. Here is the math I wish someone had walked me through before I sent that first invoice.

Net 30 means you are the bank

Net 30 reads like a neutral deadline: pay within 30 days. Look at it from the other side of the table. Your client has received the work. You have received a promise. For those 30 days, you have issued an interest-free loan to a company that is probably larger than you.

Big companies know this perfectly well. Corporate finance teams track days sales outstanding the way engineers track latency, and stretching it is free money for them. A procurement department that pushes a small vendor from Net 30 to Net 60 has effectively borrowed from that vendor at zero percent, and it shows up as an efficiency win in their annual report.

None of this means you should refuse Net 30. It is the market default, and fighting it on every contract costs goodwill. The point is to know what you are trading. When a client asks to move from Net 30 to Net 75, that request has a price, and you are the one paying it.

The 2/10 net 30 trick, and what it really pays

One client offered me a term I had never seen: 2/10 net 30. It means: if I pay within 10 days, take a 2 percent discount. Otherwise the full amount is due in 30 days.

I almost ignored it. Two percent of a four-figure invoice sounded like a rounding error. Then I ran the numbers.

A 1000 dollar invoice with that term gives the client two choices: pay 980 within 10 days, or pay 1000 at day 30. The 20 dollar difference buys 20 extra days of credit. Annualize that, using the banker's 360-day convention that invoice math traditionally uses, and the cost of those 20 days is 2/98 multiplied by 360/20, which is about 36.7 percent per year.

That number deserves a second read. The client's alternative sources of short-term money, a credit line, a factor, an overdraft, all cost a fraction of that. So when a client offers you 2/10 net 30 as the vendor, they are handing you a paying proposition on a plate, and you should nearly always take it. When you offer it to your clients, you are buying fast cash at a steep implied rate, which can still be the right call. Cash you have today is cash you can bill against on the next project, and for a one-person shop, velocity often beats margin.

The mistake is not choosing either side. The mistake is treating 2 percent as too small to think about, when it is actually 36.7 percent a year wearing a disguise.

A due date without a penalty is a suggestion

The same client who paid in 47 days? The second invoice had "Net 14" on it. It changed nothing, because I had no consequence attached.

Late fee clauses fix this. The standard formulation is 1.5 percent per month on overdue balances, which compounds to roughly 19.6 percent a year. Two things surprised me about that number. First, it is not arbitrary: it sits high enough to sting and low enough to stay inside the usury caps that several US states place on late charges. Second, you generally cannot invent a punitive rate after the fact. If the clause was not on the invoice the client agreed to, enforcing it becomes an argument instead of arithmetic.

In practice I have collected a late fee exactly once. That is fine. The clause works the way a good fence works. Most people respect it, and the one time someone tests it, the conversation starts from your document instead of your feelings.

Invoice numbers are cheap insurance

The last piece is the one I resisted longest, because it looks like bureaucracy. Invoice numbers should be sequential, unique, and never reused, even across years and clients.

The reasons are all downstream. When a tax office asks you to reconcile a quarter, sequential numbers let you prove no gaps exist. When a client disputes a charge, "invoice 0042" is an unambiguous reference for both sides. When two clients merge and their accounting departments compare records, a clean series survives the audit. Freelancers who reuse numbers or restart them every January eventually buy back the difference in hours, usually during the worst possible week.

Putting it on paper

None of this helps if it lives in your head at deadline time. The terms that matter fit on three lines at the bottom of an invoice: the due date, the discount if you offer one, and the late fee. When I finally started writing invoices that carried all three, my average time-to-payment dropped from that 47-day embarrassment to under three weeks, with no difficult conversation at all.

If you want to see the terms side by side with real numbers, or generate an invoice that already has the slots for them, I keep a free invoice maker for exactly this: fill in the fields, get a clean PDF, no account. For the longer version of the discount math, including when it is worth refusing, the early payment discount breakdown covers the cases this post skipped.

Payment terms are not admin. They are the part of your rate that decides when you actually get paid, and sometimes whether you get paid at all. Learn the math once, put it on every invoice, and let the document do the enforcing.

I Ran My Own Favicon Checker Against 10 Sites. All 10 Failed.

lixy — Sat, 05 Sep 2026 15:38:21 +0000

I maintain a small collection of single-purpose web tools. Last month I built a favicon checker: you type a URL, it reads the icon declarations in the HTML head, probes every referenced file, and also hits /favicon.ico directly, because plenty of software still requests that path without ever reading your HTML.

The first thing you should do with any auditing tool is point it at your own stuff. So I did. Ten sites, all built by me, all shipped and verified in browsers I actually use.

All ten failed. Not seven out of ten. Ten.

Failure one: SVG-only icon sets

Every site had a nice crisp favicon.svg and nothing else. Modern browsers request it, render it at any size, everything looks great in Chrome and Firefox. Then something older comes along: a bookmark sidebar, an RSS reader, a corporate proxy portal that lists your link, that one intern running Opera 12. These clients do not parse your <link> tags. They request /favicon.ico and hope.

All ten sites returned a 404 for that path. The fix is not glamorous. You need an actual .ico file, ideally with 16, 32, and 48 pixel frames packed inside, plus a PNG for iOS. More on that below.

Failure two: no apple-touch-icon

Nine of the ten sites had no apple-touch-icon.png. When someone saves such a site to an iOS home screen, Safari does not use your favicon. It takes a screenshot of the page, letterboxes it, and calls that your app icon. If you have ever seen a bookmark that looked like a cropped text paragraph, that is why.

The fix is one file and one tag: a 180 by 180 PNG, referenced with <link rel="apple-touch-icon" href="/apple-touch-icon.png">. Done. No JavaScript, no media queries, no dark mode variants needed. iOS rounds the corners itself.

Failure three: the 404 that would not leave

This is the one that cost me an evening, so pay attention if any of your sites sit behind Cloudflare.

I generated the missing icons, deployed them, and re-ran the checker. Still 404. I deployed again. Still 404. I started doubting my build, my deploy script, my cache headers, my sanity.

The files were fine. The problem was that Cloudflare had cached the original 404 responses. The .ico extension is on Cloudflare's default cached file list, and that rule does not distinguish between a 200 with an image and a 404 with an error page. The edge had helpfully stored my failure and now served it at speed.

You can confirm this with a response header check: if cf-cache-status: HIT shows up on a request you know should be fresh, you are looking at a cached answer, not the origin's. Two ways out: request the file with a query string like ?v=2, which bypasses the cache and shows you what the origin actually returns, or wait for the cached entry to expire on its own. Purging works too if you have dashboard access.

So the deploy sequence that actually worked was: upload the files, verify with a query string, then trust that the plain path would heal itself as the cache aged out.

How I generated everything locally

No online favicon service, because the source icons belong to the sites and uploading them somewhere for conversion defeats the point. The pipeline:

Render the source SVG in a headless browser with a transparent background, at each target size. This respects whatever the SVG actually draws, which matters for icons with effects that naive rasterizers mangle.
Use Pillow to pack 16, 32, and 48 pixel frames into a single multi-resolution .ico.
Save a 180 by 180 PNG as apple-touch-icon.png.
Add the tag block to the HTML head of every page template.

Then the checklist before calling it done: /favicon.ico returns 200 with an image content type, apple-touch-icon.png exists, and the sizes declared in the HTML match the actual pixel dimensions of the files. That last one is sneaky. I found two sites declaring sizes="32x32" on a file that was actually 48 pixels square. Browsers mostly cope, but a checker that compares declared versus actual will flag it, and the fix is a one-line attribute edit.

The five minute version for your own sites

If you want to audit your own setup without building anything, run through this:

curl -I https://yoursite.example/favicon.ico and look for 200 plus an image content type, not text/html
Check that /apple-touch-icon.png exists and is 180 by 180
Compare the sizes attributes in your head against the real dimensions of the files they point to
If you use a CDN, remember it may cache your 404s the same way it caches your assets

Or point a checker at it. I eventually wired the probe logic into a free favicon checker that runs the whole battery in one go: the direct /favicon.ico request, every declared icon, the apple-touch-icon, format sniffing, and declared versus actual dimensions. It runs server-side probes only, no account, and it is how the ten-versus-zero result above got measured. For a deeper reference on sizes, formats, and which tags to use, the favicon best practices guide on the same site covers the long version.

The humbling part of shipping an auditing tool is that it audits you first. All ten of my sites failed a check I had just written the logic for. The icons took an afternoon to fix. The Cloudflare cache lesson would have taken much longer to debug in production, and that one I only hit because the checker kept retesting instead of trusting my deploy script's success message.

Tools that re-verify from the outside are worth more than tools that report what you intended.

Four Java Bugs That Bad Indentation Hides in Plain Sight

lixy — Thu, 27 Aug 2026 22:45:59 +0000

javac does not care what your code looks like. Whitespace carries zero meaning in the Java Language Specification, so the compiler reads your file as a stream of tokens and skips every space you typed. Fine for the machine. A problem for you, because indentation is the part of the code that talks to humans. When the layout says one thing and the braces say another, the reader trusts the layout, and the bug ships.

Here are four bugs I have either shipped, reviewed, or nearly missed. Every snippet compiles, and in every one the indentation is lying.

The extra semicolon that turns a condition into a no-op

java
if (cart.total() > FREE_SHIPPING_MIN);
applyFreeShipping(cart);
chargeCustomer(cart);
The layout says: carts above the threshold get free shipping. The semicolon right after the condition says otherwise. A lone semicolon is a complete, empty statement, so it becomes the entire if body, and applyFreeShipping runs for every order, threshold or not.

The same trap exists under for and while: for (Item item : items); is a loop that iterates over everything and does nothing, then the indented line below it runs once. Static analysis knows this pattern (SonarQube rule S1116, IDE inspections flag it), but only when someone runs it.

Fixed:

java
if (cart.total() > FREE_SHIPPING_MIN) {
applyFreeShipping(cart);
}
chargeCustomer(cart);

The dangling else that picks the wrong if

java
if (customer.isVip())
if (order.isGiftWrapped())
includeGiftCard(order);
else
chargeUpgradeFee(order);
Read it the way the indentation suggests: VIP orders get a gift card, everyone else pays an upgrade fee. Java binds else to the nearest if, so the fee is actually charged to VIP customers whose order has no gift wrap. Non-VIP customers never reach the else at all.

java
if (customer.isVip()) {
if (order.isGiftWrapped()) {
includeGiftCard(order);
} else {
chargeUpgradeFee(order);
}
}
Same tokens, different program. Braces settle ownership of the else. Indentation never can.

The closing brace that ends the block one line early

java
if (!response.isOk()) {
log.warn("bad response, will retry");
}
retry(request);
This reads as "log and retry on failure", but the brace after the log line already closed the if. retry runs on every request, success or not. The only thing claiming it is conditional is the indentation, and indentation has no vote.

This one shows up after refactors: someone deletes a line, the closing brace lands one row too high, and nobody re-formats the block. With the brace parked at the right margin and the layout untouched, code review walks right past it.

java
if (!response.isOk()) {
log.warn("bad response, will retry");
retry(request);
}

The unbraced guard chain, a.k.a. the goto fail shape

java
if (session == null)
return false;
if (!session.signatureValid())
return false;
revokeSession(session.userId());
return grantAccess(session);
Every line under the guards looks like part of the chain. Only the first two are. revokeSession belongs to no if at all, so it runs on every login attempt, including successful ones, right before access is granted. When the session is null it does not just run pointlessly, it throws.

The shape has a famous ancestor: CVE-2014-1266, the Apple goto fail bug. One duplicated line under an unbraced if chain in C skipped certificate verification on every SSL connection in iOS for over a year. Different language, same mechanism: unbraced guards plus a little drift equals a security bug that compiles.

java
if (session == null) {
return false;
}
if (!session.signatureValid()) {
revokeSession(session.userId());
return false;
}
return grantAccess(session);
Why Java puts up with this
Python made indentation part of the syntax, so the layout cannot lie. Java moved all structure into braces and semicolons and left the layout as free space. The trade is that you can format code any way you like, including ways that mislead. Indentation ends up working like a comment written in whitespace, and comments rot.

Let a machine own the layout
The fix for all four bugs is not reading harder. People read less carefully under deadline, not more. The fix is giving ownership of layout to a formatter so no human re-indents by hand and drift cannot survive:

Format on save: IntelliJ save actions, or format on save in VS Code. The file stays in canonical shape, so a misplaced brace becomes visible immediately.
Enforce it in CI: Spotless, Checkstyle, or fmt-maven-plugin failing the build. Drift stops at the pull request instead of production.
Quick one-offs: for a snippet from a code review or a machine without your IDE configured, paste it into JavaFmt, a free online Java formatter. It runs in the browser, code never leaves the tab, and it applies the classic four-space conventions.
If you want the longer background: does indentation matter in Java covers why teams standardize at all, and Java line wrapping rules covers the part of the layout that formatters still argue about.

Three habits, in order of impact: always brace single statements, format on save, fail the build on drift. The compiler will never care about your indentation. Make something that does.