Live data from Hacker News

Finish your stuff

250bpm.com

81–90 of 177 posts

Re: Finish your stuff

#81

Earlier quoted context omitted.

"If you're embarrassed by the first version of your product (i.e. suppose it's buggy, ..." A first release must not be buggy. But it can have a limited set of functionality. Imho, the real art of software development is to restrict the initial set of functionality and get that done, as quickly as possible (but not quicker), bug free (sic) and useful.

Did you just (sic) your own comment? I'm confused.

No, I (sic)ed 'bug free', because this is a goal that may never be achieved. I want to say "try as hard as possible" but did not want to look like I think it actually IS possible.

Re: Finish your stuff

#82
post #67

This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something bet…

Your comment is absurd. "A finished project is a dead project?"

Re: Finish your stuff

#83
post #70

Earlier quoted context omitted.

I've found: 1) Usually getting something finished is a boring slog. You get the (you think...) brilliant idea phase when you're all fired up, then you get "this is really boring" phase when you're working your way through a thicket of problems, squashing bugs, finding new bugs, thinking you should refactor (you shouldn't, usually) and completion seems like an ever-receding goal. 2) Break big goals into smaller goals.…

Valid point, I totally see what you mean. >>> You get the (you think...) brilliant idea phase when you're all fired up, then you get "this is really boring" phase. In my experience, there are 2 kinds of 'really boring' phase. One kind, as you mention it, is the less exciting part of the work, be it writing docs, or some edge case bugs, etc. The other kind is when you discover that you largely underestimated the compl…

I learned a lot from a beginner's art class a long time ago. The teacher threw some rope on the table and said "Here - draw this."

Problem - I can't draw. I have no idea what I'm doing. I am completely terrified of making some kind of horrible messy fuck-up non-art and...

To keep it short - it's all fine. I'm not Durer, and I sketched something that didn't look much like rope. But it was way better than I expected.

The takeaway: there's a kind of pain barrier with a lot of projects. You think "This is not working, it's not going to work, I'm totally wasting my time on it", and all kinds of other critical thoughts.

Then you keep at it, and often - usually - it all works out.

The one exception I've found is that if projects for other people feel stuck, there's often a good external reason, and it's possible that you're genuinely wasting your time on them.

But if it's a solo project and it's not working, you don't have to force that iteration to work. But if you keep pushing and iterating and changing, something good falls out. IME the intense frustration is often the sign you're on the way to a breakthrough.

Re: Finish your stuff

#84

Am I the only one that really hates the carpenter analogy? As someone who does woodworking on the side of my programming, there's a million reasons why it's a terrible way to think about software development. The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair. Someone else isn't going to have to come along later to maintain the chair an…

Carpenter analogy is as bad as the "book author" analogy. You write a book and let it go. Nothing to support, all updates are to be paid by customers in a new release.

"Book author" is at least closer to the truth. There are editions and old copies floating out there, it's hard to estimate completion dates, and authors have many of the same copyright problems. The difference is that software must live in a dynamic and shifting 'house' where everything gets rearranged by vendors, probed for weaknesses by attackers, and new features are constantly demanded by the users. Solutions to all of this are tacked on as an endless stream of appendices. Throw in patents for extra insanity. Both analogies strain to fit this reality.

Edit: That brings me back to the article. "Finishing software" just means we should act more like authors. Very hard to achieve when you think of the differences above.

Re: Finish your stuff

#85
post #67

This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something bet…

I disagree, based on personal experience. I have a few projects no longer in active development, but I use them frequently. They do what they are supposed to, they don't break down and require no maintenance other than changing the expiry date on the credit card associated with the hosted account every few years.

Re: Finish your stuff

#86
post #67

This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something bet…

Your comment is absurd. "A finished project is a dead project?"

Yes, which part did you not understand?

Re: Finish your stuff

#87
post #79

I find it irritating when people look at some of my projects on Github and consider then "abandoned" because they haven't had any commits in a year or two. They're not abandoned: they're finished. They do what they're designed to do, and I use them regularly. Outstanding issues may exist for feature requests that I don't need, or for minor bugs that won't occur in anything but obscure edge cases that don't apply to t…

If it's anything you expect other people to use, then I'd consider anything that hasn't been updated in the past year "abandoned", yeah.

If it's your personal projects though, I don't make that assumption.

Re: Finish your stuff

#88
post #67

This is absurd. A finished project is a dead project. If it isn't improving, it's dying. Never finish your projects (unless you're just doing homework). Software is a system. Systems of any non-trivial complexity are living things that must adapt and evolve. Constantly. (Also, there is absolutely nothing wrong with abandoning a project. Gain as much as you can from your experience and quickly move on to something bet…

> A finished project is a dead project. If it isn't improving, it's dying.

This might be true for large and broadly scoped projects, but for small Unix-style modules/tools it isn't always the case.

To use real-world examples, see point-in-polygon[1] and robust-point-in-polygon[2]. The tools are both "finished" and any further API scope/modifications would be harmful to the software that has come to depend on them.

They could forever be improved in documentation, discovery (i.e. a website), etc but at a certain point it is better to place your effort into new tools.

[1] https://github.com/substack/point-in-polygon

[2] https://github.com/mikolalysenko/robust-point-in-polygon

Re: Finish your stuff

#89
Yeah, it's hard to have a productive life with always moving targets.

With git, github and software managers pulling directly from it (although a decentralization way could be even better), I wish we get more often software by hash so we stop worrying less about copping with new changes and more about doing what matter to us.

Re: Finish your stuff

#90

Am I the only one that really hates the carpenter analogy? As someone who does woodworking on the side of my programming, there's a million reasons why it's a terrible way to think about software development. The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair. Someone else isn't going to have to come along later to maintain the chair an…

Taking this to the next level: I come across people all the time that put tremendous effort into building similes for... everything. Not every concept needs an analogy to be understood if we can explain things using correct and simple language.

Analogizing computing actions has become something of a trope. Doing so poorly has become a running gag.
Post reply on HN