6 ms·

The title makes it sound like the number of employees at Github scaled to 25k. The actual meaning though is that the number of Github contributers / participant

• seldonnn 7y ago
  I’m not an engineer and read it as the latter, correct meaning. Preposition “on” makes it pretty clear.
  • saghm 7y ago
    Maybe it just sounds that way to engineers then; I'm an engineer, and I read it the same way GP did. "on" is the preposition I'd use if I were describing the engineers as working on Github (as I just did right now)
    • uponcoffee 7y ago
      I'm in the same boat. On has many meanings, as written 'on Github' could mean: - Github is the platform/medium/support facilitating work - Github is the target/aim/focus of the work E.g. 'Working on a table' means I could be making a table or I am using a table to work on something.
    • jeffwilcox 7y ago
      Sorry for any confusion! I originally intended this as an update to a previous post (years before we acquired GitHub) that had the title "From 20 to 2,000 engineers on GitHub: Azure, GitHub and our Open Source Portal", so was attempting to go for a good side-by-side comparison. Post from 2015: https://jeffwilcox.blog/2015/11/azure-on-github/ https://jeffwilcox.blog/2015/11/azure-on-github/ I do realize it's probably very unlikely anyone here read that post. Happy to see if the OP wants to clarify better.
    • deleted 7y ago
      [deleted]
    • simonh 7y ago
      I'm on Github and I'm also on Facebook, but I don't work for either of them, and I don't think either of those statements is in any way confusing. I think the confusion is due to the use of the term scaling. Github has 37 million users, so 'scaling' it by another 25k is kind of meaningless. Having said that we know Microsoft owns Github. If the same article had come out in relation to Apple we'd immediately know what it was talking about without any confusion.
      • iamnotacrook 7y ago
        Are you a lead engineer on Facebook? I am. I don't work for Facebook but they host my baby photos. I think it's a little confusing.
        • simonh 7y ago
          If you worked for the company, I'd usually expect 'lead engineer at Facebook'.
          • jessaustin 7y ago
            The adjective "lead" would be somewhat diluted if there were 25k of them?
  • tedunangst 7y ago
    If the title said scaling to 25k engineers on Windows at Microsoft, would you think it's the number of people running Windows?
  • quickthrower2 7y ago
    Not clear to me. Microsoft has many departments. "On Github" I took to mean "Working On Github" as opposed to "Working on Office 365"
  • C1sc0cat 7y ago
    Yes for a native speaker its obvious unfortunately not every one is and gets caught out. When your writing potentially for non native speakers you have to be careful. I am doing a document that may well be read by our European co workers, so I am making sure to use basic grammar and explicitly explain what a "synonym" is in case I accidently confuse them.
  • BlackJack 7y ago
    They should've said "using" instead of "on" so it's unambiguous. I was confused too.
  • lugg 7y ago
    No, it's not clear at all. You can read it either way. Github is now a product for Microsoft. Teams work on products. The title was misleading and poorly written. Title could have been, "Scaling Microsofts GitHub usage from 2k to 25k teams." Or "Migrating the remaining Microsoft engineers into GitHub organisations, a scaling story from 2k to 25k contributors.
• irjustin 7y ago
  I was also quite surprised - Why does Github need 25k engineers.... let alone 2k engineers?!
  • deleted 7y ago
    [deleted]
  • js8 7y ago
    It is actually straightforward. Typically, to maintain the code, you need twice as much engineers than was needed to write the original code. Of course, you could write half the code in the first place, and then you will be safe - your engineers can maintain all the code themselves, you don't need to hire more of them. But this strategy has no place in modern software development, where we want to move fast and break things, since we can always maintain the code later, post-IPO, with more engineers.
    • freeflight 7y ago
      > Typically, to maintain the code, you need twice as much engineers than was needed to write the original code. As a non-coder this sounds horribly inefficient. Isn't coding also about automating tasks so people don't need to do them manually anymore? But with the above scaling, we'd always need more humans to solve new problems generated by coding itself, which feels quite counter-productive to the original intention, that of automation so fewer people are required for the same work.
      • js8 7y ago
        As a coder, I understand your confusion. It's a (slightly sarcastic) variation of an old adage from Brian Kernighan: https://www.quora.com/Computer-Programming-How-true-is-the-quote-You-need-to-be-twice-as-smart-as-the-person-who-wrote-the-code-in-order-to-debug-it https://www.quora.com/Computer-Programming-How-true-is-the-q...
      • ageitgey 7y ago
        This is more about Silicon Valley start-up culture than about how coding itself works in a perfect world. Here's an example of how extreme it gets. Imagine you work in a commercial-facing start-up that blows up seemingly overnight. In those kinds of companies, you'll have a core product that got super popular but was built by a small team. But now the investor money is coming in and everyone is taking about "throwing more coal in the engine". The company has to keep showing growth to keep investors happy but they essentially got lucky with the original idea and have no idea how to repeat it. In an attempt to accelerate growth, management spins up 10s of new teams to build out new lines of business. They'll hire a bunch of product managers who will come up with lots of new spin-off products that need to be built ASAP so the CEO can talk about them with investors in the next quarterly call. All of a sudden the company has an ad-tech team, a customer loyalty tech team, an affiliate marketing team, a local retail commerce team, a physical gift cards team, a "whatever mobile SDK Apple announced at the last WWDC" team, and so on. And all these teams need supporting services so you get another wave of new teams who build supporting services. And of course now no one is really working on the original product that is generating the revenue because it won't get anyone promoted since it is already "mature". Everyone has moved on to new teams where they can "make a bigger impact" aka claim responsibility for moving a metric so they get more money. Jump forward 24 months later and almost every one of those ideas will have failed to gain any real traction in the market and definitely won't have made a profit. But now a business that used to be run on a simple monolithic web app maintained by 20 people has been replaced by a 1000 person dev team building 75 microservices to power all these new verticals. But when all the new verticals fail to grow much, all the best developers move on in search of new projects more likely to get them promoted so you end up with a second wave of 2000 fresh college replacing them that all in aggregate generate barely any additional value over just having kept the original webapp going with the original team.
• redcalx 7y ago
  Yeh. I had one pull request accepted into dotnet core a couple of years ago; I wonder if that was enough to be included in that 25k number?
• onion2k 7y ago
  Quite misleading IMO. Maybe you could be a bit more charitable in your interpretation? It's obviously not the meaning you chose first, so it's more likely a mistake than anything malicious.
  • jessaustin 7y ago
    It isn't charitable to impute a suggestion of malice to the adjective "misleading". The headline does mislead most of its readers, regardless of the motives behind writing it. We hold headlines to a higher standard because clickbait is so awful. Even if only mistakenly so, this headline functions as clickbait.
• philshem 7y ago
  I agree that the title leads to confusion. Maybe a sed ‘s/engineers/contributors/g’ would help?