Debugging with print() vs. Debuggers

𝐈 𝐛𝐮𝐢𝐥𝐭 𝐚 𝐂 𝐝𝐞𝐛𝐮𝐠𝐠𝐞𝐫 𝐟𝐫𝐨𝐦 𝐬𝐜𝐫𝐚𝐭𝐜𝐡 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐈 𝐝𝐢𝐝𝐧'𝐭 𝐥𝐢𝐤𝐞 𝐕𝐒𝐂𝐨𝐝𝐞'𝐬. In CS 137, I wanted to really understand how the stack and heap work in C. Not just conceptually, but by watching memory change as my code runs. VSCode's debugger wasn't cutting it for me, so I built my own tool from scratch and also used this as an excuse to learn Rust. CRusTTY is a C interpreter written 100% in Rust with a terminal UI that lets you: - Step forward and backward through your code - Watch the stack and heap update in real time - Catch memory bugs like use-after-free, null pointer dereferences, and buffer overruns as they happen It supports a solid subset of C: structs, pointers, pointer arithmetic, malloc/free, recursion, and more. The whole thing runs in your native terminal with no setup required. Building this taught me more about C's memory model than any lecture could... Sorry Victoria! Turns out the best way to understand how something works is to implement it yourself. MIT licensed and open source! github.com/aicheye/crustty #C #Rust #SystemsProgramming #ComputerScience #OpenSource

Debugging doesn’t start in the debugger. It starts in your head. When something breaks, most developers do this: jump to logs → scan random code → guess. That’s why debugging feels slow. This is the actual order I follow while debugging C++ or managed applications: • First, reproduce the issue reliably • Then, understand what changed, not what failed • Question every assumption you’re making • Narrow down execution paths aggressively • Only then look for the root cause Tools don’t fix bugs. Clear thinking does. Once you control the scope, most bugs become boring. And boring bugs are easy to fix. This mindset matters far more than knowing any specific debugger shortcut. Agree or disagree? #SoftwareEngineering #Debugging #Cpp #DeveloperMindset

💥 Debugging Taught Me More Than Coding Ever Did As a developer, I used to think learning new libraries would make me better. But debugging made me dangerous. Here’s what debugging taught me: • Reading stack traces calmly • Understanding lifecycle deeply • Spotting memory leaks • Handling nulls properly • Thinking about edge cases • Not trusting “It works on my device” Real growth happened when I stopped copy-pasting from StackOverflow and started asking: 👉 Why is this happening? Debugging builds problem-solving muscle. And problem-solving > syntax knowledge. #AndroidDevelopment #Kotlin #Debugging #SoftwareEngineering

Build and test Langflow components directly in VS Code A community-built VS Code extension makes it possible to edit Langflow component code, sync changes back to your local instance, and run flows, all without leaving your IDE. With this extension, developers can: - Browse Langflow projects and flows inside VS Code - Open and edit component Python code - Save and sync changes back to Langflow - Execute flows via API and stream outputs in real time Designed for developers who want a tighter feedback loop when working on custom Langflow components, especially alongside AI-assisted coding tools. Built by Samuel Matioli 👏 🔗 VS Code Marketplace https://lnkd.in/dcKzFYAb 🎥 Demo https://lnkd.in/dwgHVNwz

The Systems Mindset in a High-Level World Why Under-the-Hood Knowledge Matters (Even in JavaScript) Lately, I've been diving deep into Rust, Assembly, and Kernel architecture. To some, it might seem counterintuitive to focus on the "metal" when so much of the world runs on high-level languages like JavaScript. But as I explore the V8 Engine, I’ve realized that the most "magical" parts of modern software are just pure, beautiful systems engineering. Understanding how V8 works has changed how I view performance: JIT Compilation: Seeing how the Ignition interpreter and TurboFan compiler transform dynamic code into optimized machine code in real-time. Memory Management: Beyond just "writing code," it’s about understanding the Garbage Collector’s cycles to prevent memory leaks and the "leaky pipes" of the software world. Optimizing the Path: Knowing that when a system hits a bottleneck, we have the power to bridge the gap using Rust via WebAssembly or Node-API to achieve near-native speeds. My takeaway? Whether you are using a "manual" wrench or an "automatic" power tool, the goal is the same: building an architecture that is stable, efficient, and leak-proof. I’m excited to keep bridging the gap between high-level flexibility and low-level precision. #SoftwareArchitecture #V8Engine #SystemsProgramming #RustLang #JavaScript #BackendEngineering #KernelMindset

