6 ms·

"I Did a Bad Job"

86 points by AshMokhberi 16y ago

biot 16y ago
One thing not mentioned is: "I did a bad job... selecting the idea". For myself, I've had some stunningly lousy ideas that, at the time, I thought would change the world but looking back I'm glad I never executed on them as they wouldn't have been viable no matter how flawlessly they were executed. I've also had my fair share of ones that I should have executed on but didn't so it goes both ways.
- Locke1689 16y ago
  I agree. I read the DistinctID idea and immediately had a pit in my stomach: "I hope the technical lead has a really good security background." Many software projects are, as I like to refer to them, "generalist projects." A good developer can make significant progress and success with these kinds of projects. However, there are some projects that I feel very hesitant about when someone without domain experience is brought on the project. These kinds of projects include, as a brain dump: machine learning, OS/low level systems development, cryptography, distributed systems in challenging environments, and reliability engineering. I'm not saying a non-expert can't succeed in these areas, just that it makes me antsy.
RyanMcGreal 16y ago
Indeed: "Our servers are over capacity and certain pages may be temporarily unavailable. We're incredibly sorry for the inconvenience."
- AshMokhberi 16y ago
  haha, tumblr is always doing that :)
  - RyanMcGreal 16y ago
    It's back up now - and definitely an insightful read. Thanks for sharing.
toadi 16y ago
Lots of people work on startups having a families and a mortage. That's why I disagree that the choice of co-founder was bad because of these reasons. I think this is a overgeneralization. Then you state you should manage development better and set better expectations. Well I think this is the main reason in the failure. Did your co-founder knew exactly what you espected?
- AshMokhberi 16y ago
  I agree it is over generalisation, but I feel in my case it was a main causation. He did under stand what my expectations where. However it was more that most of the time he had to work to support his family. He was not in a 9-5 job, he was doing freelance. So its not like he had a defined amount of time he could work. Clients work always came first and consumed most of the time.
  - toadi 16y ago
    Well I can fill 14 hours a day with client work too. But when working for your startup you calculate the minimal income you need and only spend the amount of hours on a client to earn it. The rest of the time is spent on working for your startup. When I was co-owner of a isv our main income in the beginning was consultancy for clients. In addition we developed our product and used the spare money to hire additional developers. The consultancy work made sure we had a minimal paycheck at the end of the month which would pay our mortage and the bills. Maybe this model is not sustainable anymore with being quick to the market and bead competitors on speed. But it worked in that period of time.
    - studiofellow 16y ago
      This is exactly what I'm doing for my startup and have found it works really well. Although I have to say it helps to have even a small network of contacts who can direct work your way. It's easy to burn through a lot of time just looking for freelance work.
    - dools 16y ago
      +1 one for this model, this is exactly how we're building Decal.
snippyhollow 16y ago
I'm a terrible programmer http://blog.kickin-the-darkness.com/2007/09/confessions-of-terrible-programmer.html http://blog.kickin-the-darkness.com/2007/09/confessions-of-t... !
- Tycho 16y ago
  One thing that seems terribly broken in most IDEs/code-editors is that tiny spelling mistakes can ruin your program. Visual Studio helps out with AutoComplete, in that you can deliberately never fully type a variable/function yourself, always use intellisense to complete things and use the right letter case. Although it's still not completely immune. When you run a script in Coda, say, first instinct is to look for functional problems, and usually there will be some, so you'll change stuff. But additionally there will be these tiny spelling errors, and failing to fix them right away leads to all sorts of trouble. How do most folk deal with this? Just get 'better' at not making small mistakes?
  - Vivtek 16y ago
    You get better at not making them - but much more importantly, you get better at realizing what mistakes you're likely to make, so when you make them and something doesn't work as expected, you find and fix the small mistakes very quickly. You also generally get better at testing and at diagnosis. It does get better.
    - ams6110 16y ago
      Yeah you get better. It's like learning to ice skate, maybe... you fall a lot and get a lot of bruises at first but eventually it gets to the point where you don't think about it. I learned to program before IDEs and I still use Emacs as my primary editor for almost everything. I find the Visual Studio "IntelliSense" type behaviors in most IDEs annoying in the extreme. But I can see how if that's what you started with, you'd come to find it useful.
      - Tycho 16y ago
