Hacker News Reader

Comment by edw519 | Hacker News Reader

Our product development was almost stalled for months on end.

Then you're doing something wrong.

Scaling, debugging, refactoring, customer support, prospect interaction, and even raising investment must all be done in support of product development, not instead of product development.

I am a notorious single tasker who loves coding more than anything else, so I used to have the same problem. If some other task took priority, all product development stopped.

Until a artist friend of mine told me the secret of his success, 4 words I have never forgotten, "I paint every day."

Now I code every day. No matter what else happens.

With 3 of you, I would expect that at least one of you could keep building something every day without any of you dropping any of the other eggs you must juggle.

View on HN

Yes, we probably were doing something wrong. That's the point of the post: to explain how easy it is to get into a situation where you are making little progress, and our story of getting out of it. I sincerely hope that others will be able to cope better when faced with a similar situation.

It's easier said than done, though. Development takes significant ramp-up time; if you spend 10 hours a day on it, you get much more than 5 times as much done than if you spend 2 hours a day. We already did what we could in terms of distributing workload amongst people to minimize context-switching.

It's easier said than done, though.

No kidding!

Sometimes I think that the definition of success has less to do with intelligence, hard work, and breaks and more to do with finding a way to do that which is easier said than done.

Didn't mean to be negative in grandparent, just to take advantage of sharing some of the best advice I ever got. There's a lot to be said for making progress every day, no matter how hard it is.

Best wishes for your continued success!

Just wanted to add I concur wholeheartedly, that's why my #1 commandment is "make progress every day". http://pzxc.com/ten-commandments-of-business-and-life

> Development takes significant ramp-up time; if you spend 10 hours a day on it, you get much more than 5 times as much done than if you spend 2 hours a day.

So true. Having one hour for coding is next to worthless. Perhaps the fabled 'zone' for programmers is merely a long enough stretch of uninterrupted time to immerse oneself.

Joel Spolsky used to write a lot on this topic, one of his key recommendations were private offices with a door that closes for developers. Lately I have seen little to indicate that the industry (startups or established companies) are moving in that direction. What are your experiences? Do you know many companies implementing this? Would you? Given that avoiding disturbances is so critical to developer productivity it seems like a no-brainer, I just don't seem to see it in the field.

EDIT: Here's one of Joels pieces on the topic (great read):

http://www.joelonsoftware.com/articles/FieldGuidetoDeveloper...

He actually answers my question by saying that no VCs would allow a company to squander their money on something so lavish. Wonder if people here agree with that assessment today.

   "Our product development was almost stalled for months on end."
   Then you're doing something wrong.

I disagree. When we were fundraising we got no actual product development done, and from what I hear this is rather normal. "Months" may be a bit long, but they also launched around the time they raised, so combined with all the support emails (free products = lots of support...good reason to charge!) I can completely understand.

Our fundraising took around 6 weeks, I got nothing done. I tried to take on all the businessy things like support, so my cofounder could keep coding. He got work done, but it was mostly paying the technical debt we had accumulated when trying to launch quickly. I'm convinced that was the right thing to do, since it seems to have gone well for us.

I can definitely see the benefit in the "code every day" mentality, but personally the extra context switch isn't worth it for me. I'm very conscious of when I'm not pushing new code and it physically pains me, so I keep tabs on it and never go more than a day or two without coding, but I don't make any hard-and-fast rules about my coding time.

> I tried to take on all the businessy things like support, so my cofounder could keep coding. He got work done, but it was mostly paying the technical debt we had accumulated when trying to launch quickly.

... it sounds like you were following his later suggestion pretty much exactly. Also, paying down technical debt may not be sexy, but it's damned important.

You're right, but Martin already said his team was working on things like scaling as opposed to iterating on the product. I think that's what every startup needs to do post launch: harden up the quality of their product before pushing forward with new user-facing features.

