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.
Finish your stuff
81–90 of 177 posts
Re: Finish your stuff
#82This 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…
Re: Finish your stuff
#83Earlier 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…
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
#84Am 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.
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
#85This 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…
Re: Finish your stuff
#86This 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
#87I 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 your personal projects though, I don't make that assumption.
Re: Finish your stuff
#88This 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…
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
#89With 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
#90Am 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.