bourbaki 16y ago
You did a bad job? In that post, you analyze perfectly the causes of your failure. If you learn something from that experience, your job wasn't bad, was good. Have success is important, everybody wanna get money and fame, but fail and learn from it is important too.
- AshMokhberi 16y ago
  Thanks, that is exactly what I was trying to get at in the post, doing a "bad job" is not doing "bad" at all.
- isleyaardvark 16y ago
  If you don't look back and think you did a bad job, it obviously means you're not improving.
bluethunder 16y ago
This is a really insightful writeup. Thanks. I just wanted to mention that a lot of things that you did bad, look so only in hindsight. Not that they are not bad, in the sense that you could have done better, but the very same things that now look bad could be construed to be actually 'good' had your startup gone right. Even the startups which do end up successfull do not become so by doing everything right. For example: 1. Your co-founder was not committed due to mortgage or family, however he was a great tech guy. And there is a chance that hte startup might have done better, without him spending as much time, in which case you would have duly thanked his technical chops which contributed to startup success. 2. If you would have been stricter with the goals your co-founder might have bailed early. Had the startup done better, being less strict could have been construed as a good management decision which helped accomodate your co-founders competing personal commitments. 3. Similarly for setting a deadline - sometimes things just take longer, and your startup might have turned over a good leaf by just trying hard enough. There is really no easy way to know when you have to stop. Essentially, the point that I am trying to make is that it is extremely hard to figure out what is the real reason for failure, and most such analysis misses the woods for the trees. However, being able to distinguish correlation from causation is extremely critical as it is the basis on which startups should pivot (or shut down).
- AshMokhberi 16y ago
  You have some very good points, which I'm in agreement with. It's impossible to analyse the defining points of failure and come out with the correct answers. But trying to understand what was not working well cumulatively, is a better way of understanding how one problem can stem into many more. Should I have broken the idea down soon enough and got something visible out there, potentially non of the other issues would have arisen or not been so relevant. The same goes for any of the other points I mention.
jacquesm 16y ago
The hardest part for me in analyzing past (partial or complete) failures is to make sure that none of those will bite me again. if there was a way to guarantee that you only make every mistake once then that would be progress. Kudos for being able to look at your own project this ruthless and to try to distill the lessons. If you succeed in never repeating any of the mistakes please tell me how. As for the write-up: you did a good job.
- AshMokhberi 16y ago
  Thanks I'm glad you appreciated it. It is likely that I will make the same/similar mistakes again, no one can prevent it. I think understanding what mistakes you are likely to make, allows you to watch out for them. While you will still make them, you will be quicker to try and remedy the situation.
BrandonM 16y ago
"I did a bad job" Proofreading this blog post. I'm not usually a pedant, but this post repeatedly made basic grammar errors. It detracted and distracted from what was otherwise a great article.
- AshMokhberi 16y ago
  Sorry if it spoilt the experience. I will try to pay more attention next time. Thanks for pointing it out. :)
  - mcantor 16y ago
    I enjoyed this writeup too, but was also distracted by the errors. I do a lot of proofreading; I'd be happy to send you a list of editorial corrections if you feel like it is worth the time.
  - BrandonM 16y ago
    The main thing was the frequent use of "where" in place of "were." Another thing that jumped out at me was the omitted words in the introduction. If you'd like me to go back and proofread, I'd be happy to. Thanks for an insightful article.
    - AshMokhberi 16y ago
      Thank you very much for offering. I would really appreciate it, if it will not consume too much of your time. You can mail me at, me[at] ashmokhberi [dot] com Thanks very much in advance.
      - BrandonM 16y ago
        Sent.
infocaptor 16y ago
The important fact is "You did a job". Some people never get to do the "job" or "work for themselves". Can you believe that for the first year of my product (infocaptor) I had zero sales. At that I kept feeling, "I did a bad job" doing the following -selecting the market -selecting the coding language -marketing and so on.. But eventually I prevailed. The product is now successful and all the learnings is only going to shorten the path to success for my new product (mockuptiger) I like to enjoy the journey more than the destination and think financial gain is just a side effect. ofcourse you need mile posts to know that your are going somewhere and these financial gains are excellent mile posts. So enjoy,live and learn - repeat :)
gohat 16y ago
This is very helpful and appreciate it. I think one of the most important skills to have in business and entrepreneurial pursuits is realizing when things aren't going great. You develop the tendency in life to whitewash things, to always think in the positive. But this isn't always necessarily good. I read a fascinating piece which said that depressed, pessimistic people were actually more accurate in their analysis of some things than happy optimists. Being able to think/accept that you have room to improve is a good thing. It's when the real improvement/learning takes place.

