No matter the many critical comments this is actually a pretty concise summary of the technology / concepts behind blockchain including recent developments such as scalability / rollups and interoperability, which are hard to find good explanations for.
Recommended read for anyone interested in the space from my perspective!
Despite potential imperfections.
Interesting to see this so far up the ranks on Hacker News. Despite the content not being technical, cutting edge or intellectual as most stuff here (as also noted in the comments regarding the challenge to find clear takeaways).
Maybe this indicates that a lot of people here can relate to the author's emotions regarding encountering people with alcohol problems, also in the tech scene?
Signal's by default e2e encrypted chats can be used across platforms, e.g. synced across desktop and mobile.
Telegram's secret chats are only available on the device where you initiated them. That's a major disadvantage.
Signal doesn't even have a web app. They have a desktop app that works great and that I use every day, all day long for all kinds of communication. On my desktop and laptop.
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 / participants at Microsoft increased to 25k.
Quote:
"At Microsoft today we have almost 25,000 engineers participating in our official GitHub organizations for open source, a great number of them contributing to open source communities throughout GitHub."
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)
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
flowkey is a profitable education tech startup helping millions of users worldwide to learn piano.
Flexible working times, constant learning, a cutting edge tech stack (React Native, GraphQL) and an experienced team are waiting for you.
Working culture close to Open Source, pick issues yourself, no sprints/deadlines, work on the topics you are most passionate about.
Full trust for end to end feature ownership, no product managers telling you what to do.
Specific examples of what classifies as a “hard” or “easy” interview question would be very helpful to have reference points and assess one’s own interview process.
I wish this comment were higher in the thread, because it's essential. I'm very interested in this finding from triple byte, but we have no guidelines for what hard and easy questions are.
I know these questions are part of triplebyte's product, so a full, repeatable study isn't in the cards. But if someone from triplebyte could just post a few examples of each, I'd be able to get a lot more out of this result.
Easy - reverse a string, determine if a string is a palindrome, reverse the digits of an integer, determine if one string is an anagram of another.
Hard - implement a subset of regex match in optimal time+space, find the operations required to turn 1 word into another word given a list of transitory words, find the median of 2 sorted arrays in optimal time, find the next permuted value.
I think those "easy" examples are too easy to get any meaningful signal from. If they struggle, they have no idea what they're doing, and if they don't, you don't really learn anything about how they work because there's not much to them.
Other people have mentioned Triplebyte using console tic tac toe as a question; that seems like a better sort of "easy" question that still lets the interviewee have a chance to show off their problem solving and factoring skills.
examples of hard (subjective), recursive algorithms, anything that requires dynamic programming, generating permutations/subsets, problems that require a "de facto" memorized algorithm such as tree/graph traversals, coloring of subsets etc.
And here's the problem. People don't agree what's hard/easy. If I ask you to find duplicate values in a nested data structure (arrays of arrays) ... that calls for recursion. I think that's easy.
flowkey | https://www.flowkey.com | Full stack Web & Data Science | Berlin, Germany | FULLTIME, ONSITE
flowkey is a profitable education tech startup helping millions of users worldwide to learn piano.
Join us as a Data Scientist or Full-stack JavaScript Engineer. Flexible working times, constant learning, a cutting edge tech stack (React Native, GraphQL) and an experienced team are waiting for you.
Thanks for the catch. My web development skills are definitely sub-par. Fixed the landing page now, to some extent. Hopefully it's not rendering it unreadable.
https://carefulwords.com/curiosity
what's "gewgaw" doing under "curiosity" though?