10 ms·

Life at a startup

226 points by emmett 16y ago

TheSOB88 16y ago
Really awesome story. From the guy's page, it looks like he's a super hacker - learning to program at nine, embedding a Scheme interpreter in the Linux kernel. Between this and jacquesm's recent "it's easy" post, I wonder, do you have to be this kind of crazy passionate coder to be able to accomplish this kind of thing? I feel like I could be passionate about coding certain things, but nothing I'm doing now comes close.
- geoffw8 16y ago
  I'm currently grappling with "Computer science for dummies", wonder how I feel ;)
  - stcredzero 16y ago
    If you can get things done, then this counts for a lot. I know people who are geniuses and polymaths -- the kind of guys who do the calculus to optimize patterns for making their own juggling balls as a leisure activity. That doesn't mean that they are the best at getting things done though. Be able to get things done. Be good at taking into account what you don't know. Know how to cooperate and delegate. This is the stuff that's most useful.
    - moblivu 16y ago
      Another important thing isn't the complexity of the project, but the impact it has. Sometimes people tend to build on the big side when the best thing they can do is the simplest, just look at Facebook or Google.
  - gtani 16y ago
    I just found this, googling for Pat Methenys quote: Be the worst guy in every band you’re in. http://apprenticeship-patterns.labs.oreilly.com/index.html http://apprenticeship-patterns.labs.oreilly.com/index.html
- abstractbill 16y ago
  Thanks! I'm really glad you liked it. Don't worry about people being better at hacking than you though. There's always someone better, and in the end the only thing that really matters is your ability to get stuff done.
