> I doubt that all of their staff is doing DevOps or maintaining servers
Please don't assume this.
Just because you don't use the app and have no interest in the app or company does not mean you need to have a reductionist outlook on other people's work.
Bumble has a great and in depth engineering blog [0] here that doesn't make it 'an app with some basic functionality.'
1. I clicked the we're hiring link. Most roles are in EU (particularly UK and Spain). Is that for cost reasons? I know hiring engineers is cheaper in those two locations in particular. Or is it for EU/Badoo reasons?
2. Despite frequently playing up its female-led workplace, all but one of the blog posts are authored by men (based on photos and names). Is this reflective of their staff? The Badoo staff? The pool of people who like to write blog posts?
Please don’t assume this. Parent comment’s question seems genuine.
Why are you assuming genuineness when the parent mentioned this:
'an app with some basic functionality'
'I doubt that all of their staff is doing DevOps or maintaining servers'
'Is software dev in such a sad state that you can't deliver'
'what the heck are they overworking on?'
This is enough to know that the parent is dismissing the effort and work of others to the point that they are expressing a reductionist viewpoint of the entire app and company, which is not ok.
I’m just assuming the question was asked in good faith :) I’ve seen this topic discussed on HN about many companies and sometimes there are interesting and unexpected reasons for the high headcount.
I don’t think they’re implying that everyone is working overtime. Scaling up to accommodate a lot of new users isn’t always simple, we all know this. And a looming IPO means the pressure to get that scaling right first time is high (and has plenty of non-tech requirements to stress out employees too)
A busy year like that combined with the effects of COVID means that a lot of people feel burnt out. A synchronised break also has benefits: with no-one working there’s much less chance you’ll be tempted to “just check emails quickly” and get sucked back in.
I didn’t have a particularly intense workplace in the last year and I still feel pretty burnt out so I can sympathise.
It's knowledge work that is almost always in the complex domain, and as such it's far from simple. In fact it's the domain of unknown unknowns. So to have a product with millions of users with an online attack vector, that takes security and uptime serious, you need the following lead roles as a minimum:
* Architect
* Security
* Test
* Agile
* Developer
* Operation
* Owner
* UX
An app with millions of users are likely to have multiple teams that have a subset of the full application. For every feature you want to develop or any significant refactorings, you need to involve at least architect, security, test and operations. My experience is that teams around 8-10 people can be really productive and run a service. If you really want to accelerate and be best in class you assign teams to specific parts of the service that makes sense. Could be signup, search, chat, ect.
Then you probably want teams for analytics, ads and marketing, legal and before you know it, you have 50+ people working directly on a "self-standing product".
All that said, if the code base is crap, and the organization of the employees are similar it's highly likely that alone is responsible for creating the additional workload compared to a better codebase and organizational structure.
I should imagine there's a fair few customer support people along with at least a handful of content moderators - considerably more labour intensive than software dev/devops/sysadmin, I think.
Obviously there's also comms teams, marketing, HR, finance, etc. I'd say these are probably also more labour intensive than dev/devops/sysadmin because they tend to involve a lot more human contact, etc.
Come in to an exciting new opportunity. The first week you recoil in horror the technical debt. It appears the previous maintainer/builder didn't know one or more of: basic system admin, testing, documentation, packages, coding design, database design, or security.
The incidents start. The code is so interdependent it's terrifying to make even a small change. Fixing a bug in their custom json generator breaks a service you don't know exists and takes out billing. Yes they wrote their own. You lose the confidence of the team already there. Now you are too afraid to make changes.
All you can do is toil or try to think about selling a rewrite. When one or both of those hit burn out you fire up LinkedIn and beg for mercy.
But they have a lot of open positions, so there's apparently a lot more to this app than I realize: https://team.bumble.com/open-roles
Maybe there's some of that happening in there