Live data from Hacker News

Finish your stuff

250bpm.com

131–140 of 177 posts

Re: Finish your stuff

#131

Earlier quoted context omitted.

> I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." Big monoliths are too useful to go away. Does emacs "do one thing and do it well?" No, it does a million things, some of them better than others. Nevertheless, lots of Unix guys use it.

Emacs does do one thing and one thing well: it runs elisp code. The image just happens to have a text editor and a bunch of other useful utilities built-in.

To expand on this, each elisp package tends to do one thing and do it well. The majority of my Emacs workflow is basically just a bunch of small, single-purpose elisp programs that get used alongside one another.

Emacs looking like the antithesis of the Unix philosophy is only because the Unix nature is deeply embedded within it.

Re: Finish your stuff

#132
post #17

Earlier quoted context omitted.

Reid Hoffman: https://pbs.twimg.com/media/Bldr6K1IEAAzeSl.jpg:large

Thanks. I had trouble reading it in text form, but now that it's an image that includes a guy's head I get the point.

I thought there was some confusion about who the credit for the quote went to. People weren't referring to Reid by name. The link was simply the first Google result that I clicked. Random.

Re: Finish your stuff

#133
post #8

> You bought a damned chair and you want it to remain a chair, not to find out that it's some kind of protean piece of furniture that's a chair today and partly a table tomorrow and, who knows, maybe you'll be able to humidify your cigars in it next week. This is exactly my problem with web-services (and software that auto-updates itself).

I wish more software updated itself. I don't want to navigate to the download page and run the installer every time it updates. That's busywork.

This is already a solved problem with package managers. You shouldn't ever have to "run the installer" each time you need to update a program.

Re: Finish your stuff

#134
post #39

I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." > Please join me in my effort and do finish your projects. Hear, hear. A friend and I hosted a "Finish it! Weekend" once (as opposed to a "Startup Weekend"). The idea was to get people together for one weekend and finish that last 10% or whatever of a project. Sadly we were the only two to show up. (And we both finished ou…

Nice idea. Call it a "FinishUp Weekend" as opposed to a "StartUp Weekend"?

Who wants to do one of these in NY?

Re: Finish your stuff

#135
post #60

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…

(Oil) Painting is a better analogy in some ways, as each project is unique, may have evolving requirements, rework, etc. And the fact that projects are rarely "done", you just stop working on them at some point (hopefully a "good enough" point) Mismatches include near total lack of reusability/composability, solo vs group effort, etc. All analogies are flawed, some are useful.

I think creative writing can also be a good analogy, for the reasons you state and also it seems closer to me since we are authors of the code we write.

Stories can evolve, plots get interwoven and some cut, its never finished until publishing maybe, and even then there can always be sequels.

Anyway, we could do this all day.

Re: Finish your stuff

#136
I don't know, lot of interviews I've been to in the past doesn't seem to value the fact that I spent almost 4 years of my life working on a single project (which will never be finished but pretty damn good by now) or that I've been selling and supporting customers with it.

A basic memoization algorithm type questions or 'tell me about a time when you...' and I choke every god damn time while a fresh graduate with a CS degree breezes through it.

I don't spend time on any of that when I'm working on a problem, it's important for me to build something that just works first in order to meet project deadline and then optimize afterwards but I guess this is not good for an employee point of view since they want someone who is more focused on producing code over product functionalities and features. At that point it would be useless if you've built something they can't look at the code (why the hell should I reveal proprietary information?).

So basically I find myself with the ability to finish but unable to be hired as an engineer as I lack CS and experience writing code in an office environment. Contrary, finding freelance projects and landing work has always been far more easier, and I can maximize my value for my client and also myself, since it is tightly coupled to the ability to complete projects on time and solve problems. Pushing back deadlines because of disagreements over code formatting or technology choice is not how I want to spend my time.

Re: Finish your stuff

#137
The only software that gets truly finished is embedded firmware for small devices, which is done when it is debugged and covers all the conceivable use cases, and development stops. (The firmware may still generate new descendant code, but users have to get new hardware to get that code.)

For much software, being finished is actually a kiss of death, because it is expected to keep improving and putting out new revisions. So "finished" is regarded as a synonym for "abandoned".

"Finish your stuff" for that kind of software is a poor directive. Rather, it should be, "before each release, get your stuff into a state of completion whereby everything that is documented is implemented and vice versa, and the quality is good (bug-wise, etc)".

Re: Finish your stuff

#138

Earlier quoted context omitted.

> I thought the Unix philosophy embraced the idea of "small tools that do one thing really well." Big monoliths are too useful to go away. Does emacs "do one thing and do it well?" No, it does a million things, some of them better than others. Nevertheless, lots of Unix guys use it.

Emacs does do one thing and one thing well: it runs elisp code. The image just happens to have a text editor and a bunch of other useful utilities built-in.

I think that's stretching the meaning of the philosophy quite a bit.

Re: Finish your stuff

#139

Earlier quoted context omitted.

If you're embarrassed by the first version of your product (i.e. suppose it's buggy, or is lacking in it's UI) then it's probably not ready to ship? There is nothing worse than shipping a half-baked product.

There are a lot of things, like say your competitors eating your lunch. If someone comes along and sort of satisfies the need it's easier for them to get people to upgrade than it is for you to come along later with a more polished product and ask them to migrate.

Depends on how much lock in your product has. Often an early releaser ends up creating a market and then a competitor comes in and releases a much more polished product and everyone jumps ship.

Re: Finish your stuff

#140
I can't think of a piece of software I wrote and feel finished, not because I abandoned them, but because I stop improving them when they are good enough for the task.

Maybe it's just me but I never feel a software is finished. You can at least refactor it or add new funcionality, improve speed/readability/reliability until the end of time. It's like writing a book. You can always rephrase, add new characters improve the story, but you have to stop writing it sometime.

Post reply on HN