Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
timewarrior
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
26 ms
·
91.
▲
by
timewarrior
9y ago
I disagree with this post. I am originally from India and used to be on H1. I have worked at companies like LinkedIn and Dropbox - so also know this from the point of view of supposedly highly qualified H1 candidates. I also was in leadersh
92.
▲
by
timewarrior
9y ago
I completely agree. But the privilege works both ways. Which is why people like me aren't coming to the US from India anymore. They would rather build startups in India or go to Singapore, Europe or Canada. Only of my friends, who has
93.
▲
by
timewarrior
9y ago
Just because I was able to overcome, doesn't mean the system works fine. It took a lot of hard work and luck to get me to overcome this. So I would say that my life improved in-spite of H1. I was able to found a startup (and successful
94.
▲
by
timewarrior
9y ago
I agree with all your points. Consultancy companies are lobbying to keep this system broken. I hope they all go out of business.
95.
▲
by
timewarrior
9y ago
I respectfully disagree with that. Maybe your friend wanted to do a startup where he owned the majority voting control in the startup. You can't do it on H1. Maybe he wanted to go meet his family but couldn't because his visa rene
96.
▲
by
timewarrior
9y ago
If it's possible consultancy companies already move the jobs to India. And if the intention is to solve the problem of jobs moving to India, create a law designed to fix that. H1 wasn't designed to fix this problem. Let it do what
97.
▲
by
timewarrior
9y ago
H1 visas work like a long tail. Most of the visas are used by big consulting companies to suppress wages. Most of these jobs pay less than 65k and displace American workers because they would demand more. A small part of the visas (less tha
98.
▲
by
timewarrior
9y ago
I agree that there will be some challenges and hopefully future changes fix that. However current reality is that very few startups employ H1. I founded a startup when I was on H1 hired someone else on H1 and it was a pain to go through all
99.
▲
by
timewarrior
9y ago
The intent of H1-B was to get talented immigrants for jobs for which we had a shortage of American labor. Instead it has become a tool for indentured labor of foreigners (especially Indians) to be used to suppress wages and exploit the fore
100.
▲
by
timewarrior
9y ago
Just saw this comment. Not sure if you will see the response. You raise a really good point. If someone is joining a startup at an early stage, work like it is your own baby. You are spending your most valuable currency by being here - whic
101.
▲
by
timewarrior
10y ago
If you build stateless horizontally scalable service (and you should) - you are almost always going to be blocked on DB. On the app server front you just keep adding more machines behind load balancer. As I look back, if we had used RoR or
102.
▲
by
timewarrior
10y ago
Main question here is that would they have done better if they had started with scale in mind. When you start you don't know how you product will look like when it has millions of users. You will likely do major product changes quite a
103.
▲
by
timewarrior
10y ago
It might be a good idea to read my post again. When I talk about 'service which failed' it was other products (e.g. Facebook, Twitter etc) - not components of my product. My post says 50M+ users and 1B+ message on a day. Almost 50
104.
▲
by
timewarrior
10y ago
+1 - it wasn't a typo. DB machines benefit a lot from huge RAM.
105.
▲
by
timewarrior
10y ago
There have been a bunch of discussions about language choices and impact on productivity. Wanted to touch upon this here based on my experience. TLDR: Depends a lot on individual situation. Pick the language you are fastest and most comfort
106.
▲
by
timewarrior
10y ago
Thanks for sharing your experience. There is always scope for a botched execution or just pure bad luck. I wish someone shared more candid details of what happened at Friendster.
107.
▲
by
timewarrior
10y ago
It's all in good spirit of sharing and learning. When you are thinking back, also consider the alternative where could you have missed opportunities and product launches because of extra effort spent on scaling upfront. It's all g
108.
▲
by
timewarrior
10y ago
It is great that you got a few which got traction out of 8 tries. This is an incredible success rate. Most people see much less success. The original suggestion is geared towards first few tries that people make. Once they have made a few a
109.
▲
by
timewarrior
10y ago
Can you please share some examples. I would love to learn from your experience.
110.
▲
by
timewarrior
10y ago
You make a great point. Health should be the topmost priority and I need to get better at it. However to my original point - you can lose fitness (within reasonable limits) and then gain it back and not notice a difference later on. However
111.
▲
by
timewarrior
10y ago
Would love to know more about your story. My biggest learning is Functional->Fast->Pretty from the product POV and Launch as soon as you can from an Engineer's POV. Some more details on my blog: https://anandprakash.ne
112.
▲
by
timewarrior
10y ago
Thanks for putting across your point in such a straight forward way. I didn't call out directly not the DB tables point. This kind of premature optimization is a huge red flag and I would anyone I am advising to avoid it.
113.
▲
by
timewarrior
10y ago
Agreed on this point. Many a times there is heavy lifting - recommendations, machines learning etc. However that is don't using specialized technologies in a non user facing process and the results are then dumped into a DB available f
114.
▲
by
timewarrior
10y ago
I mentioned something similar in a separate comment. My initial DB schema was pretty bad. We did at 2 schema rewrites and migrations from the launch to 5M users. Each time it took 2 weeks of sleep less nights. The machines today are really
115.
▲
by
timewarrior
10y ago
I remember reading that Friendster founder was complaining that there were facing a lot of technical issues and investors were not letting him invest effort in fixing them. IMHO, if your investors need to be involved in seeking approval for
116.
▲
by
timewarrior
10y ago
Agreed that completely blasé is pretty bad. However in this case being blasé would mean, not working hard to scale when you users are getting a bad experience. A basic stack these days node.js+mongo, go+*sql can easily handle more than 100k
117.
▲
by
timewarrior
10y ago
We were using MySQL like a persistent queue. As soon as a message was spawned, we would send it to downstream SMS gateways and delete them. So essentially that volume didn't use a lot of memory. At stage 3 we had 50% daily active users
118.
▲
by
timewarrior
10y ago
I am guessing you point is that if I had chosen Meteor and MongoDB - we wouldn't have been able to scale. My initial DB schema was pretty bad. Had to do quite a few DB migrations - which took weeks of work to execute. I have used Mongo
119.
▲
by
timewarrior
10y ago
I built this product as a side project within another startup I was working in. We had lot of money, had been around for 3 years and did not have a product. Because of this I had multiple levels of bosses above me in the company. They all g
120.
▲
by
timewarrior
10y ago
Couldn't agree with this article more. I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day. When I
More ›