"papercuts" is a very poor metaphor for this. In the real world, a cut from an edge of a sheet of paper is surprisingly painful (and sometimes briefly a little scary that something so innocuous can cause such injury and pain!), but the body heals the cut in 24 hours or so with no conscious effort. In the software world, one will keep bumping into the defect while remains, and there is no guarantee that it will ever be corrected.
> yeah it really seems like he's just talking about bugs.
Inconsistent, and oft very much a matter of opinion.
If there's a race condition which causes a loading indicator not to show up it's a bug, but is it a bug if nobody put in a loading indicator because nobody cared, or considered that the operation could take sufficiently long some signal would be useful?
thankfully "bug" is not a precise jargon, it can be anything and everything that bugs you. anyone arguing over the definition of "bug" is usually trying to weasel out of having to fix one.
I think a "bug" is anything that isn't operating as the designers wanted it to. If there's an aspect that just sucks, but is operating as intended, that's not a bug. That's a "misfeature" (or BAD -- Broken As Designed).
But a bug doesn't have to be a malfunction. It can be a terrible UI flow or other annoyance. But if it's not what the designers had in mind, it's a bug.
> In the software world, one will keep bumping into the defect while remains, and there is no guarantee that it will ever be corrected.
This is something which does happen in the real world although I don't know that there's a term for it (hence papercut being used instead, as an unnecessary recurring issue which in the grand scheme of things is not exactly deadly — as opposed to sharp edges, which are usually APIs which are tricky to use).
For instance it's common to have bits (of varying sharpness) sticking out of walls and other surfaces onto which things or people will repeatedly snag. Or uneven flooring.
They are generally minor annoyances people live with, though they can cause actual harm (falls, wounds).
We used to call them cherries, because the fix would usually be a single commit to a single file with a handful of lines changed, so it would get git-cherry-picked into the release tag rather than having its own ticket, branch etc
I agree. Instead, I like to talk about "tripwires" in my work. Some software and data environments are full of tripwires, so it's impossible to move at a brisk pace. Every step must be slow and closely monitored. Because the system does not actually guarantee any of the properties one would reasonably expect it to have, and moving quickly under intuitive (or even explicitly documented) assumptions will quickly lead to an error-riddled, unrecoverable state.
I don't know of a "person" who heals papercuts in 24 hours. It's like 24-48 hours of open pain, body identifies the healing spot and places blood toward it. 72-96 hours, basic healing. 144 hours new formed scab. 7-14 days, good enough to function again like it did not happen.
and if its located in a high-tension spot (papercuts are always located there like fingers), well then you need band-aids otherwise its recipe for churn.
papercuts is perfect for the methaphor. its tension area, high traffic spots. but the author missed the point about super glue (or duct tape, in other authors words)
People heal at different rates. Some climbers regularly split their fingertips and they can heal up well enough to climb on again within a couple of days.
Its a poor metaphor because you're focusing on the wrong part of the metaphor.
It's called a papercut after the "death by a thousand papercuts" chinese torture / execution method. The idea is that a single papercut by itself may not "kill" the project, but collectively they will bleed the project to death out as much as a single massive death-blow.
When viewed from this angle, it's a perfect metaphor.
related from Nassim Taleb: if in an expensive area you need too choose between a shoddy looking restaurant and a beautiful stylish one, go to the shoddy one, because probably the only reason it can survive in that area is that it has great food, the stylish one could survive just because people go there for the atmosphere.
That is only true in an equilibrium. Most of the time things are not in an equilibrium and it's perfectly possible that shoddy restaurant is going to close very soon or hasn't been open for a long time. Of course if you know that this restaurant was shoddy and is shoddy for years now, then it's fair to assume the food is great.
I view it differently. It's not that papercuts don't matter, it's that people tolerate papercuts when there is no viable alternative. Glitchy software with maddening defects is evidence of lack of competition. If a competitor was to offer a product that didn't have the defects but was able to accomplish the same real goals, they'd quickly take over the market. Failing to fix these annoyances shows that you are not worried about competitors. Sometimes this is a good business strategy, sometimes it will be your downfall.
Finding and dominating a niche is the best business strategy. I agree that glitchy and buggy software may serve as a way in for a new entrant, so once you got your customers it’s a good idea to keep raising the quality. Here’s a good example of a conglomerate who uses that strategy: https://www.youtube.com/watch?v=nVK2s80SfyM
We should consider more collaboration on open source software, rather than competition. Meaning, creating a competitor platform that many people contribute to like ants. Also open protocols and standards like HTTP, SMTP, EVM, etc.
Wikipedia beat Britannica
The Web beat AOL, MSN, etc.
Linux and BSD beat proprietary platforms on many platforms (including Android)
Science beat alchemy
Often we think "more competition" is the only way, but collaboration and gift economies can over time beat closed silos that compete.
Yeah these were my thoughts exactly when I read the article.
Like sure, ok, most software works, but I don't think it's a waste of time or effort to strive for something beyond barely functional.
It also only approaches this problem from the viewpoint of a developer. As a user of dozens and dozens of pieces of software daily, each with their own annoyances and weird behaviors that don't necessarily stop me from using it, that shit stacks up.
the difference between two products is unlikely to be in papercuts only.
the reality is that's there's an infinite # of bigger things that need fixing.
Related concepts: The Brown M&M’s Principle (Papercuts could be perceived as indicators of overall quality). Broken Window Theory (Papercuts may communicate poorer quality is acceptable). In practice it's a question of priorization and limited resources. I recommend setting aside some time to fix them.
This is a case where thought experiments based on your own assumptions just aren’t very useful.
It’s very way to end up arguing with straw men about made up categories.
What you define as “paper cuts” is probably very arbitrary and would differ significantly between individuals. It only makes sense in the context of an existing backlog of issues that is properly groomed and labeled. Otherwise you may as well just call them “pet peeves” instead. It’s totally subjective.
So whether they “matter” or not is really unanswerable outside of that context, and frankly not very interesting within that context as well. If they mattered they would already have been fixed…
> If they mattered they would already have been fixed
I just don’t think this is true at all. I’ve always been on teams where the backlog of issues with very real business value (for any value of “matters”) far exceeded the capacity of the team. Given that, it meant that there was a constant battle of prioritization. That process ought to include “Papercuts” as an input variable, for sure.
The author has come to the dark side. I’ve long advocated that paper cuts don’t matter. I don’t even think of fixing them unless it’s very cheap and safe to do so. Both cheap and safe are key. I’ve seen people fix paper cuts to only introduce a major issue in the product.
Now if it turns out that your highest priority issues are now just paper cuts, then congratulations!
It's something that requires judgement and balance.
We've all seen P.O.S. enterprise software products that take the "we-don't-care-about-paper-cuts" attitude to an absurd extreme. Everyone who has to use them uniformly hates them. I am looking at you Oracle, MF-er!
The thing is paper cuts are everywhere, you're going to run into them, it's part of why you're paid to do what you do. The Chinese have a word for this. I think it's "Chabuduo", it's a kind of nonchalance about snags and imperfections in favor of getting stuff done. It works. To an extent. At some point, however, you have to get your shit together and address the snags that come up over and over again. If you don't it's a sign of not caring about the people doing the work and the people who have to use your product.
There's another word that's the opposite of "Chabuduo". It's "mise-en-place" from the realm of cooking. It means having your space, tools, and ingredients (work materials) laid out, pre-measured, and ready to go. It's absolutely necessary, IMHO, for consistent quality work-- and not just in cooking.
Knowing when to "Chaduduo" and when to "mise-en-place", I think, makes for the most productive work.
Papercuts might matter, but there's a time and a place for everything. If you have limited resource-constrained, and the choice is between solving minor issues or driving the product forward, do the latter.
That doesn't mean you shouldn't be improving quirks and annoyances in the product, but such things should be proportional to work that delivers value.
At some point, it can devolve into perfectionism and grind all meaningful progress to a halt.
Maybe every quarter (or some other time period) have a timeboxed story to search and destroy these papercuts. One variation would have the story opened and collecting papercuts over a period of time; then when it hits a certain number, the story gets bumped up in priority.
I suspect too many of these papercuts might leave a door open that lets bugs in.
As someone who is team anti-papercut, Jira I think is a good example. Chances are if you use jira at work you know many people who hate jira, devs complain about it all the time, stuff that seems like it should be 1 step takes 3, and every so often someone proposes an alternative. It sticks around and dominates the space because it does solve a lot of problems and is flexible enough that it becomes entrenched in your teams workflows and for any give papercut you can generally workaround it and ignore it. Still if it didn’t have these papercuts people wouldn’t even consider replacing this behemoth with something else and I am sure there is a fair amount of user churn due to these issues, e.g. dev who hates jira starts a start up and vehemently opposes using it due to previous experiences.
I remember when Canonical did a lot of work to fix 'papercuts' in the linux desktop, and they used that term because there was a lot of 'small' bugs that really added up to make the whole thing a pain to use. Especially at the time people were advocating desktop linux as better/more stable than windows but the reality was that for many common tasks you would run into brokeness (audio glitches, wifi problems, etc), but many open source devs saw these bugs as 'minor' although they had an outsize impact on the user experience.
Software "papercuts" work like an abrasive to users. They more they are, they more dread it becomes to use the software, especially if they have to because of work.
When a competitor comes along, you know where the users are going.
But "papercuts" is a weird name. They are bugs. Bad bugs but not bad enough that the author wants to fix them.
People learn to tolerate minor bugs in software because most software is buggy. If I became upset at every minor (or even major) bug I encountered in day-to-day life, there would be no time to do anything else. On rare occasions I get blocked enough to track down and report/fix the bug[0], but mostly I just try to find a workaround and carry on toward whatever my original goal was.
Even if every bug were to be fixed, one would be frustrated by behaviors that are clearly intentional but stupid, usually because someone tried to over-simplify something[1], hack in a "helpful" shortcut[2], or has aesthetic preferences against supporting complex use cases[3].
Finally, beyond those two great lakes of bugs and bad ideas, we come to the endless ocean of missing minor functionality. The comic reader that lets page order be swapped for manga but doesn't change which arrow "next page" is bound to; the web browser that doesn't allow translating a page unless its language heuristics get tickled in the right way; the mobile keyboard that couples auto-punctuation with spelling correction.
It's like the joke about wine snobs -- if you don't know much about wine then most wines taste fine, but if you take a wine appreciation course then you'll never be able to enjoy it again.
[3] I am annoyed daily by crates.io lacking per-user namespaces, and the primary objection to adding them seems to be driven by a preference for single-token package names.
Most of your comment is strong but reducing nuanced discussion about something as foundational as package namespacing to "aesthetic preference" is not one of your strong points here.
Package namespacing in Rust is not foundational -- the compiler and toolchain are decoupled from the identifier used by crates.io and Cargo. Non-Cargo build systems (such as Bazel) are able to work with arbitrary package names without problem.
There are three general directions crates.io package namespaces might take, and aesthetics plays a major role in not currently having any of them:
1. Use human-readable strings as on Github, yielding package names like `jdoe/some-package`. The crates.io maintainers prefer to avoid this due to potential operational load from people requesting changes to their username.
2. Use opaque (but stable) namespaces such as an integer user id, yielding package names like `user-12345/some-package`. Some people have a strong aesthetic aversion to this.
3. Assign each package a UUID. This is technically possible in current crates.io if the leading character is [a-f], but I've never felt mean-spirited enough to actually do it.
It's all about the elasticity of demand. That's why software that one must use - perfectly inelastic demand - is usually the shittiest, such as government software and corporate crapware. Inelastic demand means that the supplier has no incentive to decrease cost for the consumer (annoyance is an indirect cost). Elastic demand means the supplier benefits from a decrease in cost, because it results in more units sold.
Bugs don’t matter until they do. I once worked at a SaaS firm with atrocious reliability- eventually the NPS surveys said that was the top issue. Surprisingly it receded to issue #N when reliability went to “we don’t have a weekly outage”. This was a multibillion dollar SaaS.
My two cents is that paper cuts hamper productivity more than anything else. Even if customers don’t care about monthly downtime/small gotchas. The dev team will have to spend time thinking about it and dealing with it. A company with a 2 hour build, and multi day test cycle will naturally have dev productivity near zero.
I think coming up with terminology for a blog like this is stupid. In some years the author is going to write an aside that goes something like this:
(Papercuts is a term I coined ten years ago on my blog)
They matter to builders that care. While software may deliver value, and the business makes money at this moment in time, a disregard for quality over time would create an environment that pushes out builders that care. And when you have people building product that don't care, it's hard to argue they'd care for the customer either. The slippery slope argument, I know. But "how you do anything is how you do everything."
That said, the surface area for any product is huge. It makes sense to prioritize paper cuts that have ROI. Otherwise, you'd never ship. And it is fundamentally true that customers buy and use because it gets their job-to-be-done finished, despite the paper cuts they'd have to wade through.
But like our most closely-held ideals, we may never reach them, but it doesn't mean we should stop trying entirely. Besides, once they find an alternative, or a competitor becomes viable, they'll switch. Paper cuts don't matter, until they do. It's a debt of another kind, where the piper will always come knocking eventually.
I think you have to define quality. If you define quality as the absence of annoyances I think you're probably over optimizing the wrong thing. You want to provide a clear, fast path for users to solve their problems and at scale you have to prioritize providing paths to solving big problems for users rather than fixing the volume of small annoyances, it's incredibly more impactful.
From a business point of view, this depends on your competition. If there's a competing product that solves problems as well as yours, having fewer warts is a powerful competitive advantage.
From a craft point of view, they all matter a lot. We all want to make products that are actually good on every level, right?
But, as you say, you can't optimize for everything.
> The realisation: I keep paying for and using software even though it has papercuts.
Because there is no viable alternative. If the two pieces of software offer same (or at least similar) features, one that has less "papercuts" will win, no? To put it simply, if there is an alternative, we use software that is _better_ (having less papercuts is one way of measuring, I guess).
So if you have 2 software options to choose from, and they accomplish the same thing (or, at least, they are both designed to accomplish the same thing), which one will you choose: one that sucks more or one that sucks less? Or, if you think that all software sucks - one that sucks or one that sucks just a little less? There basically is no product (software or not) without some cons; so in the case pros are the same, wont you choose the one with less cons?
Papercuts and other bugs/UX-issues do matter, but as with anything it’s contextual.
Is the application providing more value than the issues detract? Are there enough issues that the balance is no longer in favour of using the application?
That’s why the phrase is “death by a thousand papercuts”. A single one won’t push a user away, but many of them combined will.
The more common phrase is in fact "death by a thousand cuts", referring to an excruciating [sic] Chinese method of execution. https://en.wikipedia.org/wiki/Lingchi
Ah true, I should have mentioned that. But both do exist in common parlance (obviously the papercut one is the derivative) but I figured papercuts was more apt.
Life is full of papercuts. You just have to choose your battles wisely when taking them on, whether it’s software or a creaky floor in your house or anything else.
To author - what a missed opportunity to use "superglue" as a healer and metaphor. Temporary fixes are probably good enough - these cuts will be re-absored by another team later, anyway or washed away by organizational/product learning.
Do they matter? I'd argue that yes, they absolutely do.
They might not make people refuse to use a piece of software, or actively seek out an alternative - but they're certainly going to result in users having a lower opinion of that software, and make them more likely to take notice if an alternative happens to come to their attention.
I have a reverse corollary of this, which is: As I do/use things that are useful/interesting despite of their papercuts, then if I don't do/use something because of perceived "papercuts", they are probably not really the reason.
Examples are not recording music because my audio interface is a bit too laggy, or not taking photos because my camera lens is a tad blurry in the corners. The real reason is that I'm not motivated / inspired enough and like to blame the "papercuts" of my gear.
To the artisan/craftsman writing code for their own pleasure? Yes!
To FAANG scale companies in their primary user interactions? Absolutely! (The big guys measure substantial revenue impact from almost-imperceptible latency differences, for example.)
Always, in every context, over every other thing you could be doing, without prioritization? Of course not.
I think the “always fix paper cuts when you hit them” mindset could be great in some places. You would not last long as a startup if that was your philosophy.
Papercuts are worthy of special consideration though, because if you ignore them, they can in aggregate build up to a substantial drag. Just make sure you talk to your users, measure your funnel, and watch them use your product. If they are delighted, you probably don’t have too many papercuts.
74 comments
[ 0.66 ms ] story [ 175 ms ] threadInconsistent, and oft very much a matter of opinion.
If there's a race condition which causes a loading indicator not to show up it's a bug, but is it a bug if nobody put in a loading indicator because nobody cared, or considered that the operation could take sufficiently long some signal would be useful?
Meh. It's just as often that they're trying to get something changed against maintenance or stability policy.
But a bug doesn't have to be a malfunction. It can be a terrible UI flow or other annoyance. But if it's not what the designers had in mind, it's a bug.
is a great phrase, and I'll use it.
This is something which does happen in the real world although I don't know that there's a term for it (hence papercut being used instead, as an unnecessary recurring issue which in the grand scheme of things is not exactly deadly — as opposed to sharp edges, which are usually APIs which are tricky to use).
For instance it's common to have bits (of varying sharpness) sticking out of walls and other surfaces onto which things or people will repeatedly snag. Or uneven flooring.
They are generally minor annoyances people live with, though they can cause actual harm (falls, wounds).
and if its located in a high-tension spot (papercuts are always located there like fingers), well then you need band-aids otherwise its recipe for churn.
papercuts is perfect for the methaphor. its tension area, high traffic spots. but the author missed the point about super glue (or duct tape, in other authors words)
It's called a papercut after the "death by a thousand papercuts" chinese torture / execution method. The idea is that a single papercut by itself may not "kill" the project, but collectively they will bleed the project to death out as much as a single massive death-blow.
When viewed from this angle, it's a perfect metaphor.
I think that if you're a small fish swimming in a big, shark-infested pool, it's the only viable strategy.
We should consider more collaboration on open source software, rather than competition. Meaning, creating a competitor platform that many people contribute to like ants. Also open protocols and standards like HTTP, SMTP, EVM, etc.
Wikipedia beat Britannica
The Web beat AOL, MSN, etc.
Linux and BSD beat proprietary platforms on many platforms (including Android)
Science beat alchemy
Often we think "more competition" is the only way, but collaboration and gift economies can over time beat closed silos that compete.
Like sure, ok, most software works, but I don't think it's a waste of time or effort to strive for something beyond barely functional.
It also only approaches this problem from the viewpoint of a developer. As a user of dozens and dozens of pieces of software daily, each with their own annoyances and weird behaviors that don't necessarily stop me from using it, that shit stacks up.
I recently watched a bit of Triumph of the Nerds, and caught a snippet where Andy related a similar story to the camera: <https://www.folklore.org/StoryView.py?project=Macintosh&stor...>
5 or 10 seconds at boot doesn't seem like a lot, but shit stacks up.
If your potential users don’t really see the benefit of your app, no amount of pixel-perfect rendering is going to help.
It’s very way to end up arguing with straw men about made up categories.
What you define as “paper cuts” is probably very arbitrary and would differ significantly between individuals. It only makes sense in the context of an existing backlog of issues that is properly groomed and labeled. Otherwise you may as well just call them “pet peeves” instead. It’s totally subjective.
So whether they “matter” or not is really unanswerable outside of that context, and frankly not very interesting within that context as well. If they mattered they would already have been fixed…
I just don’t think this is true at all. I’ve always been on teams where the backlog of issues with very real business value (for any value of “matters”) far exceeded the capacity of the team. Given that, it meant that there was a constant battle of prioritization. That process ought to include “Papercuts” as an input variable, for sure.
Now if it turns out that your highest priority issues are now just paper cuts, then congratulations!
We've all seen P.O.S. enterprise software products that take the "we-don't-care-about-paper-cuts" attitude to an absurd extreme. Everyone who has to use them uniformly hates them. I am looking at you Oracle, MF-er!
The thing is paper cuts are everywhere, you're going to run into them, it's part of why you're paid to do what you do. The Chinese have a word for this. I think it's "Chabuduo", it's a kind of nonchalance about snags and imperfections in favor of getting stuff done. It works. To an extent. At some point, however, you have to get your shit together and address the snags that come up over and over again. If you don't it's a sign of not caring about the people doing the work and the people who have to use your product.
There's another word that's the opposite of "Chabuduo". It's "mise-en-place" from the realm of cooking. It means having your space, tools, and ingredients (work materials) laid out, pre-measured, and ready to go. It's absolutely necessary, IMHO, for consistent quality work-- and not just in cooking.
Knowing when to "Chaduduo" and when to "mise-en-place", I think, makes for the most productive work.
That doesn't mean you shouldn't be improving quirks and annoyances in the product, but such things should be proportional to work that delivers value.
At some point, it can devolve into perfectionism and grind all meaningful progress to a halt.
I suspect too many of these papercuts might leave a door open that lets bugs in.
When a competitor comes along, you know where the users are going.
But "papercuts" is a weird name. They are bugs. Bad bugs but not bad enough that the author wants to fix them.
Even if every bug were to be fixed, one would be frustrated by behaviors that are clearly intentional but stupid, usually because someone tried to over-simplify something[1], hack in a "helpful" shortcut[2], or has aesthetic preferences against supporting complex use cases[3].
Finally, beyond those two great lakes of bugs and bad ideas, we come to the endless ocean of missing minor functionality. The comic reader that lets page order be swapped for manga but doesn't change which arrow "next page" is bound to; the web browser that doesn't allow translating a page unless its language heuristics get tickled in the right way; the mobile keyboard that couples auto-punctuation with spelling correction.
It's like the joke about wine snobs -- if you don't know much about wine then most wines taste fine, but if you take a wine appreciation course then you'll never be able to enjoy it again.
[0] three weeks ago: https://bugs.ghostscript.com/show_bug.cgi?id=706551
[1] A lot of GNOME's applications fall into this category, for example its "Document Scanner" vs xsane, or "Music Player" vs Rhythmbox/Banshee.
[2] two weeks ago: https://mstdn.io/@jmillikin/110211856191257399
[3] I am annoyed daily by crates.io lacking per-user namespaces, and the primary objection to adding them seems to be driven by a preference for single-token package names.
There are three general directions crates.io package namespaces might take, and aesthetics plays a major role in not currently having any of them:
1. Use human-readable strings as on Github, yielding package names like `jdoe/some-package`. The crates.io maintainers prefer to avoid this due to potential operational load from people requesting changes to their username.
2. Use opaque (but stable) namespaces such as an integer user id, yielding package names like `user-12345/some-package`. Some people have a strong aesthetic aversion to this.
3. Assign each package a UUID. This is technically possible in current crates.io if the leading character is [a-f], but I've never felt mean-spirited enough to actually do it.
My two cents is that paper cuts hamper productivity more than anything else. Even if customers don’t care about monthly downtime/small gotchas. The dev team will have to spend time thinking about it and dealing with it. A company with a 2 hour build, and multi day test cycle will naturally have dev productivity near zero.
That said, the surface area for any product is huge. It makes sense to prioritize paper cuts that have ROI. Otherwise, you'd never ship. And it is fundamentally true that customers buy and use because it gets their job-to-be-done finished, despite the paper cuts they'd have to wade through.
But like our most closely-held ideals, we may never reach them, but it doesn't mean we should stop trying entirely. Besides, once they find an alternative, or a competitor becomes viable, they'll switch. Paper cuts don't matter, until they do. It's a debt of another kind, where the piper will always come knocking eventually.
From a craft point of view, they all matter a lot. We all want to make products that are actually good on every level, right?
But, as you say, you can't optimize for everything.
Because there is no viable alternative. If the two pieces of software offer same (or at least similar) features, one that has less "papercuts" will win, no? To put it simply, if there is an alternative, we use software that is _better_ (having less papercuts is one way of measuring, I guess).
Hum... I don't think people give-up or adopt software based on minor annoyances at all. I have never seen this happen on practice.
Is the application providing more value than the issues detract? Are there enough issues that the balance is no longer in favour of using the application?
That’s why the phrase is “death by a thousand papercuts”. A single one won’t push a user away, but many of them combined will.
They might not make people refuse to use a piece of software, or actively seek out an alternative - but they're certainly going to result in users having a lower opinion of that software, and make them more likely to take notice if an alternative happens to come to their attention.
Examples are not recording music because my audio interface is a bit too laggy, or not taking photos because my camera lens is a tad blurry in the corners. The real reason is that I'm not motivated / inspired enough and like to blame the "papercuts" of my gear.
To the artisan/craftsman writing code for their own pleasure? Yes!
To FAANG scale companies in their primary user interactions? Absolutely! (The big guys measure substantial revenue impact from almost-imperceptible latency differences, for example.)
Always, in every context, over every other thing you could be doing, without prioritization? Of course not.
I think the “always fix paper cuts when you hit them” mindset could be great in some places. You would not last long as a startup if that was your philosophy.
Papercuts are worthy of special consideration though, because if you ignore them, they can in aggregate build up to a substantial drag. Just make sure you talk to your users, measure your funnel, and watch them use your product. If they are delighted, you probably don’t have too many papercuts.