
Finish your stuff - cjg
http://250bpm.com/blog:50
======
wainstead
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 our projects, which suggests this might be a
good kind of hackathon to host every six months or so).

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

~~~
wainstead
I searched my old emails and indeed we called it "Finish Up Weekend." It was
held May 10, 2013 at Work In Progress (in Las Vegas). I'll credit John Hawkins
(9seeds.com) with the name.

~~~
prawn
I did something remotely similar with a guy online - we set a schedule to each
launch a monetised microsite within five days and 'keep each other honest'
(e.g., not get lazy and do nothing each night). The plan was that each morning
we'd check in and show progress - only allocated an hour each night. The
pressure would motivate us to see it through.

Even though we'd never met and did everything via email, I still found it
effective and built a site that made several hundred dollars and then sold
down the track. Nothing lucrative, more than my hourly rate by hours spent.

~~~
hellbanner
Curious what the site was

~~~
prawn
Two-keyword domain, Adsense-monetised, 5-6 pages of content I wrote myself.
Location-specific.

Each night I did a tiny portion of the work:

\- research keywords and write bullet points \- decide on domain, buy domain
and set up hosting \- extend bullets to x paragraphs per page \- create site
with nav and pages \- launch and paste in ad code

Each evening was about an hour.

MFA sites are a bit slimy and unfulfilling so I tend to favour other side
projects these days.

------
netcraft
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 and have to be knowledgeable about the
specific tools that the chair was built with.

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

~~~
steveklabnik

        > Not every concept needs an analogy to be understood if we
        > can explain things using correct and simple language.
    

That's a pretty big linguistic 'if', actually... how do you come to understand
the 'correct and simple language' in the first place?

~~~
thaumasiotes
[https://xkcd.com/895/](https://xkcd.com/895/)

------
rlpb
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 the primary use case. I welcome high quality patches but otherwise
have no interest in pursuing them.

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

~~~
nathan_long
Abandoned or stable? If it has no dependencies and a small feature set, it may
just be done. "Stable" is a good thing.

~~~
enraged_camel
Let me give a more concrete example: if something was developed in Rails 3 but
was not updated for Rails 4, then I assume it won't work (I'm on Rails 4.1).

This doesn't mean the entire project needs to be re-written. Often times, a
simple note that says "compatible with Rails 4" would be satisfactory.

But if even the readme is not updated, that makes it difficult for me to put
any faith in it. And unfortunately there are tons of projects like that on
GitHub.

~~~
nathan_long
That's a fine example. It has dependencies, the dependencies change quickly,
so the project needs updating.

