
It’s Never Going to Be Perfect, So Just Get It Done - mhb
https://www.nytimes.com/2019/07/07/smarter-living/its-never-going-to-be-perfect-so-just-get-it-done.html
======
dgreensp
I’m reminded of a similar online NY Times piece I read, years ago, I think by
a woman named Gladys, which was entirely about the harrowing process of
procrastinating on, and eventually writing, the piece. All I could think was,
poor Gladys. Not, here’s an authority on procrastination. Heck, I’m more of an
authority on procrastination, based on my high school and college years alone,
not even counting that I’ve overcome it in my 30s.

There is so much better advice than “just get it done” (isn’t that like
telling a commitment-phobe, nobody’s perfect, so just pick someone and commit?
I’m sure someone, somewhere, has given themselves that advice and taken it,
with positive results, but it’s kind of questionable advice in general).

For example, “meditate” is good advice. Let the anxiety come up; allow it to
flow, and leave; see it without judging it or trying to figure it out. Even
realizing your problem with starting is an anxiety problem, and feeling the
feeling in your body, is a huge step. Maybe noting some beliefs that
contribute to it. “Journal” is good advice. Practice writing in your voice,
and the act of writing. Journal about your anxiety. Learn to enjoy your
writing. Practice will improve the quality. Discounting quality will not help.

Stories about how I procrastinated on something for a month and then late one
night managed to forget my usual thought patterns for an hour and do it? I
have hundreds of those from my past. There is some information in the thoughts
I had when finally doing it (“I get it! You just do it!”), but not relative to
the information you will get from going inwards and asking how to change your
own patterns of feelings, thoughts, and behaviors.

~~~
ohazi
I often tell myself to "just start" rather than to "just get it done,"
especially when I suspect my anxiety is driving.

If I tell myself I'm just going to sit down and pretend-work on the thing
that's making me anxious for five minutes, just to get a feel for it, and if
it ends up being crappy, I'll just toss it and start over later, I'm usually
able to short-circuit the anxious "everything must be well-understood and
perfectly optimized before you even start, or you're going to fail, because
this problem is crazy hard" part of my brain.

Usually five minutes turns into 45 minutes, and I either finish, or conclude
that it wasn't so bad after all.

~~~
Buttons840
> pretend-work

I pretend I'm live streaming my programming session, it seems to cause some
switch to flip in my brain and seems to help.

Maybe I should actually live stream? But I probably wouldn't have real
viewers, and don't know how to fit multiple monitors into a stream.

~~~
koolba
I'm convinced that the majority of the value from pair programming (literally
sitting next to each other, not "virtual" pair programming) comes from the
fear of looking like a lazy idiot in front of the other programmer.

~~~
mathieuh
Hah same here. Half the time I ask someone to pair with me it’s because I
simply cannot muster the motivation to do anything for whatever reason. I find
I go through a couple of weeks of this a couple of times a year, I guess you’d
call it mild burnout.

~~~
lixtra
If you assume mild burnout, do you think it’s long term the right strategy to
force yourself through it? What would your body have to do to tell you that
it’s not mild anymore? What if it does? Take care!

~~~
brennebeck
Just a bit of anecdotal experience for additional thought: I did the same for
years, ignoring the signs, pushing through long hours, etc. and eventually
developed idiopathic epilepsy. As it’s idiopathic, there’s no known direct
cause (e.g. no head trauma, no tumors, etc.), but there’s a decent amount of
evidence that supports at least a strong correlation between my lifestyle
(lack of sleep, overwork, etc.) and the development of the disease. And of
course lack of sleep is now one of my primary triggers, but that’s also fairly
common amongst epileptics once the disease is ‘active’.

Best wishes GP.

Edit: point really being: it’s mild burnout until it’s not.

------
CM30
Well, they've got a point. There are definitely quite a few projects whose
creators needed to step back, stop spending years focusing on the wrong things
and actually get something done. I mean, look at Duke Nukem Forever. Might
have done pretty well had they not spent 14 years on it. Same with many other
games and pieces of art that spent decades in development, and sometimes
bankrupted/broke their creators in the process.

Does that mean you should rush? Obviously not. Does that mean having an eye
for detail is bad? No, not at all.

But it does mean you should try to finish your projects at some point.
Something that never gets released at all is pretty much useless, and it's
probably better to get your products while you're alive rather than have them
released posthumously by your estate.

