> stock options did become nearly universal in tech compensation
Although I've noticed that options have been replaced more and more these days with RSU's (plain old grants) because options have a tendency to go "underwater", suggesting that they weren't all that great to begin with.
Right, options go underwater precisely when the company is not doing well and you are at greatest risk of losing the job. That's not a great risk profile.
I learned long ago (when my company decided they couldn't give me options because we were too big so they did these "I can't believe it isn't an option", which expired worthless): until cash is in my bank account it is just a promise waiting to be broken. If I want to invest I want it my choice.
In any case, it is a bad idea to invest in the company you work for - unless you are high enough up in the company that you see the real books, or you have so much invested they have to show you as a large shareholder. (nobody is the later - large shareholders have a full time job managing their money not working for someone else). There have been a number of cases where a company has unexpectedly filed bankruptcy and someone lost their job and their savings on the same day.
> In any case, it is a bad idea to invest in the company you work for
I'd question this conventional wisdom, simply because you have a lot more information about the company as an employee than a random investor does, even if you are not in possession of things like financials that the SEC considers "material non-public information". Things like culture, intelligence of your coworkers, whether or not you're actually delivering on your commitments, how many feature requests and bug reports you get from your customers, mood of management, perks offered, etc. are all intangibles, but they are usually better predictors of long-term company performance than the financials that the company gives investors.
If your company is not doing well enough or is not something that you would consider investing in, you should find a different company to work for. Bad things are going to happen in your future, regardless of whether you own shares or not.
I used to be on a project that, IMHO, had possibly considerable impact on capabilities and even some specific financials in a publicly traded corporation.
After about third earnings call (which happened a tiny bit before the trading window for our stock grants opened), I (re)learned the hard lesson that even if we delivered and I had actual, material, move the needle impact on corporate financials, that would not translate in any way to stock price. Except maybe if I pushed it really, really, down by causing an avalanche of problems that resulted in some big name deal going down.
The stock prices are vibe based, once its publicly traded your share value will be based on whatever vibes pushed numbers in excel around earnings call, and it's perfectly normal occurrence to beat expected earnings per share for 3 quarters straight and every quarter get a different vibed-off reason as to why the price should go down.
No you don’t. If you did, you would be subject to lock outs. The average rank and file employee at any BigTech company knows only a minuscule more than the general public.
Amazon for instance has over 1 million employees. You know nothing about most of your coworkers or whether other teams are delivering featured
> The average rank and file employee at any BigTech company knows only a minuscule more than the general public.
They know the clients, the contracts, hiring, cost cutting way before the general public does. The problem is that many BigTech is sum of many units which might not be correlated, but for say Nvidia or Apple I would assume the employees would be a good people to take the stock advice from.
And this is again an obviously naive assumption. Your average developer at Apple has no idea how many iPhones Apple sold in China. Nor do Nvidia employees they know how many GPUs NVidia sold. Your random Amazon developer didn’t know Jassy was going to announce at the earnings call that Amazon was going to announce that they were going to spend more this year on Capex for AI related hardware than they’d free cash flow tanking their stock.
Again, I worked at AWS and we had no insider knowledge
> Your average developer at Apple has no idea how many iPhones Apple sold in China.
But if anyone is connected to few friends across team, they would know they are hiring for China sales team(or dependent team like internal tooling for sales etc.) aggressively or firing them.
As large as any big tech company is and as a silo’d few employees have friends across teams. Besides that, at every tech company, all information like that is a need to know and isn’t shared with “friends” - especially information that can move markets.
I don't know if you ever worked on big tech? Everyone knows this through gossips, referrals, friends of friends etc. The hard part is to figure out how actionable this information is.
> information that can move markets.
That's the hardest part to figure out. Stocks aren't very correlated with anything. Slight changes in this quarter's iPhone sales in China doesn't move the share price very much if it is within range of expectation.
> but for say Nvidia or Apple I would assume the employees would be a good people to take the stock advice from
Isn't Apple pretty famously secretive even internally around stuff like product launches? I would expect a company that runs a tight ship to have rank-and-file employees who would have less potentially actionable info than ones at companies that don't control information as well.
In a tiny company this is true. In any medium (much less large) company you don't know much more than anyone else on the street - and the independent analysts who just watch public information closely usually know more than you do about all that. (it is their job to read the data from China and figure out what that means for the companies involved).
I worked for AWS in Professional Services (full time blue badge employee). Part of “sales”. Even when we talked internally asking for advice from the service teams (the people who worked on the various AWS services) or even internally within ProServe outside the project team, when we spoke on Slack, we didn’t mention the customers in Slack channels outside of a need to know basis and used the acronym “IHAC” (I have a customer) when referring to the customer.
I assure you the random developer on the EC2 service team for instance knew nothing about the sales deals.
Also a “$100 million dollar sales deal” is nothingburger for AWS not enough to move the market.
Do you think someone on the Alexa team in the retail division (“CDO”) knew anything about what was going on within AWS?
> Do you think someone on the Alexa team in the retail division (“CDO”) knew anything about what was going on within AWS?
Hmm, no?
As a solutions architect at Amazon I was very much a "rank and file" employee, and privy to large deals, so I'm not sure what you're on about. I haven't heard of Professional Services, presumably you guys had different responsibilities.
But either way, it’s monumentally a kind of weird statement to think that anyone besides “janitors” would know anything about the deals that would go through or to think a “$100 million sales deal” would move the needle especially as we see right now that AMZN is tanking because they reported they will spend more than all of their free cash flow on CAPEX for AI. You couldn’t have predicted that
SAs are not allowed to give the customer code or actually do anything. When a customer signs a contract (SOW) with ProServe, they are billable consultants who actually do implementations. Even they can’t touch production workloads and basically do everything in non production environments and teach the customer hope to do the work and move it into production
You have more information, but only in a small area. if there is fraud by the executives they will hide it from you. If a different division doing poorly bringing everyone down you won't know before anyone on the street. even in your own division you won't know all the important numbers, a great feature coming doesn't mean customes really want it, you might be sucked into thinking a useless vanity project is something customers care about.
Every time I got an RSU I could just sign into my RSU account and press a single button which sold them all, put a portion of the proceeds aside for taxes, and deposited the rest as cash directly into my bank account within 1-2 business days.
What makes them more or less controllable? I know they can have specific triggers applied to them so as to delay vesting. Are options somehow immune to that or is it something else entirely?
Note that I’m speaking more about private companies than public ones. But an RSU is basically only liquid if the company says it is. Shares, out of exercised options, have a lot more flexibility.
Right, but that seems to be comparing unvested RSUs to vested and exercised options. Are options more strict about what games can be played with vesting triggers?
Options have some minor value in signalling that you're a true believer. You should in fact care only about base salary, but not telling the people doing the hiring that can be quite useful. Doing a fake come-down on base in exchange for options shows you are invested and surely worth hiring.
The core problem is the quixotic quest for efficiency. Right now I'll blame JIRA because that's the latest incarnation of this beast, but it's the mindset behind thinking that's a good idea in the first place. As long as I've been working I've been under artificial, meaningless time constraints that seem to only exist to catch cheaters, but that actually serve to make experimentation impossible.
As somebody else pointed out, I read the entire article and still can't figure out what the author is actually talking about. That said, this sounds an awful lot like the reddit moderator problem: when you rely on unpaid volunteers, they become activist crusaders.
Apparently TDF wanted to host LibreOffice Online for free, when it had previously been a source-only project. Collabora didn't like that as they did 95% of the development and wanted to be able to sell support for their own version, but they didn't want to be competing against TDF's version at the same time.
I can understand Collabora not being jazzed about it, but is there anything in the license that would prevent a third party who is neither Collabora nor TDF from doing the same? I mean, it's one Dockerfile away from anyone doing it, right? May as well be TDF who distributes an official binary.
> "Batteries included" ecosystems are the only persistent solution
Or write your own stuff. Yes, that's right, I said it. Even HTTP. Even cryptography. Just because somebody else messed it up once doesn't mean nobody should ever do it. Professional quality software _should_ be customized. Professional developers absolutely can and should do this and get it right. When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right.
> When you use a third-party HTTP implementation (for example), you're invariably importing more functionality than you need anyway. If you're just querying a REST service, you don't need MIME encoding, but it's part of the HTTP library anyway because some clients do need it. That library (that imports all of its own libraries) is just unnecessary bloat, and this stuff really isn't that hard to get right.
This post is modded down (I think because of the "roll your own crypto vibe", which I disagree with), but this is actually spot on the money for HTTP.
The surface area for HTTP is quite large, and your little API, which never needed range-requests, basic-auth, multipart form upload, etc suddenly gets owned because of a vulnerability in one of those things you not only never used, you also never knew existed!
"Surface area" is a problem, reducing it is one way to mitigate.
> the "roll your own crypto vibe", which I disagree with
Again, you run into the attack surface area here. Think about the Heartbleed vulnerability. It was a vulnerability in the DTLS implementation of OpenSSL, but it affected every single user, including the 99% that weren't using DTLS.
Experienced developers can, and should, be able to elide things like side-channel attacks and the other gotchas that scare folks off of rolling their own crypto. The right solution here is better-defined, well understood acceptance criteria and test cases, not blindly trusting something you downloaded from the internet.
1. It's really really hard to verify that you have not left a vulnerability in (for a good time, try figuring out all the different "standards" needed in x509), but, more importantly,
2. You already have options for a reduced attack surface; You don't need to use OpenSSL just for TLS, you can use WolfSSL (I'm very happy with it, actually). You don't need WolfSSL just for public/private keys signing+encryption, use libsodium. You don't need libsodium just for bcrypt password hashing, there's already a single function to do that.
With crypto, you have some options to reduce your attack surface. With HTTP you have few to none; all the HTTP libs take great care to implement as much of the specification as possible.
That's actually not really crypto, though - that's writing a parser (for a container that includes a lot of crypto-related data). And again... if you import a 3rd-party x.509 parser and you only need DER but not BER, you've got unnecessary bloat yet again.
When I started programming in the early 80's, personal computing had just recently become a thing. Before that, if you wanted to learn to program, you first needed access to a very rare piece of hardware that only a select few were granted access to. But when personal computing became a reality, programming exploded - anybody could learn it with a modest investment.
I suspect we're trending back to the pre-personal computing era where access to 'raw' computing power will be hard to come by. It will become harder and harder to learn to program just because it'll be harder and harder to get your hands on the necessary equipment.
Although I've noticed that options have been replaced more and more these days with RSU's (plain old grants) because options have a tendency to go "underwater", suggesting that they weren't all that great to begin with.
reply