[HN Gopher] Finish Your Stuff (2015)
___________________________________________________________________
Finish Your Stuff (2015)
Author : tosh
Score : 128 points
Date : 2021-06-15 14:00 UTC (9 hours ago)
(HTM) web link (250bpm.com)
(TXT) w3m dump (250bpm.com)
| hyperpape wrote:
| Finished software has lots of nice properties. What this article
| gets wrong is that it elevates a situational property of certain
| software to an imperative. Like so much praise of Unix, it's
| fetishized.
|
| To be finished, software has to exist in a specific context, for
| a circumscribed purpose. But some software is inherently open-
| ended, because the question of how we should work is open-ended.
| The way we work has changed over the past decades, and the
| software that supports that work has also changed. IDEs aren't
| finished, and neither is Emacs. Compilers might have a stable
| interface, but their internals aren't ever finished (you can
| artificially freeze the optimizations you do, but you're not
| done, you're giving up).
|
| Even for the cases the article starts with, I have my doubts. Is
| grep finished, or is it stagnant? The wow feature of ripgrep is
| performance, but it also provides new functionality (like ag
| before it).[0] Grep is finished, but the cludge of pipelines and
| copied shell snippets that people attach to it aren't. Eventually
| someone says "instead of find xargs blah, let's write a tool."
| Finished software makes a decision about shunting the complexity
| elsewhere.
|
| [0] Amusingly enough, I don't use ripgrep or ff or many other new
| tools, because I am a creature of habit. But they look like
| something I _should_ use.
| mdrachuk wrote:
| Everyone is a creature of habit. So new tools should be tenfold
| better to kick the habit. Is ripgrep so good? Doubt it,
| although it's definitely better.
| lawrencema92 wrote:
| The main reason I don't use it much is because I can't expect
| others to have it as well when writing scripts or sharing
| commands.
| mixmastamyk wrote:
| I use ag wrapped in a shell script interactively. Does
| exactly what I want with more than enough speed. Been
| packaged with Debian for a long time as well. Ripgrep
| doesn't seem to offer any advantages although could
| probably find something if I had time.
| toomanyducks wrote:
| This article seems to complain more about a lack of focus than a
| lack of completeness - I'm going to go out on a limb and say that
| maintenance is good. Maintainence keeps software up to date with
| new tools, old bug fixes, and occasionally new hardware. I like
| all of this. None of this turns the OP's chair into a table.
|
| And if you have a clearly defined and (from the Unix Philosophy)
| _narrow_ focus, you 'll not transform your chair beyond the
| original purpose.the If something gets in the way of the narrow
| focus, you'll revert it. Really, this feels like it derives from
| _do one thing_.
|
| I think the value of minimizing updates is in massive and
| adaptable systems with hundreds of iterating moving parts, not in
| small UNIX-like tools where the focus naturally restricts the
| updates.
| dt3ft wrote:
| I have a pretty good track record of finishing software projects
| I start.
| choeger wrote:
| Hmm, good luck trying this with scrum: Planning meeting for
| sprint 23. "I think we're done." "How can we be done?" "All
| agreed-upon features have been implemented." "Aha, but this user
| story here, that I totally did not pull out of my backside tells
| a different story."
| superasn wrote:
| > Imagine the carpenters were like programmers. You bought a
| chair.
|
| Except no carpenters ever gives out chairs for free let alone
| thousands and millions of them for free. And then they get abused
| for making a shoddy chair even though sometimes it is the best
| thing available in the market for free.
|
| There is an amazing video editing program for Linux called
| shotcut. Absolutely and 100% free. It may not be finished but The
| commercial version of it on Windows costs anything from hundreds
| to thousands of dollars per month yet this is the comment I came
| across from a person today(1):
|
| > _It's even named SHOTCUT so similar to SHORTCUT. The only
| reason i stay with it is because i only know how to edit on it.
| @shotcut, if you are reading this, i hope you have a bad day._
|
| I've read similar comments on vlc, audacity, etc. The amount of
| complaints and lack of appreciation of OSS projects is absolutely
| mind boggling to me, yet we keep getting new amazing software for
| free.
|
| (1) https://forum.shotcut.org/t/move-more-clips-at-a-time/10105
| nanidin wrote:
| Perhaps projects should include a "don't be an asshole"
| addendum to their license of choice that allows revocation in
| cases of abuse by users. It's a small thing to ask, but I'm not
| sure I like 2nd order and higher consequences of such an
| addendum.
|
| But man, it would probably feel great to reply as @shotcut,
| "Your license to use shotcut has been revoked under section
| 8.3.4 of the license agreement. Please cease use of shotcut
| until remedies under section 8.3.4 have been made (public
| written apology for abusive behavior)".
| nine_k wrote:
| It's more magnanimous to just ignore such users, and listen
| carefully to the users who care about (but not necessarily
| understand well) the software.
| grawprog wrote:
| >I've read similar comments on vlc, audacity, etc. The amount
| of complaints and lack of appreciation of OSS projects is
| absolutely mind boggling to me, yet we keep getting new amazing
| software for free.
|
| I find the worst is with OSS projects that are intended to
| replace professional software. Software that costs hundreds or
| thousands of dollars.
|
| Gimp, shotcut(and other video editors), libreCAD, libreoffice,
| OSM, Ardour, inkscape, Krita, even linux itself.
|
| I've seen some of the most vitriolic and nitpicky comments
| towards that and other similar software, over sometimes the
| stupidest things like ui differences to the commercial
| equivalents or something equally as shallow.
|
| Myself, I'm just happy there's so much professional quality
| open source software. It may not have the bells and whistles of
| the fairly expensive commercial equivalents, but compared to
| only 15 years ago or so, the amount of software these days that
| will let you do professional quality work at home completely
| free is incredible to me and the quality of OSS offerings keep
| getting better, while in a lot of cases, the commercial
| versions seem to have focused almost entirely on converting as
| many of their products to services as possible.
| blt wrote:
| "Commercial equivalent" might be more clear than "commercial
| version" - at first I thought the program was dual-licensed.
| bonoboTP wrote:
| You'd be surprised how little most people think about this.
| People outside the programming bubble just google programs and
| install them. For them there is no difference between open
| source, freeware, shareware etc. They have a task, they look
| for a free-as-in-beer software and then have an opinion on its
| quality. They have zero idea of how software is made or
| financed. For all they know or care, it could just fall out of
| the sky or grow on trees.
| hardolaf wrote:
| I honestly think Shotcut drove Black Magic Design to release a
| mostly complete free version of Davinci Resolve. It is just so
| good, that the leader in editing software had to make the tool
| free to most users.
| underdeserver wrote:
| I'm sorry you had to handle that, but it's the nature of the
| world that some people are uncaring ingrates. Don't fixate on
| them. Most people do appreciate the work and effort.
| alexdowad wrote:
| Great article. While there is definitely some software which
| needs to continually change by its very nature (think tax
| preparation software, where the tax laws change a bit each year),
| probably there are a lot more programs which _could_ become
| stable and then only receive tiny fixes or tweaks every now and
| again.
|
| Witness what DeK did with the version numbers of TeX... Instead
| of counting upwards with the natural numbers, each successive
| version of TeX receives an added decimal digit appended on the
| end, which makes it approximate pi more closely. The implication
| is that the program is asymptotically approaching its final
| state, after which it will not change.
| ChrisMarshallNY wrote:
| _> I dare you to list three finished software projects._
|
| I can probably list 30, and point to the repos.
| benibela wrote:
| When I was a teenager I finished a dozen software projects
|
| Closed-source games for Windows 98
|
| It was absolutely perfect. Closed-source, no one comes and
| complains they cannot compile anymore when the compiler and the
| library headers change. Games are just done, and if there are
| bugs they do not really matter. And Windows 98 apps still run
| perfectly on Linux with WINE.
| fouric wrote:
| Please do - I'm inclined to doubt whether or not those projects
| have any substantial amount of value without actually seeing
| them.
| ChrisMarshallNY wrote:
| Here, this might help:
| https://stackoverflow.com/story/chrismarshall
|
| It's in my HN handle. I stand behind all my posts.
|
| I've got links to a couple of dozen, in there (at least).
| Maybe over 30. I tend to toss one onto the pile, every now
| and then. I don't keep count. I don't fork other people's
| stuff. I'm the original author of all of it. I'm a bit...
| _obsessive_. My GH Activity Graph has been solid green, for a
| few years. I stay busy.
|
| A couple of the projects are sort of "WIP," but you will note
| that they are also highly polished. A number of repos are
| legacy repos for shipping apps that have been retired.
|
| I have been _shipping_ software for my entire adult life, and
| _finishing_ projects is my "at rest" state.
|
| Right now, the other tab in my browser is a Confluence page,
| describing a project I'm developing (not open-source). It's a
| slog. I hate writing documentation.
|
| But complete documentation is a big part of "finishing"
| software.
|
| That project won't be done for months. I'm enhancing the
| documentation for an API that I wrote (the backend server),
| so the developer working on the dashboard can get his work
| done.
| trentnix wrote:
| Art pieces don't get finished. The artist just eventually stops
| and moves on to the next assignment, next commission, next piece,
| etc.
|
| > Imagine the carpenters were like programmers. You bought a
| chair.
|
| There are volumes and volumes written about the definition of
| done. It's not so simple.
| the__alchemist wrote:
| This is often a scope problem. In open-source software, or
| corporate software not-well-managed, it's easy to take on too
| many features. This can happen by trying to address issues and
| PRs that should be rejected as out-of-scope. Or saying know to a
| request from another team, or a customer.
| scubakid wrote:
| The trend of software engineers starting and not finishing their
| creative projects has always been interesting to me, as I tend to
| err in the opposite direction -- for most of my projects, I get
| this compulsion to carry them to the finish line via as many
| caffeine-fueled nights as necessary... maybe it's driven in part
| by sunk-cost fallacy or something (admittedly, in retrospect some
| of those projects probably weren't worth the extra
| effort/stress). Still, I find it intriguing how often this other
| archetype appears.
| pram wrote:
| Priority and motivation can change pretty easily. You can think
| something is cool and interesting at the start, and then it
| fades over time. It's just expectation vs reality, no different
| than a project car rusting in your garage or an unfinished
| novel etc
| scubakid wrote:
| Yeah, it's understandable for sure. Personally though, I find
| overcoming the technical obstacles and the general process of
| incrementally crafting a better and more perfect thing to be
| an addicting cycle.. perhaps reinforced by the fear/knowledge
| that abandoning a project means capping its potential and
| locking in all those spent hours at minimal return on
| investment.
| tuyiown wrote:
| What is finished ?
|
| I've made a rust implementation of handlebars rendering that
| passed all handlebars test cases (on the feature set I covered,
| namely everything that did not involved JS parsing and
| evaluation), put it in a lib, ran performance checks against
| other implementation (not stellar, but good enough) documented
| the design and common API use cases.
|
| Yet, it was not finished in the sense that it relied on third
| party compiler plugin with dependencies on APIs removed on rust
| 1.0 release.
|
| That experimental part was 100% what I wanted to play with, I
| didn't care much of the risk of being stuck in the end.
|
| So, my goals where met, I moved on, and finished depends only on
| the way you look at it.
|
| I suspect large part of stuff that get started goes stale for
| more or less the same circumstances: it is finished because the
| goal was toying from the start, even though the author might have
| been delusional on publishing a re-usable outcome.
| bayindirh wrote:
| A project doesn't have to be that complicated to be useful.
| I've coded two utilities. One for converting IPs to their hex
| representation and back and linking it to various files
| automatically (for PXE booting), and another for using Mailgun
| from command line.
|
| Both tools are 2-3 hour jobs, running on production for years,
| and they meet all the requirements. OTOH, if you want to extend
| them, you can improve them leaps and bounds and they'd be
| _never_ finished in my life.
|
| I love this quote from DaVinci: "Art is never finished only
| abandoned". I also consider software as a form of art (which we
| can debate if you feel), and in my book, _software 's never
| finished, only abandoned_.
|
| And, to be honest, I love how software is never finished.
| MarcellusDrum wrote:
| > I also consider software as a form of art (which we can
| debate if you feel)
|
| I've never thought of it this way, but I think I agree.
| Nonetheless, can you please explain this idea more? Its an
| interesting view.
| bayindirh wrote:
| Software can be considered as art from many perspectives
| IMHO. Some of these perspectives are UI, UX and internal
| architecture. Smaller parts like API design or
| implementation of a specific feature can be art in itself
| though.
|
| In my book, elegance and high quality design is important,
| however it's expensive. A good architecture needs a lot of
| work to build and even more work to keep it clean, because
| software tends to outgrow its design during iterations as
| it gets more features. This is the prime cause of software
| rot.
|
| An elegant architecture is easy to program and extend until
| you outgrow it. An elegant UI is a beauty to look at. An
| elegant UX has minimal mental load. OTOH, making all three
| happen at the same time is a very hard task. My experience
| is on systems side and high performance code. So I focus on
| architecture and UX. I try to make very performant and
| complicated applications very easy to use, almost making
| them too easy to use.
|
| This removes burden from user, it removes friction. The
| user accomplishes something complicated without much
| effort, yet the results are precise, accurate and most
| importantly _correct_. This is what I consider art. OTOH, I
| make sure that all custom controls are available to the
| user if the user needs.
|
| In all cases, developer and user gets joy from
| developing/using the application. It feels nice rather than
| a burden. It feels smooth, like an enjoyable road trip
| where you both enjoy the road and driving at the same time.
| joshuaengler wrote:
| Absolutely true. You need to finish everything you start (within
| reason), because starting new projects then quitting becomes akin
| to an addiction. Don't develop bad habits, start only projects
| you know you can finish and see them through to the end if you
| want to be successful.
| snek_case wrote:
| When I was a teenager I would hop from project to project and
| rarely finish anything. I wouldn't necessarily say it was an
| addiction so much as I didn't know any better, and I would quit
| whenever I encountered a sufficiently challenging technical
| problem, because at that point the excitement waned, and the
| project actually became difficult. Then it was easy to get
| excited by a new project, which, in my head, would be all fun
| and no stress, until I encountered the next major technical
| challenge.
|
| In order to break out of that pattern I had to recognize that I
| had a problem and that this pattern existed in the first place.
| Nowadays, I usually stick to smaller project with a well-
| defined scope, avoid starting too many projects, etc.
|
| That being said, as a hobbyist, you have no duty to finish
| anything. In my opinion, it's OK to reassess your priorities
| from time to time. If you started something, and it's really
| become too stressful, you're not really sure where it's going
| anymore, it's OK to put it on ice and move to something else
| for a while. It's one thing to keep pushing because you really
| believe you'll be creating something that adds value to the
| world, it's another thing to punish yourself because hey, you
| really have to finish this thing, otherwise you're a quitter.
|
| If you're working on a startup, you definitely don't want to
| quit, particularly if other people depend on you, but if you
| already have a full-time coding job, you don't want to burn
| yourself out working on side-projects, which is unfortunately
| possible. So you also have to learn to respect and accept your
| limits IMO.
| mentos wrote:
| I'd say that's a natural part of learning as a kid. You're
| exploring and mapping the contours of your environment. I'd
| argue 100 half finished projects are better than 2-3 finished
| at a young age.
| dgan wrote:
| That's nonsense. I translate that to "don't ever try to dig
| into GCC/LLVM/Linux Kernel, because you won't be able to
| 'finish' it" There are hundreds projects out there that are
| worth exploring even one will never 'finish' them, whatever
| that means
| haswell wrote:
| If you're not careful, this stance is a really good way to
| never start anything.
| zcw100 wrote:
| Quitting has its place and what I would avoid is absolutist
| thinking. You don't need to finish everything that you start.
| Sometimes you don't even want that as a goal like when
| exploring or developing prototypes. The only reason that, "only
| start what you're going to finish" sounds good is because
| people tend to imagine finishing a project the way they
| imagined it would be when they started. There is also the story
| of the person that toils away year after year on a project that
| probably isn't going to have the outcome they intended. Then
| again there are people that toil for years that seem hopeless
| only to make a major breakthrough. There's a lot of uncertainty
| in the world. No one path is certain.
| Emma_Goldman wrote:
| I think it depends upon what you mean by 'start'. It can be
| fruitful to experiment with many projects, developing them to
| the point at which you can make a reasonable judgement as to
| their value.
|
| You're right that once you seriously commit to a project, you
| should generally follow it through. But then perhaps that's the
| problem: people aren't seriously committing to projects, just
| playing around with them endlessly in a strategic abyss.
| mariodiana wrote:
| What's the saying, "the last 20 percent takes 80 percent of the
| time"? That's why people don't finish. Once the fun part is
| over, they lose interest. The habit to develop is seeing things
| through that last bit of polishing.
| zeepzeep wrote:
| But also learn when to give up
| ChrisArchitect wrote:
| Previous discussion
|
| _4 years ago_ , https://news.ycombinator.com/item?id=15464702
|
| _6 years ago_ , https://news.ycombinator.com/item?id=9837915
| neilk wrote:
| The author seems to be suggesting that one can "finish" a project
| solely by limiting technical scope. But what really allows one to
| finish is limiting the set of users and use cases. Limiting
| technical scope is just an indirect way of accomplishing this.
|
| So there's a huge tradeoff between "finishing" and potential
| impact. I've heard of ZeroMQ. Until today I'd never heard of
| Libmill.
|
| And that's okay! I'm just saying I don't think it's possible to
| have a project that both has a large set of users and covers a
| narrow enough set of functionality that it can be "finished" by a
| single person.
| julienreszka wrote:
| Comparing software development with cabinetmaking is quite cocky.
| Totally different material and scope.
| underdeserver wrote:
| I think finishing your stuff is a late step in a software
| engineer's journey. It's appropriate when you feel you've had
| your fill experiencing the fun of exploration and exhausted the
| growth you achieve by taking on a technical challenge that's
| beyond your experience (but not your ability!).
|
| It's the final touch - it proves you can craft something and put
| it on display, ready for the world to see.
|
| (Of course, there are always bigger technical challenges and new
| areas to explore. This doesn't apply to them.)
| tut-urut-utut wrote:
| What if you never intended to finish? What if you only do it for
| fun of working on something interesting? Is it then wrong to stop
| as soon as it stops being fun, and you face "hard" or boring
| problems?
|
| Let's not pretend that everything needs to be "finished" or
| monetized. Let's just not kill fun by spreading pressure to
| "finish" or "get it done".
| rob74 wrote:
| As long as you (a) don't publish your project as open source
| (i.e., keep it private on GitHub) or (b) put a really big fat
| warning in the README that it's an experiment that may be
| abandoned at any time and nobody should rely on it, I guess
| it's ok... but who really does that?
| rdpintqogeogsaa wrote:
| I have a very large stash of private unfinished projects for
| this exact reason.
| matheusmoreira wrote:
| Publishing a project does not mean you're obligated to
| maintain it. There is no need to explicitly write this in
| documentation either. Nobody is obligated to work for free.
| If people expect to rely on developers, they need to hire
| them.
| matheusmoreira wrote:
| Sometimes I make a project just to learn something new.
| Sometimes I make a project just to prove that some crazy idea I
| had could actually work. Sometimes I make a project in order to
| reinvent old stuff in a new way that makes more sense to me.
|
| > Let's just not kill fun by spreading pressure to "finish" or
| "get it done".
|
| Completely agree. I have no idea why people are being shamed
| for walking away from projects. They aren't paying us, there's
| no incentive to offset the boring work. There is absolutely no
| obligation to finish anything. People who don't like that are
| more than welcome to do it themselves or pay for it.
|
| If people want to spend time finishing and polishing a project,
| that is absolutely fine. However, it must happen because they
| wanted to do it, not because they were shamed for not doing it.
| Nobody has the right to tell people what to do with their
| valuable time.
| meristohm wrote:
| What do you think about reframing "walking away" as "done!" or
| "done for now, no problem if I never get back to it before I
| die"? Done-enough rather than a nagging presence of unfinished
| work?
|
| Edit to add: ties in with my reluctance to use "should" with
| myself or anyone else.
| willismichael wrote:
| I started an open source pet project that I thought would take me
| a few weekends. After a few years, I finally feel like it's
| "finished". The problem is that I keep having people posting
| issues on the github project, asking for features that are
| outside the scope of what I want to do with it. I don't really
| know a diplomatic way to say no, so I usually just ignore the
| requests, which itself isn't very polite.
| haswell wrote:
| Just my personal take, but be clear about what you don't intend
| to "fix" or incorporate. Say it's not aligned with the project
| goals and it's not on the roadmap.
|
| This will help folks evaluating the project better assess how
| well it fits, and leaves behind a potential feature set for a
| new project (or fork).
|
| In the long run, not communicating might be worse than a
| disappointing but clear answer.
| Tarucho wrote:
| Maintenance is hard and once you are past the 20% that handles
| 80% of the cases work feels like maintenance.
| mattepp wrote:
| I disagree, starting projects that were way too big for me taught
| me alot about not just the language I was using to develop them,
| but about best practices, why it is important to have a solid
| ground to stand on, before adding more features that seem cool.
| It also taught me the importance of testing, as my projects were
| getting bigger, more components were interacting with each other,
| and manual testing soon became way too time consuming.
|
| In short, you learn by your mistakes.
| jedimastert wrote:
| Nothing is finished, always abandoned. Sure, you may have a list
| of exit criteria, but I can almost guarantee there were ideas you
| had to FIGHT to not add.
|
| (I may or may not have written a blog post about it, although is
| was more about creative endevours
| https://aarontag.dev/2020/01/20/nothing-is-finished.html)
___________________________________________________________________
(page generated 2021-06-15 23:01 UTC)