Yes, But What Have You Done?(codinghorror.com)
codinghorror.com
Yes, But What Have You Done?
http://www.codinghorror.com/blog/2007/07/yes-but-what-have-you-done.html
11 comments
> "As is the case in most things, the best advice can be summed up in one word: think."
But not too much.
But not too much.
plants mostly.
I don't get this. Care to explain?
"Eat food. Not too much. Mostly plants."
- Michael Pollan
http://www.amazon.com/Defense-Food-Eaters-Manifesto/dp/15942...
http://www.amazon.com/Defense-Food-Eaters-Manifesto/dp/15942...
"but not too much, plants mostly" is a reference to the advice given on how to eat in The Omnivore's Dilemma.
I agree with this part:
"I believe there's a healthy balance all programmers need to establish, somewhere between...
1. Locking yourself away in a private office and having an intimate dialog with a compiler about your program.
2. Getting out in public and having an open dialog with other human beings about your program."
...but I'm not really sure I see the point of the rest of it. Jeff points out that most programmers are introverts (which I have my doubts about, but that's a different matter) and that #1 is no problem. So then why is he spending most of his time talking about upping the amount of time we spend on #1?
Personally, I'm of the opinion that we as programmers do too much. It's fashionable to complain about people who talk and think more than they do, but we forget that it's also important to take time to reflect on what we've done so we can learn to do it better. Whether that be in the form of group discussion or introspection is another matter, but the moral of the story is not to do too much.
"I believe there's a healthy balance all programmers need to establish, somewhere between...
1. Locking yourself away in a private office and having an intimate dialog with a compiler about your program.
2. Getting out in public and having an open dialog with other human beings about your program."
...but I'm not really sure I see the point of the rest of it. Jeff points out that most programmers are introverts (which I have my doubts about, but that's a different matter) and that #1 is no problem. So then why is he spending most of his time talking about upping the amount of time we spend on #1?
Personally, I'm of the opinion that we as programmers do too much. It's fashionable to complain about people who talk and think more than they do, but we forget that it's also important to take time to reflect on what we've done so we can learn to do it better. Whether that be in the form of group discussion or introspection is another matter, but the moral of the story is not to do too much.
... but if you do it right now without thinking about it, you might just run into one of many hazards:
1. someone else has already done it. 2. you end up doing it poorly. 3. you end up wasting time on something nobody cares about. 4. you could have been doing something else.
1. someone else has already done it. 2. you end up doing it poorly. 3. you end up wasting time on something nobody cares about. 4. you could have been doing something else.
Designing is aiming, not locking down on a target.
In comparison to shooting at random, when designing you still don't know if you're going to hit the target but you've at least made it clear what and where you think the target is.
Further, design and planning is a courtesy to the users. If you're churning out prototypes and basically shooting at random then you have effectively demoted your potential users into mere filters to help you see what will hit the wall and what will not.
I don't mean to defend waterfall design or any of that ancient crap. You can't design software like that but you must design it somehow.
Prototyping—seeing yourself what works and thinking about what would Joe or Jane want to use the software for—is a great way to design. But prototypes aren't real products. They're not even eggs of real products: prototypes are really meant to be thrown away.
It is not imperative to spend years with design committees just as you don't have to "do it fucking now" either. Release something small but make sure it's something you've truly designed. If you just throw anything that merely compiles or runs onto the market then "I'll fucking leave now" (and won't come back).
In comparison to shooting at random, when designing you still don't know if you're going to hit the target but you've at least made it clear what and where you think the target is.
Further, design and planning is a courtesy to the users. If you're churning out prototypes and basically shooting at random then you have effectively demoted your potential users into mere filters to help you see what will hit the wall and what will not.
I don't mean to defend waterfall design or any of that ancient crap. You can't design software like that but you must design it somehow.
Prototyping—seeing yourself what works and thinking about what would Joe or Jane want to use the software for—is a great way to design. But prototypes aren't real products. They're not even eggs of real products: prototypes are really meant to be thrown away.
It is not imperative to spend years with design committees just as you don't have to "do it fucking now" either. Release something small but make sure it's something you've truly designed. If you just throw anything that merely compiles or runs onto the market then "I'll fucking leave now" (and won't come back).
I think this is more useful for people trying to enter the industry. Startups looking to hire generally look more at what you have done, what code have you written. My last job interview asked to see my github / or any code examples. So this article to me just says "hey, you claim to be a coder. Let me see code that you took to write. I don't care if it's perfect, just let me see that you are constantly trying to solve problems and are interested in coding."
I very much agree with this line in the first comment:
"3. Getting out in public and having an open dialog with other human beings about something that does NOT involve programming."
To avoid burnt out that is.
"3. Getting out in public and having an open dialog with other human beings about something that does NOT involve programming."
To avoid burnt out that is.
An oldie but a goodie none the less. This kind of reminds me of Jason Fried's quote "inspiration is perishable"... which I interpret to mean: act now. Also, I'm also reminded of that Youtube video of the lady with cancer... "don't waste f*cking time..." she says. Very inspirational. http://www.youtube.com/watch?v=gePQuE-7s8c
Always Be Coding?
Thank you Thank you Thank you. I think it's time for another break from Hacker News :)
The last thing the world needs is more pundits. Pundits only add ephemeral commentary to the world instead of anything concrete and real. They don't materially participate in the construction of any lasting artifacts; instead, they passively observe other people's work and offer a neverending babbling brook of opinions, criticism, and witty turns of phrase. It's pathetic.
Take heed of this, Hacker News. Nothing annoys a real entrepreneur more than a wantrepreneur pundit.
Take heed of this, Hacker News. Nothing annoys a real entrepreneur more than a wantrepreneur pundit.
However, I think the programming world has now oscillated to far in the other direction. There seems to be a widespread perception that having a 5 minute discussion, hacking some shit out, and releasing it is the best way to do things.
The "fuck planning, just ship it" dogma is just as perilous as the "don't ship it until it's ready, even if that means it will take years" dogma.
Instead, try to ask yourself the following questions before you hit the "deploy" button:
- Will I be embarrassed by the quality of this software?
- In user tests, has it shown itself to be useful enough?
- In user tests, has it shown itself to be confusing?
- Will future features be undermined by releasing this version? (For example, will the UI have to change dramatically to add certain must-have features I have yet to implement?)
As is the case in most things, the best advice can be summed up in one word: think.