Claude Code gives every session a scratch folder under /private/tmp, and it is easy to think that this folder is where all of its leftovers live. It is the smallest part: more temporary files sit next to it, and the long-term record of every session stays in ~/.claude for a month by default.
For fifteen years the .env file has been the most convenient lie in web development: a plaintext file full of production-grade credentials, kept safe by the single assumption that only you would ever read your own disk. That assumption is now false, and the fix is less dramatic than it sounds.
The plugin built, packaged and published on the first try. I could not have explained the packaging step to anyone, and I shipped it anyway. After several months of building games, static sites, libraries and plugins with an artificial intelligence (AI) assistant doing most of the typing, that sentence is the whole story: producing code stopped being the hard part, and something else moved into its place.
When a coding agent writes most of the code, reading every diff stops being realistic, and "reading diagonally" — skimming — becomes the default. It is a real bet, not a safe one: architecture doesn't break in any single diff, it erodes across all of them, and skimming checks exactly the part that was never the problem.
Every strategy for surviving the flood of machine-written pull requests optimizes the same thing: catching bugs. The research on code review says catching bugs was never the job it was best at.
This article explores the growing significance of linguistic precision and thorough understanding of foundational knowledge in the context of AI and software development, highlighting the historical importance of clear communication in the field and the relevance of Agile methodologies in the AI era. It also outlines the skills needed to effectively work with AI and navigate the evolving landscape of web development and other tech-related fields.
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco is a well-regarded book in the field of management and organizational behavior first published in 2001.
DeMarco challenges the conventional wisdom that companies must maximize efficiency at all costs. He argues that an obsession with efficiency can lead to a work environment that lacks the slack necessary for innovation, flexibility, and the maintenance of employee well-being.
The book advocates for creating slack within organizations to allow for recovery, learning, and innovation. DeMarco suggests that by allowing some degree of slack, organizations can improve their adaptability, employee satisfaction, and ultimately, their long-term performance.
"Slack" is not just a critique of the relentless pursuit of efficiency but also a practical guide to creating a more humane and effective workplace. It's a must-read for managers and leaders who want to foster an environment where innovation and creativity can thrive, without sacrificing the well-being of their employees.
Tree shaking is a term used in the context of web development, particularly with JavaScript and modern front-end build tools, to describe the process of removing unused code from your final bundle. It's like shaking a tree to let the dead leaves (unused code) fall off, so you end up with a lighter, more efficient bundle that only includes the code that's actually used in your application.
This concept became particularly relevant with the rise of module bundlers like Webpack, Rollup, and tools like Parcel, which analyze your import and export statements to determine which parts of a module are used by your application. If a function, class, or variable from a module is never used, the bundler can exclude it from the output bundle, reducing the size of your application and improving load times for your users.
The Dependency Inversion Principle (DIP) is one of the five SOLID principles, and it plays an essential role in achieving maintainable and flexible code. It can be applied to frontend development, particularly when using technologies like React and Redux.
Most projects get a license by copying whatever the last project used. This post explains what the main licenses actually ask of people who use your code, how to choose one with three questions, and what the licenses of your dependencies ask of you.