Let me give a counter-example. PriorityQueue is a data structure
implementation published as a Ruby gem in 2005:
[https://rubygems.org/gems/PriorityQueue/versions/0.1.2](https://rubygems.org/gems/PriorityQueue/versions/0.1.2).
It has not been updated since, because it doesn't need to be. It just works.
(It could use better docs, but even that would be a one-time change.)

Similarly, I have a gem that helps build searches with ORMs -
[https://github.com/nathanl/searchlight](https://github.com/nathanl/searchlight).
It doesn't directly depend on any ORM, just the "chained method calls to build
queries" interface that they implement. That means I don't need to update it
when ActiveRecord or Sequel or Mongoid gets a new feature. Which means I
commit far less often. I consider it feature complete and only make bug fixes,
which should eventually stop.

At that point, it may look abandoned, but it won't be. Just stable. Which I
consider a good thing.

------
onion2k
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 there aren't many reasons to
hide what you're doing other than it being a bit rubbish. I don't _entirely_
agree with the idea that people who don't show things off are necessarily
incompetent, especially if showing off your work means putting it under
general public scrutiny (who can be very nasty), but there's a huge amount of
value to be gained in getting feedback _from your peers_ as early as possible.

[1]
[http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_fo...](http://www.nasa.gov/pdf/293253main_62682main_jerry_madden_forum7.pdf)
(Non-PDF version:
[http://www.altisinc.com/resources/rules/](http://www.altisinc.com/resources/rules/)
)

~~~
mironathetin
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 avoid the refocus discussion.

The all important point is a constructive team that knows their job. But
especially in space project related development, you may be surprised to find
managers who don't know much about software.

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

------
melling
"Real artists ship"

"if you are not embarrassed by the first version of your product, you've
launched too late"

[https://en.m.wikipedia.org/wiki/Release_early,_release_often](https://en.m.wikipedia.org/wiki/Release_early,_release_often)

I'm sure there are many others, but these ones keep me shipping.

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

~~~
duggan
> There is nothing worse than shipping a half-baked product.

Well, other than never shipping at all, which is, of course, the point ;)

~~~
Gravityloss
Depends on the business.

If you're shipping respirators, cryovalves, automated replenishment systems...

~~~
duggan
Somehow I doubt you or anyone else here is shipping respirators and cryovalves
as side projects, and even if so, the context here is clearly web and
infrastructure software.

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

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

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

~~~
orkoden
The software in my package managers' sources is outdated.

------
haberman
The only way to "finish" software in the way the author describes is to find
or invent an abstraction that is exceptionally powerful and well-designed. It
has to give users what they want for a multitude of different use cases
without requiring the library to grow to accommodate those use cases.

In practice, abstractions this powerful and flexible are almost impossible to
create. For example:

\- the Linux kernel is based around POSIX, which is a pretty good set of
abstractions. But its API surface area is huge, and whenever users want to do
something not in POSIX, the Linux developers have to invent a new syscall or
stick more crap in /proc.

\- Lua is an exceptionally well-designed scripting language and
implementation, that satisfies tons of use cases while staying small. But it
keeps adding features to address pain points of existing users. For example,
Lua 5.3 added integer support. Users wanted it.

\- zlib is perhaps the closest I can think of to a library truly being "done."
And it gets away with this because it is perhaps one of the easiest
abstractions to define and contain: a simple string->string streaming
transformation that uses a roughly constant overhead of memory. That's pretty
much as good as it gets!

~~~
MichaelGG
Even zlib looks to be a bit more complex than that when doing streams of
packet data: [http://www.bolet.org/~pornin/deflate-flush-
fr.html](http://www.bolet.org/~pornin/deflate-flush-fr.html)

There's also stuff like preset dictionaries and so on so string->string is
just one part of the abstraction and isn't a full signature. Compression
level's another.

zlib's also not competitive in many scenarios, so it's only "done" for limited
scope.

------
gedrap
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 well defined, small goals. Define v1.0 which would contain only
the most critical features, ship it (even if it means simply tagging on git).
There's something hugely motivating about completing things, no matter how
simple they are.

EDIT. One more thing I'd add, when working on a side project, don't start
thinking about how everyone will be using, how many thousands of github stars
it will have, whatever. It doesn't even have to be actually useful, as long as
you have good time and learn something on the way. I've worked on a few
projects that I'd say are totally useless (such as
[https://github.com/GedRap/xs-vm](https://github.com/GedRap/xs-vm) ) but at
the same time I see them as successful because a) had great time b) learned
something new, even if it's some small details about a library or a language.

~~~
TheOtherHobbes
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. Repeat recursively until done. Then do
it some more, because you missed a few things. Sweat the small stuff, because
when you glue it all back together and you've worked through phase 1 properly,
the big stuff just works. (Or near offer, anyway.)

Keep the cognitive load low: small microprojects and problems, one at a time.

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

If you just keep starting new projects when you hit phase 1, you don't ship.

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

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

~~~
gedrap
Great comment, gave me some ideas and motivation, thanks for sharing!

------
mironathetin
"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 declare it highest priority.
This is the best way to work hard all the time and get nothing done at all.
Well, we all read peopleware a long time ago, all except of the managers.

Anybody here, who has a good idea how to handle these traps?

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

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

~~~
otherusername2
> the secret weapon of the powerless

It is. I've had a few managers where everything we all tried to change change
were fruitless. The only solution was to either antagonize until things got
out of hand, or to ignore.

> I like to confront, discuss and get things improved

That's a good initial starting point. But I've also learned that there comes a
time when expending any more of my own energy fighting such people is no
longer worth it.

> incompetent managers

In my cases, it wasn't incompetence but rather character. You can have
rational discourse with incompetent people. You can show them why they're
wrong. You can't have a reasonable discussion with someone who's own mind
jumps from high-priority to high-priority, wanting everything yesteryear but
isn't willing to put in the actual resources to get things done.

I've dealt with too many managers like that to expend much energy on it
anymore. Mind you, ignoring them should be a last resort, but given enough
experience with such managers, you learn to quickly know when you're dealing
with one.

I'd much rather spend my time making customers happy.

~~~
mironathetin
"I've dealt with too many managers like that to expend much energy on it
anymore."

You have many good points. And they match my experience. I'll try with less
persistence.

------
ams6110
Just an aside on the carpenter metaphor, there's sort of a running joke that a
carpenter's house is never finished. It's not just the software profession
that has this problem.

~~~
innguest
But as the carpenter goes on doing his stuff, the things he did stay put. They
do not suddenly become incompatible with each other, or need to be maintained
daily. Carpentry is orders of magnitude less brittle. It doesn't even compare.

Programming is more like policy writing. Definitely not like carpentry.

------
Kenji
Slightly OT, but

 _Except for some basic UNIX tools, like grep or make_

Is make a basic tool? I'm often surprised when I find out new features of make
that I was unaware of. I feel like it's bigger than it appears to be.

~~~
emmelaich
I consider _make_ a basic tool.

So much of programming and administration is about managing dependencies, and
_make_ is the default tool.

Such a pity it has a shitty syntax.

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

~~~
oconnor663
In the end though, readability/maintainability end up being at odds with
features/speed. I like to think about the hypothetical programmer that has to
take over my project ten years from now. Is the value of a new feature worth
their pain and suffering? Is my project going to be too painful to keep alive?

I think the projects at [http://suckless.org](http://suckless.org) have taken
maintainability to a really inspirational level.

------
pfortuny
Oh, come on: software is usually much more than a table or a chair. It grows,
it needs care, it is more like a plant than something static.

What does it even mean to "finish" a program like 'ls' given the increasing
complexity of filesystems with time?

~~~
vezzy-fnord
The semantics of POSIX dirents haven't really changed, and any file system
complexity is abstracted by the kernel's VFS subsystem to provide generic data
in all cases. So, yes, it is possible for something like 'ls' to be finished,
or at least for really long times.

~~~
pfortuny
Ok, yes, my example was not the best one.

But at the same time, consider things like UTF-8, localization, etc. They
appear at the least expected moment and someone has to do something unless the
tool becomes useless.

I understand you get the idea, though.

------
qznc
The point of the article is not "Finish your stuff", but "Tackle smaller
problems".

~~~
cafebeen
That sounds more in line with the unix philosophy!

------
rdtsc
Is nanomsg finished?

I found its Windows support rather broken -- failing test cases. Strange
lockups.

[https://github.com/nanomsg/nanomsg/issues](https://github.com/nanomsg/nanomsg/issues)

I do not see Martin working much on those these days. Does anyone know how
untangle those state machines besides him.

~~~
shepardrtc
Martin has passed the reins on to Garrett D'Amore, but I would say the
majority of the project is finished.

------
kazinator
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)".

------
danvoell
A couple times today, I found myself in the middle of something and came back
to HN to procrastinate. I saw the Finish Your Stuff headline and left to
finish what I was doing. I need to have a little banner on top of my computer
that says "finish your stuff"

~~~
raldu
You may find _noprocrast_ feature on HN settings page useful. It is a polite
reminder that tells you to go back to work. You can adjust how many minutes
you can stay at HN ( _maxvisit_ ), and when you can come back ( _minaway_ ).

------
jsingleton
The Zero MQ guys seem to have some pretty good wisdom to impart. Pieter
Hintjens has a free book at
[http://cultureandempire.com](http://cultureandempire.com) which is worth a
read.

~~~
vidarh
The iMatix guys have been amongst my heroes since they released Libero (state
machine code generator) and built Xitami on it (both mentioned by Hintjens as
"finished" projects in a comment to the linked article) back in the 90's...

~~~
vanessa98
Why is there so much dysfunction around everything they do?

~~~
vidarh
Is there? Care to expand?

------
sova
Some very practical, down-to-earth, solid advice.

Lines I found insightful: "... make it functionally complete in the first
place.

... If it can't be made functionally complete it's too big. You've tried to
bite off a piece that's bigger than you can swallow. Just get back to the
drawing board and split off a piece that can be made functionally complete."

^_^

I really like the idea of splitting a project into phases. You might have
Three phases, each one building on the last, but the very first complete phase
should be a complete and usable thing in itself.

First the skateboard, then the scooter, then the bike, the motorcycle, and
finally the car.

~~~
pdpi
> First the skateboard, then the scooter, then the bike, the motorcycle, and
> finally the car.

I've always found this metaphor incredibly amusing, because, to me, it
actually highlights the _problems_, rather than advantages, of the iterative
approach. At every step of the process, you're not only increasing complexity,
you're also pivoting your product to the point where:

1\. your previous clients are unlikely to still be well served by the new
product, and are likely to churn as a result

2\. the engineering challenges are different enough that most of the
components aren't really reusable, and trying to shoehorn one stage into
becoming the next will give you a sub-par product.

~~~
sova
It's not about incremental development, it's about passing the baton. The
spirit is motion/movement/transport, and the corresponding vehicle should be a
natural expression of that with your available tools. Who said that the goal
should be product-oriented? If I want to reach Alaska I will gladly take
whatever transportation suits me best at the time. If I were insistent that my
tank was clearly the most capable vehicle, although I would eventually get
there, it would not be as enjoyable, imho.

------
kefka
> Imagine the carpenters were like programmers.

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

Terrible analogy.

------
rc4algorithm
> Except for some basic UNIX tools, like grep or make, it's almost impossible
> to find anyting that's truly finished, not simply abandoned.

Much of the stuff in the OpenBSD base.

thttpd also comes to mind.

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

~~~
firethief
Is TeX dead?

~~~
jdimov9
You had to fish hard for this example, didn't you?

Sometimes, genius strikes and you get something so precisely thought out and
so well executed that it lasts for generations.

Still, I'd have to answer your question in the affirmative. The original TeX
is quite dead indeed. It (and the ecosystem around it) have evolved
significantly over the years and continue to evolve as we speak, so it is far
from finished.

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

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

~~~
emodendroket
Yes, but now we've clearly abandoned the familiarity of the analogy, making it
less clear how much value the analogy has in illuminating what we're trying to
say.

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

------
shabbyrobe
What does this mean for the future of nanomsg's development?

~~~
rumcajz
The project was take over by Garrett D'Amore so it's up to him to decide on
its future.

~~~
shabbyrobe
Thanks for the reply. Are you still involved in any capacity or have you
decided to move on from the project entirely?

------
JustSomeNobody
A lot of people equate "done" as "abandoned". Wasn't there some ruffled
feathers between Rob Conery and some user over Massive being "done"?

But, then, who wants those kinds of users, right?

------
splaty
I'm 5 years into the programming business and my own projects are just
starting to get into a usable state in a reasonable amount of time. Finishing
things feels a bit further away still.

Thanks for the article.

------
chipsy
I currently approach it from the "cyclical" time-management model. I'll know
that things are never finished, but what I can do is finish a sketch of a
broad system, or a detailing of a smaller portion, and return to it later.
Repeating that a few times gets very powerful results.

What never works is when I start building an eternal software edifice. My name
is Ozymandias, king of kings...

------
raggiskula
Just leaving this here, side project comic strip
[http://www.commitstrip.com/wp-
content/uploads/2014/11/Strip-...](http://www.commitstrip.com/wp-
content/uploads/2014/11/Strip-Side-project-650-finalenglish.jpg)

------
hobarrera
This is the sort of wisdom that's really hard to pass on. I've learnt this
from experience, and many other have. But when we try to pass this on to new
programmers, the message never quite reaches them until they've learnt in by
experience.

------
panadolkey
Run of the mill software exhibit life cycle patterns more like a small animal.
It starts out all nimble and has to grow and change over time to become an
adult of its kind; then it eventually dies.

Finishing your projects is good advice overall though.

------
euphemize
I like this idea, but I'm not sure it's realistic. Constraints change all the
time, just like your users' needs. In principle this works, but I'm not
convinced that everything should aim to be finished.

------
omouse
I'm at the last 10% of a screencast script; there's two more phases after this
but for some reason my productivity on the project has slowed to a crawl. I'm
not sure how to overcome this feeling.

------
z3t4
If you think "giving up" on a project is easy. Try "giving up" on your
"dreams", those project you work on every day, even though you know you wont
make it.

------
iambot
But its so hard! :) my strategy is to have many 3-9 side projects on at any
one time, each is really just practice and I judge the concepts based on how
often revisit them.

------
halayli
We share this problem with painters. It's hard to know if it needs a final
brush touch or it's done.

------
linux_devil
Very good read , particularly comparison of chair with product in first few
lines was opener .

------
jblok
"Lately, after 30 years in the programming business, I've finally managed to
cut down my projects to a reasonable size."

After 30 years of programming, you'd better be a pretty decent programmer. And
maybe that's why their projects take less time to complete.

~~~
vidarh
If you look at his progression, a lot of it is also about shaving down the
size and complexity. E.g. the AMQP -> 0mq -> nanomsg chain which is a journey
of cutting complexity.

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

~~~
s73v3r
"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"

That might be because they know that afterwards never comes.

