Those are certainly great points. With regards to technical debt, I feel like it's trading one form of dying for another. Eventually bugs and performance issues will bring product quality down to the point where it starts to affect your brand. I heard a quote at Mongo Seattle along the lines of "customers will forgive delay, but they will not forgive a bad product." Obviously 10gen has been around for a while and has…
Whoa, he went away. I still have the response saved on my desktop if anybody is curious about the context.
I'm glad! I had to keep the list short for the blog, but I think this would be a great place to collect other ideas. What 10 points would you have written?
A main one for me is that 'Shortcuts don't pay off in the end'. It hurts when you, as a developer, pour your sole into your app only to have your partners take shortcuts and purchase 'likes', or otherwise 'stuff the ballot-box'. Take the time to help develop sincere social and ad strategies for your app, and your potential for a higher-quality yield increases.
I almost had that point in there, but cut it before publishing.
I also had a point about "your code generation tool isn't good enough."
Hey all. This is my first post to HN and also my first contribution to the Startup Weekend blog as an employee. I think the subject matter would be interesting here and would love to hear if there is anything you think I missed. Startup Weekend gets to be in a cool place to lead among tech entrepreneurs and I'm always to happy to advocate for those in our field. Thanks for reading :)
I'll be at the Startup Weekend event in NYC tonight/this weekend. First time with this hackathon, excited to see how it goes.
I appreciated the recommendation to learn how to read a balance sheet. I want to keep my expertise grounded in the technical side of things, but I know I will get a lot more done if I can speak eye-to-eye with the business folks.
Add the mythical man month to the list. SO many non-technical folks fall victim to the idea that by putting more people on a job you can get it done faster, when in reality as we all know, efficiency drops sharply after a point. It takes a woman 9 months to carry a pregnancy, 9 women can't do same the job in one month, and the same is true for solving any complex problem.
Add the mythical man month to the list. SO many non-technical folks fall victim to the idea that by putting more people on a job you can get it done faster, when in reality as we all know, efficiency drops sharply after a point. It takes a woman 9 months to carry a pregnancy, 9 women can't do same the job in one month, and the same is true for solving any complex problem.
Except sometimes you CAN throw manpower at a problem and solve it more quickly. All projects are not the same, and all problems are not the same. It largely depends on how parallelizable the work is and how competent the overall system architecture is.
Point being: lets not turn platitudes into rules:)
Those are certainly great points. With regards to technical debt, I feel like it's trading one form of dying for another. Eventually bugs and performance issues will bring product quality down to the point where it starts to affect your brand. I heard a quote at Mongo Seattle along the lines of "customers will forgive delay, but they will not forgive a bad product." Obviously 10gen has been around for a while and has…
Whoa, he went away. I still have the response saved on my desktop if anybody is curious about the context.
Add the mythical man month to the list. SO many non-technical folks fall victim to the idea that by putting more people on a job you can get it done faster, when in reality as we all know, efficiency drops sharply after a point. It takes a woman 9 months to carry a pregnancy, 9 women can't do same the job in one month, and the same is true for solving any complex problem.
Except sometimes you CAN throw manpower at a problem and solve it more quickly. All projects are not the same, and all problems are not the same. It largely depends on how parallelizable the work is and how competent the overall system architecture is. Point being: lets not turn platitudes into rules:)
My point isn't about throwing manpower at a problem, it's about diminishing returns. The notion that if you put two people on a problem they will be able to solve it twice as fast is a logical fallacy. That's a fact, not a platitude. That being said, if you put 100 people on the problem, you may be able to solve it quickly, but even then you will eventually reach a point where adding more people does not add any more benefit. That's what I wish more non-technical folks understood.