Live data from Hacker News

Getting to 2M users as a one woman dev team [video]

brightonruby.com

71–80 of 303 posts

Re: Getting to 2M users as a one woman dev team [video]

#71

Pretty nice, 1 dev 3 team members in total and 1 million users? Are there any other products with such a small team and a huge userbase? Does this scale and when the business requires more coding and technical debt comes how do they manage it?

It's not a small team, but Valve seems to have a very similar proportion of employees to users. I think they have about 400 employees, and a user base of 140 million. That's roughly 3 employees per million users.

WhatsApp pre-acquisition by Meta was also very lean, some 40-50 people total serving 200 MAU.

Re: Getting to 2M users as a one woman dev team [video]

#72

Pretty nice, 1 dev 3 team members in total and 1 million users? Are there any other products with such a small team and a huge userbase? Does this scale and when the business requires more coding and technical debt comes how do they manage it?

Whatsapp pre Facebook. It has reportedly around 50 employees at acquisition, and 450 million users at the time.

Re: Getting to 2M users as a one woman dev team [video]

#73
post #66

Earlier quoted context omitted.

[flagged]

She's a woman, so it's correct to call her a "woman". No agenda here, necessarily.

I think user "tomp" means that "a one man team" basically means "one person team" in English (and many other languages).

Saying "one woman" is shifting the attention to the fact that the one person dev team consists exclusively of women. Which, I think, is pretty cool and note worthy because it is uncommon. Say a startup is run from an tiny island in the pacific, that would also be noteworthy.

To me the thing becomes "woke" when we are told not to use "one man dev team" to mean "one person dev team". Basically when it becomes political correct speech policing. But then the word "woke" is rarely defined, so it mean whatever to whomever at this point.

Re: Getting to 2M users as a one woman dev team [video]

#74
post #25

Earlier quoted context omitted.

> Are there any other products with such a small team and a huge userbase? My game Nebulous was 1.5 devs (one full time one part time) and multiple millions of MAU. 9.5 years later it's still going well. > when the business requires more coding and technical debt comes how do they manage it Delete bad code. Replace with good code. Sounds simple enough but in my experience at mega and mid corps, step 1 is almost never…

It's due to fear. Fear of breaking something that may depend on that bad code. Test automation rarely covers every possible case, and nobody wants to be on the hook when some code changes cause other stuff to break.

it's always fear for me. I'd rather leave it commented out for a decade or so to be safe.

Re: Getting to 2M users as a one woman dev team [video]

#75

Pretty nice, 1 dev 3 team members in total and 1 million users? Are there any other products with such a small team and a huge userbase? Does this scale and when the business requires more coding and technical debt comes how do they manage it?

> when the business requires more coding and technical debt comes

Tech debt doesn't come because the business requires more coding. It comes from poor planning and rushed implementation, often spurred by overzealous and naive management.

This is a small team with one dev, so they likely do things correctly from the start and don't acquire much if any technical debt. Nothing has to be done yesterday, ever.

Re: Getting to 2M users as a one woman dev team [video]

#76
post #25

Earlier quoted context omitted.

> Are there any other products with such a small team and a huge userbase? My game Nebulous was 1.5 devs (one full time one part time) and multiple millions of MAU. 9.5 years later it's still going well. > when the business requires more coding and technical debt comes how do they manage it Delete bad code. Replace with good code. Sounds simple enough but in my experience at mega and mid corps, step 1 is almost never…

It's due to fear. Fear of breaking something that may depend on that bad code. Test automation rarely covers every possible case, and nobody wants to be on the hook when some code changes cause other stuff to break.

