DEV Community: Abhishek Singh

I built a dataset of 50,000 debugging sessions — and what I found surprised me

Abhishek Singh — Sat, 27 Jun 2026 15:30:30 +0000

Most bug datasets only tell you: "Bug was fixed in 23 minutes."

They don't tell you what happened during those 23 minutes.

So I built one that does.

What is DebugTraj-50K?

It is a dataset of 50,000 developer debugging sessions with 665,364 step-by-step behavioral events recorded across 8 programming languages and 71 error types.

Every session captures what a developer actually did while fixing a bug:

How many times they searched Google
How many compile attempts they made
Which files they opened
Whether they used an AI tool
Whether they asked a colleague
What strategy finally worked
And whether they succeeded or gave up

This is not a dataset about bugs. It is a dataset about human behavior under pressure.

Who is this useful for?

AI researchers and companies
Tools like GitHub Copilot and Cursor need behavioral data to train models that understand how developers think — not just how code looks. This dataset fills that gap.

ML practitioners
You can build models to predict:

Will this debugging session succeed?
How long will it take?
What will the developer do next?

CS educators
See exactly where students struggle, how long they take, and what makes senior developers faster.

DevTool companies
Understand real developer pain points when building IDEs, debuggers, and productivity tools.

Individual developers
Compare your own debugging habits with 50,000 others.

The Daily Coding Companion

On top of the dataset I built a practical notebook called the Daily Coding Companion.

It answers questions every developer asks themselves while debugging:

How long will MY bug take to fix?
Am I taking too long compared to my peers?
What should I try next when I am stuck?
When should I stop and ask for help?
Which language is actually hardest to debug?

You just fill in your language, your error type, and how long you have been stuck — and it gives you answers based on real data from 50,000 sessions.

No ML knowledge needed.

# Example: estimate fix time for your current bug
my_language   = 'Python'
my_experience = 'Mid-level (2-5 years)'
my_severity   = 3

similar = sessions[
    (sessions['programming_language'] == my_language) &
    (sessions['experience_level']     == my_experience) &
    (sessions['error_severity']       == my_severity)
]

print(f"Expected fix time : {similar['resolution_time_minutes'].mean():.0f} minutes")
print(f"Chance of fixing  : {(similar['outcome']=='fixed').mean()*100:.1f}%")

Key findings from the data

Senior developers fix bugs 3.7x faster than junior developers on average
Rust and C++ take 1.5x longer to debug than Python or JavaScript
Sessions where developers took a break had a higher fix rate
AI tool usage is highest among mid-level developers, not juniors
After 8+ searches and 12+ compile attempts, asking a colleague increases fix rate significantly

Links

Dataset: https://www.kaggle.com/datasets/abhisheksingh016/debugtraj-50k

Daily Coding Companion notebook: https://www.kaggle.com/code/abhisheksingh016/daily-coding-companion

Both are free and open under CC BY 4.0.

If you find it useful, an upvote on Kaggle goes a long way. And if you build something with this dataset, I would love to see it in the comments.

How Datacenters Actually Work: A Walk Through the Building Nobody Sees

Abhishek Singh — Mon, 08 Jun 2026 10:04:24 +0000

"Every server you spin up on AWS, Vercel, or DigitalOcean lives in a physical building. Here's what that building actually looks like — from the power substation to the GPU rack."

How Datacenters Actually Work: A Walk Through the Building Nobody Sees

"The cloud is just someone else's computer" — but nobody tells you it's a $2 billion building with 50 megawatts of power, a lake's worth of cooling water, and security that makes airports look casual.

The Building You Never See

I deployed my first website in 2019. I typed git push, Vercel said "Done," and I felt like a wizard. Three years later while reading Data Engineering I realized: I had no idea where my code actually ran.

This article is what I wish I'd known. A walk through the physical architecture of modern computing — the building, the power, the cooling, the network, the server. No marketing. No fluff. Just what actually happens when you type curl https://api.example.com.

1. The Substation: Where Electrons Enter

Before your request touches a server, it touches a substation.

A hyperscaler datacenter pulls 50–100 megawatts — enough for 40,000 homes. No standard grid connection handles that. The utility builds a dedicated substation on-site, stepping down 115kV transmission lines to 13.8kV distribution.

Why this matters to you: That substation is your first single point of failure. If it goes down, everything goes down. Redundancy starts here: dual substations, dual feeds, automatic transfer switches.

