My raises never matched inflation but then my compensation is like 700k a year. I don't know whether my raise needs to match the cost of living increase.
When I last worked at a FAANG I was very clear on exactly what they had to pay me to put up with their bullshit (I happen to be independently wealthy). This kind of “nominal raise” below inflation actually meant my salary went down, so I quit.
How did you know you're independently wealthy enough to do this? I'm at a stage where I'm sort of there and getting more and more annoyed by large organizational BS, but I keep thinking "one more year is that much more of a buffer."
Funny enough, it happened because of the 2022 layoffs. I figured I'd be fine (and was), but it made me go though the math and realized I was close to escape velocity. On one hand, it made getting excited about uninteresting work that much harder, but because I wasn't quite there with enough buffer, the bad job market still gave me anxiety.
I’ve never known anyone to escape that situation. The “one more year” attitude is pervasive.
In my case it was easy because I didn’t join the company until after I was already independently wealthy, from an IPO (quitting that company was an easy decision too, due to all the magical changes that happen after IPO).
Most of these will usually make a program crash. Crashes are testable and not a memory safety issue. Exception handling was created specifically to deal with this.
The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.
The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible.
Which is a pity, because the language itself does not seem to be so bad.
> Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.
I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response.
> The Rust literature is poorly written compared to C and Ada
I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing?
I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library:
Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far.
So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:
Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.
> So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:
Why do we need links to the source code? Doxygen is already embedded in the source, you should already be reading the source code on your local machine. It makes no sense to go searching across the web for information that's already stored on your local machine. Especially since you have no idea if the version you find on the web matches the version you're using locally.
Hah! Do you have a running search giving you alerts when lmdb is mentioned or something?
> How is doxygen a disaster?
I've just never read any good, user friendly documentation ever produced by doxygen. Even when I used it myself. It always comes out looking like a pig's breakfast.
Like, take the lmdb docs. And I'm sorry for picking on it. But its a good example, because you've clearly put effort into using doxygen to document lmdb. I think the lmdb docs are about the best that doxygen generated documentation gets.
But none of those concepts are defined or explained. They're simply referenced without explanation in a big jumble of function names and descriptions, leaving me to figure out how they're supposed to work together. Maybe if those data types were defined up the top of the page? No. Doxygen tries to put some data structures at the top of the page - but for some reason the only documented types are MDB_val, MDB_stat and MDB_envinfo. All terrible places to start reading if you want to understand how to use lmdb.
Good documentation would lead with some front matter like:
- What does the library do
- How does the library sees the world. Here, explain the above concepts and how they relate. (Eg an environment represents a set of files on disk. Each environment contains a numbered set of databases, database contains a set of records. You can read and write within a txn. You can use a cursor to iterate. ... Etc)
- Code examples of all of the above. Ideally a hello world, and more complex / specific examples showing each feature.
Doxygen does not help with any of that. From this documentation I don't know how to use lmdb to make a correct program. I can kinda guess how to use various features, but not what the features actually are or how to use them correctly.
For example, I can obliquely tell from reading the function descriptions that an environment can be opened multiple times at the same time. But I have no idea why I'd want to do that, or how, or what performance implications there are, or if there are any gotchas I need to be aware of if I do that. I see there's a bunch of functions for mdb_env_copy. Does that copy in memory or on disk? Does it do it atomically, like at a snapshot? Is it synchronous? Does it fsync? fdatasync? What errors can happen? The documentation isn't helpful.
So I'm not just banging on about rust, here's equivalent - but much better - reference documentation for prisma:
They explain the concepts and present examples for how to use all the features. When I read those docs, I come away knowing how to use the library to solve my problems. I don't have that experience reading the lmdb documentation.
Maybe its possible to produce good documentation using doxygen. But I've never seen it done. Not even once.
-----
Side points:
> you should already be reading the source code on your local machine.
I'd rather not read the source code of all my dependencies to understand how to use them. Reading the source code of your dependencies should be a last resort. Eg, I don't go reading my compiler's source code if I want to understand my programming language. I don't want to read the source code of my web browser, or postgres, or linux, or any of this stuff.
> It makes no sense to go searching across the web for information that's already stored on your local machine. Especially since you have no idea if the version you find on the web matches the version you're using locally.
I hear you, but honestly I don't really care where documentation lives. Just so long as I can find it and read it. But with rust in particular, if you want local documentation you can run cargo doc to generate & open the documentation of your project and all your dependencies, which is nice.
And re: versions, rust docs hosted online also have a little 'version' field up the top showing which version of the library you're looking at the documentation of. Eg if you open https://docs.rs/rand/ I see "rand-0.9.2". If you change versions, the URL changes. It'd be nice if doxygen had that too.
No luck needed. It was a series of intentional choices anyone could make if they wished.
I co-run two tech companies in silicon valley, maintain several online communities, organize events, have an active social life, travel a lot, have many tech hobbies, go to shows and events, etc.
I am hardly the amish person people tend to imagine.
FOSS software can work for virtually anyone in the modern world that wants freedom.
It takes a lot of luck to be able to live in the Bay Area in the first place, and a lot of luck to be able to "co-run two tech companies in Silicon Valley".
If you think this is something anyone can Just Do if they decide to do it, you have fallen pretty hard for a certain kind of capitalist propaganda.
“Even if you are paying, you are the premium product.”
I think we need to stop saying that quote since the existence of subscription. Can you stop Google from tracking you or let you define your “algorithm” if you have purchased YouTube Premium and one of the Google Drive plans? I really doubt.
I think it is the value of the company matters. If their intentions is to keep investors happy, the users are always the product no matter paying or not. By contrast, there are quite a lot of free open source software doing the same for free, but the users still remain user.
There is a premium plan for the AI features, so that's the strategy, which does make some sense, I bet a lot of people will want to have those features.
Good software is never freemium. It is either paid upfront or it is a timebomb. I am okay with keeping things proprietary and asking for a fair price. Once free-to-play is introduced, the software is gone for good.
I thought about buying Affinity a couple of months ago since they offered a perpetual license. Now I won't even think installing it
If a professional can't give critical feedback in a professional setting without being rude or belittling others, then they need to improve their communication skills.
This is not that though. This is just developers being unable to handle constructive criticism, and when they can't win the argument on merits, went for the HR option. It happens.
I've had it happen to me too, but my response was to resign on the spot (I was already not satisfied with the company).
The "toxic behaviour" I had done? I reverted a commit on the master branch that didn't compile, and sent a slack to the Dev who had committed it saying "hi! There appears to have been a mistake in your latest commit, could you please check it out and fix it? I've reverted it in the meantime since I need to deploy this other feature"
The dev responded by force pushing the code that did not compile to master and contacted HR.
I decided there was greener grass on other pastures. I was right.
When I started breaking the build would end up with the person who did it having to wear the dunce hat for the day. This was before git so there are now fewer excuses for breaking the build today.
Yes, of course. The point of my heavy-handed post was to try to find out what is actually going on here. Does this person have any insider info? Or are they (as many are in the discussion, and as I suspect is the case here too - but I am going only on the balance of probabilities!) just using this as an opportunity to relate this to their own grievances, so they can discuss those?
We've only got one side of this particular story, we don't know what happened from the other person's point of view, we don't know what form this HR complaint took - or any of the other details. We can bet, just as I did in my last paragraph, but in my view the odds are more questionable and the topic more likely end up as unproductive venting. Any good comments will get lost.
Still, it's also true that the link is just there as a starting point for discussion, and the discussion can take any forms that the readership would find interesting.
It’s also super rude to make claims as to what occurred and why in any situation you yourself were not privy to or involved in but I don’t see you rushing in with the same vigour to point that out.
Yes. Seems pretty clear from the post to me that they are making assumptions based on a similar event in their past, not that they were involved first hand in this event.
Having worked in the valley, I've seen what critical feedback meant in many companies there, and it removes all usefulness of the info because there is a ceiling of what is socially acceptable to say; therefore, you can't know how bad or urgent things are.
Everything is ASAP. They are super excited about everything. And nothing you do is wrong, it just could be improved or they like it but don't love it.
You don't know if something is important, basically.
Just like Louis CK said, "if you used 'amazing' on chicken nuggets, what are you going to say when your first child is born?". But in reverse.
Personally, I'd rather work with someone who would tell me my work is terrible if it is.
In Germany, you can't even legally say somebody did a bad job at your company in a recommendation letter. Companies created a whole subtext to workaround that, it's crazy.
Some things are just bad. You should be able to say it is. Not by saying it could be better. Not by using euphemism. It's just something that needs to go to the trash.
In fact, I don't trust people who can't receive this information, even if not packaged with tact (which you should attempt to, but life happens). If you can't handle people not being perfectly polite every time, I can't help but feel I won't be able to count on you when things get hard.
I am with you on this. Worked in our Dublin office was so refreshing to have straight up communication vs whatever the song and dance we do here in US.
> In Germany, you can't even legally say somebody did a bad job at your company in a recommendation letter. Companies created a whole subtext to workaround that, it's crazy.
I don't think it's just about legality. Whether the recommendation letter is included in the application is at the distinction of the applicant. When you want it to reach the next company, you must write is so, that the former employee considers it to be a good recommendation.
First of all, in southern countries we hardly do recommendation letters, if we do they usually ended up being written by ourselves and if the company agrees with the content, it gets signed.
Exactly because of this, you are supposed to give referrals that then talk whatever they feel like about the experience working with you was all about.
Having a whole legal process for recommendation letters, that have created a whole industry of hidden language that looks good on the surface but tells exactly otherwise, was a surprise to me.
Being "reported to HR" doesn't mean "almost got fired". It likely meant a meeting where someone explained "hey, the way you communicated that caused some upset, let's discuss better ways to handle that situation next time." Very often in larger companies, complaints about things like "this bigwig from this other group jumped all over us" are automatically sent through HR because HR has staff whose job just is resolving conflicts between people and keeping things peaceful.
FWIW, it can also mean a meeting where HR says to the complainer: "Are you good, dude? Why are you complaining about this? This is perfectly normal workplace behavior. Stop wasting our time."
From what you know of Carmack, does "can't give critical feedback in a professional setting without being rude or belittling others" sound like him to you? It does not to me, though granted maybe he's different in his non public persona than what you can see in presentations and talks.
I assume it must be 2015 at most because my first job in 2008 ran everything, including images, on HTTPS. But I can imagine some last holdpouts 7 years after that.
- Enable Color Management and HDR display on non-MacOS platforms
- Play HDR video
- Support common and rising media codecs and container formats (HEVC, MKV, JXL)
- Support WebXR properly on desktop
reply