Stopping at 90%
austinhenley.com
austinhenley.com
But I sat down and completely rewrote all the scaffolding around the presented algorithm, to make for a smooth and fast demo. Wrote up documentation for the implementation, gave it a command line interface, set up a script to reproduce the measurements in the paper with a single execution (downloading the required data and comparing several methods). Broadcast in all channels available to me (institution press release, LinkedIn posts, GitHub awesome list linkings). And I actually brought the demo to the workshop, which wasn't required at all, I could have just presented it as a poster.
The feedback of the people seeing the polished demo was fantastic, but now I'm sitting here with my 5 GitHub stars on the repo, after I put like 2.5 extra months of work into it. Maybe it led to more people noticing it, and finding it useful. Maybe not.
Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success.
If your reason to perfect something is internal (high personal standards and taking pride in your work) then great - take the opportunity cost in stride and finish something you'll be satisfied with. But if it's external (eg. making it just that bit more impressive to others) I'd say usually your time would be better spent moving on to the next thing.
I do see the tradeoff between spending more time discussing the project vs perfecting its technical aspects though. This can be tough for us techy folks who don't really like evangelism. In this respect, I believe academics and technical founders face quite similar challenges.
On another note, the feedback in the replies here has been incredibly uplifting, and I want to express my sincere gratitude for that.
Those 2.5 extra months could save orders of magnitude more (for users) if it does find success. The problem is those 2.5 months often don't translate into higher likelihood of success.
Consider that if you hadn't gone the extra mile, your work would with 99% probability never be useful again (I say without having seen it). Now it may be a shoulder for someone to stand on to make even greater things than they would otherwise be able to. This could be in several years, when your own attention is in a completely different space.
It does take some work (not two months) to sanitize the project, write documentation, put the boilerplate open source documentation and go through the approval process.
I’ve released 8 projects to GitHub using this process over 3 years and collectively may have gotten 15 stars in total. But the way I see it, it’s a great portfolio and the only chance in my career that I could actually show production code from work I’ve done professionally along with my resume.
Also, how many times have we changed jobs and had to solve the same problem from scratch because we couldn’t legally or ethically use code from a previous company? This solves that problem too.
Your work represents you. Even if no one stars it, you now have a portfolio of work you can be proud of that you can point to when you’re interviewing instead of yet another to do app.
On my resume while I can’t say who I did it for, I can say what I did and point to open source artifacts that came from it.
At my age now and at this point in my career, I would never spend significant time outside of work coding.
Somewhat to my surprise, I've found that at least 90% of candidates who include a GitHub username, when I go look at their repositories, either have nothing but unmodified forks of existing open-source projects or obvious "go through the tutorial for technology X" projects. I can totally get how, after seeing that kind of thing ten times in a row, people might give up looking.
But I still always look, both at the person's public repositories and at their contribution history in other public repos.
Tip: If you're applying and want people to look at your repo. Mention this in either your cover letter or on top of your resume. If it's empty, better to leave the link out altogether.
So I’m thinking about with each major bullet point of what I did in STAR format, I’ll have a footnote to the open source code that came from it
My prior two jobs came from knowing someone who knew someone looking for my particular combination of experience and meeting them.
I’m not saying I’m a special snowflake. But I’ve previously been hired for more strategy/architect type positions where the CxO or director wanted someone who was vetted.
My last two jobs before my current one and probably my next one aren’t really based on traditional submit my resume and interview. It’s based on networking and now mentioning “check out my GitHub profile” when you get a chance.
He doesn't say anything. I look around to see if my thesis is on his bookshelf, but no, it isn't there. Then I turn around & I find my thesis. It is in his trashcan. I was so stunned & shocked. My advisor says sheepishly - look its just a Master's thesis. Its not like you have discovered a new theorem or something. These results are well known in the literature.
I just put my floppy in that trashcan and walked out. Its been more than 2 decades now but I still remember that incident like it was yesterday. Literally, nobody gives a fuck.
you are taking a single experience and applying it universally - maybe most people don't care, but there are some people who do.
But yeah, Master's thesis are usually useless. (although if I had followed what I had written in my master thesis, I would be quite wealthy smh)
I worked on my master's thesis quite a bit, even worked on submitting a publication (it was in control systems and was only rejected because they wanted more empirical results). The stuff was extremely groundbreaking - we were able to get 2 orders of magnitude of better performance compared to existing solutions.
Fast forward to a few weeks back, when I was talking with a process team at a multi-billion dollar biotech company (yes, it's a huge) somewhat casually, when that idea cropped back up. Their response was basically "meh, we really don't need that much higher performance".
I'm sure if I were to start up around this, I would be able to get enough funding from the recent AI rounds from VCs. But I wouldn't have customers willing to buy this in the first place! I would be like the proverbial solution looking for a problem to solve.
The gesture is unfortunate and I understand that you were shocked. I'm curious if your view of it changed with experience however?
I mean, unless you actually discover something great - which very rarely happen, is frankly exceptional and would probably lead to a paper on top of the actual thesis - a master thesis is mostly something you do for yourself. The point of doing it is what you learn durint the exercise. It's not really intended for being read outside of your jury. An advisor might keep a few good ones to give as reference to future students but that's pretty much it.
Hopefully, your advisor actually gave a shit when he was advising you. That's where he could have been valuable.
On the other hand, I get a guy who I can see is optimistic, friendly, humble, hungry etc and know I’m going to be happy to give him his raise every 6 months. He will be a good employee which is only really 10-20% about his skill. If he gets through our technical interview then why would I even bother looking at his repos? A homemade stupid flashy website tells me he has a rudimentary understanding of computers, he’ll figure out the rest if he doesn’t know it. Are these applicants going through my history or my companies history, painstakingly preparing questions about something tangentially related to their position? I hope not, there is simply too much movement to expect anyone to care that much.
You shouldn’t care in most cases. I wouldn’t care. I hadn’t had any open source contributions since 1994 when I submitted code to the ftp info Mac archive until 2020. The only reason I have any now is because I get paid for it.
> On the other hand, I get a guy who I can see is optimistic, friendly, humble, hungry etc and know I’m going to be happy to give him his raise every 6 months. He will be a good employee which is only really 10-20% about his skill.
Are you going to do a strategic hire who only has 20% of the skill you are looking for? Are you going to hire him as a team lead? Someone leading a major new initiative without having proven industry skills?
> A homemade stupid flashy website tells me he has a rudimentary understanding of computers,
And that’s why I don’t do coding outside of work. Every piece of code I have on GitHub is running at a company somewhere and they paid my employer to use it. I more than likely spent hours on calls gathering requirements, vetting the design, teaching them how to use it, etc.
The problem is that a Github repo is too much time an effort to evaluate on technical merits. And even if the work is good, how fast can you do it? Some people turn out good work at 1/3 the rate their peers, I don't want to hire them. Between other parts of the evaluation I can give the repo 30-60 minutes max, just not enough time.
1. Correctness
2. Matching the content to the intended audience
I find that in general I have no time to check correctness, nor is it obvious who the intended audience is. A blurb and basic setup instructions is fine if the intended audience is the author. A tool intended for a particular set of power users may not require motivation. The author may well know how to write more accessible documentation and chose not to for a sensible reason.
It’s almost impossible to be a force multiplier without them.
When I asked for this I was told they had looked at my GH account and that it was clear that I had the skills they needed. That was nice.
Something similar happened on the job after that.
But in the last two gigs I had to do a coding exercise and I was a bit disappointed that my GH didn't seem to have an effect.
The difference? In the last two jobs the companies were big organisations, with a clear interviewing process, and the technical interview was on hands of almost random engineers that could even not be part of the team I was joining.
When I have been involved in the process, I always look for public open source code. So far I have never had a candidate with an active GH account.
Personally, I have been happier working with the people that cared about these things.
As for hiring for my team, the results are unfortunately much less useful. The vast majority of GH repos are completely useless, half finished tutorials or some long abandoned project.
Sometimes I have found some really interesting work though, and this always earns the candidate an interview from me.
But I agree that I'm in the minority, most other senior developers or managers don't care about it at all. And I've never had a recruiter mention it.
If you do want nice notes, solicit them in the readmes. “If you see this, send me a note at foo@bar and tell me your thoughts!”
I rarely email a random person my random thoughts unless I have a smart question or bug report. Maybe only once have I sent a thank you this is so interesting email. Don’t want to bug people.
So keep doing it and talking about if it's your passion. Don't do it if it's forced. It's the passion that stands out and humans can tell if someone is really passionate about something or not.
Or just remember GitHub stars are like any other kind of useless social media currency and don't mean anything.
If there's one change I'd like to make to GitHub, it would be to make the value of a starring decay over time. But I'm sure even that could be gamed.
Maybe I should have kept my expectations in check, considering not many labs will have the setup ready to go, let alone have the inclination to dabble with it. But that was a step I didn't consciously take.
There's an uncanny silence from the world when you've thrown so much of yourself into a project, and you're the only one to care about it. It really shouldn't catch you off guard if you're thinking about it rationally, especially if you're not regularly communicating about the project for more people to notice it. But it still doesn't feel great.
> Getting stuff out there to be noticed is difficult, a lot of work, and going the the last 10% does not guarantee any more success.
This is true. It’s still a bet. It could have wildly high expected value and still turn up a 0. But doing nothing guarantees you won’t have more success.
If you believe in your work and would like to see someone build upon the results, having clearly reproducible results also makes all the difference. Most of the time, you won't even know that people are trying out your code/model/whatever, and friction in the onboarding often means that they will move onto something easier.
If you bound the last 10% and avoid scope creep, I am all for investing the time.
In the future, when you're bootstrapping a project and building scaffolding, you know what the 100% looks like and feels like, which means you're going to do a much higher quality job on the first 80-90%.
The first 80-90% of your future projects will be smoother, faster, and more likely to bring you success.
Sports analogy: by practicing your swings 100 times instead of "until I got my first on-base", you're investing in your future RBI and OBP, which is more valuable than any individual hit today.
It helps out if the project is relevant to the role
If your benchmark is number of stars on Github, then yes, things might get depressing when "JS toy framework number 45" easily gathers hundreds of stars.
But, personally, I have half a dozen reasonably polished projects on less trendy topics. While not huge, I know they were useful to other people. Some are packaged in linux distributions, others I've got requests for improvements, or were used as cross-reference for concurrent implementations, or were forked and continued a life of their own.
It's not huge, but by spending ~30% more time on things like documentation, tests, proper build system, a post here or on Reddit, I've enabled these projects to be more than an unapproachable pile of code.
And if it saves even one person the effort of implementing these projects, that's a result well worth the ~30% more effort for polishing the project in my book.
Lastly, users/interested people are often not developers. Personally, I have two websites related to a video game (one displaying some stats, the other being a loot box simulator). Both projects sit a 0 star on Github, but the access logs tell a different story, there has been thousands of (non-bot) visits since both went live, being useful to quite a few players of this particular game.
It's hard to measure impact, but it's extremely easy to underestimate it.
While both come from religion, an evangelist is not the same thing as a theologian.
- religion: a person who tries to persuade people to become Christians, often by travelling around and organizing religious meetings
- opinions: someone who often talks about how good they think something is, and tries to persuade you to have the same opinion
- religion: one of the writers of the four books in the Bible about Jesus Christ
https://dictionary.cambridge.org/de/worterbuch/englisch/evan...
Is there any logic to this exceptional world?
You could argue that "sales" just means "I'm trying to sell you on (using|supporting|believing in) this thing", but I think evangelism is a more suitable term in a non-commercial context.
This was instrumental in developing desktop publishing industry.
I agree the term is dated and should be retired.
And they buy things. But I agree that marketing would be a better term in many cases.
As far as I can tell I have no "buy things" motivation. I am not trying to get my sister in law to hire me to install and maintain an asterisk phone system or an instance of nextcloud or add a custom feature to vlc etc. Nor do I do those things in general where I would benefit indirectly if more people wanted those services generally.
The OP is referring to the second type I think.
Of course the two are not mutually exclusive, you could have an evangelist job for an open source company selling data protection software/services for example.
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."
80% of the work is completed in 20% of the total development time; while the remaining 20% of work consumes 80% of the time.
And this is something I've seen again and again: the large, most impactful features and architecture of a system are designed and implemented fairly quickly; it's the many small details get forever to be defined and implemented accurately.
Now if 90/90 is accurate because of unknown unknowns, or just because we are all terrible at estimation and planning is debatable;)
It's the curse of open source projects. So many projects get to the point where it sort of works, and then the authors, having done all the fun stuff, get bored and quit. So the project never reaches the Just Works stage.
And for academic work in particular, going from "prototype good enough to get numbers out of" to "product someone can reliably use" is a huge amount of effort, along which there are zero papers.
EDIT: Here's a summary:
A program is just a set of instructions that seems to do what you want. All programmers say "Oh, I can easily beat the 10 lines / day cited by industrial programmers." They are talking about just coding something, not building a product.
A product (more useful than a program):
* can be run, tested, repaired by anyone
* usable in many environments on many sets of data.
* must be tested
* documentation
Brooks estimates a 3x cost increase for this.
To be a component in a programming system (collection of interacting programs like an OS):
* input and output must conform in syntax, semantics to defined interfaces
* must operate within resource budget
* must be tested with other components to check integration (very expensive since interactions grows exponentially in n).
Brooks estimates that this too costs 3x.
A combined programming system product is 9x more costly than a program.
https://www.cs.usfca.edu/~parrt/course/601/lectures/man.mont...
Not exactly the definitions Brooks used, but memorable and in my experience surprisingly accurate.
What I can get running in a weekend for my personal use would:
- take 20 days (10x) to turn into something that other teams in the same company can easily consume without much effort on their part
- take 200 days to turn into a public facing product that people would actually use instead of their current thing
IMO, this is why engineers so often look at products and think "Oh, I can build that in a weekend"
I've created plenty of toy languages and reactive UI libraries in a weekend. People may find inspiration and take some ideas from my 2 days of work but nobody is going to use those as a replacement for their current thing without the next 198 days of effort.
A small example: if you can create a "spreadsheet to website generator" in a few hours, it'll be a month before you've built it out enough to launch a product around it that will attract users.
In 10 hours, I can make something that looks starts to look valuable to my wizened eyes. This is the happy path.
In 100 hours, I can build something that the rest of my team can begin to see the value in. This is the MVP.
In 1000 hours, I can make something that I can actually sell to a customer - but only with clear expectations that there may be months or years of on-going polishing required. The is the beta.
In 10000 hours, I was able to learn this perspective. No product is ever done. You only ever get to that tenuous beta phase and then becomes almost entirely about dealing with customer feedback.
For me personally, I start to check out after the 100 hour stage of development. Tedium and repetitive concerns begin to leak in and tempt the strategic nuclear problem solving facilities with insane overkill solutions (aka abstraction hell). I now try very hard to find reasonable handoff strategies before I get to that point. There are other team members who cannot stand the indeterminism of the 0-100 hour range of development, so this works out really well in our shop. Setup the pattern, let the tool operator zone out for the duration of their shift. Not everyone wants to be ivory tower architect and can find far more joy in the simpler tasks.
The first 90% is work that is composed of 90%+90%. And the second 90% too.
So you end up with .9*(90%+90%)+.9*(90%+90%).
Oh wait.
A project with a published write-up unlocks so much more value than one which you complete without giving others a chance of understanding what you built.
I've maintained internal blogs (sometimes just a Slack channel or Confluence area) at previous employers for this purpose too.
I also find a side benefit of writing about what you're doing (or talking about it) other than visibility and education is that it makes you understand it better as well in a very tangible way.
I've not had a great deal of success with encouraging others to start doing this, but I still find that the impact my own work has within the company is greatly improved if I have somewhere that I can write about it.
I don't expect others to actually read my internal blog on an ongoing basis, but I get a great deal of value out of being able to send links to posts on it to people. I wrote up a big essay about how to use our internal analytics tool once, for example, and shared that with anyone who asked how that thing worked.
I've used a few different mechanisms for these:
- A Slack channel. Free to setup, anyone who wants to follow along can join the channel.
- A confluence blog - confluence has a "blog" feature which you can just start using.
- An organization private GitHub repo full of markdown files.
I did eventually publish the internal blog posts I wrote at one organization (an organization which has since shut down) - I shared those here: https://simonwillison.net/series/vaccinateca/
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"
- 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.
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.
That's just documentation. The same can be argued for things like code quality and unit testing... not integration testing tho ;)
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 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.
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.
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.
> What are some common activities to go from 90% to 100%?
To the list I'll add
- 100% coverage
- rewrite it in Rust (ha ha)
IMO, getting from 90% (it works and does the right thing with any valid input) to 99% involves things like
- paying down all technical debt
- handling malformed or adversarial inputs, including all edge-cases, "reasonably"
- better documentation; tutorials, how-tos, explainers, and references. In multiple formats (don't forget your `man` page).
- checking for low-hanging perf/memory wins.
- interface polish. Is there a long-running operation that might benefit from a progress bar? Or some other indicators which aren't strictly necessary, but would help users model of the state of the program?
The problem isn't that it's difficult to track. It's not even clear what the remaining 10% is, or if it's 10% to begin with.
If you asked 10 people what the rest 10% is about, you'll get 10 different answers.
1. People notoriously lobby for greenfield projects. Obviously all the viable products are already built, they don't want to make research moonshots (bad for quick promos). So, they create do weak market research and justify their 1000th CRM project.
2. Once it's approved, the building is done by lowly SDEs. Meanwhile, managers and senior engineers are busy in Self-congratulatory emails, giving presentations and taking as much credit as they can.
3. In Bad Big Techs, the building part is fast-tracked so that upper-echelon can gather more kudos per quarter. This creates the toxic WLB scenario.
4. The product launches and gets initial users mainly due to large marketing push. Now the biggest task in hand is operational tasks such as handling outages, security risks etc. These are low visibility unthanked tasks.
5. The PMs/Managers/Senior Engineers don't believe their own product will actually get traction. They jump to another project after receiving virtual medals/promos and the cycle starts anew.
In the whole process, the top brass has done nothing but evangelize themselves. The only real skill they've demonstrated is convincing their seniors/ teaching their seniors to convince their seniors to greenlight the project.
A task becomes so big and daunting when considering everything that should be done to take it to completion-- that I put off even starting it.
I thought the article title was an exhortation to people like me to change their mindset and get to work -- and forgive themselves for, even target, stopping at 90%.
That could be healthy and useful.
I thought that is what it would be, too.
And I agree, that is a healthy approach if a task seems too big to complete. Just focus on the minimum viable outcome, and be sure to break things down into small pieces, minimum viable outcomes in their own right.
More like 50%.
Shipping software has a lot of non-coding stuff.
We are in the last [coding] lap of a project that has been ongoing for two years.
I think we probably still have at least another eight to ten months of stuff ahead of us before we ship.
We spent 4 months building a software system, running experiments, writing an academic paper, and submitting it to a journal for publication. So now we are done. The end. Right?
Yes! This is what I call stopping at 90%!
The remaining 10% is far more difficult to track and often has no clear stopping point. It's often better to skip the last 10% and move on.
I do think there are pitfalls to this though. There's a tendency to want to smooth over problems and mistakes and amplify successes, which also makes the story you are telling pretty boring and artificial.
Basically: Let me tell you a story of the time we tried to play golf. We went to the US Open and signed up with our fantastic team of engineers, it wasn't easy and our team had to work long hours to figure it out as we went but thanks to teamwork we struck hole in one every time. We're fantastic at golf, and the audience cheered for our amazing teamwork and leadership success, and Tiger Woods came forward from the crowd to shake our hands and was was very impressed with what we were doing in such short time.
Like this story had no downs, it's completely flat and omits any problems and greatly exaggerates the successes. It's also like not far off the median linkedin post about a project in progress.
It removes all the things that makes a story compelling. What were the problems? How were they overcome? What were the lessons learned?
It’s when my kids think they’re done with breakfast but haven’t washed their hands.
It’s when a PM is done with a feature when it’s deployed to production but its success hasn’t been measured.
It’s when I’m done with writing a blog post but haven’t proofread it.
Defining done and having stakeholders agree on the definition is how we move forward. Without that, the entropy of work trends to empty busyness.
Or maybe I have it backwards and the 10% is 80% of the value? But no, that makes me uncomfortable considering my pattern of unfinished projects so I’m going to go with my first theory.
A lot of it comes from this - wanting to be at 100%. And as some people here have pointed out, the last 10% takes probably just as much time/energy as the first 90. So yeah, it's a tradeoff. There are definitely a lot of areas where the last 10% matters a lot, and is the differential between successful and mediocre companies for example. But, in a lot of cases, 90% is just fine - I'd rather have 90% and live than strive for 100% and have the thing stay in the closet.
Put the code on github when there's something to look at. Write your blog posts as soon as you have something usable. Tell your colleagues to use it as soon as it brings them value.
Do what OP calls "the last 10%" continually while doing the rest, then you don't stand before the false dichotomy of stopping at 90% or not.
Funny that OP mentions this as part of the last 10% because the experience in my company is the complete opposite. People tend to send self-congratulatory emails before a project is even 90% done. This creates perversive incentives. Some people who want to game the system will stay around just long enough to get visibility, credit, and virtual pats on the back. Then they'll move on to another project that they can capitalize, either not finishing the rest, or dumping it into another unsuspecting soul.
It's hard to find time and energy for dedicated work sessions on personal projects with a full time job. Small incremental improvements ftw!
"Find someone that can poke holes in your work, then go address them."
The underlying issue is widespread in OSS projects. Increasingly it is all about features (for which those who are paid to "work" on projects are rewarded). Others spend 10x the amount to fix the features or leave the projects or are driven out by the corporate developers.
Marketing _is_ real work. Software is only useful if it's being used. Now, it's up to the author (or PO/PM) to define _who_ the users are. If it's an internal team, a slack message to that team's channel saying "hey I made X do y" is marketing, but necessary. Sending a PR to an OSS project is marketing. Updating the docs to show how to use your new thing is marketing.
What does "address" them mean?
If starting from scratch on a fresh project is the easiest way to factor out the design flaw at the heart of my whoopsie, does that count as addressing the problem at a higher level, or blowing off my current whoopsie at 90%?
This is a a very "programmer" view of the world that the work is when code is being produced, and everything else (especially anything involving people) is not actually productive.
You can have enormous impact with that other form of work.
Marketing is huge, even for open source projects, even hobby projects. It very directly affects your ability to have an impact on the world. If you do zero marketing, the only impact you have is what you do with your hands, which is not a lot in most cases.
Blogging and talking about what I do (=marketing) has opened doors to the extent that I've been able to quit my job and do full time work on what was once a zany hobby project to pass the time during covid isolation. That is, investing some time in marketing in the past let me spend more time "working" on code in the present.
The impact has been kind of insane. I've been in The New Yorker because of this. I've done radio interviews. Nothing of this would have happened if I wasn't constantly writing about my projects, constantly making rings on the water stretching farther and farther out. It takes a while to get going and pick up momentum, but the accumulated effect can get very strong.
This is marketing. It doesn't have to be shallow and corporate and SEO optimized and pestering users for newsletter subscriptions. It can be authentic and personal... but it's still marketing. If anything, that's the best sort of marketing. I believe what I write, I stick to my principles and I'm not trying to bullshit anyone. That stuff shines through.
It is rational to stop somewhere between 0% and 100%. There is no guarantee you will find traction in the last 10% or the last 1%, if you get that far. It might have been rational to stop at 17% and instead spent the time and resources on something else.
To make an honest and rational decision, there should be go-conditions at several points along the project. Work stops when conditions aren't met.
Bonus site: https://www.doesthedogdie.com/
More than 80% of the results come from selling it, 20% comes from doing it. It's the case with research, building startups, homework, whatever. If it's not pushed into production and marketed, the value is there, but very tiny.
Some people see the results and make the mistake of spending more than 20% of their focus selling it, but nobody respects people who talk a lot but do little.
Software is almost never finished. You can always make an improvement to just about anything, but it should at least meet some minimum threshold.
I would honestly like to understand if the 10% is in reality 10% or more like 80%. Is the project done until it has adoption? Until it finds utility in someone else's workflow?
And does it take 10% more work or 80% more because it's adjacent to what you really are good at?
In it he describes the process of both his writing and his marketing.
You're not done writing when the chapter is written, that is just the start. All the editing is the time consuming part.
The marketing needs to be part of the plan before the writing starts. It isn't "write a book and then sell it". He's continuously building his audience, trying to figure out what to write, writing, editing, "selling" (not actively selling, but doing the work to get feedback or get people excited about what he is writing).
Repeat, repeat, repeat.
Every exam I took eventually hovered around that number - assuming I studied. This was particularly visible in math class in high school, where our teacher put emphasis on consistent work.
It's a useful model because on one hand if I have a score, I can tell if I did my best and how much of my success can be attributed to individual effort.
On the other, when I don't have a score, I at least have a reasonable upper bound on how much was done and how well.
The actual answer is get partners motivated enough to do the rest.
[0]: https://chrislema.com/a-done-done-culture-habit-one/
[1]: https://www.amazon.com/Creating-Done-Culture-Habits-Performe...
It helps, in general, to manage expectations.
I don't, and as far as I can tell that's fine. This seems somehow unbalanced.
If someone started sending companywide emails summarizing their random projects I would start sending companywide emails saying how I cleaned the microwave in the break room.
And from years of doing these things I think they massively underestimate the 'system' as you put it. This system involves process, culture, rewards and a ton of politics.
It has some very unique challenges different from shipping products. Often your total addressable market is one team in the company, so product analogies aren't much help. You really need to gain political power to get buy-in. Or in today's corporate environment just be okay with finishing the task to 90%
This system needs to be in place prior, building it isn't 10% tacked on the end of a small project.
Half done is what I'll think when coding is finished.
On one of my open source projects which did get a little bit of initial traction, at one point traction slowed down and I was paranoid and thought that the code could be improved more and I reworked a lot of stuff to make it work optimally with Kubernetes. But some years down the line I found out that a significant subset of my users actually preferred how it worked before and were still using the old version. I still think it was a good move because the new architecture is much simpler and more elegant but probably not necessary as it didn't help my project get more traction.
Sometimes the only problem is just marketing and social networking and if you're not born at the right place and right time, there's nothing you can do about it.
... I should save time and get ChatGPT to summarize articles.