[HN Gopher] Stopping at 90%
___________________________________________________________________
Stopping at 90%
Author : alexmolas
Score : 289 points
Date : 2023-08-02 06:16 UTC (16 hours ago)
(HTM) web link (austinhenley.com)
(TXT) w3m dump (austinhenley.com)
| nsmog767 wrote:
| 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.
| grumpy_coder wrote:
| 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.
| twodave wrote:
| 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.
| huijzer wrote:
| 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.
| js8 wrote:
| I think we can all agree on the fundamental truth that taking
| out the 90% of the software system leaves you with the 90% of
| the software system.
| huijzer wrote:
| Can we start calling "evangelism" "sales" again, by the way?
| Someone who calls themselves an "evangelist" is a salesperson,
| or someone who studied theology.
| monooso wrote:
| 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.
| phkahler wrote:
| Evangelists are selling themselves while promoting
| something.
| dragonwriter wrote:
| > Someone who calls themselves an "evangelist" is a
| salesperson, or someone who studied theology.
|
| While both come from religion, an evangelist is not the same
| thing as a theologian.
| [deleted]
| wumms wrote:
| > evangelist
|
| - 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.
| ..
| pessimizer wrote:
| People who are paid to have an opinion don't count.
| darkclouds wrote:
| And yet they omit Lawyers in front of juries and
| Lexicographers writing the next edition of a dictionary.
|
| Is there any logic to this exceptional world?
| hgsgm wrote:
| Yes, but it's fuzzy.
| darkclouds wrote:
| 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.
| detourdog wrote:
| 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.
|
| I agree the term is dated and should be retired.
| inopinatus wrote:
| Software theologians are called "architects".
| mikrl wrote:
| What, you don't want to spread the good word of our lord and
| saviour... software???
| mlok wrote:
| Not the same things : Sales goal is to get listener's money.
| Evangelism goal is to convert listeners into new supporters /
| enthusiasts.
| bjornasm wrote:
| Its the same things, they are just selling the concept and
| the product, not just the product.
| hutzlibu wrote:
| "Evangelism goal is to convert listeners into new
| supporters / enthusiasts."
|
| And they buy things. But I agree that marketing would be a
| better term in many cases.
| Brian_K_White wrote:
| 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.
| nickserv wrote:
| 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.
| amelius wrote:
| You can use divide and conquer on that!
|
| 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.
| HPsquared wrote:
| It's a bit like the Pareto principle. 20% of the work takes 80%
| of the time.
| Animats wrote:
| Indeed.
|
| 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.
| graphviz wrote:
| If the software endures long enough, there is no 100%. The
| Just Works stage is not stable. The ground keeps shifting
| beneath your feet.
| Animats wrote:
| Many open source projects go directly from Sort of Works to
| Abandonware, never having reached Just Works.
| renegade-otter wrote:
| Yes, it's the 90-90 rule. It has its own Wikipedia entry:
| https://en.wikipedia.org/wiki/Ninety-ninety_rule
|
| "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."
| throw310822 wrote:
| 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.
| coolgoose wrote:
| I always knew it as the 80/20 rule :D
| mathgeek wrote:
| That's the Pareto Principle.
|
| https://en.m.wikipedia.org/wiki/Pareto_principle
| mhluongo wrote:
| So is 90/10.
| mathgeek wrote:
| The wikipedia page for the 90/90 rule quite literally
| says "not to be confused with the 90/10 rule".
| skeeter2020 wrote:
| read the thread again; it's the 90/90 rule.
| gwd wrote:
| 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.
|
| https://www.cs.usfca.edu/~parrt/course/601/lectures/man.mont...
| rednab wrote:
| The way I've explained this to coworkers and stakeholders is,
| "A prototype costs 1x, a product costs 3x, and a platform
| costs 9x."
|
| Not exactly the definitions Brooks used, but memorable and in
| my experience surprisingly accurate.
| hgsgm wrote:
| 3 is far too small.
| didgetmaster wrote:
| Agree. 10x at each stage is more realistic.
| skeeter2020 wrote:
| 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.
| P_I_Staker wrote:
| 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.
| tantaman wrote:
| I've found it to be 100x
|
| 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.
| bob1029 wrote:
| I think this tracks very close to my experience.
|
| 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.
| johncch wrote:
| Thank you for saying this. I'm currently in the 100h
| phase and I'm struggling to explain it and you said it
| beautifully.
| Nition wrote:
| 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 .
| SoftTalker wrote:
| 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.
| skeeter2020 wrote:
| worse, it's not a cohesive 40%, but a long tail percentage
| complete of numerous features: 90% of feature A, 67% of B,
| 1-30% of countless more...
| MattHeard wrote:
| I prefer to stop at 80%.
| Brian_K_White wrote:
| 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.
| [deleted]
| w-m wrote:
| 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.
|
| [0]: https://fraunhoferhhi.github.io/X-maps/
| saulpw wrote:
| Consider that you only went to 99%, and this comment is the
| final 1%. (Or maybe it's the next one, or the next..)
| ant6n wrote:
| 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.
| dwaltrip wrote:
| Polishing things up is hard work. You are now more experienced
| and better at it. That's very valuable.
| cinntaile wrote:
| What a weird coincidence, I have met someone on that list of
| authors.
| w-m wrote:
| Weird indeed. And I've met all of them! What are the odds? (:
| casey2 wrote:
| 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.
| pessimizer wrote:
| This sounds like a personal problem.
| travisjungroth wrote:
| There's one "we" in that comment and it refers to a specific
| group of people: the authors of that paper.
| seabass-labrax wrote:
| 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 :)
| fleischhauf wrote:
| as a researcher in Computervision, thank you so much for going
| the extra mile!!
| sailorganymede wrote:
| I landed a new job today because of a project I put on Github
| with 0 stars I put out 2 years ago :)
|
| It helps out if the project is relevant to the role
| sidmitra wrote:
| There might be people years from now that could benefit from
| your work. Caring about something and putting it out there is
| never in vain.
| DoughnutHole wrote:
| 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.
| w-m wrote:
| 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.
| gen220 wrote:
| 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.
| chrsig wrote:
| What outcome were you hoping for when you decided to spend that
| time and energy?
| w-m wrote:
| 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.
| grog454 wrote:
| > 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.
| 3np wrote:
| 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.
| seabass-labrax wrote:
| 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.
| scarface_74 wrote:
| 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.
| scruple wrote:
| 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.
| Hermitian909 wrote:
| 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.
| scarface_74 wrote:
| 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?
| Hermitian909 wrote:
| 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.
| scarface_74 wrote:
| I am more concerned about #2 than number one. I want to
| know how well they communicate. But then again, I'm
| highly biased toward communication skills.
|
| It's almost impossible to be a force multiplier without
| them.
| koreth1 wrote:
| 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.
| hectormalot wrote:
| 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.
| scarface_74 wrote:
| 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
| imtringued wrote:
| 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.
| scarface_74 wrote:
| 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.
| Vadim_samokhin wrote:
| I think scruple meant not just putting a github nickname,
| but specific links to repos. That's what I do - but
| people still don't give a shit.
| nickserv wrote:
| 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.
| SoftTalker wrote:
| 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.
| scarface_74 wrote:
| In my case as I mentioned originally - my open source
| code came directly from client work.
|
| 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.
| reidrac wrote:
| 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.
| srcreigh wrote:
| 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.
| scarface_74 wrote:
| 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.
| dxbydt wrote:
| 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.
| katbyte wrote:
| > 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.
| seabass-labrax wrote:
| 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.
| supazek wrote:
| 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.
| scarface_74 wrote:
| > 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.
| uncletaco wrote:
| 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.
| travisjungroth wrote:
| 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.
| candiddevmike wrote:
| You can always buy GitHub stars if you need that kind of
| validation: https://baddhi.shop/product/buy-github-followers/
|
| Or just remember GitHub stars are like any other kind of
| useless social media currency and don't mean anything.
| rikroots wrote:
| 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.
| w-m wrote:
| 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.
| protastus wrote:
| 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.
| didgetmaster wrote:
| 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.
| angarg12 wrote:
| > 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.
| secretcombos wrote:
| 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.
| marginalia_nu wrote:
| Yeah.
|
| 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?
| seabass-labrax wrote:
| 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.
| RyanHamilton wrote:
| 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%.
| wouldbecouldbe wrote:
| It's can work but they never talk about the operational &
| support costs such an approach has, let alone the emotional
| price
| nlpalks wrote:
| 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.
| maccard wrote:
| > 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.
| smitty1e wrote:
| > "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%?
| marginalia_nu wrote:
| > real work
|
| 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.
| [deleted]
| ansc wrote:
| You could as easily write:
|
| 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.
| alexmolas wrote:
| 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.
| [deleted]
| imadj wrote:
| > where as the remaining 10% is far more difficult to track and
| often has no clear stopping point.
|
| 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.
| mercurialsolo wrote:
| Done is a hard concept.
|
| 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?
| yobbo wrote:
| > ... 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.
| KnobbleMcKnees wrote:
| A version of what you're describing is the sunk cost fallacy
| dizhn wrote:
| My familiarity with the fallacy enabled me to quit watching
| John Wick in the last 10 minutes. 10 minutes saved is not
| nothing.
| selimthegrim wrote:
| You didn't quit when the dog got killed?
| dizhn wrote:
| Come to think of it, I think it was John Wick 2.
|
| Bonus site: https://www.doesthedogdie.com/
| sfink wrote:
| 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".
| jongjong wrote:
| 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.
| Kiro wrote:
| 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.
| simonw wrote:
| 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.
| P_I_Staker wrote:
| 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 ;)
| clintonb wrote:
| 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.
| P_I_Staker wrote:
| 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.
| lvturner wrote:
| 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"
| dalbasal wrote:
| 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.
| poisonborz wrote:
| 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.
| zelphirkalt wrote:
| What is core work and what is tangential work?
| poisonborz wrote:
| Writing code vs documentation, support, marketing etc.
| graphviz wrote:
| 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.
| whartung wrote:
| 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.
| joelhaasnoot wrote:
| I'd actually advocate to stop before 90% so that you can figure
| out if the 90% is the right thing...
| yakkomajuri wrote:
| 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.
| perlgeek wrote:
| Publish early, publish often.
|
| 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.
| sixthDot wrote:
| Very well known
| https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule.
|
| > 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)
| Karellen wrote:
| 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?
| winwang wrote:
| - Add dependent types
| paulcjh wrote:
| 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%
| hkon wrote:
| 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.
| pc86 wrote:
| 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.
| hamdouni wrote:
| It's more like Pareto 80/20 than 90/10. Maybe 50/50 as the rest
| to be done is out of my league.
|
| Half done is what I'll think when coding is finished.
| EGreg wrote:
| 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.
| server_man3000 wrote:
| 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.
| zgin4679 wrote:
| TL;DR as summarized by Ted Turner: "Early to bed, early to rise,
| work like hell and advertise."
| JacobSeated wrote:
| Things rarely reach a 100% and that's okay imo - as long as I am
| still making progress.
|
| It's hard to find time and energy for dedicated work sessions on
| personal projects with a full time job. Small incremental
| improvements ftw!
| muzani wrote:
| 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.
| imadj wrote:
| What if you don't want to sell it? Does that mean you did 100%
| or the remaining 10% shift to sth else
| taneq wrote:
| 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.
| Tade0 wrote:
| 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.
| alex-mohr wrote:
| See also Chris Lema's "Done Done" essays[0] and book[1] for more
| about the value of taking things to finished.
|
| [0]: https://chrislema.com/a-done-done-culture-habit-one/
|
| [1]: https://www.amazon.com/Creating-Done-Culture-Habits-
| Performe...
| amelius wrote:
| I see this a lot with hardware drivers. They tested it once on
| one system and it worked, then called it a day.
| davidgerard wrote:
| MVP, which I keep seeing in practice as stopping as far before
| 90% as you can.
| albert_e wrote:
| I have the opposite problem at a personal level.
|
| 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.
| triyambakam wrote:
| > 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.
| simonw wrote:
| 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.
| marginalia_nu wrote:
| Yeah.
|
| 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.
| drsim wrote:
| I call this the definition of done.
|
| 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.
| romesmoke wrote:
| 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.
| ChrisMarshallNY wrote:
| 90%?
|
| 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.
| pizza wrote:
| 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.
| pgpta wrote:
| 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.
| hkon wrote:
| 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.
| blitz_skull wrote:
| 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.
| pachico wrote:
| 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.
|
| It helps, in general, to manage expectations.
| welder wrote:
| TLDR: Marketing, QA, and roadmapping are often forgotten when
| finishing the "on-paper" deliverables of projects.
|
| ... I should save time and get ChatGPT to summarize articles.
___________________________________________________________________
(page generated 2023-08-02 23:02 UTC)