Forem: Chris Quinn

You're Fixing the Wrong Bugs

Chris Quinn — Sat, 20 Dec 2025 09:06:07 +0000

Your bug tracker has 47 open errors, but which one is breaking checkout? Which affects just one user? Which is getting worse this week? Most teams debug randomly instead of strategically, wasting time on low-impact bugs while critical issues affect revenue. Without impact scoring and trend analysis, bug backlogs become undifferentiated noise where revenue-critical errors sit alongside cosmetic annoyances.

This is Post 1 of our Cazon launch series on error intelligence. Follow along as we unpack the problem, introduce solutions, and show you how Cazon is building the missing intelligence layer between production errors and AI coding assistants. You can also read along at https://blog.cazon.dev/

It's Monday morning. We open the bug tracker and see 47 open issues. Our manager asks: "Which bug should we fix first?", so we scan the list:

TypeError: Cannot read property 'user' of undefined (opened 3 weeks ago)
API timeout in payment processing (opened yesterday)  
Button misaligned on mobile Safari (opened 2 months ago)

Which one matters? We check timestamps, read descriptions, look for labels. Nothing tells us which bug is breaking the business and which one is just noise. So we do what every engineering team does: we fix the newest one. Or the loudest one. Or whichever one the CEO just complained about in Slack.

This is the hidden cost of undifferentiated bug backlogs.

The Hidden Cost of Random Debugging

Here's what most engineering teams don't talk about: 40% of developer time goes to debugging. That's not controversial; everyone knows debugging takes time. But here's the part that hurts: 60% of that debugging time is spent on the wrong bugs.

On the face of it, it's easy, right? Oh, the checkout flow has a bug affecting 27 users this week with a revenue impact of $1,000. The admin panel has a typo in a rarely-used modal with a revenue impact of $0. Both are "open bugs" in the same list but surely we tackle the checkout flow first... right? Hands up if your team has ever fixed the admin panel issue first.

The typical mid-size engineering team has 30-50 open bugs at any time. Without impact scoring, we're debugging blind.

Why "Newest" Doesn't Mean "Most Important"

The default sort order in most bug trackers is created date (newest first). This makes sense for support tickets but makes zero sense for engineering priorities.

Consider these three bugs, all opened in the same week:

Bug A: Payment API throwing 500 errors

Started last Tuesday, affecting 5% of transactions. Trending UP from 4 errors/hour to 20 errors/hour. Revenue impact: Medium-High.

Bug B: Search results sometimes empty

Started Wednesday, affects 1 user so far. Not trending. Revenue impact: The CEO saw it.

Bug C: Dashboard loading slowly

Started Monday, affects all users. Trending DOWN (we added a CDN). Revenue impact: Low (UX annoyance, not a blocker).

If we sort by date, we fix Bug A last because it's the oldest. But it's the only one that's actively getting worse and costing money. This is why "newest first" is dangerous. It rewards recency, not urgency.

If we sort by perceived priority, then take a guess at which one we're fixing first.

The "Gut Feeling" Approach Doesn't Scale

Small teams can debug by feel. With 5-10 bugs, someone on the team knows which ones matter. We discuss them in standup and have context. But the moment we hit 15-20 open bugs, gut feeling breaks down.

Why? Cross-project bugs mean different teams don't know each other's context. New team members can't distinguish critical from noise. Distributed teams lack shared standups to build tribal knowledge. Technical debt means old bugs become invisible background radiation.

At 30+ bugs, the backlog becomes write-only. Bugs go in. Nobody reads them. They accumulate until someone does a "bug bankruptcy" and closes everything older than 90 days. We've all done this.

Traditional Bug Trackers Don't Solve This

Let's be honest: Jira, Linear, GitHub Issues don't actually triage bugs. They organize them. They let us add labels and priorities. They sort by arbitrary fields. But they don't tell us which bug affects the most users, which bug is trending worse this week, which bug blocks revenue versus which is cosmetic, or which bug is a known pattern with a 5-minute fix.