I agree totally with your disagreement. I am not doing any fundraising, but we are negotiating a couple enterprise sales and I am handling all bug fixes/user support. I have hardly made any progress on planned features. It's just way too much dealing with people and constant email interruptions and trying to be innovative. I am also taking on the businessy stuff as well, while my gainfuly employeed co-founder is free to drop a couple hours a day on code. This is one of the strongest arguments for > 1 founder IMHO.

I paint every day

Beautiful. In Russian we have a proverb "Дорогу осилит идущий" that roughly translates as "he who walks the path will make it to the destination". It sounds much better in Russian, and I was struggling to translate this into English for a while now, retaining the simplicity and elegance. This might just do it.

How about "He who travels gets there."

Sadly, not the same. A more literal translation is "the road will be overcome by the walker". There is a sense of a struggle in it, but also a sense of an achievement in the end. And the walker is he who walks rather than stand still, that is he who exerts effort towards the goal.

You suggestion does not deliver the same emotional load for me.

The phrase itself is a grossly inaccurate translation of a biblical verse into Russian, and using the original is not much help either.

I personally prefer the more literal translation. I think it keeps the sense of a struggle and achievement as you described.

But is it good English? I'm not a native speaker, but it does sound somewhat unnatural.

I agree that it does sound unnatural but I still would say it conveys the meaning better. The more correct version you wrote seems to loose the idea of struggle (to me at least).

It also occurred to me just now that original phrase presents the road from two different points of view: it is an obstacle, as its length separates you from your goal, but it is also the means to reach your goal. Does this make sense?

It seems awkward to me, probably because I have been taught to despise the passive voice in writing. I prefer 'The walker overcomes the road' which feels more better :)

If you can't reproduce the equivalent emotional load in English, it's probably because this particular phrase is not part of the culture. You can simulate it, much like Tolkien might, by choosing words that are more likely to resonate with an English speaker. For example, the word "walker" is not going to cut it, and "pedestrian" would be worse. Your explantation is helpful.

So you could try variations like "The traveler will beat the path." Or wait for the Russian module of WordLens :-).

How about, "Walk and you'll come"?

Twitter stalled for a quite a long time when they were struggling to scale, it's not necessarily a bad problem to have.

Also, it sounds like development was going on, improving architecture for scale and fixing bugs.

I've heard several people rave about rapportive so whatever they are doing is obviously working.

Well, I think from a customer point of view they see "making things more stable/reliable" as "no progress". Customers, rightly so, expect things to be stable and reliable from the start. Otherwise, they are testing your product and not every customer wants to do that.

I feel like Twitter was very lucky that they did not see a decrease in use and adoption while they had many problems with scaling.

I think Twitter benefited from having no attractive competition during that time (mostly there were similar sites, with little innovation and few users).

Also I think you get a 6-9month grace from early adoptors while they can see you scaling up staff and getting funding. However, after a certain point they start putting up blog posts about the lack of progress and pointing out alternatives. I think this is partly because it takes a while to get really used to what your app. does and how it's useful to them.

Yes, Twitter was lucky in more than one way. I agree with what you said about early adopter. I'd label these people as "willing to test products", even if that means they will encounter some bugs or issues. However, not every business will be able to say that about their first set of customers.

I think the biggest benefit for Twitter was that thanks to their API there were developers working on improving an innovating on top of the product even when Twitter was focused entirely on scaling.

"Then you're doing something wrong."

Naw. Everyone who raises money learns the same lesson. Fundraising causes your product to nearly stop. It sucks, but I've never seen it not be the case. Add to this that these guys had an early crush of users and I can imagine how painful it was.

> > Our product development was almost stalled for months on end. > Then you're doing something wrong.

Easier said than done.

I reached a point where I finally realized how deep in technical debt my startup was. Actually, that's not true. At some point I realized "OMG, I've got three months of work to do just to stop stuff from breaking every day". I was wrong. It was literally 12 months.

I'm now at the end of that 12 month slog.

I will never let stuff get as bad as it got then, so this was a wonderful learning experience.

...but to say that, based on where I was, it was the WRONG decision to put out the house fire before building more additions on the building is to speak without the detailed knowledge that someone in the situation brings to the problem.

Reply on news.ycombinator.com