It's also probably worth pointing out that a creator will likely never be as
happy with their work as a customer will. After all, you created it, you've
got nothing to be surprised by. So right off the bat, some of the 'magic'
found in experiencing a piece of fiction/work of art for the first time is
immediately gone.

You're also quite likely to see all the flaws, all the things you could have
done better, all the possibilities that didn't pan out yet, etc and feel
disappointed compared to some ideal you had in your mind.

~~~
bluGill
For software you should make something - any part - work and release it. Then
do regular feature releases after that.

If you are not working alone you can ask your marketing people for help,
sometimes it is worth waiting for a big bang release, sometimes not (For some
things if you miss Christmas you should delay until next Christmas). I
recommend you err on the side of release too soon - customers are the ultimate
answer, if their feedback on what is important is useful to have (but their
feedback is not always correct!)

~~~
paddlepop
This doesn't work so well for video games. Reviews come out saying its thin on
content with a score to match and can kill a game before its had a chance to
expand. Developers have started trying to do this more often lately with mixed
results, DICE and Blizzard are high profile examples of this. Blizzards latest
World of Warcraft expansion was heavily criticized for the lack of content on
release day and has yet to shake the bad blood even after two big content
patches. DICE tried this with Star Wars Battlefront but couldn't keep fans
long enough with the limited maps it released with.

~~~
nostrademons
It doesn't work for AAA games, but it can work really well for indie games.
Think of something like Factorio, where version 0.1 looked like this:

