7 ms·

I've heard Fuchsia referred to as a "principal engineer retention project" at Google. I'd be curious to know if others have heard the same.

Kinrany 6y ago
I wonder if this could be turned into a better way to fund public research.
notatoad 6y ago
i've definitely heard that said before here on HN. are you hearing it referred to that way internally at google?
- deleted 6y ago
  [deleted]
abarth 6y ago
As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)
- jacobush 6y ago
  ... but also your colleagues?
- suchire 6y ago
  Not solely, but in part? ;-)
- swetland 6y ago
  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.
  - abarth 6y ago
    Thanks! Yes, your ideas are alive and well in the project.
- wmf 6y ago
  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?
  - abarth 6y ago
    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.
    - gowld 6y ago
      The Eng Council is 5 people in a position of governance, not everyone who contributes.
      - abarth 6y ago
        Ah, I didn't realize the comment above was about the Eng Council. I'll raise the issue at our next meeting. Thanks!
  - evil-olive 6y ago
    The OWNERS file is typically used, sometimes by automated tooling, to answer the "who should I ask to code review these changes?" question. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_reviews.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/c... https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners https://docs.github.com/en/free-pro-team@latest/github/creat... https://docs.gitlab.com/ee/user/project/code_owners.html https://docs.gitlab.com/ee/user/project/code_owners.html 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.
    - 6y ago
- raphlinus 6y ago
  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.
  - abarth 6y ago
    I look forward to it!
  - dewitt 6y ago
    Yay! Welcome back!
- baybal2 6y ago
  Adam, how much were you involved in drafting this manifest?
  - abarth 6y ago
    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.
- asadawadia 6y ago
  What was your journey to principal?
fh973 6y ago
This also how golang started, but doesn't mean it won't develop a life of its own.
epage 6y ago
For all on this thread involved, thank you! 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.
- bestorworse 6y ago
  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.
zbowling 6y ago
I think the quote was _senior_ engineer retention project" and that was many years ago :)
deleted 6y ago
[deleted]
PragmaticPulp 6y ago
> 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?
- ponker 6y ago
  So they are available when you have a project to ramp up quickly, and so they don’t work at a competitor.
- dbbk 6y ago
  I wouldn't say it's a useless project per se. But the usefulness of it is certainly yet to be determined.
- incrudible 6y ago
  The ROI is keeping your competition from the bottom starved for engineers.
- hobs 6y ago
  Punishing your competitors and maybe making money.
- com2kid 6y ago
  > 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.

Kinrany 6y ago

I wonder if this could be turned into a better way to fund public research.

notatoad 6y ago

i've definitely heard that said before here on HN. are you hearing it referred to that way internally at google?

deleted 6y ago
[deleted]

abarth 6y ago

As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)

jacobush 6y ago
... but also your colleagues?
suchire 6y ago
Not solely, but in part? ;-)
swetland 6y ago
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.
- abarth 6y ago
  Thanks! Yes, your ideas are alive and well in the project.
wmf 6y ago
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?
- abarth 6y ago
  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.
  - gowld 6y ago
    The Eng Council is 5 people in a position of governance, not everyone who contributes.
    - abarth 6y ago
      Ah, I didn't realize the comment above was about the Eng Council. I'll raise the issue at our next meeting. Thanks!
- evil-olive 6y ago
  The OWNERS file is typically used, sometimes by automated tooling, to answer the "who should I ask to code review these changes?" question. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_reviews.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/c... https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners https://docs.github.com/en/free-pro-team@latest/github/creat... https://docs.gitlab.com/ee/user/project/code_owners.html https://docs.gitlab.com/ee/user/project/code_owners.html 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.
  - 6y ago
raphlinus 6y ago
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.
- abarth 6y ago
  I look forward to it!
- dewitt 6y ago
  Yay! Welcome back!
baybal2 6y ago
Adam, how much were you involved in drafting this manifest?
- abarth 6y ago
  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.
asadawadia 6y ago
What was your journey to principal?

fh973 6y ago

This also how golang started, but doesn't mean it won't develop a life of its own.

epage 6y ago

For all on this thread involved, thank you! 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.

bestorworse 6y ago
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.

zbowling 6y ago

I think the quote was _senior_ engineer retention project" and that was many years ago :)

deleted 6y ago

[deleted]

PragmaticPulp 6y ago

> 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?

ponker 6y ago
So they are available when you have a project to ramp up quickly, and so they don’t work at a competitor.
dbbk 6y ago
I wouldn't say it's a useless project per se. But the usefulness of it is certainly yet to be determined.
incrudible 6y ago
The ROI is keeping your competition from the bottom starved for engineers.
hobs 6y ago
Punishing your competitors and maybe making money.
com2kid 6y ago
> 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.