Key number: A 100MW datacenter uses ~$50M/year in electricity alone. At 10 cents/kWh, that's 500 million kilowatt-hours. The power bill is the largest operating cost — bigger than staff, bigger than servers.

2. The UPS Room: The 10-Second Bridge

Electricity doesn't flow directly from substation to server. It passes through UPS — Uninterruptible Power Supply.

The UPS does two things:

Condition power: smooths voltage spikes, frequency drift, harmonic distortion
Bridge outages: when grid power fails, the UPS instantaneously switches to battery — no interruption, zero milliseconds The battery room is massive. Think hundreds of lead-acid or lithium-ion racks, each the size of a refrigerator. They provide 5–15 minutes of runtime. Not hours. Minutes. Just enough for the generators to spin up.

Key insight: UPS batteries are the most replaced component in a datacenter. They degrade, they swell, they fail. A facility manager once told me: "I don't sleep through thunderstorms. I sleep through battery replacement schedules."

3. The Generators: Diesel and Doubt

When the UPS battery hits 50%, the generators start.

Diesel generators, typically 2–3 megawatts each, housed in sound-attenuated enclosures outside the main building. A 50MW facility might have 20+ generators. N+1 redundancy: if you need 10, you install 11.

The catch: Generators don't start instantly. There's a 10–15 second gap between grid failure and full generator power. The UPS covers this gap. The generators cover everything after.

The dirty secret: Most datacenters test generators monthly but rarely test the full chain — grid → UPS → battery → generator → transfer → server. The 2021 OVHcloud fire in Strasbourg started when a generator transfer failed during maintenance. The building burned. 3.6 million websites went offline.

4. The Cooling: The Real Cloud

Here's the number that shocked me: for every 1 watt of compute, a datacenter spends 0.3–0.6 watts on cooling.

Your server generates heat. A lot of heat. A single NVIDIA H100 GPU draws 700 watts and converts almost all of it to heat. Rack 40 of them — 28 kilowatts per rack. Stand next to that rack and it's a furnace.

How cooling works:

Step 1: Hot aisle / cold aisle containment

Server racks face each other in pairs
Cold air blows up through perforated floor tiles
Hot air exits the back, captured by overhead ducts
Never mix. Mixing wastes energy.

Step 2: CRAC/CRAH units

Computer Room Air Conditioners (refrigerant-based) or
Computer Room Air Handlers (water-based, more efficient)
These push chilled air under the raised floor

Step 3: The chiller plant

Industrial chillers cool water to 7–10°C
Water circulates to CRAH units, absorbs heat, returns warm
Cooling towers reject heat to the outside air

Advanced: Liquid cooling

Direct-to-chip: cold plates on CPUs/GPUs
Immersion: servers submerged in dielectric fluid
AI training clusters (100k+ GPUs) require this — air can't handle the density

Key number: Google's datacenters use 1.1 PUE (Power Usage Effectiveness). Meaning: for every 1 watt to servers, 0.1 watt to everything else. The industry average is 1.5. Older facilities hit 2.0. That difference is millions in annual power bills.

5. The Raised Floor: Architecture Beneath Architecture

Walk into a datacenter and you step onto a raised floor — typically 24–48 inches above the concrete slab.

Under that floor: a plenum. Chilled air flows through it. Cables run through it. Power feeds through it. The floor tiles are removable steel, perforated where air needs to rise, solid where cables cross.

Why raised?

Air distribution: uniform cooling across the room
Cable management: power and network underfoot, not overhead
Flexibility: reconfigure cooling and cabling without structural changes

The trend: Hyperscalers are moving to slab floors with overhead cooling. Hot air rises — capture it at the top. No raised floor means higher ceilings, more rack density, less construction cost. But retrofitting an old facility? Nearly impossible.

6. The Rack: Where Your Server Lives

Finally, the server. But first, the rack.

Standard rack: 42U height, 19 inches wide, 36 inches deep. "U" = 1.75 inches. A 1U server is a pizza box. A 4U server is a tower on its side.

Power per rack evolution:

2010: 3–5 kW (typical web server)
2015: 8–10 kW (virtualization density)
2020: 15–20 kW (GPU acceleration)
2025: 30–50 kW (AI training clusters)

At 50 kW per rack, you're at the limit of air cooling. Liquid cooling becomes mandatory.

What lives in the rack:

Servers: compute. 1U, 2U, 4U form factors.
Storage: disk arrays, SSD shelves, NVMe enclosures.
Network: top-of-rack switches, patch panels, fiber trays.
Power: rack PDUs (Power Distribution Units), circuit breakers.

