Live data from Hacker News

Finish your stuff

250bpm.com

61–70 of 177 posts

Re: Finish your stuff

#61

Now what if your home regularly changed in such a way that your old chairs didn't sit upright anymore? There are limits to the carpentry analogy.

If your chair covers the area of Los Angeles, it'll sure have problems with changing landscape. If it's a regular-sized chair, less so.

Re: Finish your stuff

#62
post #10

There's a great list of project management advice by Jerry Madden of NASA that gets posted here occasionally[1]. One of the points is; "Rule #30: It is mainly the incompetent that don't like to show off their work." Madden's remark is based on the specific environment he was involved in (NASA engineering); if you're surrounded by people who are good at their jobs and who know how to criticise constructively then ther…

There are other important reasons not to show things before they are done: one is the impatient group member who rather refocuses a development than to wait until it converges to something usable. It takes a lot of experience to make a realistic guess, how long software projects take. It also takes a lot of experience to put progress reports in a way that it always looks like great things are happening in order to av…

I'd say it is a better idea to show something finished (or if it's too big, a part of it that it finished). Because if it's not finished, those who look at it will have hard time to understand where you are, where you can go and thus they'll have hard time making a good review of it, or worse, they'll associate the unfinished stuff to your incompetence, lack of vision, lack of will, whatever.

Re: Finish your stuff

#63

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…

"You got it 80% done in one weekend - get it the other 80% done in another!"

Re: Finish your stuff

#64

Now what if your home regularly changed in such a way that your old chairs didn't sit upright anymore? There are limits to the carpentry analogy.

Right, and even the use cases for software can change in such a way that it can influence the entire architecture.

"We want to design a simple rocking chair for a sweet elderly couple." becomes "We need to make enhancements to this chair to equip it with an ejection seat suitable for a fighter pilot in a jet. No, you can't start over either, there isn't enough in the budget for that."

Re: Finish your stuff

#65
> Imagine the carpenters were like programmers.

So, they do the work for free, and updates as long as people keep using it?

Terrible analogy.

Re: Finish your stuff

#66

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…

> 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.

Re: Finish your stuff

#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 better / more meaningful.)

Re: Finish your stuff

#68

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.

Re: Finish your stuff

#69

"Lately, after 30 years in the programming business, I've finally managed to cut down my projects to a reasonable size." ... long before those thirty years, someone who thinks he is a great manager may take over the steering wheel (he or she). And things are ready to start from the beginning. Im my group, we have another flavour of not finishing things: managing by whatever is in front of the managers mind and declar…

> managing by whatever is in front of the managers mind and declare it highest priority Bane of my existence for the longest time. Eventually I learned to just ignore those managers. They're too chaotic to remember whatever I was supposed to work on for them anyway.

Ignoring seems to me like the secret weapon of the powerless. I like to confront, discuss and get things improved. But it is so hard to get incompetent managers up to speed, if they lack years of experience.

Re: Finish your stuff

#70
post #24

In my own experience, I found the following 2 things being the most important: 1) Keep it fun. Sometimes you start working on something and a week later you realize it's not as great as you expected it to be. Maybe you are working on some game and you can see it won't be as fun to play as you thought, etc. It's fine, it's ok to stop working on it. Forcing yourself to work on it won't produce any good. 2) Start with w…

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 complexity, or saw some major flaws in the initial idea. Like I've mentioned in my previous comment, maybe you start working on a game and find out some major flaws in the gameplay and can't see it being a fun game to play anymore. While it's not always obvious which case you are facing, in the later case, in my opinion, it's fine to halt the project. If you don't believe in it, nothing good will come out of it.

>>> It's not unusual to have problems with phase 1. But it's also the difference between being a professional and being a hobbyist.

I guess it depends on what's the purpose of the side projects. If it's something you try to make a business of (passive income kind of thing), then yeah you totally should get a bit of extra will power to get it shipped. But if it's something that is done just for fun, then I wouldn't sweat it that much.

Post reply on HN