"I Did a Bad Job" | Hacker News Reader

"I Did a Bad Job"

blog.ashmokhberi.com

86 pointsAshMokhberi32 comments

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

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.

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?

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.

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.

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.

+1 one for this model, this is exactly how we're building Decal.

I think the mistake was selecting a cofounder who was more committed to his consulting work than to your startup. As a freelancer your cofounder had the option to scale back his consulting or treat the startup as another consulting client. If he had to work to support his family then you didn't select someone with enough runway.

For all its benefits, the conventional wisdom of HN that one should pay off their mortgage prior to a startup may often be a mistake. A mortgage is leverage, and the cash used to pay ahead twenty years would be better used for a longer runway - $100,000 will cover many months of mortgage payments. What would most startups do for $100,000 worth of seed money?

Likewise, if a family keeps someone from going all-in to the startup that's only an issue when the other founders believe that going all in is a point of pride. In this case however, it's not that your cofounder wasn't going all in, it was that he wasn't even anteing up.

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.

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.

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.

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.

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

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?

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.

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.

With VS it's almost like testing each individual line though, at least for syntax and spelling. What I did was deliberately type things with as little attention to case/formatting as possible, and then watch to see VS transform it into neatness. Which meant it understood the line as expected.

Can't expect every editor to have the same features, but some sort of 'smart' plugin would that monitored your words and picked up things that were 'probably a mistake' would be useful. Then you could run the plugin every so often. A spelling mistake can be practically invisible because of the way your brain processes things.

How do most folk deal with this? Just get 'better' at not making small mistakes?

Yeah, this is exactly what happens when you do a lot of programming. Apparently, writing code isn't like writing natural language, where some people are terrible spellers and just can't get better. I know lots of programmers who are terrible spellers, some who can't spell a word twice the same way to save their lives, and in code they are as good at getting function and variable names right as anyone else. (FWIW, I observe this working in statically checked, compiled languages. Bad spellers don't seem to go through more "fix typo, compile, fix typo, compile" cycles than good spellers. It might be different when you don't have the compiler's immediate feedback pricking you to make fewer mistakes.)

The only problem is when people create class, function, and variable names that contain misspellings. Then your brain has to fight with itself, leading to repeated errors.

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

Sorry if it spoilt the experience. I will try to pay more attention next time.

Thanks for pointing it out. :)

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.

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.

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.

Sent.

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.

Indeed:

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

haha, tumblr is always doing that :)

It's back up now - and definitely an insightful read. Thanks for sharing.

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.

Thanks, that is exactly what I was trying to get at in the post, doing a "bad job" is not doing "bad" at all.

If you don't look back and think you did a bad job, it obviously means you're not improving.

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 :)

Reply on news.ycombinator.com