8 ms·
It's not really possible to say how many people are "working on" Threads, I bet. Threads is using Meta infrastructure. Should all those employees count towards
by whateverman23 3y ago
It's not really possible to say how many people are "working on" Threads, I bet. Threads is using Meta infrastructure. Should all those employees count towards Threads employees? How about HR? Legal? Internal tools? Building staff? Security? etc etc.
- adam_arthur 3y agoI'm not particularly interested in Twitter itself, I just disagree that many of the products we use today require a large number of developers. Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now. That trend will only continue. OpenAI only had ~100 employees at one point. You don't need 100s of operations people if you move from on-prem to serverless, for example. Today, social media requires the most people in content moderation/support, rather than development. Tomorrow those people are likely to be supplanted by LLMs or similar more tailored AI moderation models. Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact
- whateverman23 3y agoI see it as four categories, from least employees to most: 1. Desperately trying to make short term cash, and are trying to do their best with fewer employees than needed to maintain the current product. (Twitter is here). 2. Enough staff to maintain the current product, but not significantly innovate. 3. Significantly more than needed to maintain the current product, leaving room for people to work on non-core products that may end up being the next billion dollar project, even if the vast majority flop (Most big tech companies are here). 4. Way too bloated, with not enough projects to work on or not enough revenue to justify the R&D. The problem is that outsiders have a really really hard time understanding the product complexity of half a billion+ user services. Comparing OpenAI to the social media sites that this HN post is talking about is a great example. It's a completely different product with completely different challenges than FB, twitter, threads, youtube, whatever. Another great example is people citing "day in the life" videos that are actually recruiting videos showing the brighter sides of the job. Or people citing employees who claim that the company hired them to do nothing, when in reality it's a recruiter that was hired shortly before hiring slowed.
- adam_arthur 3y agoDo you agree or disagree that techproducts today are easier to build than 15 years ago? Everything else is irrelevant. Technology drives abstractions which drive deflation by allowing fewer people to produce more goods. This has been proven and observed for thousands of years Companies can thrive while overemploying people, but eventually they get undercut by one that doesn't
- whateverman23 3y agoYou're conflating two different topics: 1. "Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now." Correct. It's easier now to build apps that we used 10-15 years ago. 2. "Do you agree or disagree that techproducts today are easier to build than 15 years ago?" Incorrect. Tech product complexity has increased in many ways in the last 15 years (and the increase in complexity is larger than the decrease in complexity we talked about above). -- Regulation. COPPA regulations strengthened significantly around 10 years ago. Europe's GDPR went into effect in like 2016. Those are just a couple popular ones. Remember when Amazon just didn't collect sales tax? Sure makes things easier! And remember, those laws are constantly changing. If NJ raises their sales tax, you better have someone paying attention. If Europe comes up with a new privacy law, you better have enough people to drop everything and implement everything that's needed. -- Scale + globalization. Myspace topped out at like 100 million active users around 15 years ago. Facebook is 30 times that size now! That scale comes with complexities most don't think about. How do you report user video ad income to the IRS-equivalent in Andorra? I don't know, but you now need to know at Facebook's scale!
- orwin 3y agoI'm automating network engineering. We still hire network engineers, and while scale/regulations are big reasons why, do not forget security. This can trigger entirety new projects. Some industries still transfer their driver updates in sealed, marked usb sticks to their clients. A lot of companies invested in IOT in the past 5 years, and just recently decided they wanted all their connected stuff to go through specific Cisco routers. Security is my SWE job security.
- sroussey 3y ago> You don't need 100s of operations people if you move from on-prem to serverless, for example This statement really leaks a lack of experience with large systems. The efficiency loss for going to some serverless regime and the costs associated would be astronomical. My god…
- rhaway84773 3y ago> I just disagree that many of the products we use today require a large number of developers. In a non competitive world this might be true (although I have my doubts). In a competitive free market world it isn’t because a competitor can then beat you by hiring more developers and delivering more features faster than you could. > Its easy to find many examples of apps that were challenging to build even just 10 years ago, that are somewhat trivial now. The consequence of this isn’t that people continue using those tiny apps. The consequence is that people’s expectations increase dramatically. There was a time Evernote was a Unicorn. Today, even though building a product like Evernote would still be fairly challenging, it’s considered a feature. > You don't need 100s of operations people if you move from on-prem to serverless, I have not yet, in practice, seen overall spend go down by moving to serverless. You may have fewer ops people, but you now need more devs to achieve the same work because a lot of ops has been shifted to devs. That being said, I’ve often seen serverless not even lead to a reduction in ops. > Many products that required 1000s of people 10 years ago, may only require 100s today. To me this is just a fact This does not come close to matching reality. In the late 90s early 2000s you and a handful of other devs could build a multimillion dollar product using Visual Basic which only ran on Windows and was distributed as a binary to be run by your clients and it would be a best in class product. Today, you would need a designer, web developers, and someone with experience in pushing it to production and securing it to simply build an MVP version that ran on browsers. In addition you would need another set of iOS developers and another set of Android developers. Heck, you may even need an Apple Watch and iPad app to be competitive. All of this would probably be required to simply make your app competitive, never mind best in class. What your comment appears to be missing is that with software development becoming easier, what changes most is an increase in customer expectations.
- simmschi 3y agoAt a certain scale you start to break many things that you're used to abstract away into a neat little box. This can be anything, from kernel, libraries, network stacks to anything running in the cloud. "Serverless" is not really an option at a certain scale. It's likely too expensive, but especially a giant risk if you abstract away something that can fail in an interesting way. I remember we once managed to break the AWS ELB in one AZ and had a nice little call with a dev from Seattle. Another time we managed to saturate EC2 in a zone at a certain time. You will need people who can dig into this. If you're at Twitter scale you'll probably want whole teams digging into aspects that you take for granted.