Spoofing the camera in Google Meet Zoom Teams and more restyvod restyvod restyvod Follow Oct 25 ## Spoofing the camera in Google Meet Zoom Teams and more #showdev #javascript #webdev 1 reaction Add Comment 14 min read

I built a system design app that teaches why and helps you in interviews Santosh Ravi Teja Goteti Santosh Ravi Teja Goteti Santosh Ravi Teja Goteti Follow Oct 6 ## I built a system design app that teaches why and helps you in interviews #showdev #systemdesign #webdev #ai 1 reaction 1 comment 6 min read

Netflix has ordered a second season of limited series The Beast In Me, with Claire Danes back reprising her Emmy-nominated role and exec producing.

The show keeps up its string of early pickups, with the latest coming soon after the fourth season finale.

I wanted AI to work directly with a real Xbox. Not just generate code on a PC. I wanted the same...

Most RAG demos stop at the answer.Alchimista You upload a document, ask a question, get a plausible...

YouTube video by PEDESTRIAN TV

version 0.01 of mochi. laughable i know, but he's so cute! I've been building a little green...

YouTube video by Peacock

YouTube video by Peacock

Last week my AWS bill hit $300. I knew there was waste hiding somewhere. Forgotten EBS volumes, idle...

🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖 ujja ujja ujja Follow Sep 5 ## 🚨📢Launching Docgrity 🚀: Documentation integrity for you, your team, and your agent friends. 🤖 #showdev #ai #documentation #opensource 11 reactions 1 comment 3 min read ujjavala.github.io ## GitHub - ujjavala/docgrity-vscode: Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. · GitHub Find contradictions, duplicates and open questions in your repo's markdown docs — and raise GitHub issues to fix them. Powered by your own Copilot subscription. - ujjavala/docgrity-vscode github.com producthunt.com

Introducing AI Disclosure on DEV: Tools for Nuance, Clarity, and Better Feeds Author leads by example using the new tag Ben Halpern Ben Halpern Ben Halpern Follow for The DEV Team Aug 26 ## Introducing AI Disclosure on DEV: Tools for Nuance, Clarity, and Better Feeds #showdev #announcements #ai #community 49 reactions 2 comments 3 min read

Introducing AI Disclosure on DEV: Tools for Nuance, Clarity, and Better Feeds Author leads by example using the new tag Ben Halpern Ben Halpern Ben Halpern Follow for The DEV Team Aug 26 ## Introducing AI Disclosure on DEV: Tools for Nuance, Clarity, and Better Feeds #showdev #announcements #ai #community 49 reactions 3 comments 3 min read

Kiro Crew + AWS DevOps Agent over MCP = autonomous incident detection, investigation, and fixes. One config block. 34 tools. Runs while you sleep.

Every show would benefit from an episode like this one.

I was tired of SOS apps failing in dead zones, so I built a pure Dart, 100% offline TFLite crash detection engine. Bhagya Prasad Dannina Bhagya Prasad Dannina Bhagya Prasad Dannina Follow Jun 28 ## I was tired of SOS apps failing in dead zones, so I built a pure Dart, 100% offline TFLite crash detection engine. #showdev #flutter #machinelearning #opensource 31 reactions 4 comments 1 min read

Hermes Bot Mode: I Built a Team of AI Agents That Hand Off Work to Each Other Hermes Agent Challenge Submission: Write About Hermes Agent Vivek Shetye Vivek Shetye Vivek Shetye Follow Aug 18 ## Hermes Bot Mode: I Built a Team of AI Agents That Hand Off Work to Each Other #showdev #ai #hermesagentchallenge #automation 8 reactions 2 comments 6 min read