86 points by AshMokhberi 16y ago

biot 16y ago

One thing not mentioned is: "I did a bad job... selecting the idea". For myself, I've had some stunningly lousy ideas that, at the time, I thought would change the world but looking back I'm glad I never executed on them as they wouldn't have been viable no matter how flawlessly they were executed. I've also had my fair share of ones that I should have executed on but didn't so it goes both ways.

Locke1689 16y ago
I agree. I read the DistinctID idea and immediately had a pit in my stomach: "I hope the technical lead has a really good security background." Many software projects are, as I like to refer to them, "generalist projects." A good developer can make significant progress and success with these kinds of projects. However, there are some projects that I feel very hesitant about when someone without domain experience is brought on the project. These kinds of projects include, as a brain dump: machine learning, OS/low level systems development, cryptography, distributed systems in challenging environments, and reliability engineering. I'm not saying a non-expert can't succeed in these areas, just that it makes me antsy.

RyanMcGreal 16y ago

Indeed: "Our servers are over capacity and certain pages may be temporarily unavailable. We're incredibly sorry for the inconvenience."

AshMokhberi 16y ago
haha, tumblr is always doing that :)
- RyanMcGreal 16y ago
  It's back up now - and definitely an insightful read. Thanks for sharing.

toadi 16y ago

Lots of people work on startups having a families and a mortage. That's why I disagree that the choice of co-founder was bad because of these reasons. I think this is a overgeneralization. Then you state you should manage development better and set better expectations. Well I think this is the main reason in the failure. Did your co-founder knew exactly what you espected?

AshMokhberi 16y ago
I agree it is over generalisation, but I feel in my case it was a main causation. He did under stand what my expectations where. However it was more that most of the time he had to work to support his family. He was not in a 9-5 job, he was doing freelance. So its not like he had a defined amount of time he could work. Clients work always came first and consumed most of the time.
- toadi 16y ago
  Well I can fill 14 hours a day with client work too. But when working for your startup you calculate the minimal income you need and only spend the amount of hours on a client to earn it. The rest of the time is spent on working for your startup. When I was co-owner of a isv our main income in the beginning was consultancy for clients. In addition we developed our product and used the spare money to hire additional developers. The consultancy work made sure we had a minimal paycheck at the end of the month which would pay our mortage and the bills. Maybe this model is not sustainable anymore with being quick to the market and bead competitors on speed. But it worked in that period of time.
  - studiofellow 16y ago
    This is exactly what I'm doing for my startup and have found it works really well. Although I have to say it helps to have even a small network of contacts who can direct work your way. It's easy to burn through a lot of time just looking for freelance work.
  - dools 16y ago
    +1 one for this model, this is exactly how we're building Decal.

snippyhollow 16y ago

I'm a terrible programmer http://blog.kickin-the-darkness.com/2007/09/confessions-of-terrible-programmer.html http://blog.kickin-the-darkness.com/2007/09/confessions-of-t... !

Tycho 16y ago
One thing that seems terribly broken in most IDEs/code-editors is that tiny spelling mistakes can ruin your program. Visual Studio helps out with AutoComplete, in that you can deliberately never fully type a variable/function yourself, always use intellisense to complete things and use the right letter case. Although it's still not completely immune. When you run a script in Coda, say, first instinct is to look for functional problems, and usually there will be some, so you'll change stuff. But additionally there will be these tiny spelling errors, and failing to fix them right away leads to all sorts of trouble. How do most folk deal with this? Just get 'better' at not making small mistakes?
- Vivtek 16y ago
  You get better at not making them - but much more importantly, you get better at realizing what mistakes you're likely to make, so when you make them and something doesn't work as expected, you find and fix the small mistakes very quickly. You also generally get better at testing and at diagnosis. It does get better.
  - ams6110 16y ago
    Yeah you get better. It's like learning to ice skate, maybe... you fall a lot and get a lot of bruises at first but eventually it gets to the point where you don't think about it. I learned to program before IDEs and I still use Emacs as my primary editor for almost everything. I find the Visual Studio "IntelliSense" type behaviors in most IDEs annoying in the extreme. But I can see how if that's what you started with, you'd come to find it useful.
    - Tycho 16y ago

bourbaki 16y ago

You did a bad job? In that post, you analyze perfectly the causes of your failure. If you learn something from that experience, your job wasn't bad, was good. Have success is important, everybody wanna get money and fame, but fail and learn from it is important too.