Debugging FastAPI Applications in VS Code: A Complete Guide Ever set a breakpoint in VS Code, run your FastAPI app with uvicorn, hit the endpoint… and nothing happens? You’re not alone—and the fix is simpler than you think. The core issue: When you start your FastAPI server from the terminal, VS Code’s debugger isn’t attached to the process. Your breakpoints exist only in the editor, not in the running app. ✅ The solution: Launch your FastAPI app through VS Code’s debugger using a proper launch.json configuration. Once you do that, breakpoints, step-through execution, variable inspection, and all debugging tools work flawlessly. What this guide covers: Why breakpoints don’t trigger when using terminal-run uvicorn How to configure launch.json correctly for FastAPI Running and debugging with debugpy + uvicorn Laptop-friendly debugging shortcuts (Fn keys included) Step Into vs Step Over (and when to use each) Common debugging pitfalls and how to fix them Result: Set up your debugger once, and you’ll never struggle with “breakpoint not hit” issues again. Debugging FastAPI becomes predictable, fast, and frustration-free. If you’re building APIs with FastAPI and VS Code, this setup is a must-have in your workflow. Happy debugging! Read more with setup guide : https://lnkd.in/dfgqJVMs #FastAPI #Python #VSCode #Debugging #BackendDevelopment #APIDevelopment #WebDevelopment #SoftwareEngineering #PythonDevelopers #Uvicorn #DeveloperTips #Programming #CodingLife #TechGuide #LearnPython #DevTools #EngineeringBestPractices #SoftwareDevelopment #DebuggingTips

Struggling with weird outputs in your C programs? 😩 Missing semicolons, format mismatches, array overflows—these common pitfalls ruin output of c program examples and frustrate beginners. My latest blog breaks down 6 top mistakes with real code snippets, buggy outputs, and easy fixes. Debug faster and code confidently! 🔗 Read full guide: https://lnkd.in/gEXUQqg8 #CProgramming #LearnC #ProgrammingTips #Debugging #CodeNewbie #TechBlog #SoftwareDevelopment #CPrograms #analyticsjobs

Day 2 — Debug story EngiDock doesn’t use a full CI pipeline yet. Deployments are script-based. This week, I hit an issue that changed my thinking. No code changes. Fresh install. App broke. Root cause? A Python dependency wasn’t pinned. Pip pulled a newer version. Behavior changed. That’s when it hit me: Without CI, every deployment is slightly different. What CI would solve here • Reproducible build environment • Automated dependency validation • Pre-deploy testing • Early failure detection • Consistent Docker image builds • Version-locked artifacts Right now, installs depend on the current state of PyPI. That’s risk. What I did immediately • Locked exact dependency versions • Documented environment setup • Standardized deployment steps What’s next Setting up a lightweight CI pipeline: Build validation Dependency check Basic test stage Automated image creation Lesson You don’t realize the importance of CI until something breaks without you touching the code. EngiDock is teaching me: manual deployments work — until they don’t. More real engineering notes coming.

Every Bolt.new user hits the same wall eventually. Bolt makes a fix. The fix breaks something else. You prompt again. Bolt fixes the new thing and re-breaks the original. Three iterations later, you're further from working code than when you started. The instinct is to keep prompting. That's the wrong move. The context is already polluted with conflicting attempts — more prompts deepen the problem. The fix is stepping outside Bolt entirely. Paste the error, the relevant files, and critically — what Bolt has already tried — into Claude.ai for a fresh diagnosis. Claude reads it as a debugging trace, identifies the root cause, and gives you a minimal fix to bring back to Bolt as a scoped instruction. Bolt builds. Claude diagnoses. Neither is sufficient alone for complex projects. Full workflow → https://lnkd.in/gjyzCxpy

Claude Opus 4.6 turned one terminal session into a 4-person engineering team. I shipped a full Python repo (CLI tool, tests, docs, structured output) without writing a single line of code manually. Here's what happened in the video: I started from an empty folder in Windows PowerShell 7, opened Claude Code, and defined a set of subagents: RepoArchitect, ParserEngineer, TestWriter, DocsWriter. First, a structured task list got created automatically. Then work was delegated in parallel to those subagents. Claude generated the full project: a Python CLI that turns messy meeting notes into a clean action tracker (action_items.md) plus a machine-readable export (actions.json). Finally, it ran the tests (pytest), fixed issues on its own, and polished the README so the repo was actually shareable. Project: Actionize. "Meeting Notes to Action Tracker" Input: a deliberately chaotic meeting_notes.txt with mixed owners, weird date formats like "next Fri", priorities like P0/P1, and broken lines. Output: deterministic, stable ordering grouped by owner/due date in Markdown + structured JSON for automation. Unit tests + docs included, so it's more than a demo. It's a repeatable workflow. The biggest takeaway for me: Opus 4.6 isn't just "better answers." It's better execution. Subagents + tasking make the build process feel like a lightweight engineering team operating in one terminal session. #ClaudeAI #AIEngineering #DeveloperTools #BuildInPublic