[https://www.factorio.com/blog/post/fff-184](https://www.factorio.com/blog/post/fff-184)

Then they just kept releasing every week for 7 years, and now you have people
building CPUs and explaining Apache Kafka with it.

Ostriv is another recent game that comes to mind as having a similar
development cycle. Also many F2P MMOs - most of the non-Blizzard online games
I know do regular releases that frequently change the game mechanics (often,
to a big player uproar) but still keep their userbase. Fortnight and Pokemon
Go are two big ones here.

~~~
georgeecollins
Lots of games come out in early beta now and raise money through sales as they
are developed. It is a better model than crowdfunding for games, because you
start from a demonstration of competence in game development and you (usually)
have direct view into the development process.

------
andrewstuart
I still build out everything required to realise the vision, and that usually
takes at least months to build.

There's an analogy in startups that you should build a great skateboard first
if your vision is to build a better car, but I just don't agree.

If you have a vision for a better car then you need to deliver a better car,
not a skateboard, because, well a skateboard just isn't a car.
[https://blog.crisp.se/2016/01/25/henrikkniberg/making-
sense-...](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)

If my idea is to create a business for sharing cars, but it's cheaper and
quicker to build a business where local kids drive you around on their
pushbikes, I just don't see that as being the same. Those who argue for
skateboards versus cars would say "well you are solving the problem of rental
transport and starting in a practical way". Meh.

The other thing I think is important is not to waste the initial attention for
your product on something that is not in fact the true vision of what you had
in mind.

But so far I haven't succeeded so my philosophy can't be given much credence.

~~~
nostrademons
In practical startup terms, if your idea is to deliver _either_ a better car
or a better skateboard, you've already failed. Both these industries have a
century of optimization behind them; even if you did manage to catch up, any
useful innovations would be copied by incumbents. Successful startups usually
come out of _new_ markets: areas where the environment has changed such that
existing product categories or delivery channels no longer match what
consumers want to do. You can't really define these as "better" except in the
sense of users adopting them rather than existing alternatives: if you could,
the existing companies would've done it.

Rather than designing a great skateboard or a better car, your goal might be
to design the Schweeb, or OneWheel, or Segway, or HyperLoop, or rideshare or
scooter rental company. There're still plenty of ways to fail with these, but
at least you have a chance of success.

~~~
andrewstuart
The real question is "what, _exactly_ is an MVP?"

Some people interpret an MVP almost literally as almost nothing - just a web
page that describes the idea and asks for email addresses.

Others interpret the MVP as almost nothing, but a "workable" almost nothing -
i.e. some code that users can find. After users have found it, the code will
be iterated upon until the original vision is realised.

The skateboard people interpret an MVP as making a series of easier-to-build
similar, broadly analagous products on a path to eventually building the full
product that you envision.

I interpret the MVP as being the minimum system that completely realises the
vision. That might takes months to build. but the point is that when any user
sees it, they should understand completely what this thing is meant to be. It
doesn't mean the software is complete in every possible way, but it does mean
that everything needed to make original vision working and obvious.

Speaking to the original post, this takes time and it might take alot of time.

~~~
nostrademons
The vision is irrelevant to the customer.

There's an easy way to tell _in hindsight_ whether something was an MVP. Did
it get beaten to market by someone who came out with something worse? Then
it's not Minimal. Does nobody use it? Then it's not Viable. Do they get bored
and move on? Then it's not a Product.

Doing this with foresight, so you're the one who actually puts out the MVP for
the market and captures it, is significantly harder. Whoever manages to do
that ends up rich, so if it were easy, we'd all be rich. But a general rule of
thumb is that if the world is moving on and _other_ people are getting rich
while you sit there refining your idea, your idea of "Minimal" isn't actually
minimal, while if you're continually pumping out ideas that nobody likes, your
idea of "Viable" isn't actually viable.

~~~
mamon
>> The vision is irrelevant to the customer.

Having vision for a product means correctly identifying customer's problem and
proposing a solution for it. Dropbox vision is: "Make user files accessible
anywhere, by storing it in the cloud synching them across devices". Google's
vision is: "Make all information in the world easy to find and access, by
having search engine know you better than you know yourself" :)

Customers either buy into your vision, or ignore it, and the latter means that
the problem that you stated does not exist or is not important enough to your
users.

For you, having clear vision helps you create MVP, because you can easily
identify which features are crucial, and which are nice to have.

------
Millennium
I really wish I could stop seeing this everywhere I went. I get that there are
people who need this kind of advice, but for someone like me, this advice is
poison. For everyone who needs to be carefully and constantly reminded that
you can't let the perfect become the enemy of the good, there's someone else,
maybe several someones, who need to be carefully and constantly reminded that
"good enough" is almost never good enough. And this latter group, when left
unchecked, tends to do a lot more harm than the former.

~~~
rtpg
This is definitely in the category of advice (much like GTD) of "if you don't
think you need this advice, you probably don't need it."

I feel like there's an alternate wording for this advice that is less "cut
corners" and more "determine how many corners you don't want cut".

Maybe involving a target condition? You want to make the best thing possible.
Keep on aiming for the best, but establish a baseline that you would find
acceptable. Maybe you won't make something perfect, but you'll now have a
target that you _can_ get to.

This thought process reframes the discussion of "good enough" away from "did I
spend enough time on this? Surely I can spend another week and make it 10%
better" to "Does this meet the requirements". There is no longer a debate to
be had, just a yes or no question to answer.

So when people ship things that just aren't good enough you don't have a
discussion around spending more time on things or being more careful, you have
a discussion around what your baseline requirements are (which is _actually_
what you care about).

~~~
Millennium
This makes sense to a certain degree, but "just ignoring it" only goes so far:
even seeing it is corrosive to a certain extent, and by the time you've even
registered it enough to ignore it, a lot of the damage is done.

Perfectionists undergo a similar phenomenon, I'm told. After all, the modern
"Do it badly" movement was itself a response to the corrosive effect of the
"'Good enough' isn't" message permeating all of society. I'm not
unsympathetic. In solving one problem, it didn't exactly create another -we've
always had perfectionists to some extent- but it made that problem much, much
worse than it had once been. But the fact is, it was done to solve a real
problem in its own right, and that problem has not gone away.

What it comes down to is conflicting needs. The all-pervasive "'Good enough'
isn't" came about because some people genuinely need it, and they genuinely
need it at that level. The same is true of the now-pervasive "Do it badly": it
is genuinely needed, and at this level. And you can't balance them, because
they inherently undermine each other. So what do you do?

------
tabtab
Steve Wozniak suggests the Apple II became successful because he's a
perfectionist. He talks about throwing out almost-finished designs because he
thought of a more streamlined approach while implementing the existing one.

Then again, Steve Jobs has suggested that "Woz" spent so much time fiddling
with Apple II hardware that he never got around to adding floating point math
to Apple BASIC. (They probably should have hired somebody else to work on
BASIC if Woz seemed more hardware-oriented.)

~~~
cm2012
Perfectionism is great when you know exactly what the customer wants (like a
custom made shoe). It wastes too much time when you're experimenting to find
out what the market wants.

~~~
jdsully
The part I’ve always had trouble with is you need a certain amount of polish
before the idea is acceptable. The quality of delivery heavily influences
people’s perceptions. So this is a very fine balance.

~~~
cm2012
Quality is local optimization, Market Fit is global optimization. As the
saying goes, if you're not embarrassed by v1 you waited too long to launch.

~~~
piker
But consider results in consumer technology: Palm versus Blackberry versus
iPhone.

~~~
glennpratt
Did you use the first iPhone? It had a ton of gaps, even in the market at the
time. I believe they would have hamstrung it if not addressed in subsequent
versions.

I personally have never viewed iPhone as an example of perfectionism in
product delivery. To me it's a whole bunch of solid execution over a very long
time scale, before and after introduction.

~~~
rchaud
Consumers and the press were much more forgiving of the iPhone's shortcomings
than they were with anybody else. The 2007 iPhone was 2G only (when 3G on
Nokia, Samsung, and Blackberry phones was standard), and it constantly dropped
calls on AT&T in the US. Steve Jobs was in full reality distortion mode thanks
to several successful iPod/Mac releases, and people loved the showmanship.
Loyalty to Apple wasn't purely about the quality of the product.

The Blackberry Storm was released in 2008 to compete with the iPhone and was
completely trashed by critics, despite doing the basics extremely well (call
reliability, high quality capacitive touchscreen). I had one at the time and
apart from the fact that BBOS 6 wasn't 100% touch-optimized, it was very
usable. Unfortunately its app store was lacking, whereas the iOS app store had
plenty of flashy, gimmicky apps that better served as a showcase for the
iPhone's capabilities (gyroscope, motion sensor, etc) rather than useful
functionality.

~~~
jdsully
The polish was in the fluidity of the interface. To make touch easy the
interface couldn’t jump around just as you touched the screen.

Its not that the iPhone was fast - but when it couldn’t render it showed a
square pattern and still scrolled roughly in tune with your finger. None of
the other players thought that was important.

~~~
rchaud
Wow, that took me back...I remember the little mosaic graphic to display parts
of the web page that the browser hadn't loaded. Feels like a lifetime ago, but
it makes sense to have that little bit of UX improvement, since back then all
we had were full-fat desktop websites.

------
pier25
At least in software "getting it done" is only half the problem. The real
problem is knowing how to find a balance between _good enough_ and
catastrophic long term consequences. It's a balance between tactics and
strategy.

The approach is different in other disciplines such as artistic creation where
blind confidence in what you are doing is a better long term strategy and we
give a lot more importance to tactics. The more you work the better you
become.

~~~
robotsquidward
This comment speaks to me. I'm in a weird point at my job where I'm right at
the tail end of supporting this legacy app I've worked on for years, and a
brand new app my team will be building from scratch.

It's pretty surreal, because I've been dealing with many of the negative long
term effects of decisions that were made for this app years ago, meanwhile I'm
about to have to make a whole host of similar new decisions for the next app.
I know there are going to be compromises, I know I won't be able to make it
_perfect_ , so finding that balance is going to be critical.

I'd love to hear from someone who's had to find that balance and what they've
learned.

~~~
pier25
I'm sure you learned _a lot_ about the problem from maintaining the legacy
app.

There is some intuition that develops over the years, but honestly the only
reliable way I've found of knowing how to properly solve a problem is solving
it multiple times.

------
jhedwards
I had the same negative reaction to the title that other commenters had, and
of course I was thinking about software. But then I opened the article and saw
a picture of a canvas and my mind shifted to music.

I know lots of people who love to write music or want to write music but can
never get anything done because of a feeling that it has to be perfect. I have
always embraced an aesthetic of rough imperfection in my music and (I suppose)
as a result I have record over 30 albums and EPs. Sure, lots of that music is,
well, cringe-worthy, but there are some gems in there that wouldn't exist if I
let perfectionism get in the way of _production_.

~~~
pier25
For artistic creation I always come back to this anecdote from the book "Art
and Fear":

 _" The ceramics teacher announced on opening day that he was dividing the
class into two groups. All those on the left side of the studio, he said,
would be graded solely on the quantity of work they produced, all those on the
right solely on its quality.

His procedure was simple: on the final day of class he would bring in his
bathroom scales and weigh the work of the “quantity” group: fifty pound of
pots rated an “A”, forty pounds a “B”, and so on. Those being graded on
“quality”, however, needed to produce only one pot – albeit a perfect one – to
get an “A”.

Well, came grading time and a curious fact emerged: the works of highest
quality were all produced by the group being graded for quantity. It seems
that while the “quantity” group was busily churning out piles of work – and
learning from their mistakes – the “quality” group had sat theorizing about
perfection, and in the end had little more to show for their efforts than
grandiose theories and a pile of dead clay."_

~~~
bluGill
That anecdote seems to be a story that was just made up. It is believable if
the students have never done ceramics before, however if the students have
done a lot before I would expect thinking about what to make would become more
useful than doing something again for the millionth time.

~~~
zaphod4prez
I also remember this story and hearing that it was just made-up rather than
real. However, I know a lot of professional artists and most of them do not
have a process that consists of "sitting and thinking about what to make." It
is often a generative process that consists of making small/sketchy things and
iteratively fleshing it out. In other words, although that anecdote doesn't
seem to be referencing any sort of study, it matches very well with my
experience in the art world & in teaching art.

~~~
bluGill
I agree that spending most of a class thinking about what to produce is not
useful. However just creating without thought isn't the best way either.
Someplace in the middle is where to be.

That is get an idea, and create it in sketch form. Then examine the sketch
(often waiting a few days is required to be a good critic of your own work).
If the idea is good start fleshing it out a little at a time - examining it
critically at each step. In some mediums you can erase, in others you need to
create a new sketch of the same. Eventually you get something good. Many
artists will have more than one piece in progress at a time so they can have
that break to get away from their mental investment and look critically at it.
(this last is not universal)

------
JetezLeLogin
So-called satisficers are happier with their decisions probably because they
_are decisions_ , that give them a sense of control. "I chose this 'good-
enough' option, I will now proceed." In other words, if there exists some
better path out there, I don't care, because this is good enough, and I want
to proceed. It's all coming from, and directed from, within. You are the agent
in charge.

Whereas so-called maximizers are always at the mercy of an external world that
might contain a previously-unknown "better" or "best" option that they feel
obliged to find. It comes from without; the world is in charge, the vagaries
of a perfect ideal are in charge; the person is only hapless and reactive.

Thinking you're in control of your destiny (even if it's not true) is more
satisfying for people.

