@bdcravens posted this 2-year-old link (https://news.ycombinator.com/item?id=3922579), referencing the same post. Read the whole thread -- lots of interesting comments from all kinds of perspectives.
A question for the community, based on this comment:
I've been speaking to a few of the more established startups in the Bay Area that built apps on Rails and have started migrating the performance hotspots to the JVM. There's definitely a pattern I've seen.
1) First version of the app is built in Ruby, Python, or PHP and the lightweight stack helps the business stay nimble as it finds its market position/niche. During this time, there are a LOT of inexperienced, younger engineers working on the code.
2) Once the right market position is found, the app takes off and scaling problems abound as the lightweight stack starts to fall down at massive scale.
3) Funding is secured and more experienced, older talent (the Guild) is brought in (at much higher salaries) to help fix the hot spots. This is usually done using a combination of using the JVM or unmanaged C/C++. The engineering demographic often switches here as you see a lot of 30-something veterans from Yahoo, Google, etc come in and bring their tools with them.
4) Scaling isn't an issue anymore, but the culture has changed a bit as the business has become more established. Many of the early folks have moved on or gone into leadership roles. A few have been absorbed into the Guild and will move on.
It's very interesting. I've worked mostly in the midwest and the South during my career, and this lifecycle of talent is not something I've really observed outside of the Valley.
Why wouldn't this be something that takes place outside of the Bay Area?
Why wouldn't this be something that takes place outside of the Bay Area?
As someone who's worked both inside and outside the Bay Area - because startups on the outside can't afford to do step 3. Or don't dare to. They keep patching things up, applying duct tape upon gaffer tape solutions ad infinitum.
In a lot of cases they also just never reach the scale where doing this would make sense.
Comments
@bdcravens posted this 2-year-old link (https://news.ycombinator.com/item?id=3922579), referencing the same post. Read the whole thread -- lots of interesting comments from all kinds of perspectives.
A question for the community, based on this comment:
hkarthik 780 days ago | link (https://news.ycombinator.com/item?id=3923997)
I've been speaking to a few of the more established startups in the Bay Area that built apps on Rails and have started migrating the performance hotspots to the JVM. There's definitely a pattern I've seen.
1) First version of the app is built in Ruby, Python, or PHP and the lightweight stack helps the business stay nimble as it finds its market position/niche. During this time, there are a LOT of inexperienced, younger engineers working on the code.
2) Once the right market position is found, the app takes off and scaling problems abound as the lightweight stack starts to fall down at massive scale.
3) Funding is secured and more experienced, older talent (the Guild) is brought in (at much higher salaries) to help fix the hot spots. This is usually done using a combination of using the JVM or unmanaged C/C++. The engineering demographic often switches here as you see a lot of 30-something veterans from Yahoo, Google, etc come in and bring their tools with them.
4) Scaling isn't an issue anymore, but the culture has changed a bit as the business has become more established. Many of the early folks have moved on or gone into leadership roles. A few have been absorbed into the Guild and will move on.
It's very interesting. I've worked mostly in the midwest and the South during my career, and this lifecycle of talent is not something I've really observed outside of the Valley.
Why wouldn't this be something that takes place outside of the Bay Area?
As someone who's worked both inside and outside the Bay Area - because startups on the outside can't afford to do step 3. Or don't dare to. They keep patching things up, applying duct tape upon gaffer tape solutions ad infinitum.
In a lot of cases they also just never reach the scale where doing this would make sense.