That, and most orgs simply do not reward or even pretend to care about these kinds of improvements. If you delete bad (but working) code, and replace it with good (and, let's assume best-case scenario - also working) code, what has actually changed for the business?

Nothing. Except that in 3 years the junior dev that gets a ticket about doing something in this area will come in and not notice the code isn't a dumpster fire. Or, in 3 years, you won't notice that you didn't have to optimize this code a year ago.

What they do notice is that you were insisting on working on some mumbo jumbo and ok good they're done now they can actually work on something useful. Haha aren't these devs quirky? Sometimes they take a few days and work on something weird, and all the other senior devs nod and salute solemnly and I'm too scared to ask for more details, but they don't usually take too long so let's just indulge them for a few days to keep them happy so they don't leave too.

It takes a very, very deeply engineering-first org to really cultivate this intentionally. And similarly it seems like succeeding as a startup requires at least a decent amount of shipping some shit code fast so you get a series B, so usually you don't start in this posture and never shift into it before it's far too late.

And also unfortunately, devs often _do_ spend time optimizing/refactoring personal pet peeves as opposed to things that might have a good chance of mattering. I once saw another senior dev spend a week optimizing string allocations on our hot path. Our owner loves people who can do this kind of stuff, so it got a lot of praise. The microbenchmarks looked great, pretty graphs. Users noticed nothing, the actual metrics we track literally did not change, and now the already-complicated hot path is decorated with some contorted string-allocation-avoiding warts here and there and the next person to go in and change the code is _definitely_ going to keep doing that pattern, for sure. Meanwhile our oauth flow is still a tortured, unloved, twisted writhing mass of pain and suffering that prints bug reports like CVS receipts.

So... extraordinarily difficult to intentionally cultivate a culture that does this judiciously.

Re: Getting to 2M users as a one woman dev team [video]

#77

Pretty nice, 1 dev 3 team members in total and 1 million users? Are there any other products with such a small team and a huge userbase? Does this scale and when the business requires more coding and technical debt comes how do they manage it?

Look at almost anything that Marco Arment has been a part of.. Tumblr and Overcast (probably at least a 5% share of the whole podcast player market) became massively successful with only a dev or two.

Stardew Valley sold over 30m copies on a solo dev's work. I think you'd be surprised

I'm building my own product right now and never have I wished I had more technical help. It's all the other junk like sales, marketing, distribution, that makes the business so hard. Marketing and sales, in isolation, I've had success with in prior jobs. I'm a fairly productive solo developer.

However, being able to context switch and do both dev and marketing? Now that's hard. I have beyond massive respect for anyone that's even attempted it, let alone been successful doing it.

Re: Getting to 2M users as a one woman dev team [video]

#78
post #73

Earlier quoted context omitted.

She's a woman, so it's correct to call her a "woman". No agenda here, necessarily.

I think user "tomp" means that "a one man team" basically means "one person team" in English (and many other languages). Saying "one woman" is shifting the attention to the fact that the one person dev team consists exclusively of women. Which, I think, is pretty cool and note worthy because it is uncommon. Say a startup is run from an tiny island in the pacific, that would also be noteworthy. To me the thing becomes…

> To me the thing becomes "woke" when we are told not to use "one man dev team" to mean "one person dev team"

call it what you will, but yeah, you shouldn't use the word "man" to mean "person"

Re: Getting to 2M users as a one woman dev team [video]

#79

Pretty nice, 1 dev 3 team members in total and 1 million users? Are there any other products with such a small team and a huge userbase? Does this scale and when the business requires more coding and technical debt comes how do they manage it?

> when the business requires more coding and technical debt comes Tech debt doesn't come because the business requires more coding. It comes from poor planning and rushed implementation, often spurred by overzealous and naive management. This is a small team with one dev, so they likely do things correctly from the start and don't acquire much if any technical debt. Nothing has to be done yesterday, ever.

Exactly. Technical debt often comes when a lot of developers work on the same codebase. Everyone contributed and nobody refactors.

If the project is well thought out in advance a single developer is enough and will do perfect code

Re: Getting to 2M users as a one woman dev team [video]

#80
post #25

Earlier quoted context omitted.

> Are there any other products with such a small team and a huge userbase? My game Nebulous was 1.5 devs (one full time one part time) and multiple millions of MAU. 9.5 years later it's still going well. > when the business requires more coding and technical debt comes how do they manage it Delete bad code. Replace with good code. Sounds simple enough but in my experience at mega and mid corps, step 1 is almost never…

It's due to fear. Fear of breaking something that may depend on that bad code. Test automation rarely covers every possible case, and nobody wants to be on the hook when some code changes cause other stuff to break.

Can confirm. One of my proudest moments was deleting thousands of LOC of copy-paste-modify garbage. However I introduced one bug that broke another team which used an undocumented feature. It was fixed soon, but yeah, still not great. And very few people would have taken that on, I was not a career chaser.

Some would say it’s the other teams fault for not adding a cross-test against my teams code. And while that would have solved it, some things are hard to test. Even in companies who have good testing standards some things are still hard-to-impossible to test. In my humble opinion tests are great if and only if they are hermetic and fast. Unfortunately, the important things that can go wrong are usually the least testable.

In either case, in a non-perfect world (ie ~all large companies and most small ones) people optimize for not breaking things, and there’s a solid argument for that being a local optima, both for short term stability and career wise.

Post reply on HN