AshMokhberi 16y ago
Thanks, that is exactly what I was trying to get at in the post, doing a "bad job" is not doing "bad" at all.
isleyaardvark 16y ago
If you don't look back and think you did a bad job, it obviously means you're not improving.

bluethunder 16y ago

This is a really insightful writeup. Thanks. I just wanted to mention that a lot of things that you did bad, look so only in hindsight. Not that they are not bad, in the sense that you could have done better, but the very same things that now look bad could be construed to be actually 'good' had your startup gone right. Even the startups which do end up successfull do not become so by doing everything right. For example: 1. Your co-founder was not committed due to mortgage or family, however he was a great tech guy. And there is a chance that hte startup might have done better, without him spending as much time, in which case you would have duly thanked his technical chops which contributed to startup success. 2. If you would have been stricter with the goals your co-founder might have bailed early. Had the startup done better, being less strict could have been construed as a good management decision which helped accomodate your co-founders competing personal commitments. 3. Similarly for setting a deadline - sometimes things just take longer, and your startup might have turned over a good leaf by just trying hard enough. There is really no easy way to know when you have to stop. Essentially, the point that I am trying to make is that it is extremely hard to figure out what is the real reason for failure, and most such analysis misses the woods for the trees. However, being able to distinguish correlation from causation is extremely critical as it is the basis on which startups should pivot (or shut down).

AshMokhberi 16y ago
You have some very good points, which I'm in agreement with. It's impossible to analyse the defining points of failure and come out with the correct answers. But trying to understand what was not working well cumulatively, is a better way of understanding how one problem can stem into many more. Should I have broken the idea down soon enough and got something visible out there, potentially non of the other issues would have arisen or not been so relevant. The same goes for any of the other points I mention.

jacquesm 16y ago

The hardest part for me in analyzing past (partial or complete) failures is to make sure that none of those will bite me again. if there was a way to guarantee that you only make every mistake once then that would be progress. Kudos for being able to look at your own project this ruthless and to try to distill the lessons. If you succeed in never repeating any of the mistakes please tell me how. As for the write-up: you did a good job.

AshMokhberi 16y ago
Thanks I'm glad you appreciated it. It is likely that I will make the same/similar mistakes again, no one can prevent it. I think understanding what mistakes you are likely to make, allows you to watch out for them. While you will still make them, you will be quicker to try and remedy the situation.

BrandonM 16y ago

"I did a bad job" Proofreading this blog post. I'm not usually a pedant, but this post repeatedly made basic grammar errors. It detracted and distracted from what was otherwise a great article.

AshMokhberi 16y ago
Sorry if it spoilt the experience. I will try to pay more attention next time. Thanks for pointing it out. :)
- mcantor 16y ago
  I enjoyed this writeup too, but was also distracted by the errors. I do a lot of proofreading; I'd be happy to send you a list of editorial corrections if you feel like it is worth the time.
- BrandonM 16y ago
  The main thing was the frequent use of "where" in place of "were." Another thing that jumped out at me was the omitted words in the introduction. If you'd like me to go back and proofread, I'd be happy to. Thanks for an insightful article.
  - AshMokhberi 16y ago
    Thank you very much for offering. I would really appreciate it, if it will not consume too much of your time. You can mail me at, me[at] ashmokhberi [dot] com Thanks very much in advance.
    - BrandonM 16y ago
      Sent.

infocaptor 16y ago

The important fact is "You did a job". Some people never get to do the "job" or "work for themselves". Can you believe that for the first year of my product (infocaptor) I had zero sales. At that I kept feeling, "I did a bad job" doing the following -selecting the market -selecting the coding language -marketing and so on.. But eventually I prevailed. The product is now successful and all the learnings is only going to shorten the path to success for my new product (mockuptiger) I like to enjoy the journey more than the destination and think financial gain is just a side effect. ofcourse you need mile posts to know that your are going somewhere and these financial gains are excellent mile posts. So enjoy,live and learn - repeat :)

gohat 16y ago

This is very helpful and appreciate it. I think one of the most important skills to have in business and entrepreneurial pursuits is realizing when things aren't going great. You develop the tendency in life to whitewash things, to always think in the positive. But this isn't always necessarily good. I read a fascinating piece which said that depressed, pessimistic people were actually more accurate in their analysis of some things than happy optimists. Being able to think/accept that you have room to improve is a good thing. It's when the real improvement/learning takes place.