------
darkmighty
There are several kinds of procrastination, so it's impossible to generalize.

Some projects require very large time commitment to get right, reworking
several times, etc. Some others reach a diminishing return stage very quickly
and continued effort is wasted. You definitely shouldn't just take whatever
you have in front of you and just rush it until it's barely workable.

The critical skill is to be able to judge without anxiety and with some
precision how much additional time is going to improve the outcome, and what
is the rough global value (to you) of this improvement. Some projects have
long ramps of effort and refinement, some are just not worth the time and can
arrive at a good enough stage very quickly.

I think the best advice I could come up with is that if you're having this
sort of problem, recognize it, try to deal with the anxiety and get a
perspective on the risks vs benefits, and improve. If possible find an
environment/hobby /side occupation where you have to make a ton of such
decisions to get a lot of practice. College/personal projects tend to be
pretty sparse and give a lot of room for failure and delaying I guess.

For me it's been a very slow, progressive realization that I'll never get
things I wanted done by just leaving them to an arbitrary later date, or
obsessing too much over details. In nothing vs something, something wins.

------
ravenstine
This is exactly what I was saying in the other HN thread today about code
reviews, and I got downvoted a bunch of times. A lot of people have a
perfectionist mindset and lose sight of the fact that "perfection" can be
subjective and that the product they are creating _for the user_ is more
important than the engineer's personal vision. This isn't to say that we
should just throw out best practices, wing it, and never take criticism. Being
_willing_ to break work into further tickets and _actually_ giving them
priority can mitigate long-term problems created by imperfection in the first
place.

