Status: Mildly traumatized, slightly caffeinated, dangerously sarcastic
Primary Bug Suspect: Math
This is where its begin: Building a Web-Based Clocking System: A 48-Hour Sprint (and a Latte or Two)
🍿 Act I: The Chaos Begins – When 2 + 2 = Lawsuit
In a world where time is money and money is tracked in hours, one system decided to make up its own math.
Enter: Our ClockIn System. The supposed savior of shift tracking. The digital guardian of fair pay. The absolute rebel who decided that buffers are for weaklings and overtime math is… optional?
It all started innocently enough. A routine check. A coffee. A wild discovery:
Mohammad Tarmizi clocks out after a 10h 11m shift.
Expected overtime (with a 1h buffer): 1h 11m.
System output: 2h 11m.
Our collective reaction: 🧍♂️💀
I stared at my screens, as confused as a cat watching a cucumber. How did I —builders of logic, masters of conditionals—end up with arithmetic that wouldn’t pass kindergarten?
🔍 Act II: The Investigation – Starring Confusion, Denial, and Regret
I launched a full-blown CSI: ClockIn edition. Digital magnifying glasses out. SQL gloves on.
The Suspects:
-
The Phantom Setting
-
The server asked the database for
overtime_buffer_hours
. -
The database responded like it was on vacation: “Never heard of her.”
// Server: “Hey DB, what’s the buffer?”
// DB: “Buffer? That some kind of cheese?”
// Server: “I guess I’ll just YOLO this math then.”
-
-
The Frontend Uprising
-
Instead of using the already-calculated overtime from the database, the frontend whipped out a calculator and went, “Pfft, I’ll do it myself.”
// Database: “Here’s 1.18h of OT.”
// Frontend: “Nah, 10.18 – 8 = 2.18. I’ve got vibes.”
// Users: “Why does this feel like gaslighting?”
-
-
The Historical Time Bombs
-
Past records were corrupted with bad overtime logic, sitting quietly like bugs in Jurassic Park, waiting to strike.
-
🛠️ Act III: The Fix – Math Therapy, Database Reconciliation, and a Frontend Intervention
I split the fix into three tactical phases. Think of it like an RPG raid, but for nerds.
⚔️ Phase 1: Talking Sense Into the Database
INSERT INTO settings (setting_key, setting_value, category, description)
VALUES ('overtime_buffer_hours', '1.0', 'notifications', 'Hours after shift end to start calculating overtime')
ON DUPLICATE KEY UPDATE setting_value = '1.0';
— Database: “Ohh, that buffer! My bad, boss.”
I gave the database what it always needed but never asked for: purpose.
🧠 Phase 2: Reprogramming the Frontend’s Ego
The frontend was living its best life with DIY math until I forced it to humble itself.
// BEFORE
const calculateOvertime = (record) => {
return Math.max(0, actualHours - scheduledHours); // “I am the math now.”
};
// AFTER
const calculateOvertime = (record) => {
if (record.overtime_hours !== null && record.overtime_hours !== undefined) {
return parseFloat(record.overtime_hours) || 0;
}
return Math.max(0, actualHours - scheduledHours);
};
— Frontend: “Fine, I’ll ask the DB… just this once.”
🧼 Phase 3: Cleaning Up the Time Crimes of the Past
UPDATE attendance
SET overtime_hours = GREATEST(0, actual_hours - (scheduled_hours + 1.0))
WHERE overtime_hours > 0
AND is_reclock = 0
AND ABS(overtime_hours - GREATEST(0, actual_hours - (scheduled_hours + 1.0))) > 0.01;
— Database: “6 records updated. Order restored. Heroes applauded.”
🧾 Act IV: The Aftermath – Trust Restored, Bugs Banished
Let’s do a quick before-and-after:
Before | After | |
---|---|---|
Mohammad Tarmizi | 10.18h actual → 2.18h OT 😬 | 10.18h → 1.18h OT ✅ |
System Trust | “Can this thing count?” | “Okay, math checks out.” |
Developer Mood | 🥴 | 😌 |
😂 Act V: What We Learned (So We Can Pretend It Won’t Happen Again)
-
Don’t Assume Settings Exist
Just because you wrote it in the spec doesn’t mean your database got the memo. -
Frontend Should Stay in Its Lane
Calculating its own overtime like a kid trying to write their own report card. -
Old Data Is Like Leftovers
Ignore it long enough, and it might kill you.
📜 Bonus: A Peek at the Server-Side Logic
if (isReclockScenario) {
overtimeHours = Math.max(0, actualHours - scheduledHours); // No buffer here, just raw truth
} else {
overtimeHours = Math.max(0, actualHours - (scheduledHours + overtimeBufferHours));
}
Server-side logic: That quiet genius in the corner who actually read the documentation while the others were arguing on Slack.
🎉 The Deployment: Miraculously Drama-Free
What didn’t happen:
❌ Server crash
❌ User panic
❌ Midnight deployment pizza party
What did happen:
✅ SQL updates
✅ Frontend code hotfix
✅ Zabel casually sipping tea pretending this was always the plan
🏁 The Happy Ending: Math Finally Behaving
-
🟢 Overtime buffer: Working like a charm
-
🟢 Historical records: Fixed and squeaky clean
-
🟢 Trust from team and employees: Restored
-
🟡 Developer sanity: Slightly improved
-
🟠 Timekeeping: Now 98% less confusing
🎭 Epilogue: The Real Overtime Was the Bugs We Fixed Along the Way
This wasn’t just about fixing time tracking. It was about justice. About righting the wrongs of rogue JavaScript and neglected SQL settings. About making sure that every hardworking employee gets credited for exactly the time they deserve—no more, no less, no shenanigans.
So here’s to Mohammad Tarmizi, who unknowingly became the face of this revolution.
And here’s to you, dear reader—fighting the good fight against bugs, broken logic, and frontend drama.
Stay tuned. Next week I take on… “Why Tuesday Lunch Breaks Are 5 Minutes Longer Than They Should Be.” 😤🍽️