We have to manually research every bug to figure out its impact, and we have to do this over and over as new bugs arrive. Most teams don't. Instead, they use proxies:

"Fix bugs with 'P0' label first" – But who sets the priority? Gut feeling. Or the CEO.
"Fix bugs affecting premium customers first" – But how do we know which users are affected? Manual correlation.
"Fix bugs with the most comments first" – So the loudest bug wins? Great.

Traditional bug trackers are error organizers, not error intelligence. They're filing cabinets, not assistants.

The Real Problem: Lack of Context

Here's what we actually need to know to triage a bug:

Impact: How many users are affected?
Trend: Is this getting better or worse?
Severity: Does it block functionality or just annoy?
Recurrence: Is this a new bug or the same one we've seen before?
Pattern: Do we have a known fix for this class of error?

Most bug trackers give us none of this. We get a stack trace (if we're lucky), a description (often incomplete), a timestamp, and maybe some labels (inconsistently applied).

So we waste engineering time doing forensics. We search logs to see how many times it occurred. We correlate error IDs to user accounts. We check if this matches a previous bug. We Google the error message for the 47th time. By the time we've gathered context on 5 bugs, an hour has passed and we still haven't fixed anything.

Why This Matters Now

Five years ago, this was just "the cost of doing business." Debugging was manual. Triage was manual. We hired more engineers and hoped for the best.

But something changed: AI coding assistants. Claude, Copilot, Cursor are incredible at fixing bugs once we tell them what to fix. But they can't tell us which bug to fix first. They have no context about production errors, user impact, or business priorities.

We're giving AI tools the keys to the codebase, but they're debugging blind just like we are. This is why the problem is more urgent than ever. AI makes code easier to write but doesn't make bugs easier to triage.

What's Next

If you're a senior engineer or engineering manager, you've lived this problem. You've spent Monday mornings staring at that bug list, wondering what to fix.

The problem isn't volume. It's lack of intelligence. You don't need more bug tracking. You need error intelligence: context, impact scores, patterns, and prioritization.

Next time, we'll explore why AI coding assistants make this problem worse, not better, and what needs to change.

Picking up Rust(y) habits: learning Rust as a JS developer

Chris Quinn — Thu, 04 May 2023 04:16:35 +0000

Do you work with Javascript? I do: let's first pour one out for all the idiosyncrasies of the language we know and love and acknowledge that for all its faults, the JS/TS ecosystem is thriving: https://2022.stateofjs.com/en-US/conclusion/

While there's plenty of frameworks, micro-frontends and full-stack toolchains to master, there's something to be said for broadening your horizons. You may be wondering what other programming languages are worth learning, not least to expand your skills and improve your career prospects.

I'm here to pitch one to you: Rust. Rust has gained a lot of popularity in recent years, let's explore why Rust is a good choice for Javascript developers to learn.

What is Rust?

Rust is a systems programming language, originally developed at Mozilla as a personal project in 2006 by Graydon Hoare. It's designed to be a safe, fast, and concurrent language that can be used for a wide range of applications. Rust is particularly popular for developing low-level software, such as operating systems, device drivers, and web browsers.

Yeah, that all sounds kinda dry, but how about this: Rust was named after a hardy fungus, due to one of its primary strengths being the enforcement of memory safety. This is a key strength of the language, we'll come back to it.

Why should I learn Rust?

Here are five reasons why Rust is a good choice for you to learn right now in 2023:

1. Performance and Safety

One of Rust's primary advantages is its speed and safety. Rust is a compiled language, which means that code written in Rust is transformed into machine code that can be executed directly by a computer's CPU. This makes Rust much faster than interpreted languages like Javascript. Additionally, Rust has built-in memory safety features that prevent common programming errors, such as null or dangling pointer errors, which can cause crashes or security vulnerabilities.

Hot take incoming: This means that Rust code is much less likely to cause bugs or security vulnerabilities than Javascript.

2. Compatibility with WebAssembly

WebAssembly (WASM) is a low-level, portable bytecode format that is designed to be executed in web browsers. WASM allows developers to write high-performance code in languages other than Javascript and run them in the browser. Rust is an excellent language for writing code that can be compiled to WASM, meaning that you can write Rust code that can run directly in the browser, alongside or instead of Javascript. Check out this guide for the how and why: https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm

3. Learning Rust can improve your Javascript skills

Rust and Javascript are very different languages, but learning Rust can (albeit indirectly) improve your Javascript skills. Rust emphasizes the importance of code organization, strict typing and modularity - for me personally, I enjoyed being shaken out of my comfort zone by developing in Rust and making small, simple projects that allowed me to learn (and fail) and iterate quickly.

4. Rust's growing popularity

Rust is a relatively new language, but it has been rapidly growing in popularity over the past few years. Many large companies, such as Microsoft, Amazon, and Mozilla, have adopted Rust for in-house projects. Learning Rust now can put you in a good position to take advantage of the growing demand for Rust developers in the future. There are some projects that track programming language popularity such as the Tiobe index, which ranks Rust in the top 20 languages.

5. Have your cake and eat it

OK, fine, you might not be ready to wholesale drop our beloved JS and jump ship entirely, I understand. But what if I told you that you can leverage all the power of Rust within your Node projects? Let me introduce you to Neon:

https://neon-bindings.com/

Wrap up

Rust is a powerful and versatile language: its speed, safety, compatibility with WebAssembly, and growing popularity make it an excellent choice for Javascript developers to learn.

Whether you're looking to improve your skills, build high-performance web applications, or explore new career opportunities, Rust is definitely worth checking out.

https://www.rust-lang.org/learn
https://www.youtube.com/channel/UCaYhcUwRBNscFNUKTjgPFiA

Meteor.js Bootstrap Project

Chris Quinn — Mon, 08 Nov 2021 21:47:11 +0000

Cover photo by Oziel Gómez on Unsplash

Over at https://github.com/chrisquinnr/meteor-bootstrap you can find a quickstart app to get you up and running with a few Meteor basics, including accounts, routing, collections and adding a UI library like Bootstrap.

We're using good old Blaze in this example but a shiny new Svelte version will be coming soon.

Quickstart

Get Meteor installed: https://www.meteor.com/developers/install
Clone the repo
meteor npm install
meteor

Why Meteor?

Meteor has been making an awesome comeback over the past 18 months after the original development team moved on to new GraphQL-flavoured pastures. After being bought out by a VC firm, the project has picked up pace and as seen a renewed focus on addressing some of Meteor's roadmap.

Meteor is full stack JS framework ideally suited to realtime applications. Its early advantages were zero-config websockets and ES6 that #justWorked, but now I find that it's a great tool for prototyping and building MVPs, since we not only get to leverage the wonders of NPM but also the framework lets you bring your own frontend. Blaze, React, Angular and now Svelte are all options.

Like any framework, Meteor's benefits come at a price, in that you need to buy in to Meteor's highly opinionated structure and concepts. Fortunately these aren't too crazy and most of the rules can be broken if you want, but there are plenty of gotchas that will trip first time users up.

Hopefully that's where this bootstrap project can help, getting you from zero to... something a little faster. I'm not suggesting this is a gold standard, and I'd recommend the resources below for the authoratative take on things like application structure and best practice.

Resources

In suggested order of reading for anyone new to the framework.

Once you're up and running, why not check out the following?

Forums
Meteor Devtools
2021 Meteor Impact conference, with some great talks from the community and previews of upcoming features

And if you're hungry for more packages, examples and great community content, check these out:

Packages

Over and above anything I've written below, you should check out the Meteor Community Packages repo. This is a welcome new endeavour to bring awesome community-created modules under one roof.

Styling

Ironically the first batch of packages this project depends on aren't Meteor specific, so won't be found in .meteor/packages. We use meteor npm install to add Bootstrap and associated dependencies.

Utility, Subscriptions

underscore

Currently only used for a simple randomise function, but I use it in most projects. Of course, you can replace this with [lodash] or any number of other helper libraries. Consider only importing the functions you use to avoid loading in the whole library (see tree-shaking).

meteorhacks:subs-manager

A very useful package for controlling how your application behaves based on when subscriptions are ready. I've used this package on several enterprise projects and it's well worth it.

simple:reactive-method

Meteor helpers are powerful, they allow you to reactively update your UI based on data mutations over the wire. Sometimes though, you need to listen for the result of a server-side operation. Meteor.call is not inherently reactive, meaning you'd need to continously poll the server for the result you want. Enter Reactive Methods, a neat solution to this issue. A reactive method can call any Meteor.method you've defined on the server and, if used in a Template helper, will update reactively.

Routing & Templates

ostrio:flow-router-extra && mealsunite:flow-routing-extra

You'd be forgiven for being a little confused about the state of routing in Meteor. I know I was. The catch-all community-created solution for many years was Flow Router, which was thankfully picked up by Veliov Group (https://github.com/veliovgroup). It remains my choice too, but needs a little help from sibling packages to play nice with blaze layout below.

kadira:blaze-layout

A neat way to declare and control layouts in conjunction with your routing solution, obviously for Blaze.

Accounts

useraccounts:core / accounts-password@2.2.0 / useraccounts:bootstrap

The combination of these packages gives us user accounts, authentication and more straight out of the box! Awesome right! It's even extensible with other packages to add oAuth login providers.

Login splash screen

I've added an artifical loading screen, just because, by delaying the result of a subscriptions listener, you can find this in client/main.js. Usually logging in is pretty much instantaneous. On that note, the accounts-password / useraccounts:core packages are great, and completely extensible including social media login.

Twilio

If you dig a little deeper I've added instructions for an SMS-based login handler using Twilio (this was the main motivation for building this project in the first place). You need to set up Twilio as noted in the comments in /imports/api/apimethods/methods.js and then trigger the SMS using the provided Meteor method e.g. Meteor.call("smsLogin");

Landmrk & Serverless: innovation nirvana

Chris Quinn — Tue, 02 Jun 2020 13:37:34 +0000

The Landmrk Platform is our battle-tested, ultra-scalable platform for deploying web based, location-focussed digital experiences. During a recent campaign, our API gateway handled half a million requests in the space of 3 minutes with average CPU usage only touching 8% across a very lean autoscaling group. Landmrk campaigns typically experience huge traffic spikes in very short timeframes as our clients release new content, previously unseen artwork and tracks and compelling digital content. Fans are hyper-engaged, and we typically see high session lengths, low bounce rates and repeated engagements. Using a web-based campaign means nothing to install and no insidious permissions requests or continuous updates.

Our platform is ultra-efficient, but with this efficiency comes the need to carefully steward the continued development, innovation and maintenance of this frankly awesome product. Adding new features rightly takes careful consideration, specification and delivery with full test suites and documentation - all of which takes a reasonable amount of time.

Landmrk are, first and foremost about innovation, using cutting edge web technologies to deliver those compelling experiences that keep users coming back. So, my challenge as CTO is how to balance the stewardship of the platform versus our need to innovate & delight.

I've recently been using the Serverless framework (uppercase for the framework, lowercase for the concept) to generate quick, one-shot backend services that offload discrete campaign logic to completely isolated environments. Our stack is based on AWS and being able to use a node runtime for Lambda services means we have the wealth and breadth of the npm registry to draw from in conjuring creative ways to work with location data & more.

Our recent campaign with Big Beat used a serverless function that took the user's location and calculated the distance from the user to the current position of the International space station, as well as the weather at their location - all of which we stamped onto a bespoke digital collectible the user could download and share.

Naturally, none of this functionality would have been possible on-platform without significant time & investment. However, by mixing the flexibility of serverless endpoints with the robust, deterministic capabilities of the Landmrk platform, we were able to reach innovation nirvana with a digital collectible product that expanded a campaign's capabilities without compromising the platform codebase in any way.

One concern about serverless functions is the so-called "cold start" problem wherein lambda functions may need time to "spin up" on first execution. However, given the nature of Landmrk campaigns (rapid, intense surges in traffic) once an instance is active it can remain so for around an hour afterwards, wherein the execution time can begin immediately, which suits us just fine. We are also able to leverage AWS provisioned concurrency options, which keep a certain number of instance "ready-to-go" to avoid this issue entirely.

With the Landmrk platform and the Serverless framework at our side I'm excited at the possibility of bringing even bigger and bolder web campaigns to fans around the world.

If you'd like to know more about what we get up to at Landmrk, check out our website below, or reach out to us on Twitter or Linked In.

I'm Chris Quinn, CTO of Landmrk and you can catch up with me @chrisquinnr on Twitter or ping a note to hello@landmrk.it.

https://landmrk.it
https://serverless.com

The Rise of No-Code (dude, where's my code)

Chris Quinn — Mon, 02 Mar 2020 20:49:12 +0000

On the latest episode of Salted Bytes, James and I tore into a veritable buffet of no-code web development platforms.

From Wix and Squarespace to Zapier via Google Sheets (did we just invent a new startup?), we talk about how no-code platforms provide much-needed glue between the myriad SaaS behemoths slugging it out for your time, attention and subscription dollars. But not everything is as rosy as some no-code proponents would say - we discuss some of the pitfalls of going all-in on no-code: anyone for some of that sweet vendor lock-in?

No-code is a polarising topic and super popular here on dev.to (check out https://dev.to/search?q=no-code), but contrary to some of the views we've seen James & I think no-code has it's place in a thriving digital marketplace and actually empowers business / product owners to either raise their game or push for that little bit of extra innovation (as a treat).

In researching this episode we found a whole bunch of super-salty takes on no-code from devs across the Twitterverse, from the thoughtful and considered to the downright savage - and we include them here for your pleasure. Enjoy.

Holy Salt!

How could you say something so brave and so true

Dadjoke.gif

It is like cloud

Low-effort Twitter screencaps aside, we're really interested to see what the NextBigThing^TM in no-code is, and even more interested to see if no-code continues to be such a polarising topic... or whether one day it'll sink into the doldrums of every day office life, like Clippy and and that guy who writes Excel macros.

James & I think no-code is a valuable part of the web dev ecosystem, and here to stay - what do you think? Why not check out our latest episode at the links below and let us know in the comments!

https://dev.to/salted-bytes-podcast
https://saltedbytes.rocks

Till next time

Chris

What (not?) to do in your new tech role

Chris Quinn — Fri, 07 Feb 2020 17:59:23 +0000

Recently on the Salted Bytes podcast we discussed what to do (and NOT) to do in your first few days at a new dev role.

Some of this advice was very applicable to most jobs:

"Get to know people"
"Always join in the first few social events after you start"
"Find and cherish your mentors"

For developers though, whether in your first role or your twentieth, we had some very industry-specific tips:

Don't cling dogmatically to your old tooling or coding style - it may be familiar but you need to learn the way things are done in your new place of work - it's very likely they've arrived at their stack for compelling reasons, which are worth hearing out, and respecting. One you've done that, if you still feel duty bound to evangelise your new colleagues on your perspective on tabs v space, go right ahead.
Get to know people outside of your immediate team. This can give you invaluable insight into your new role, either from top level strategy and culture or from the low to ground must know info like how the holiday calendar works and how to claim expenses. (most companies should absolutely cover this in your orientation, but let's be honest, it's not always thorough).
Be curious, and ask the obvious question. There's a great deal of pride, and conversely, imposter syndrome permeating software development. Don't be afraid to ask even the most humbling of questions: better now than 5 months down the line. There are myriad paths into development careers, not all of them computer-science based, and sometimes you'll encounter knowledge gaps that you didn't even know existed. Swallow that pride and ask the obvious question - clarity trumps assumption every day of the week.

James & I covered more tips & tricks on the Salted Bytes podcast. Why not go check it out?

https://dev.to/salted-bytes-podcast
https://saltedbytes.rocks

Till next time

Chris