Comment by saagarjha
4 years ago
> While it is still a stretch, the title should be "Google's promo committee is killing Kubernetes", since no other FAANG-equivalent is using or contributing to Kubernetes in a meaningful way.
Apple puts Kubernetes on https://opensource.apple.com as a project they "lead and contribute to"…
> Very little work that a single engineer does can be assigned a provable revenue number. How does someone working on an internal build tool get promoted?
While I generally agree, I've made changes in our internal build tools that I can easily put a number on, although it's not a revenue number. Make build process 10s faster, 1000 engineers run this 10x a day, you're saving more than an engineer day per day of time. That's a definite impact right there, assuming your management is on board with accepting it :)
Apple is #32 in contributor commits[1]. Between SAP and Glassdoor, with ~7000 commits. You need to start adding zeroes and then some to get to Google's number of commits.
We shouldn't just measure in commits. I'd be interested to hear the case made. Where has Apple lead in Kubernetes? What have been their major initiatives? That'd be interesting to hear.
[1] https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1
There is currently an Apple employee on the k8s steering committee, so they could mean that.
Or, since the sentence is applying to a list of projects rather than to k8s specfically, it could be just a misparse and they're not claiming to lead each of the listed projects.
If you don't want the pointy-haired bosses to start measuring productivity by number of commits, start with not doing so yourself.
Commit count is largely meaningless and a low-effort way to fling around "contribution" numbers. For example, large commit numbers could be a reflection of a specific company's internal conventions around making a larger number of small changes as their own commit.
Now it's certainly plausible to me that Google is a much more major contributor to Kubernetes than Apple, but you need better numbers for showing that. For example, which companies have contributed to designing and implementing the major features in the last 5 releases?
Yeah, I'm thinking of some colleagues that can't remember any syntax that do 20 commits on the same line of code and don't clean it up.
I really have no idea, I just find it amusing that they put it front and center on their open source website.
To be fair if you look at the last year of contributions they’re #12 which is better.
> Make build process 10s faster, 1000 engineers run this 10x a day, you're saving more than an engineer day per day of time. That's a definite impact right there
Agreed, and you can measure and include similar statements regarding your Kubernetes contributions. However, if what you have to show for it is making the life of a hundred random startups easier, well why exactly should a Google promo committee care? Unless it is the specific goal of your business unit to make this impact, then the work is meaningful again.
> However, if what you have to show for it is making the life of a hundred random startups easier, well why exactly should a Google promo committee care?
He is actually talking about this in his tweets: "fixing a bug in kube-apiserver might retain a GCP customer", now he can put revenue associated with that customer into his perf packet?
The problem is that's a very strenuous argument to make (unless he could find an email that said that a customer was going to leave unless they fixed the bug) vs another engineer who found a new way of compressing emails and save the company X exabytes of storage space.
Keeping the ship running seems to be continuously undervalued at these companies compared to how they value building a new wing.
3 replies →
There are a whole lot of companies who can look at MTTR in terms of dollars, especially eCommerce. Rollback failures and CPU throttling can translate very directly to dollars when each request is a potential transaction.
Make build process 10s faster, 1000 engineers run this 10x a day
Depends where you are starting from. Taking the build from 100 to 90 seconds probably won't make a difference since people will be used to doing something else while waiting for the build to finish in the background. taking it from 10.1 to 0.1 seconds will make a huge difference since you can change your entire development process when builds are 'instant' and you can get constant feedback on any changes you make. Of course the second one is a hell of a lot harder.
or from 12 hours to 30 minutes. changes everything.
> Make build process 10s faster, 1000 engineers run this 10x a day, you're saving more than an engineer day per day of time.
I upgraded my home internet to one 2x as fast as the old service, so that I would spend only half as much time online, but it didn't work. Speed up the build process and the build will just get more complicated and the test suite slower, until it once again slows to the point of being barely tolerable. ISTM that part of Go's early popularity was from its fast builds.