We all have coding habits we would never recommend in a code review.
You know exactly what I'm talking about. It's the thing you do at 4:00 PM on...
For further actions, you may consider blocking this person and/or reporting abuse
Nice one, this is a fun topic!
Yeah,
console.logfor me too - and I'm not even ashamed to admit it, because in many scenarios it's just the easiest way to find out what's going on ...Funny how, with a 'synchronous' language like PHP, I love using the debugger - but with JS/TS, not really ...
And
!important, yeah that's also one of my sins - but I'm less proud of that, and would not generally recommend it when there's a better way! ;-)Haha welcome to the confession booth, Leob! 🙌 Your point about PHP vs JS/TS is fascinating, and honestly so true. Stepping through synchronous PHP code is a breeze, but the moment you introduce the JS event loop async/await, and callbacks, the debugger suddenly feels like navigating a maze blindfolded. console.log just feels safer and more predictable in JS!
And don't worry about the !important we've all committed that sin. At least you feel guilty about it, which means your CSS soul is still intact! 😂
Thanks for sharing your shortcuts!
Yeah the sync/async thing is why people aren't in love with using the JS/TS debugger - maybe there's a "proper" way to do it, but I haven't discovered it yet ...
you're not alone in that! The proper way to debug async JS feels like an urban legend for most of us.
The moment breakpoints start jumping between microtasks and the event loop, console.log is the only friend we have left. If you ever discover the magic secret, please let me know too! 😂
Right ... that being the case, I don't really understand why so many people keep hammering the point (in blog posts, etc):
"use the JS debugger, don't use console.log !"
I've never understood that - does not seem rooted in reality ...
You are 100% right. I think the use the debugger not console.log advice comes from an era of simpler, synchronous codebases.
In a modern app with layers of async/await promises and React re-renders, pausing the debugger often breaks the very timing issue you're trying to catch. console.log doesn't block the event loop. It's basically non-blocking telemetry for our brains.
The debugger-only purists need to try stepping through a complex async race condition and see how long they last before going back to console.log. 😂 It's not a shortcut, it's just the right tool for modern JS!
The most expensive "temporary" shortcut I routinely see in post-mortems is the raw synchronous polling loop or unbounded in-memory hashmap duct-taped together to bypass standing up a proper state machine or message broker. When teams slap a 100ms
while(true)poll across 50 container instances to avoid integrating webhook or event drivers, the infrastructure tax hits immediately: 35–45% of cluster CPU cycles wasted purely on idle context switching, connection pool starvation, and p99 tail latencies spiking from a clean 8ms to over 220ms under baseline load.Replacing those hacky spin-locks with kernel-level primitives (
epoll/eventfd), Unix domain sockets, or an ultra-low-footprint broker like NATS drops background CPU burn to near-zero while keeping memory allocations deterministic. We’ve all bypassed architectural standards to beat a launch deadline—what’s the dirtiest duct-tape solution you quietly slipped past code review, and what operational trade-off did your production fleet pay for it later?Bohdan Hordii // bohdanhordii.dev
Bohdan this gave me anxiety just reading it A 100ms while(true) poll across 50 containers is a special kind of evil. Watching p99 latency spike from 8ms to 220ms must have been a terrifying PagerDuty alert. And you're right hacking around a message broker always ends up costing 10x more in infra bills than just setting up NATS would have.
To answer your question: my worst production duct-tape wasn't at the kernel level. It was an unbounded SELECT on a table that we assumed would stay small. I bypassed pagination on an admin dashboard because it's only 10,000 rows right now we'll fix it later. Two months later, that table had 2 million rows, and the database CPU hit 100% every time someone opened the page. The trade-off? A weekend of emergency indexing and rewriting the query while the site was on fire.
It always starts with we'll fix it later doesn't it? Thanks for sharing this war story, it makes my SQL mistake feel a bit less lonely!