The network topology: Top-of-rack (ToR) switch connects all servers in the rack. Multiple ToR switches connect to end-of-row (EoR) aggregation. EoR connects to core routers. Core connects to the outside world.

Latency reality: A packet from your server to the internet passes through: NIC → server bus → ToR switch → EoR switch → core router → border router → ISP. Each hop adds microseconds. In a hyperscaler, total internal latency is <100 microseconds. The speed of light through fiber is the real limit.

7. The Server: The Computer You Actually Rent

Open a cloud server. What do you see? A virtual machine. An abstraction. But physically, it's this:

The motherboard:

2x Intel Xeon or AMD EPYC CPUs (64–128 cores each)
1–2 TB of DDR5 RAM
8–24 NVMe SSDs (or direct-attached storage)
2x 25G/100G NICs (Network Interface Cards)

The GPU (if AI/ML):

NVIDIA H100, H200, or B200
80–192 GB HBM3 memory
700W–1200W power draw
Connected via NVLink (GPU-to-GPU) or InfiniBand (rack-to-rack)

The BMC: Baseboard Management Controller. A separate computer inside your computer. Even when "off," the BMC runs. It monitors temperature, power, fan speed. It provides remote console access (IPMI/iDRAC/iLO). It's also a security nightmare — compromised BMCs have been used to persist across OS reinstalls.

The firmware: BIOS/UEFI, then bootloader, then hypervisor (KVM/Xen), then your VM. Each layer is an attack surface. Each layer adds boot time. A physical server takes 3–5 minutes to boot. A VM takes 30 seconds. A container takes 3 seconds. A serverless function takes 300 milliseconds. The trend is clear: less of the physical stack, faster the start.

8. The Security Layer: Beyond Biometrics

Datacenter security is layered:

Perimeter: Fences, bollards, cameras, guards. Vehicle traps to stop ramming attacks.

Building: Mantraps (two-door airlocks), badge readers, biometric scanners (fingerprint + iris). No tailgating.

Floor: Cage enclosures for colocation customers. Your rack in someone else's building, locked in a metal cage.

Rack: Biometric locks on individual cabinets for high-security workloads.

Logical: Network segmentation, VLANs, zero-trust architecture. The physical security is the last line, not the first.

The insider threat: Most datacenter breaches involve contractors — cleaning staff, HVAC technicians, network installers with temporary badge access. The person who knows the building's layout is more dangerous than the hacker in another country.

9. The Software Layer: What Actually Runs

Physical is only half the story. The software that manages a datacenter is its own architecture:

DCIM: Data Center Infrastructure Management. Monitors power, cooling, space, capacity. Predicts when you'll run out of power before you run out of rack space.

BMS: Building Management System. Controls HVAC, fire suppression, access control. Integrates with DCIM.

Cloud orchestration: Kubernetes, OpenStack, VMware vSphere. Abstracts the physical into virtual resources.

Network SDN: Software-Defined Networking. Routes traffic programmatically. Replaces physical router configuration with API calls.

The irony: The most physical place in computing is managed by the most abstract software. A technician might never touch a server — everything is provisioned, monitored, and repaired remotely.

10. The Economics: Why Location Matters

Datacenters cluster in specific places for specific reasons:

Location	Advantage	Example
Northern Virginia	Proximity to DC, dense fiber, tax incentives	AWS us-east-1, the largest cloud region
Iowa/Oregon	Cheap land, cool climate, renewable energy	Google, Facebook, Microsoft campuses
Singapore	Asian gateway, submarine cable hub	Equinix, Digital Realty
Mumbai/Chennai	Indian market growth, coastal cooling	Jio, ST Telemedia, CtrlS
Iceland/Norway	Free cooling, geothermal/hydro power, low latency to Europe	Verne Global, Green Mountain

Latency vs. cost tradeoff: A request from Mumbai to us-east-1 takes 180ms. To ap-south-1 (Mumbai): 5ms. But Mumbai costs 20% more per watt due to cooling and power challenges. Every architecture decision is a geography decision.

The Walkthrough Ends, The Awareness Stays

I started this article saying I felt like a wizard pushing code to "the cloud." I end it knowing the cloud is a building. A building with a substation, a battery room, a chiller plant, a raised floor, and a rack with a server that has a BMC with a firmware that might have a vulnerability I'm not patching because I don't even know it exists.

