I put a lot of work into doing the last 10% for a project recently, and I'm not convinced yet that I'll be getting anything out of it, other than my own satisfaction. After my colleagues and I got our paper (on real-time depth estimation with an event camera and a laser projector [0]) accepted at a workshop, we could have just dumped the convoluted, messy research code on GitHub and be done with it. For other people to figure it out, if they really cared.
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.
I work in the cloud consulting department at BigTech. We have a very straightforward open source approval process where we can open source any code (MIT-0) that we write for a client as long as we scrub the business processes and anything proprietary to the customer.
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.
I don't know. I don't think people actually care. Maybe I'm a cynic, maybe I'm jaded. I've sat through a handful of interviews after submitting a resume with links to my GitHub profile, links to my (former) co-founded startup, the parents we received for our work, the projects I painstakingly polished before open sourcing, etc... At the end of all of that, I can recall exactly 1 person who even casually mentioned this stuff. He ended up being a manager and he would sometimes bring it up as a point of conversation with others on our team but it never found traction. My conclusion is simply that exceedingly few people (in the wild) give a shit about this stuff. Probably other like-minded folks.
I totally agree with you. Nobody gives a fuck. I sweated 6 months on my CS Masters thesis. After the day of the presentation, I walked up to my Professor's office. As per the rules, you are supposed to hand a printed copy of your thesis to your thesis advisor. So I handed over the printed thesis proudly. Then we chatted, I said my goodbyes & left. In those days we had no github internet etc. All the C++ code for my thesis was on a 5 1/4 floppy. When I reached home I found the floppy. I was like, God I've forgotten to give him my code! So I picked up the floppy and trudged back to the university. Then I walk up to my advisor's office again & knock on the door. He is ofcourse surprised to see me. I say - Sorry I forgot to give you my code. Here is the floppy. I'll put it next to my thesis. Where is my thesis ?
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.
That's a pretty gutting experience; I'm sorry for you. But especially with the internet, the are people who value Masters work. I sent an email thanking someone for their thesis, and mentioning that I had added it as a citation on Wikipedia, but I didn't get a response. Maybe there is a vicious spiral of apathy towards undergraduate and early postgraduate work.
> 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.
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.
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.
I always look, and I'm always happy to see something meaty enough to actually talk about in an interview.
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.
Precisely this. I often check GitHub profiles if a candidate provides them, but I have the same experience. It's often times completely empty, or just a half-finished tutorial. Once it looked like a really active developer (like commits on almost all days), but that was from a repo with generated commits to make the GitHub contribution history look nice... not actual work.
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.
I’ve open source something from every project I’ve done at work since I’ve started my current job. Again - after going through the open source approval process.
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
Yeah come on just throw it on the CV if you are proud of it. Expecting the interviewer to actually click through your GitHub account and figure out what you did is additional work for them.
I am at a point in my career that aside from my current company, I haven’t done a traditional submit my resume and interview in years. Even this job kind of fell into my lap without me seeking it out.
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.
12 years ago I was interviewing for a job and I was surprised that it didn't include any coding bits, only a few light technical questions on the first interview.
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.
Can you explain why people should care? I get a guy who is not well adapted socially, who thinks he is the best thing to ever walk through the door and I know he’s going to be a short-lived nightmare for his sup and potentially for HR. A GitHub portfolio doesn’t change the fact that it’s already a broken deal.
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.
> Can you explain why people should care? I get a guy who is not well adapted socially, who thinks he is the best thing to ever walk through the door and I know he’s going to be a short-lived nightmare for his sup and potentially for HR.
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.
I've had some really good experiences as a candidate, since my GitHub has a couple repos that are actually used by people and have some stars. I've even had an interviewer tell me he had used one of them before, that was nice.
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.
I think you're probalby right. There's no way to know that a github repo represents the actual work of the applicant. References from former employers/clients are going to be the main thing I would care about.
As someone on the hiring side, Github projects only matter when they show impact via serious industry adoption (this is not sufficient, leftPad won't get you hired).
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.
If I were looking at a Github portfolio, I would be more concerned about reading their documentation. I want to know about their communication skills and why they think their code matters. What problem were they trying to solve? Even if it was to scratch an itch that they had and only three people including themselves ever use it. What was their motivation for doing it?
I find the signal from this is still too low for it to be worth looking into. Quality of documentation has a lot to do with:
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.
I kind of yada yada yadad over what I actually do.
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.
From my time on the hiring side, I was looking for passion. Side projects, githubs, etc all showed passion and. It wasn't the github project itself, it was the passion. That's what made the hires.
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.
Fwiw, 90% of the time when I visit a cool package I don’t interact with the creator at all.
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.
On the opposite end, two of the jobs I’ve had in the last ten years noted that they saw my emacs config (one interviewer admitted to borrowing from it) and I’m pretty sure it had a positive impact on my prospects.
For every person starring the repo there will be an unknown number who found it useful but aren't using GH stars or forks.
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.
I'm one of those unknown readers with no stars (why would I add to the inflation of tokens of already little worth?) and forks (why would I clutter up my forks with projects I can't meaningfully contribute to?) - but I am a prolific bookmarker of interesting projects! Those often end up pasted into IRC or Matrix channels where there is interest in later years, potentially multiplying the impact of my initial visit 10x or even 100x, inspiring future contributors or new projects.
It might not be in vain, but it can often be a poor balancing of priorities. The last 10% can easily require as much work as the first 90% - perfection is expensive.
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'm not entirely in agreement here. While there was undoubtedly some internal motivation at work (as publishing subpar code just doesn't sit right), I believe a significant portion of it was external, and I don't see that as a negative. During the polishing phase, I had two primary goals: first, to lower the entry barriers for people who wanted to try it out, and second, to expand its capabilities as much as possible (e.g., enabling it to run on a laptop rather than a high-powered desktop, without any frame drops). I view this less as an attempt to impress others, and more as an effort to enhance utility and thus broaden the potential user base.
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.
Just wanted to say, you have benefitted a lot from the last 10%.
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.
That last 10% generally has long payoff. The rewards of that paper feel immediate, but the code on GitHub will be useful to people for years. (The paper also has a long payoff. It also a short, which GitHub didn’t here.)
> 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.
You did that 10%, making your research easier to reproduce and your technology easier to use. I am going to bet that in 15 years, when you've long since moved onto other exciting things and forgotten the details of the state-of-the-art circa 2023, you'll come back to your earlier work, be it for nostalgia or comparison, and be one of those who will benefit from that extra documentation and polish :)
Sure, they're just silly internet points. Yet, after heading back from the conference, they're the only immediate, tangible pat on the back that's left. It'll be a while before the first round of article citations start rolling in. So, seeing HN readers drop by the repo and leave the tiniest note by starring it did bring a few smiles to my face.
Sadly GitHub stars do have meaning to people who make decisions about which code library to add to their current project. And to people who review libraries that tackle a specific sort of problem, whose articles then get read by people who need to make decisions, etc. Such people may also use other metrics - recent activity, number of contributors, etc - to refine their judgments, but I've seen too many examples of "must have at least 1000 stars" used as the main justification for a decision. It's sad that the world is the way it is, but I doubt it will change anytime soon.
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.
> 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 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.
> 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.
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.
Well a comment is worth perhaps only an epsilon. But since you can always write another comment, the project will never be at 100% - only in the limit.
If you're a researcher from academia applying for a job in my team, the quality of your GitHub repo makes a huge difference in how you are perceived before we even talk to you.
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.
I wrote about my motivations in a different comment. To be honest, I didn't harbor any particular expectations. Maybe a flicker of hope for a bit of feedback or interaction from someone who'd given it a go, be it results, queries, or issues.
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.
You use the academic term "we" when it should be "you" or "you can". This immediately signals to the reader that unless they are a researcher the product is not for them.
Yes but the problem is that engineering projects tend to consist of two halves. There is the first 90% of the work and there is the second 90% of the work.
I remember reading an essay by Brookes, where he makes the distinction between a "program", which can basically only be used by the one who wrote it (or with their help); a "product", which can be used by anyone; and a "system", which is more general-purpose and reliable. His point was that the first is fairly easy for one person to do in their spare time; the last often takes years of polish, debugging, extensions, and so on.
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.
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.
I've built a few products from idea to commercial software, and IME Brooks was being generous, as anecdotally I always pegged it at closer to 4x, but then I'm slow. It's actually really surprising how few product managers (forget about developers!) don't seem to know this, yet they also tend to push out the initial release way too far, so you get half a product late, then move on to the next thing.
IME 10 lines of code can easily take 1-2 weeks, if you include all that. I agree that's a bad average time, but I'm assuming other work responsibilities, and perhaps more red tape than HN is used to.
"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."
Strange, I knew a less humorous (and, I think, more useful and realistic) rule:
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.
From the title I thought this article was going to be advocating for stopping at 90%. I was thinking to myself that makes pretty good sense, I could get through twice the amount of projects .
Agree. If projects regularly achieved 90% of what they set out to achieve, that would be fantastic. My experience is that 40% is more typical, for the ones that aren't canceled before they deliver anything.
Can we start calling "evangelism" "sales" again, by the way? Someone who calls themselves an "evangelist" is a salesperson, or someone who studied theology.
That asserts that the degrees of truth in fuzzy logic relates to paths and that asserts paths are fixed. A form of lazy computing when resources are finite for a reason, and nullifies the existence of quantum physics.
For me, at least, sales implies a commercial offering.
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.
I evangelize the concepts of open source and avoiding giving up your data. Meaning any time I think it's topical and not annoying, I spout the opinions and the reasons for them.
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.
There's a difference between someone who genuinely believes what they are evangelizing, and paying marketing people to spread some corporate opinion.
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.
My perspective Guy Kawasaki was the first tech exec. with that title at Apple. His job was to figure out what different groups of users were doing and what they needed.
This was instrumental in developing desktop publishing industry.
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.
I've started to consider "commit to writing about it" as the price I have to pay for giving into the lure of another project. It's one of the main reasons I publish so much content on https://simonwillison.net/ and https://til.simonwillison.net
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.
Im interested to learn more about the internal blogs you set up at previous employers. Do employees use it to write about their ongoing projects? Thanks for sharing!
I've mostly tried to lead by example: I start an internal blog, write about my projects and hope that others will follow my need and start their own.
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/
This seems like a non-existent problem in software development. Who has ever felt being done and satisfied with anything? It's always the opposite with an endless backlog of improvements.
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.
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 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.
If the author has interested you in the possibility of doing the other 10% of work, I would recommend the book "Traction - How any startup can achieve explosive customer growth" by Weinberg and Mares. It actually suggests gaining traction at the same time as developing to ensure a constantfeedback loop. In some cases you will even want to build parts of your product to help you gain traction.I think they even mentioned alternating each week, one week dev, one week marketing, i.e. 50%.
I'll admit, to me the point that the author considers 90% is where I consider 99%.
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?
I've seen the complete opposite of this in Big Tech.
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.
I think point number 2 is what the author is talking about.
Honestly I don't mind others doing what they want to make themselves seem important. I will move on to the next task at hand. It's not like it's going to make a difference for me either way.
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%.
> 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%.
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.
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.
In my experience this last 10% is the one that differentiates great work from good work. In my team we use to call it "put the bow on the gift". Receiving a well packaged gift makes the difference.
Promote as you build is the way to go (if you can). I'm posting my book online, article by article. That way you get real-time feedback as to what works at what doesn't.
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?
The risk to this is that your competitors seize the opportunity to criticise your mistakes as if you're hiding them, even if you wrote about them yourself! As such, one justification for keeping problems secret is that your competitors don't know about them. It's unfortunate, as it stops a lot of good-faith collaboration, where strangers will come and offer support.
The Pareto Principle would beg to differ. I highly doubt you’re getting the same value out of the remaining 10% that you got out of the first 90%.
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.
There's a saying the homebuilt aircraft community - 90% done, 90% to go. The last 10% always takes the longest, and especially for stuff like side projects as a developer, a lot of times it's the 10% you want to do the least so it feels like it takes 10x longer than it actually does.
Some time ago there was a post on here about not putting projects out to the world. A lot of devs in the comments shared their stories about projects dying out because they weren't 100% ready. I share the same sentiment.
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.
> Broadcast an email with the takeaways so that the rest of your organization knows about it.
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.
I was delighted to see this headline and post. The remedies he suggests are unfortunately 86% marketing! Only one line suggests real work, but done by others:
"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.
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.
> The remedies he suggests are unfortunately 86% marketing! Only one line suggests real work, but done by others:
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.
> "Find someone that can poke holes in your work, then go address them."
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%?
> ... If no one knows about it or won't give it a chance, then it's as if it never happened.
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.
I wish I had been able to do that. But at least I get to see announcements for John Wick 4 and get a warm fuzzy feeling that I have escaped watching 3 whole movies, and thus have an extra 6 hours in which to do something better in my life with an exceptionally low bar for "better".
More than 80% of the work is doing the work, the remaining 20% is selling that you did it.
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.
About 80% of the doing-the-work bit is figuring out what you're doing and how. There's a lot more work to work than just the bit that we think of as the work.
The world is flooded with software where the developers stopped at 90% (or even less than 80%). There is little or no documentation. Very little testing was done so anything but the most simple input can reveal bugs. The UI is convoluted and not intuitive. The list goes on...
Software is almost never finished. You can always make an improvement to just about anything, but it should at least meet some minimum threshold.
From an academic perspective, sure? I guess? But most things done in the name of academia are for the purpose of learning, so the goals are different. If your goal is to build a PRODUCT this is stupid advice. You really want to stop once your primary use cases go end to end. It doesn't even need to scale. Go make a sale or whatever flavor of "get users" your product needs to be validated. Most products don't get the benefit of being able to stand on their own. Every customer you add comes with their own unique last 10% that you'll need to work on to get them to sign up. So go find out what THOSE requirements are, or you'll end up doing the wrong "last 10%". Oh, and make sure you understand what the client is actually asking for, or you'll end up doing the wrong 10% and losing your next big customer, which can be a super demoralizing experience.
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?
For an interesting perspective on this, I'd recommend Ryan Holiday's book Perennial Seller.
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).
Related to this I have a measure that I call "general effectiveness" - mine is 83-86% meaning, when I'm, in my view, perfectly prepared, the outcome is actually closer to that.
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.
Changing the intended user from the developer to an external client is a really high g-force maneuver and past a certain level of complexity it’s likely to flameout the developer without a reliable support system.
After the first 90% there is the other 90%. People underestimate how much time that takes. It requires partners and skills you have not necessarily honed.
The actual answer is get partners motivated enough to do the rest.
This article just breeds classic toxic work mentality. There is nothing wrong doing 90% of a project. Hell, I’ve learned the most doing just 50-70% of side projects and moving to other ideas faster.
This is why, at least at work,you need a strict definition of done.
A DoD isn't only useful to you and your team but also to the rest of your organisation so that everyone knows that you might still be working on a task/project although you have already finished the most visible part of it.
Why must I care about any of those things besides maybe a long tail of natural at-will refinement?
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.
I'd prefer a "going beyond 100%" formulation. The concrete deliverables are the end goal. Anything extra is welcome, of course, but modern life doesn't leave room for anything extra. Aspire towards what the author frames as "100%" and be prepared for disappointment.
I'm a nontechnical marketer with a senior person who builds internal tools. We very much have this problem. We get it...most of the way there. But without a strong system to distribute it, get feedback, get buy-in, a lot of the work is underutilized.
I do feel the article isn't clear on what the context is, but it sounds like it is really this sort of corporate 'project' like internal research or tools.
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.
In the context of building a product it’s normally best to do some of that final 10% as early as possible. Fail fast, see what works fast.
I’ve had so many projects not get to 100% due to things I could have validated in the first 5%
if you create a project, create it as if people would use it, not to keep it in github repo, if you keep your project to yourself the entire effort you had put in the project is completely uselesss.
It's hard to know why projects didn't get traction. Is it because the documentation is not as good as it could have been? Is it because the marketing was insufficient? There are some projects out there which are similar to some of my projects and which did get traction and they have basically the same level of polish and documentation. I feel like it just comes down to marketing which itself just comes down to social connections. I'm quite certain now that if someone like Elon Musk looked at some of my projects and promoted them, they'd get tons of traction. The user feedback on some of my projects has been very good but it appears that none of my users has been a high-exposure individual.
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 will gladly stop at what the authors defines to be 90%.
Someone else can do the tasks outlined by the author. I will work on solving the next problem in my area of expertise.
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.
[0]: https://fraunhoferhhi.github.io/X-maps/