Congrats on the promo! It didn't quite retain me either, but I was a lowly staff software engineer. I am returning to Google though (back to the Google Fonts team), and it's entirely possible we'll get a chance to work together again.
Congrats on the promo! It didn't retain me (though I didn't get promoted to Principal, so maybe I don't count) but I did enjoy working on Fuchsia. Nice to see much of the syscall design seems to have survived.
I'm sorry, but I'm not sure what you mean by "this manifest." The blog post linked above was written by Wayne Piekarski, who is a Developer Advocate for Fuchsia. My role in the project is as a software engineer.
Since you're here, "abarth", it took me several clicks to get to the OWNERS file and all I saw was a list of email addresses. Calling that "governance" is... could we at least get some names and maybe brief bios on these people?
It's not meant to be a place for developer bios. If for no other reason than one developer could appear in many OWNERS files scattered throughout a repo, or in multiple repos, and keeping the bio current across all of them would be a nightmare.
Let me add some context. I was looking at the governance links on the site and found https://fuchsia.dev/fuchsia-src/contribute/governance/eng_co... which at the bottom simply says "The current members of the Fuchsia Eng Council are listed in this OWNERS file." I think it would improve the transparency/accountability of the project to have more than a list of email addresses here.
I understand where you're coming from, but that ends up being an inclusion issue in the project. I'm comfortable having my name and bio "out there" on the Internet, but I recognize that's a privilege. Not everyone who contributes to the project will be comfortable doing that.
> I've heard Fuchsia referred to as a "principal engineer retention project" at Google.
No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
> No rational company is going to create useless projects just to retain expensive engineers. What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
(Short) story time!
Windows on ARM was a solo pet project of a high level engineer at Microsoft!
There are some engineers who are so valuable that letting them spend non-trivial amounts of time on whatever they want is a very good use of company resources.
Sometimes just not letting the competition have them is valuable!
I've worked with a few 10x-20x engineers, if someone is that productive, they can spend 2 years off on another non-ROI project, come back, and spend 2 years on a project with ROI, and the company still comes out ahead.
Most company's aren't smart enough to figure this out, then again determining who these people are is also a problem. That latter part is funny (ironic?), because on the ground floor everyone who encounters a world class engineer is pretty darn sure of it.
I don't think it's fair to call Windows on ARM an "engineer retention project". They actually released Windows RT and tried very hard to make it work. They still have it going with the Surface Pro X, and they just announced an emulation layer to get x64 applications working on ARM, which if it works well would solve RT's biggest problem, a lack of legacy applications: https://www.neowin.net/news/it039s-official-x64-emulation-is...
That is correct. It was a one man show for a long time (I don't think it was his only job, just a side project), then when tablets happened a full team was ramped up behind it.
> What's the point in retaining engineers if you're just going to pay them to work on something without expected ROI?
I'm not claiming that Google or other companies often do this, but just to play Devil's advocate, here are reasons why they might:
* Prevents them from going to the competition.
* Uses their prestige to attract or retain other developers.
* Keeps them "on retainer" in case a hard problem that needs their rare skills appears in the future.
When I worked at EA, we had a star engineer that spent, like, 75% of his time totally dicking around on whatever he felt like. But when say, it was a month away from FIFA's ship date and they couldn't get the game to run faster than 5 FPS, they would call him in. He would work some magic, the game would ship on time and with adequate perf, and he'd return to goofing off. Well worth EA's money to keep him on salary.
The rationale behind decisions in a BigCorp with very large Other Revenue Sources is entirely different from that of a small company that could be crushed by market forces on a moments notice.
As others have pointed out, the ROI can be something entirely different than $$ in the accounting ledger.
9 years into my BigCorp career and I still find it flabbergasting.
Since I was got into programming in middle school, I was obsessed with OS design (yeah, reading the source code for L4 in high school). As I went further in my education, I felt the landscape was pretty stagnate at this point and went into other areas (initially driver development and now developer tooling).
While I've not had a chance to jump over to Fuschia to participate, it warms my heart to see the development going on.
When looking more closely on Fuchsia architecture you might well be back into OS design obsession. As the kernel is, IMHO strongly based on a microkernel design, the OS APIs presents itself as userspace APIs. They are in fact, defined by what the userspace implements. And there is a lot of freedom on how to implement this API.
The majority of microkernel based OSes just implement these APIs to emulate UNIX APIs and that IMHO is a waste of potential but understandable in order to be backward compatible and not have to develop whole new userspace applications from scratch.
But I really like Fuchsia's take on the design of this userspace and the way the 'capability security model' is integrated into it. The amount of APIs built into the base 'Fuchsia platform' really blurs the line between and OS and a stack with OS plus essential services. Today, IMHO, things like automatic updates, software distribution, crash reports, and other low level application centric facilities should really be provided by the OS and that is done in the base Fuchsia platform.