The physical doesn't disappear because we abstract it. It becomes invisible, then dangerous. The OVHcloud fire, the AWS us-east-1 outages, the Equinix BGP leaks — all physical failures wearing digital masks.

Understanding the building beneath your bytes doesn't make you a facilities engineer. It makes you a better architect. Because the best distributed system is the one that knows it's distributed across buildings with different power grids, different flood risks, and different humans walking the floor at 3 AM.

Further reading:

Why India Builds Datacenters Differently: The Architecture of Tropical Computing — how 45°C heat, monsoon humidity, and unreliable grids force completely different engineering decisions
Uptime Institute's Annual Outage Analysis
Google's PUE Data

What surprised you most about physical infrastructure? Drop a comment

I built ZeroAPI — free AI tools for developers, no API key, no signup, ever

Abhishek Singh — Sun, 07 Jun 2026 09:55:22 +0000

I'm a CS professor from India. Between teaching, research, and writing books on KDP, I built ZeroAPI — https://zeroapi.in - a free AI tools platform for developers and students.

The whole thing started because I kept watching my B.Tech students struggle to access AI tools. ChatGPT API costs money. Most tools want a signup. Students in Tier 2/3 cities in India don't always have a credit card. So I built something with a hard rule: zero API key, zero signup, zero data storage. Ever.
What ZeroAPI does

Six tools, all free, all instant:

🎤 Mock Interview Simulator — Pick a role (SDE, Data Analyst, ML Engineer), difficulty, and get AI-generated questions with feedback on your answers. Good for cracking campus placements.

📋 Resume Analyzer — Paste your resume, get ATS score, strengths, weaknesses, and a section-by-section rewrite suggestion.

📄 Resume Builder — Guided wizard that outputs a clean, ATS-optimized resume. No templates to pay for.

⚡ Code Explainer — Paste any code snippet (Python, C++, SQL, JS) and get a plain-English breakdown. Great for reading unfamiliar codebases.

🔬 Research Summarizer — Paste an abstract or full paper. Get structured summary: problem, methodology, findings, limitations, gaps.

❓ MCQ Generator — Enter any topic, difficulty, and count. Generates exam-ready multiple choice questions instantly. Used by teachers and GATE/placement aspirants.

The Learn section

Beyond tools, ZeroAPI has a Learn section — technical articles written for developers and job seekers. Things like:

How Agentic AI Actually Works (with Python)
50 Python Interview Questions for 2026
System Design Interview Patterns
CUDA GPU Programming Deep Dive

and many such articles. Each article links directly to the relevant tool so you can practice immediately after reading.

The Roadmaps section
ZeroAPI also has structured learning roadmaps — interactive knowledge graphs with phase-by-phase learning paths, skill assessments to skip what you already know, topic checkboxes to track progress, and curated resources per phase.
Roadmaps for: Full Stack, Data Science, ML, DevOps, Cybersecurity, and more.

The BreakIt section

My favourite part: BreakIt — a debug challenge arena where you fix deliberately broken code.
Real bugs. Real explanations. No toy puzzles.
Examples:

The Silent Data Killer — dropna() silently removes valid rows. Your revenue is wrong but looks right.
The Accuracy Trap — You reported training accuracy. Your ML model is useless in production.
The Empty Set Trap — NOT IN with a subquery containing NULLs returns zero rows silently.
Floating-Point FinTech Flaw — Binary floats can't represent 0.1 accurately. Your audit fails.
Mutable Default Disaster — Using [] as a default argument creates shared state across calls.

Each challenge has: broken code → hint system (reveal one at a time) → solution → explanation → lesson. Categories cover Python, ML, SQL, JavaScript, Systems/C++.

The stack

React + Vite frontend, deployed on Vercel
Groq (llama-3.3-70b-versatile) as AI backend — chosen for speed
Serverless Vercel API routes as proxy (API key never exposed to client)
Upstash Redis for article view telemetry and blog reactions
Pure JS arrays for the blog/challenge data (no CMS, no database for content)
No ads. No tracking. No dark patterns.

What I'm looking for

Honest feedback on:

Which tool do you find most useful?
What's missing that you'd actually use?
Any bugs you find in the BreakIt challenges (meta, I know)
The platform is actively being developed. Roadmaps and BreakIt are the newest additions.

→ zeroapi.in
Built by Prof. Abhishek Singh — CS professor, KDP author, and builder of things. Also runs @pyofpython on YouTube.
If this is useful to even one developer who couldn't afford API credits, it's worth it.