Hoi hoi! I’m @nyaomaru, a frontend engineer who dislikes crowded places, so I'm planning to take a quiet vacation in September. 🏝️ Have you used **DSA View View** already? 👀👀 I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀) Features a timeline to step backward mid-loop nyaomaru nyaomaru nyaomaru Follow Jul 15 ## I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀) #showdev #typescript #dsa #react 58 reactions 22 comments 7 min read DSA View View allows you to understand DSA by visualizing how your implementation actually runs. But just introducing the tool is not enough. > Can it actually help us understand DSA? In this article, we'll walk through three classic problems: * Two Sum * Binary Search * Bubble Sort We'll first understand the algorithm, and then see what is actually happening with **DSA View View**. Let's learn together! 😸 ## 🗺️ Two Sum Let's start with a very famous problem. Given an array of numbers and a target value, find the indices of two numbers whose sum equals the target. For example, nums = [2, 7, 11, 15]; target = 9; The answer is [0, 1]; Because 2 + 7 = 9 Simple! So, how should we find them? 🤔 ### Brute Force The easiest approach is probably checking every possible pair. function twoSum(nums: number[], target: number): number[] { for (let i = 0; i < nums.length; i++) { for (let j = i + 1; j < nums.length; j++) { if (nums[i] + nums[j] === target) { return [i, j]; } } } return []; } This works. But if the array becomes large, we may need to compare a lot of pairs, right? The time complexity is _O(n²)_ Can we avoid checking the same values again and again? Yes. Let's use a `Map`. function twoSum(nums: number[], target: number): number[] { const seen = new Map<number, number>(); for (let i = 0; i < nums.length; i++) { const current = nums[i]; const need = target - current; if (seen.has(need)) { return [seen.get(need)!, i]; } seen.set(current, i); } return []; } The important part is this 👇 const need = target - current; Instead of asking > Which two numbers should I combine? we ask > What number do I need to complete the target? Let's follow the example. At first current = 2 target = 9 need = 9 - 2 = 7 Have we already seen `7`? No. So we remember `2`. seen = { 2 → 0 } Next current = 7 target = 9 need = 9 - 7 = 2 Have we already seen `2`? Yes! 👀👀 seen = { 2 → 0 } So return [0, 1]; Done! Because we only need to walk through the array once, the time complexity becomes. Time: O(n) Space: O(n) ### 👀 Let's View View It The implementation is quite small. But when I was first learning this pattern, this part still felt a little magical. if (seen.has(need)) * Where did `need` come from? * What is inside `seen` at this moment? * Why does checking the previous values solve the problem? This is exactly where visualization helps. dsa-view-view.vercel.app With DSA View View, we can move through the runtime one step at a time and inspect how the values change. 2 ↓ Need 7 ↓ Remember 2 ↓ 7 ↓ Need 2 ↓ Found 2! 🎉 Now the `Map` is not just some mysterious trick. We can actually follow the idea. > Remember what we have already seen, and check whether the value we need is there. Nice! 😸 ## 🔍 Binary Search Next is **Binary Search**. Suppose we have this sorted array [1, 3, 5, 7, 9, 11, 13] And we want to find 11 Of course, we could start from `1` and check every number. 1 → 3 → 5 → 7 → 9 → 11 That works. But Binary Search does something smarter. Instead of checking from the beginning, it checks the **middle**. [1, 3, 5, 7, 9, 11, 13] ↑ mid Our middle value is `7`. We are looking for `11`. 11 > 7 Because the array is sorted, we already know something very useful. Everything on the left side of `7` is also smaller than `11`. So, we don't need that half anymore. 👋 [1, 3, 5, 7, 9, 11, 13] └───────┘ search Now we check the middle of the remaining range. [9, 11, 13] ↑ mid And 11 === 11 Found it! 🎉 Here is the implementation. function binarySearch(nums: number[], target: number): number { let left = 0; let right = nums.length - 1; while (left <= right) { const mid = Math.floor((left + right) / 2); if (nums[mid] === target) { return mid; } if (nums[mid] < target) { left = mid + 1; } else { right = mid - 1; } } return -1; } There are three important variables. left right mid They represent the current search range. For our example, they start like this left = 0 right = 6 mid = 3 [1, 3, 5, 7, 9, 11, 13] ↑ ↑ ↑ left mid right Because nums[mid] < target; we move `left`. left = mid + 1; Now [1, 3, 5, 7, 9, 11, 13] ↑ ↑ ↑ left mid right And `11` is found. ### Why Is Binary Search Fast? This is the interesting part. Each step removes about **half of the remaining candidates**. If there are 1,000 values, we don't necessarily need 1,000 checks. It becomes roughly 1000 ↓ 500 ↓ 250 ↓ 125 ↓ ... That's why Binary Search has Time: O(log n) Space: O(1) But there is one very important condition. > The data must be sorted. Without sorted data, we cannot safely throw away half of the search range. ### 👀 Let's View View It Binary Search is one of the algorithms that made me want a visualization tool in the first place. The code itself is short left = mid + 1; or right = mid - 1; Easy. But when learning it, I sometimes found myself thinking: > Wait... which part are we searching now? 😿 dsa-view-view.vercel.app When we visualize `left`, `mid`, and `right`, the idea becomes much easier to follow. We are not randomly changing three numbers. We are continuously shrinking the search area. ███████████████ ↓ ███████ ↓ ███ ↓ █ That's Binary Search! Cut the unnecessary half. Then cut it again. And again. And again. Until we find the answer. ✂️😸 ## 🫧 Bubble Sort Finally, let's sort something! Consider this array. [5, 1, 4, 2, 8]; We want. [1, 2, 4, 5, 8]; Bubble Sort repeatedly compares **two neighboring values**. If they are in the wrong order, it swaps them. Let's look at the beginning. [5, 1, 4, 2, 8] ↑ ↑ Compare 5 > 1 So swap them. [1, 5, 4, 2, 8] Next [1, 5, 4, 2, 8] ↑ ↑ Again 5 > 4 Swap! [1, 4, 5, 2, 8] And continue. [1, 4, 5, 2, 8] ↑ ↑ 5 > 2 Swap! [1, 4, 2, 5, 8] Eventually, larger values move toward the end of the array. They kind of... bubble up. 🫧 That's why it is called **Bubble Sort**. Here is a simple implementation: function bubbleSort(nums: number[]): number[] { for (let i = 0; i < nums.length - 1; i++) { for (let j = 0; j < nums.length - i - 1; j++) { if (nums[j] > nums[j + 1]) { [nums[j], nums[j + 1]] = [nums[j + 1], nums[j]]; } } } return nums; } We repeatedly compare nums[j]; And nums[j + 1]; and swap them when necessary. After one full pass, the largest remaining value reaches its correct position near the end. So on the next pass, we don't need to check that position again. That's why the inner loop contains. nums.length - i - 1; ### Complexity Bubble Sort isn't very fast for large arrays. Its time complexity is Time: O(n²) Space: O(1) So I probably won't suddenly replace production sorting with Bubble Sort tomorrow. 😸 But as a learning example, I really like it. Why? Because you can **see the algorithm working**. ### 👀 Let's View View It This is probably the most visually satisfying one of the three. dsa-view-view.vercel.app Instead of only reading [nums[j], nums[j + 1]] = [nums[j + 1], nums[j]]; we can follow the values moving through the array. [5, 1, 4, 2, 8] ↓ swap [1, 5, 4, 2, 8] ↓ swap [1, 4, 5, 2, 8] ↓ swap [1, 4, 2, 5, 8] Then another pass begins. The code contains nested loops, indexes, comparisons, and swaps. But visually, the basic rule is extremely simple: > Compare neighbors. If the left one is bigger, swap them. Repeat. Repeat. Repeat. Sorted! 🎉 ## 🧠 What Did We Actually Learn? These three problems look quite different. But each one introduces a useful way of thinking. ### Two Sum Remember information from previous steps. Have I already seen what I need? ### Binary Search Use what we already know to remove impossible candidates. Can I safely discard half of the search space? ### Bubble Sort Break a larger problem into many small comparisons. Are these two values in the correct order? This is one of the things I find interesting about learning DSA. At first, the implementation can look like a collection of indexes, loops, conditions, and mysterious variables. But behind the code, there is usually a much simpler idea. And sometimes I don't fully understand that idea just by staring at the code. I want to **view it**. 👀👀 ## 🎯 Conclusion In this article, we looked at three classic algorithms: * Two Sum with a `Map` * Binary Search * Bubble Sort And more importantly, we looked at **how the data changes while they run**. I think this is where visualization can be especially useful. * Reading the final implementation tells us **what the code is**. * Stepping through it helps us understand **why it works**. That's exactly why I built DSA View View. dsa-view-view.vercel.app You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime. If you are learning DSA too, try taking a problem you already solved and viewing it step by step. You may notice something you didn't notice when only reading the code. 👀 And if there is a DSA problem you want me to cover next, please let me know in the comments! I still have many algorithms to learn myself. 😸 Let's train our DSA muscles together! 💪 If you like DSA View View, please give it a star ⭐ ## nyaomaru / dsa-view-view ### DSA View View allows you to understand DSA to see the data flow. 👀👀 Of course, it's free. # DSA View View DSA View View turns TypeScript algorithm functions into step-by-step visual stories. 👀👀 Write code, run it with structured inputs, and see the arrays, matrices trees, lists, stacks, pointers, and return values move as the function executes. It is built for those moments when reading the code is not enough and you want to _view_ why the answer changes. ## Why Try It? * 🧠 **Step through real TypeScript** Paste or edit a function, validate it, then run the exact code in the browser. * 🧩 **Views that match the data** Arrays become bars, matrices become grids, trees become node graphs, linked lists become chains, and two-pointer area problems get their own visual view. * 🌳 **DSA-friendly inputs out of the box** `TreeNode`, `ListNode`, `MinHeap`, `MaxHeap`, `PriorityQueue`, nested arrays matrices, strings, numbers, and class-style inputs are supported without ceremony. * 🔎 **39 built-in examples** Search by name, browse… View on GitHub And my DSA View View has launched at TinyLaunch! 🚀 Please take a loot 👇 tinylaunch.com See you in the next article!

