Yeah, I see this all the time in my team and this article really succinctly sums it up.

It doesn't negate the backlog and the never-ending work - the takeaway here for me is that sometimes you do indeed need to step back and say "Hey me and the team worked really hard on this, come look"

You are talking about core work. The article is about tangential work, which is just as, if not even more neglected in sw dev. In academia there is at least a tradition of publishing, lecturing and review.

What is core work and what is tangential work?

Writing code vs documentation, support, marketing etc.

This may be a fallacy. It is all connected. Some of the connections are not obvious at first. It's very tempting to create interesting features for your own edification or satisfaction, and leave them nearly undocumented. Years later, kind-hearted strangers discover these in the code and wonder why no one knows about them. Sometimes, it's like code that you just wrote for yourself might as well not even exist for the rest of the world. That's just one facet of this situation.

While there's a lot of truth to this, arguably the "done-ness" of a project has little to do with the project itself, but the intentions of the author.

I have a project on the brink of release. I'm tossing it over the wall, announcing it to the community it's directed toward and have no real intentions to move it forward. I am satisfied with it.

It's a "90/90" project. That last 90 pushing it that last mile of polish and such. It is still imperfect, and it will remain that way. I have grander designs and plans, and I'd rather have imperfect but serviceable distributed and released than have it "more perfect", but sitting on my hard drive. I also don't want to engage in any real back and forth with the community to fix what they may find imperfect. I'd rather put my time in my next effort.

If some real showstopper raises its head, I'll certainly address that. But I consider it "feature complete". Because what I certainly don't want, is a half done project, with any hopes raised or promises made only to have my attention off chasing some other shiny thing (which it is wont to do).

But a lot of the last 10% has been spent on "stuff I hate". I consider myself a framer and drywaller, leaving the mudding and finish carpentry to others. So, it's been a bit of a slog, but the summit is in sight, adding some wind to my sails to get it over the top and ship it out.

I've got myself to a position where I feel that a project is "done" when it has solid tests and comprehensive documentation.

Sure, I could add new features in the future - but I no longer feel actively guilty about things that are missing from it. And someone else could pick up from where I left off if they really wanted to.

In some cases, this advice might apply to product manager (or whatnot) at the point they decide to push/ship a feature/product.

  - Code does the thing and is at 90% polish 
  - *or 80%, 50%, etc. This is a quality issue. Off topic, IMO, as this is about completion, not quality or polish* 
  - Ship the feature to 3 enterprise clients boss promised for Q3.
  - Now you are at the point this post is about. 

At this point it's time to open your POV to understand again what the thing is about. What are the clients going to do with it? When? Who? What's the communication chain?

Now your job is to communicate. Understand who's involved. Listen to them. Communicate to them. Write a few emails well formed, high effort emails. Do presentations, live tutorials, assisted user sessions. Have goals in this space.

Within a "job," people can be very insulated from the brutality of the last 10%. It's possible (also comfortable, normative, etc) to read the paragraph above this one and say "not my job." That can apply to software, research and lots of other areas.

"Think outside the box" is usually presented in neutral ways that don't challenge us emotionally too much. That's a play version. The real box is our definition of the job, task, project, etc. Real, objective success is usually dependant on stuff outside this box. Success is when the client uses the software, likes it and gets benefit. Sales thanks you. Your boss is happy. Everyone gets a raise and they bring back pizza Tuesday.

An impossibly broad definition of success is emotionally impossible. It's too hard, too much failure, too little success, too much. Being so broad, it can also disconnect our alignment from the company's. Even in academia, the broadest possible betterment of science is not usually a workable POV.

So... the workaround is to expand and/or break out of the box at strategic points. Shipping is such a point. That allows you to have your (necessary) box but not totally neglect aspects outside of it.

I'd actually advocate to stop before 90% so that you can figure out if the 90% is the right thing...

I think it's more that the last 10% is very hard, and often times not worth it. People love to cry about not having documentation, but when it exists they complain about quality, and when quality docs exist, nobody reads them.

That's just documentation. The same can be argued for things like code quality and unit testing... not integration testing tho ;)

I suspect when quality docs exist, no one _complains_ about them.

Having poorly-written docs can sometimes be as bad as no docs at all.

I just experienced this a few hours ago where I integrated a new library, tested in CI and locally. We see errors in production. Why? A connection configuration that I thought would merge with the defaults _replaced_ the defaults. The docs don’t mention this at all, but it’s pretty crucial for going to production.

This isn't the greatest example. You're talking about an omission to the docs, so what you really wanted was MORE documentation. I can't really see how the docs lead you astray there, just that you "thought" it was different.

This is illustrative of the problem with docs. It's shockingly hard for developers to predict when enough information is enough. Assuming it were wrong information, now the docs can't be trusted!

In my experience, there's something else going on. Understanding software is hard. Often times, you have to roll up your sleeves and do some work to get the hang of it. This makes documentation an easy scapegoat.

I can't count the number of times, I've had people complain about not finding something that was clearly explained in the docs. It's not that they aren't reading either! They actually read the text, don't understand, maybe don't even recognize that they don't understand and keep reading.

I've also seen where very good documentation exists, but it contains some irrelevant information. So, I'm expected to write a smaller, almost certainly worse document, by telepathically figuring out what parts "matter for our project".

I've just seen so much bullshit in complaints about documentation. After a while, it just looks like people don't who understand (reasonable), getting upset and looking for an out. After all others understand, what are you bad at engineering?

This mindset is often driven by cultures and personalities. It's one of my pet peeves about engineering.