jamesjyu 16y ago
This is a terrific writeup, and mirrors a lot of the experiences I've had at Scribd as one of the first employees over the past 3 years. Build fast and push it live.
kayoone 16y ago
Great story, also looks like the guy really knows what hes doing. That said i read a post by him a while back where he talked about how useless unit tests are and how they dont help finding bugs: http://abstractstuff.livejournal.com/60388.html http://abstractstuff.livejournal.com/60388.html I found that quite irritating from somebody who seems so experienced.
- anamax 16y ago
  > I found that quite irritating from somebody who seems so experienced. Okay, but is he wrong? Let's be specific. He says "[Unit testing] just doesn't cover a large enough class of potential problems to be generally useful." He said how he evaluates bug-finding tools and discussed his experience. What is yours?
  - nostrademons 16y ago
    The dumb part about this debate is that it's being framed as all-or-nothing. The important question isn't "Are unit tests useful?" (the answer to that is "It depends..."), it's "Under which circumstances are unit tests useful?" If a particular unit test costs you more to write than it saves you in bugs, don't write it. And if it starts costing more in maintenance than it saves in confidence, get rid of it. There's a fair bit of cargo culting going on about how much to test - in my experience, it's not worth testing getters/setters, it's not worth testing simple "if this then set these variables" logic, and it's not worth unit testing database or external calls (you should have some integration tests for them though). It is very much worth testing tricky cases like a parser, or a bit-level decoder, or complicated algorithms. I just recently got up to 100% code coverage on a UTF-8 decoder I'd written. I found about a dozen bugs in the process. They were silly things, like leaving a digit off a hex constant, but they rippled throughout the decoder so that the results were completely wrong. If I'd just included that in another library without testing, it'd make the dependent library subtly wrong too, and I'd never hear about it until users started complaining, and they'd waste hours trying to find bugs in their code that are really bugs in mine. I'll also mention one other thing: the point of unit testing isn't to find bugs, it's to give you enough confidence in your code that you can freely change it. The real cost of bugs isn't that one erroneous event that customers will probably never notice, it's that the fear of that one unpredictable event makes management (which is sometimes you, if it's your startup) say "It works. Don't touch it, because you'll break it" and never improve the software. That's how you get shitty software that you can't fix.
bradleyjoyce 16y ago
I really wanted to read it but it was too painful on my eyes... tons of text smashed together, taking up the whole page. Fluid layouts are great, but there is a reason books aren't generally 12" wide. (hard for humans to keep their place on really wide texts) Also, increasing the line-height of the paragraphs would help a ton.
- LiveTheDream 16y ago
  I thought the line-height was fine. Agreed that reading long lines is harder, but luckily our browser windows are easily resizable.
- ideamonk 16y ago
  Give the readability add-ons a try, if you haven't already.
davidwparker 16y ago
I think the biggest takeaway for me from this is how he had the power to, and actually said, "no" to feature requests. This has definitely been a problem for several projects that I've worked on.
- ayers 16y ago
  This is a very very important thing. The package that I currently support needed to learn that years ago.
- enjo 16y ago
  I was thrust into a similar role to this guy when I was all of 24 or 25... It took awhile to learn to say 'NO', not just because it's hard but because it often led to really strong disagreements. The guys on the sales side of the product just couldn't understand when we couldn't do something. There was always an undertone of 'are you guys just not good enough?' I think that's the hardest part. Generally you say know even when it's technically possible. Hell you probably know exactly how to do it, just not in the timeframe you have. Learning to keep your ego (I can do this) from getting in the way of what's best for the product and the business is the hardest lesson a good developer has to learn IMHO. It's the programmers version of crossing the chasm.
eunice_chen 16y ago
I love the story and the writing style. He shows his passion in an honest tone; is proud of his successes and is honest about his (and the company's) mistakes. Very smart coder/hacker but also with a talent for writing (which people always think are mutually exclusive!). Props!
ideamonk 16y ago
Had a great read. Growing up watching gates, wozniac, jobs and other success stories in documentaries, I never wanted a 9to5 at a big establishment. You touch upon homebrew club which brings me back & close to what I still long for - the working in the garage/backyard moments. Perhaps its time. Thx!
JMiao 16y ago
bill: i recall viewing a startup school 07 attendee wiki and being impressed with your self description. i think you went by "bill bland" back then. good to see quality people doing great work.
wtn 16y ago
Oh nice, he beat YouTube to a seek feature that's been in QTSS for a decade.
deepakmishra 16y ago
gfghfhgfgh
bconway 16y ago
Great read, it's nice to see non-founders that are so enthralled with their jobs. Off-topic, though: All of our early press had evaporated, it turned out nobody actually wanted to broadcast their lives, and we really had no idea what to do. How did you solve this? I look into Justin.tv every few months and there's nothing compelling there for me, but it must be aimed at a different demographic.
idea4gud 16y ago
I absolutely admire the work by your team. Startup has those energy which I am hungry for , but I am stuck in enterprise world with lots ...., just watching in sheer amazement.
kmc 16y ago
"nobody was saying much to me" "I didn't bother to read the irc spec, I just watched the real-world traffic and used that as a spec" "no code review, not even any conversation about how I'd implemented things" Is this really the work environment we want to idolize?

226 points by emmett 16y ago

Really awesome story. From the guy's page, it looks like he's a super hacker - learning to program at nine, embedding a Scheme interpreter in the Linux kernel. Between this and jacquesm's recent "it's easy" post, I wonder, do you have to be this kind of crazy passionate coder to be able to accomplish this kind of thing? I feel like I could be passionate about coding certain things, but nothing I'm doing now comes close.

geoffw8 16y ago
I'm currently grappling with "Computer science for dummies", wonder how I feel ;)
- stcredzero 16y ago
  If you can get things done, then this counts for a lot. I know people who are geniuses and polymaths -- the kind of guys who do the calculus to optimize patterns for making their own juggling balls as a leisure activity. That doesn't mean that they are the best at getting things done though. Be able to get things done. Be good at taking into account what you don't know. Know how to cooperate and delegate. This is the stuff that's most useful.
  - moblivu 16y ago
    Another important thing isn't the complexity of the project, but the impact it has. Sometimes people tend to build on the big side when the best thing they can do is the simplest, just look at Facebook or Google.
- gtani 16y ago
  I just found this, googling for Pat Methenys quote: Be the worst guy in every band you’re in. http://apprenticeship-patterns.labs.oreilly.com/index.html http://apprenticeship-patterns.labs.oreilly.com/index.html
abstractbill 16y ago
Thanks! I'm really glad you liked it. Don't worry about people being better at hacking than you though. There's always someone better, and in the end the only thing that really matters is your ability to get stuff done.

jamesjyu 16y ago

This is a terrific writeup, and mirrors a lot of the experiences I've had at Scribd as one of the first employees over the past 3 years. Build fast and push it live.

kayoone 16y ago

Great story, also looks like the guy really knows what hes doing. That said i read a post by him a while back where he talked about how useless unit tests are and how they dont help finding bugs: http://abstractstuff.livejournal.com/60388.html http://abstractstuff.livejournal.com/60388.html I found that quite irritating from somebody who seems so experienced.

anamax 16y ago
> I found that quite irritating from somebody who seems so experienced. Okay, but is he wrong? Let's be specific. He says "[Unit testing] just doesn't cover a large enough class of potential problems to be generally useful." He said how he evaluates bug-finding tools and discussed his experience. What is yours?
- nostrademons 16y ago
  The dumb part about this debate is that it's being framed as all-or-nothing. The important question isn't "Are unit tests useful?" (the answer to that is "It depends..."), it's "Under which circumstances are unit tests useful?" If a particular unit test costs you more to write than it saves you in bugs, don't write it. And if it starts costing more in maintenance than it saves in confidence, get rid of it. There's a fair bit of cargo culting going on about how much to test - in my experience, it's not worth testing getters/setters, it's not worth testing simple "if this then set these variables" logic, and it's not worth unit testing database or external calls (you should have some integration tests for them though). It is very much worth testing tricky cases like a parser, or a bit-level decoder, or complicated algorithms. I just recently got up to 100% code coverage on a UTF-8 decoder I'd written. I found about a dozen bugs in the process. They were silly things, like leaving a digit off a hex constant, but they rippled throughout the decoder so that the results were completely wrong. If I'd just included that in another library without testing, it'd make the dependent library subtly wrong too, and I'd never hear about it until users started complaining, and they'd waste hours trying to find bugs in their code that are really bugs in mine. I'll also mention one other thing: the point of unit testing isn't to find bugs, it's to give you enough confidence in your code that you can freely change it. The real cost of bugs isn't that one erroneous event that customers will probably never notice, it's that the fear of that one unpredictable event makes management (which is sometimes you, if it's your startup) say "It works. Don't touch it, because you'll break it" and never improve the software. That's how you get shitty software that you can't fix.

bradleyjoyce 16y ago

I really wanted to read it but it was too painful on my eyes... tons of text smashed together, taking up the whole page. Fluid layouts are great, but there is a reason books aren't generally 12" wide. (hard for humans to keep their place on really wide texts) Also, increasing the line-height of the paragraphs would help a ton.

LiveTheDream 16y ago
I thought the line-height was fine. Agreed that reading long lines is harder, but luckily our browser windows are easily resizable.
ideamonk 16y ago
Give the readability add-ons a try, if you haven't already.

davidwparker 16y ago

I think the biggest takeaway for me from this is how he had the power to, and actually said, "no" to feature requests. This has definitely been a problem for several projects that I've worked on.

ayers 16y ago
This is a very very important thing. The package that I currently support needed to learn that years ago.
enjo 16y ago
I was thrust into a similar role to this guy when I was all of 24 or 25... It took awhile to learn to say 'NO', not just because it's hard but because it often led to really strong disagreements. The guys on the sales side of the product just couldn't understand when we couldn't do something. There was always an undertone of 'are you guys just not good enough?' I think that's the hardest part. Generally you say know even when it's technically possible. Hell you probably know exactly how to do it, just not in the timeframe you have. Learning to keep your ego (I can do this) from getting in the way of what's best for the product and the business is the hardest lesson a good developer has to learn IMHO. It's the programmers version of crossing the chasm.

eunice_chen 16y ago

I love the story and the writing style. He shows his passion in an honest tone; is proud of his successes and is honest about his (and the company's) mistakes. Very smart coder/hacker but also with a talent for writing (which people always think are mutually exclusive!). Props!

ideamonk 16y ago

Had a great read. Growing up watching gates, wozniac, jobs and other success stories in documentaries, I never wanted a 9to5 at a big establishment. You touch upon homebrew club which brings me back & close to what I still long for - the working in the garage/backyard moments. Perhaps its time. Thx!

JMiao 16y ago

bill: i recall viewing a startup school 07 attendee wiki and being impressed with your self description. i think you went by "bill bland" back then. good to see quality people doing great work.

wtn 16y ago

Oh nice, he beat YouTube to a seek feature that's been in QTSS for a decade.

deepakmishra 16y ago

gfghfhgfgh

bconway 16y ago

Great read, it's nice to see non-founders that are so enthralled with their jobs. Off-topic, though: All of our early press had evaporated, it turned out nobody actually wanted to broadcast their lives, and we really had no idea what to do. How did you solve this? I look into Justin.tv every few months and there's nothing compelling there for me, but it must be aimed at a different demographic.

idea4gud 16y ago

I absolutely admire the work by your team. Startup has those energy which I am hungry for , but I am stuck in enterprise world with lots ...., just watching in sheer amazement.

kmc 16y ago

"nobody was saying much to me" "I didn't bother to read the irc spec, I just watched the real-world traffic and used that as a spec" "no code review, not even any conversation about how I'd implemented things" Is this really the work environment we want to idolize?