5-min demo: custom agent + skill + cron job + dashboard page, installed live with one curl command. Kiro Crew isn't just a tool. It's a platform.

One FastAPI route, one Converse call with forced tool use, one container service — and the three AWS details that cost me the most time. 20/20 on the fixture set, median 880 ms against the live deployment.

## Exploring the bugs, bloat, and burnout behind today’s software and why it’s not entirely your fault. # Introduction: welcome to the software multiverse of madness Let’s be real: software in 2025 feels like it’s stuck in a _boss fight it can’t win_. Every time you open your favorite app, something’s changed and not always for the better. Your battery drains faster, the “new improved” UI hides buttons you used daily, and the performance? Feels like it’s running on a toaster powered by anxiety. You’re not alone. Developers are tired. Users are mad. Product managers are aggressively optimistic. And somewhere in the middle of this chaos, software ships whether it’s ready or not. So the question lingers: **Is software actually getting worse… or are we just becoming more aware of its flaws?** This article isn’t a rage-post (okay, maybe a little). It’s a deep dive into: * Why modern apps feel bloated, * How the pressure to ship fast sacrifices stability, * And what developers can do to fix the mess (without losing their sanity or coffee). We’ll talk nostalgia goggles, MVP culture, bloated stacks, and developer burnout with memes and examples along the way. So buckle up, because if you’ve ever screamed internally at a loading spinner, this ride’s for you. > Spoiler: It’s not entirely your fault. But you might be shipping the problem too. # Nostalgia.exe was old software really better? Ask any dev over 30 about software, and you’ll get some version of: > _“Back in my day, apps just worked and we liked it that way.”_ Cue the Windows XP startup sound. It’s tempting to believe software was better “back then.” Winamp was clean, fast, and skinnable. Microsoft Office 2003 was snappy without a billion collaboration pop-ups. Photoshop opened in seconds. Even Clippy, cursed as he was, never crashed the entire app. But before we declare a retro golden age, let’s remember a few things: * **Dial-up crashes** were a real thing. * Saving a file in the wrong format meant _starting over_. * There were _no updates_. If it was broken, it stayed broken forever. What we’re really feeling is **survivorship bias**. We remember the stuff that worked and _forgot_ how many apps silently disappeared into the void. Software that was _so bad_ , it never made it to version 2.0. Also, let’s not forget hardware expectations were lower. Nobody expected real-time collaboration or fancy animations. We weren’t trying to run machine learning in the browser while watching a 4K Twitch stream. It was simpler times because we asked less. Still, the old-school tools felt lighter, faster, more stable and there’s truth in that. They were often written in low-level languages with fewer dependencies and ran locally without a sea of JavaScript frameworks bolted together like IKEA furniture. So was old software **better**? Let’s say it was **dumber, faster, and built with fewer moving parts**. And that’s not necessarily a bad thing. # The update treadmill too many features, not enough fixes You open your favorite app. There’s a new update. The patch notes say “bug fixes and performance improvements.” But now the _Settings_ button is gone, and the app takes longer to load than Elden Ring on a hard drive from 2010. Welcome to the **update treadmill** where features keep shipping, bugs become roommates, and stability is a distant dream. In today’s world, software development has become a **never-ending sprint**. Agile cycles, CI/CD pipelines, and feature flags mean that teams can push updates weekly, daily, even hourly. And they do. But here’s the catch: **Fixing things doesn’t get clicks. New features do.** Product teams want metrics to move. Marketing wants shiny things to promote. Users just want the thing to work but they often get caught in the crossfire of KPIs and quarterly roadmaps. This leads to: * Redesigns no one asked for * Features half the user base hates * Critical bugs staying in the backlog because they “only affect 3% of users on Android 11” The result? A Frankenstein app that keeps growing but never heals. And the irony? Every time users adapt to the “new flow,” another update lands, breaking their muscle memory all over again. It’s like being in a boss battle where the enemy changes forms every 3 seconds. Modern dev workflows make it easy to ship but not necessarily to ship well. Until we shift focus from “what else can we build?” to “how can we make this actually good?”, the treadmill keeps running and we keep stumbling. # The bugocalypse why software is full of bugs we ‘accept’ Once upon a time, a bug meant something was broken and needed to be fixed. Today? A bug is more like a suggestion. Modern software ships with so many issues that users have learned to **tolerate** them. The submit button doesn’t work unless you click it twice? Cool, I’ll just… click it twice. The audio randomly stops during video calls? Classic Zoom moment. Notifications arrive 12 hours late? At least they arrive. So what happened? # Speed > perfection We live in the age of “move fast and break things” and things are **definitely breaking**. Shipping early has become gospel. MVP (minimum viable product) means get it out the door _now_ , polish later (or never). This leads to: * Unfinished features wrapped in shiny UI * Complex codebases riddled with temporary hacks * A QA process that looks like: if (itWorksOnMyMachine) { ship(); } # Feature flags to the rescue… or not To deal with chaos, teams wrap bugs in flags. “Don’t worry, it’s behind a feature toggle.” Which leads to ten versions of the same app running in production. Debugging becomes a Choose Your Own Adventure book — with traps on every page. # Real-world bug gallery: * Twitter once broke its own logout button * Slack forgot how to scroll properly for weeks * macOS shipped an update that bricked Bluetooth * One major bank’s “download statement” button silently downloaded _someone else’s_ statement These aren’t indie projects. These are billion-dollar products trusted by millions. And let’s not forget mobile apps, where bugs are immortal because updating requires going through app store approvals which sometimes means living with a broken release for _days_. So why do we tolerate it? Simple: we have no choice. We’ve normalized bad software behavior the same way we normalize potholes in our city roads. Until there’s real pressure to **prioritize quality over speed** , the bugocalypse continues and you’re either squashing them, shipping them, or stepping on them daily. # Blame the stack abstraction overkill is killing performance Remember when apps were small, fast, and didn’t consume 2GB of RAM just to open a settings menu? Well, those days are gone buried under 12 layers of frameworks, libraries, meta-frameworks, and 17 MB of unused CSS variables. Modern software stacks are like ogres: > **They’ve got layers. Too many of them.** Let’s take a simple example: You open a to-do list app. It’s built with React, which uses Webpack, which bundles a dozen NPM packages, which include Lodash, Moment.js, three unused date pickers, and a crypto mining dependency no one noticed. Oh, and it runs in Electron so it’s really just a glorified Chromium browser. # The stack is bloated, and we know it. Why? Because abstraction is convenient. Developers don’t want to reinvent the wheel, so we pull in a library. Then a plugin. Then a CLI tool to manage the plugin. And before you know it, the project has more dependencies than lines of code. Sure, it’s “easier to develop” but the cost is: * Performance death on low-end devices * Long build times * Debugging stack traces that look like spaghetti and cryptic emoji And it’s not just web apps. Even native apps suffer. Swift apps with SwiftUI that lag. Android apps pulling in entire ML models to decide which tab to show first. # Abstraction isn’t evil but it’s abused Abstractions should simplify, not _hide everything until it breaks_. But these days, we don’t even know what’s running under the hood. Our apps are built on shaky towers of dependencies that: * Go stale overnight * Break after a minor patch * Get deprecated mid-sprint And when the abstraction breaks? Good luck. The person who wrote that code now works at a llama farm in Peru. > “Why is the app slow?” _ > Because it’s trying to run a microservice architecture inside a single-page application._ # Dev feels burnout, deadlines, and doing the best we can Let’s get one thing straight: **Developers aren’t lazy. We’re overwhelmed.** Behind every janky release and laggy UI is a team of devs with 3 Zoom calls, 5 Jira tickets, and a Slack DM from a PM asking, > _“Can we just ship this now and fix the rest later?”_ We want to build good software. Really. But we’re up against deadlines, unrealistic roadmaps, and tech debt older than some interns. # Burnout is not a bug it’s a feature now Working in modern software dev often means: * Being on call for every production blip * Context switching between 5 microservices and 10 tabs * Debugging someone else’s framework inside your own code * And still smiling through standup like it’s totally fine 🙂 Add to that: * Tight sprints * Scope creep * A culture of “just push it to prod * And the dreaded: > “Let’s rewrite it in TypeScript… next quarter.” You end up with teams stuck shipping features instead of solving root problems. # Reality check: devs aren’t the enemy It’s easy to blame developers when things break. But let’s be honest — **most of us are just trying to keep the app running without crashing Slack in the background.** We build what we’re told. We rush because the product timeline says so. We compromise because perfect is the enemy of shipped. And yeah, we cut corners sometimes… but mostly because there’s no time to pave the whole road. So next time an app breaks mid-demo, remember: There’s probably a dev behind it, chugging cold coffee, quietly screaming into the void, and praying the fix gets merged before Friday. # The good news not all software is doomed Okay, we’ve dunked on bloated stacks, buggy apps, and burnout culture. But let’s not forget: **there’s still a lot of great software out there** — tools that are fast, thoughtful, and dare we say… _pleasant_ to use. Despite the chaos, many developers are pushing back against the madness and choosing _better_ over _faster_. # Small teams, big wins Some of the best software in 2025 isn’t coming from BigTech behemoths it’s coming from small, focused teams that obsess over: * Performance * Minimalism * Actual user needs ## Examples worth applauding: * **Figma** collaborative, fast, and shockingly stable (even in a browser tab). * **Obsidian** a markdown-based knowledge tool that runs like butter, with no unnecessary cloud lock-in. * **Raycast** a blazing-fast Mac productivity launcher that doesn’t try to be a browser. * **VS Code** yes, it’s Electron, but they actually optimized it. Somehow. Miraculously. These apps get the vibe right: * They ship smart defaults * Respect system resources * And evolve slowly, not chaotically # Devs are getting smarter about dumb decisions There’s also a shift in dev culture an awakening. More engineers are questioning: * Do we really need this framework? * Can we trim these dependencies? * What if we wrote less code and did more with it? And it’s working. Blogs, podcasts, and conference talks are increasingly focused on: * Resilience over velocity * Simplicity over novelty * Debuggability over abstraction We’re not fully healed, but the immune system is kicking in. So no, not all software is doomed. Some teams are saying no to the chaos. And it’s working. # Section 8: conclusion fix your code, fix the world So, is software getting worse? Not really. It’s getting _bigger_ , _faster_ , _shinier_ and sometimes _dumber_. We’ve traded the old-school principles of simplicity and stability for rapid iteration and infinite growth. Somewhere along the CI/CD pipeline, we forgot that users don’t care about your framework they care if the app _actually works_. And as devs, PMs, designers, and QA warriors, we’re all complicit in this spaghetti-tower of bloat. But here’s the good news: > We also hold the power to change it. We can slow down. We can prioritize maintainability. We can push back on unnecessary features. We can test before Friday night deploys. We can write fewer lines of code and make each one _actually count_. Because every time we choose performance over pretty animations, clarity over cleverness, and function over flex we make the web (and software in general) just a bit better. Even if the codebase is messy. Even if the tech debt is mountainous. Even if your app is one merge away from collapse. There’s still time to fix it. # Final line of code > Software doesn’t need to be perfect. It just needs to respect the people who use it and the people who build it. Now go delete that extra NPM package. Refactor that callback hell. And maybe… just maybe… bring the Save button back. # Helpful resources for the brave * Joel Spolsky: Things You Should Never Do * Martin Fowler: Technical Debt * Stack Overflow Developer Survey * GitHub Octoverse Report * Kent Beck on “Make it Work, Make it Right, Make it Fast”

Hi DEV community! 👋 TL;DR: I built a fast, ad-free IP lookup and reputation utility with native CLI...