~~~
opportune
This sounds like some non-engineer talk that ends up fucking the team up 1
year later as there code starts breaking everywhere, the code becomes very
difficult to refactor, new hires start to struggle ramping up, etc.

I agree that sometimes people can be too focused on perfection in code reviews
but consistency, modularity, and other seemingly unimportant things are
crucial in maintaining hygiene for your project

~~~
ravenstine
> This sounds like some non-engineer talk

Does it merely _sound_ like non-engineer talk, or is it _actually_ non-
engineer talk? I just want to make sure you aren't making the wrong assumption
or implying the wrong thing. I've been saying what I've been saying as a
result of my 5+ years experience doing full-time software engineering.

> I agree that sometimes people can be too focused on perfection in code
> reviews but consistency, modularity, and other seemingly unimportant things
> are crucial in maintaining hygiene for your project

It's interesting to me how easily people here are assuming that I'm implying
the absence of standards merely because I'm suggesting people opt not to chase
perfection in favor of providing a non-blocking pathway for engineers to make
changes or improvements. Maybe my phrasing is poor.

I don't think you and I disagree that consistency, modularity, etc., are
important and should have some amount of enforcement. The point I'm trying to
make is that, in my experience, people sometimes go _too far_ with this, so
there should be some set expectations as to the limits of an individual code
review. Limiting the amount of review iterations in a unit of work and
splitting feedback-related work into other tickets can help address the issue
of perfection zealotry.

