Based on comments on HN, people are surprised that a company that "just runs a website" can employ "so many people." But this is a platform processing hundreds of millions of dollars among hundreds of thousands of users.
Here's a rough sketch of possible headcount. I'm making these numbers up, but maybe you can see how it does take a lot of work to make a business like this work.
- Engineering
- 5 - frontend dev/QA (web, tablet, responsive, A/B tests)
- 5 - backend dev/QA (app logic, video/content hosting, scaling up & out)
- 5 - payments dev/QA (payments is huge and complicated, probably a few payment processor partners)
- 5 - app dev/QA (iOS and Android)
- 5 - product owners (web, 2 apps, email, internal tools for agents etc)
- 5 - management (cto, engr manager, director etc)
- Business
- 5 - creator experience, patron experience, outreach, community
- 5 - marketing, advertising, lifecycle email and email campaigns
- 5 - partnerships, relations with big creators, collaborations
- 5 - fraud detection and remediation (fraud is huge, chargebacks are expensive, and the ability to charge $1 to test cards attracts fraudsters)
- Operations
- 20 - agents handling creator/patron requests/issues (more if 24/7 or multiple languages)
- 5 - ops/systems (keep everything running, downtime means less income)
- 5 - HR, recruiting, accounting, etc
They did not do hard research, since they are still designing their game, but they did present it to playtesters. I think this is an appropriate level of diligence for a product early in the design phase, it's the equivalent of the "hallway usability testing" recommended for agile teams.
It may be impossible to say right now whether this change helps kids get better at programming faster, but presumably, more kids will play a game that they feel is more approachable, similar to how the playtesters responded.
Like I said, I don't fault their methods for what they're optimizing for: sales. I -do- fault them for implying that it will improve coding skills when they never tested for that.
Absolutely. "Programming" with cute icons may not make you a "great" programmer, but that's not the goal. It's to get you interested in the idea of telling a computer to do cool things.
As an example, my daughter had no real interest in doing anything with a computer until we showed her she could move Moana's raft around with some Scratch/Blockly code in a Disney Hour of Code game. Therefore, I think these games are absolutely worthwhile. Let kids start learning the "hard parts" of programming after we've got them hooked!
https://worldbuilding.stackexchange.com/ is also a great community, with great discussions. Part science, part fantasy. People tedn to post long fun answers that remind me of XKCD's What If? series.
One micro-solution to the "what's deployed right now" problem is to have a health-check url for your app, which includes info like what git commit was used to create the current build, when it was deployed, and some basic application health info.
You can monitor this for basic uptime monitoring and refer to it to sanity check which version is deployed. We do this at my place and it's super convenient.
I wouldn't lose sleep over it. Deep Learning is great at making recommendations or classifications, given petabytes of data, but not even close to automatically solving general-purpose computing problems.
For example, I can type an error message into Google, and get sent to the solution, since thousands of others before me have provided the training data. But can I just describe my task to Google and have it produce the solution? Not even close.
For what it's worth, Groovy does have types. It is not dynamically typed, but optionally typed. Throw a @CompileStatic annotation on your classes (or use a global withConfig) and it is very nicely typed, using Java's type system.
> Throw a @CompileStatic annotation on your classes
Only if your site has upgraded to version 2.x of Apache Groovy, which many sites haven't. Even then, converting everything to @CompileStatic at once only works wholesale for tiny codebases. You'll face a lot of debugging for anything larger -- it's more like "throw" a @CompileStatic onto one class at a time, and test after each. You'll hit the wall soon enough. Consider why Groovy itself is still written in Java, not in statically compiled Groovy, and there's certainly no mention of converting its codebase anytime soon in the latest roadmap posted on their developers mailing list a day ago.
And of course Groovy, unlike Kotlin, only triggers IntelliJ's (and Android Studio's) code completion perhaps 80% of the time. Kotlin was created by the same people who built IntelliJ and for the explicit purpose of working properly with it 100% of the time.
I think this is a good point. There's a real risk that a homework you think is simple is a little more complicated because you're making assumptions. I think it's good to have a few current team members actually code it up (not just whiteboard it), and also to talk with a few candidates to see how long it took them, to calibrate this.
It's also better to aim small (a la FizzBuzz) and walk up the complexity slowly, as opposed to starting with "Solve this ticket from our prod JIRA queue, with tests please" (which I have actually been given as a test!)
I like to aim for a very simple task, like proposed above, with maybe one non-obvious part or edge case (which the spec mentions, so it's not a trick question). Just enough to demonstrate a) clean coding for the simple parts, and b) ability to solve something without using a completely naive solution.
I think this is good advice. It's better to see first-hand pain points that businesses experience as opposed to looking for an "idea" i.e. dreaming of a solution and then trying to find a matching problem that it solves.
If you start up with an "Uber for X"-tier idea, you may spend half your time educating people that they could use your solution.
On the other hand, it is difficult to watch a non-techie business worker perform their daily tasks for a few hours without seeing something that could be improved. A macro here, some workflow automation there, etc. Find a theme and you may be able to build something that solves a lot of problems.
Here's a rough sketch of possible headcount. I'm making these numbers up, but maybe you can see how it does take a lot of work to make a business like this work.
This is probably under-representing the business side since I am from the engineering side. Also it looks like they are hiring more people for all these teams. If you want more info, you can always look up Patreon's job openings: https://angel.co/patreon/jobs https://boards.greenhouse.io/patreon#.WcFitC-6z-Y https://www.glassdoor.com/Jobs/Patreon-Jobs-E915057.htm