~~~
opportune
What I meant is, I've heard this kind of language from non-engineers before
(mostly PMs) trying to get developers to ship something in a bad state. Most
probably because they'll be gone before they start having to deal with the
repercussions of the technical debt.

>Limiting the amount of review iterations in a unit of work

Fully agree. I think there should only be two iterations max, preferably just
one.

>splitting feedback-related work into other tickets

Would never work at places I've worked. The backlog of "important tasks" is
never-ending so code cleanups, optimizations, etc. never get done because
there is always higher priority work. This isn't really in control of the team
because even if the PM agrees to let you lose a week of productivity making
the code better without adding features there's a good chance their manager,
the engineering director, etc. won't like to see that. So at least in my
experience you only have one shot at getting that code in a good state, with
the alternative being the code slowly getting worse and worse until it gets so
bad you opt for a rewrite or lengthy refactor

~~~
ravenstine
That's a totally valid point, and perhaps I am too optimistic. I do think that
a company with the right values could do that properly, but most don't,
including best ones I have worked for.

------
AareyBaba
The article is just the title stretched out into a few paragraphs. Signal to
noise ratio is close to zero.

------
myrandomcomment
Has anyone else just stopped reading stories on sites like NYT that block
reading if your browser is in private browsing mode?

~~~
dbg31415
And all the sites that won’t let me use an ad blocker or Firefox Foxus. I
don’t trust any of them not to load 300 ads.

------
beamatronic
I’ve seen some code done by perfectionists, it was beautiful to behold. It did
it’s job well. Unfortunately it was considered the “legacy system” and was
eventually retired.

~~~
AstralStorm
Some things belong in museums.

------
ljm
The problem with the headline is that if you think ‘it’ isn’t good enough,
then ‘just getting ‘it’ done’ will send you into a vicious loop that will spin
out of control as the pressure to over-achieve builds up.

You really have to reframe your view of ‘enoughness’ in a more positive light,
so instead of something being perfect (not enough until then), it’s finding a
way to see what is good enough for the time being, that allows you to move on.
Then you can go and do what you need (or do nothing if what you have is
adequate) and take the weight off your shoulders.

The startup lingo for this is MVP. There’s no getting it done with that until
you’ve reduced the scope of ‘it’.

------
thereare5lights
Just don't take it as far as Boeing did.

~~~
neverminder
Is it time for "That's what Boeing said" already?

------
quaquaqua1
Reacting solely to the headline, no.

"We're never going to find an energy better than coal, so just go down in
those mines and go earn your living like a real man!"

Critical thinking is an extremely important skill, always, forever. Not
impulsivity.

------
SubiculumCode
This is a difficult decision in science. If you are too perfectionist you will
fail. If you are not, then your contributions can be bullshit. However, there
is no such thing as a perfect experiment (at least in cognitive sciences), so
we depend on converging evidence, so pretending it can be perfect is
procrastination.

------
thom
I think many people and teams (myself included) have pretty poor self-
knowledge. You should aim to create the best product you’re capable of. Most
people either over or under estimate that, and they’re left either never
delivering, or spending the rest of their lives complaining about technical
debt.

------
pgt
Non-paywalled link, anyone? NYtimes won’t let me read it in Firefox’s Private
Mode.

~~~
Xunxi
Firefox Focus works flawlessly

~~~
chucksmash
It's blocked as "Browsing in Private Mode" for me on mobile.

------
habitue
Paywalled but, I guess the headline contains all the actionable insight
already

