As a boss-man myself, I’ve seen this “don’t let them take advantage of you” sentiment expressed in many discussions about comp and promotions, but I can’t really say I understand it. Am I just out of touch?
As I read it, the article is simply trying to help people understand what kind of work is valuable to a company and therefore what they should focus on to make themselves valuable. I presume that making yourself valuable pays dividends, including promotions! Somehow the idea of going to work and not trying your best because “you’re not getting paid … for that” just feels so cynical and divorced from how I’ve seen successful people grow and make big bucks in tech.
(And this is all a bit separate, of course, than the debate about whether staying at a company or job hopping is better for career trajectory.)
> I presume that making yourself valuable pays dividends, including promotions!
This has not been my experience at all. I've had multiple positions where I took on multiple challenges and responsibilities outside my role, reshaped the team and took the lead on getting things shipped, made sure my manager was more successful, and spent a lot of energy making all this happens... for nothing.
> and divorced from how I’ve seen successful people grow and make big bucks in tech.
Almost all of the people I've seen grow successfully never do any of this "take on extra responsibility" stuff. The vast majority were early hires that got along well with leadership in a fast growing company. Most of the promotions I've gotten felt almost arbitrary, and largely happened from being at the right place at the right time.
To be honest, I remain a hard worker who takes on extra responsibilities, simply because I enjoy it. I like solving problems and shipping things, it makes work fun. But I don't expect any recognition for it (even on annual reviews). The biggest reward for me is helping other people be successful and building cool things. Anyone working hard for a promotion or any recognition from the company is very likely wasting their time.
> that got along well with leadership in a fast growing company
I may be reading too much into your post but I'll say that this sentiment is a common pattern I see in many competent senior folks who think they deserve promotions into roles above senior. Getting along with leadership is a huge asset for for this type of leadership role. It means that you stay aligned and push in the same direction together.
If you're not going to get along well with your leadership you need to be much much better than everyone around you - which is a significantly higher bar to clear. And getting along well is a skill. It's usually not the skill people want to learn but it's hugely valuable to be able to be chummy with a difficult exec.
> Somehow the idea of going to work and not trying your best
You make a great point -- let me further explain so I'm not misunderstood.
If the person is putting in the same 40 hrs/wk (or whatever is standard) but just "doing their best", then there's no problem.
But in my experience, your manager is expecting you to do all of your assigned role (e.g. write code), but then also do a bunch of stuff on top -- e.g. leading and taking ownership of new initiatives that is extra work. Usually something like 10-20 hours' worth per week. And so now people are working evenings and weekends to get that promotion, spending less time with their family. And a lot of them still don't get the promotion. For years, or even ever. This is all free labor for the company. They get away paying for a team of 4 instead of a team of 5.
That's what I'm pushing back on. In practice, it's rarely doing your existing work but better -- it's doing a bunch of extra work that takes more time. Because nobody ever says "hey show that you can take on these new responsibilities, and so do less of your original responsibilities".
Contrast this to actually being promoted, where some of your previous responsibilities are now actually delegated to others, because your job is now focused more on higher-level design and/or management.
I don't think that's how it works. Otherwise, a level 3 engineer would be working 40 hours a week but 4 engineer would be working 60 hours a week, which isn't the case.
These additional things a senior does that a junior doesn't aren't "write more code", they're "coordinate with people outside your team more", "be more self-directed", "be more reliable", etc. Things which don't take more time, but which juniors don't do.
> But in my experience, your manager is expecting you to do all of your assigned role (e.g. write code), but then also do a bunch of stuff on top -- e.g. leading and taking ownership of new initiatives that is extra work.
Aside from AWS, who's famously bad at this, my experience is that this is usually because people want a faster career push.
Imagine Jim, 8 years into his career. Jim is pretty good and his work takes him 30-40 hours a week. If he worked another 5 years in the same role it'd probably drop to 20 and be chill.
Jim wants to get promoted. If he waited the 5 years he could do it working 40 hours a week. But he wants it now, and since he's not as good as he will be he needs to work 60. What does Jim do? He works the 60.
There's nothing wrong with this choice, I made it, I'm happy with my choice. I might make it again in the future, or not.
> There's nothing wrong with this choice [to work extra hours to get promoted].
But if there are limited slots for promotion, and that's generally always the case, the resulting competition among deserving engineers makes the extra hours more or less mandatory. Say that Amy is a better engineer than Jim and gets a third more done per hour. If Jim puts in 60 hours instead of the expected 40, then Amy isn't going to beat him for a slot unless she also starts working extra hours.
In the end, promotion becomes more about grinding than being effective. That's not great for company culture or retention of top talent.
That doesn't make the promotion more about grinding because the company doesn't care about how much work you get done in a set unit of time compared to other employees in the same set unit of time. The company cares about how much you get done, period.
If the only differentiating factor between Amy and Jim is quantity of work done (this is never the case in real life), most companies will prefer a Jim that works 60 hours to an Amy that works 40 if Jim is producing 5% more.
In software development, sure (maybe). Most jobs aren't software development.
The vast majority of jobs your production slows as hours increase but there isn't a tipping point where you're less productive, even after accounting for errors or rework. There's a reason CPAs don't clock out at 37.5 hours during tax season, or warehouses or service desks or any number of things other than the specific thing most of us do often work more than 40 hours a week, especially when actively working to get a promotion.
The problem is that we're simultaneously talking about healthy and rotten companies. In a healthy company your manager tells you "if you want a promotion, this and this needs to happen" and then you get a promotion and a pay raise. Meanwhile in my company:
- I was given a project "please convince half of the company to drop everything and do work for our team"
- I told my manager "I don't know what you're expecting from me" and he said "I don't care"
- A coworker completed his project, but then was told that the promotion requirements changed
- A coworker was promoted, said that it was a big mistake because pay rose 10% but responsibilities 200%
The thing is, online discourse has little reason to discuss healthy companies. Sharing tips and tricks how to survive in a dysfunctional organization is much more interesting.
> Somehow the idea of going to work and not trying your best because “you’re not getting paid … for that” just feels so cynical and divorced from how I’ve seen successful people grow and make big bucks in tech
The question is always how long you are "working" at the higher level.
I have worked at jobs where I was working 2 levels higher then I was for close to 3 years before my new manager came in and fixed that shit (got two promotions in 2 years).
As an individual contributor you are diluting your IC's value of the same people level if you are working at a higher level for free, the expectations is then that everyone else at your level does it and then it becomes the new normal, it's the "A rising tide lifts all boats" but in a negative connotation.
In my experience, the issue is that performing at the next level is not a guarantee for promotion. So when you do work at the next level, they can just say “it’s not sustained enough” or whatever reason and then you’re stuck — can’t really produce less so you end up looking for a way out because all that work was kind of for nothing.
I look for opportunities outside my job requirements to learn and grow but it gets really tiring and exhausting when you’re not rewarded for it. Basically there is a lot of upside for the employer but for the employee it’s a bit of a crapshoot
> Somehow the idea of going to work and not trying your best because “you’re not getting paid … for that” just feels so cynical and divorced from how I’ve seen successful people grow and make big bucks in tech.
Why don't you take a pay cut then? I mean, money is not everything, right? You can always pay your mortgage in integrity, work ethic or another buzzword.
Though last year I went to Hawaii and they refused my "great job, man" tokens, greedy assholes!
You are not out of touch. You may simply have spent time at great companies.
The OP’s advice is solid, but it assumes your manager will actively help promote you or work toward that outcome. In some companies, or with some managers, that support does not exist. There may be no incentive for them to do so. This does not necessarily come from ill intent, but rather from different organizational expectations.
Different companies can have vastly different work cultures, even if they're in the same location. So in a sense we're all a bit "out of touch" with each other.
Most days I go to work, I try my best, because if it turns out I don't get paid what I'm worth, I will F off somewhere else and take all this experience with me. And every time I've done that, I've had a significant pay rise.
RTM was my TA at MIT for a CS/systems engineering course. It took the students until we did an assignment about the worm to realize who he was IIRC. The students thought it was very cool, but even then, as a TA covering the assignment, he didn't really talk about it.
He was also a TA at Harvard with Trevor Blackwell for CS 148 (computer networking, taught by H T Kung) at the time. I remember taking that with them in 1995.
Neat visualization. There is a street performer in my town that has them all memorized (and many international zip codes as well) and makes a fun show of it, asking people what zip code they are from and putting them on a map. Sometimes it takes him a second to recall the exact town name but he always knows instantly what city they are close to, helped no doubt by the locality of the mapping. Example video:
Sure, let's take a rug as an example. I don't think there is one breakpoint. I think there are a set of axis of quality you invest into, roughly sequentially, as you go up the price scale of objects:
- $50 - Something rug-shaped exists
- $100 - Durability
- $200 - Materials
- $500 - Comfort and design
- $1000 - Basic craftsmanship
- $2000 - Refinement of craft
- $5000 - Artistry & identity
- $10000 - Tradition
- $20000 - Mastery
- $50000 - Rarity/historical importance
- $100000+ - ?
Because most people don't cross-shop $20k rugs and $200 rugs, most people are focused on one or two aspects around their personal budget. The essayist mentioned being amazing by the craftsmanship and artistry (see scale above). A broke college student might just want something that holds up in their dorm room and see what materials it's made out of and comfort as meaningless and abstract. And a billionaire shopping for a rug for their office might take everything other than rarity/historical importance as a given and just be thinking about that.
I think there is a large cognitive bias to consider everything you can easily afford "tangible and important improvements" and everything you can't as "abstract"!
The documentation is woefully out of date, sadly. Despite the code being in active development no one is touching the public docs. Though I don’t know for sure, that limitation was probably written something like 10 years ago.
Ha, well I met Scherer ~30 years ago in a high school math class and we’ve done three companies together, so you could say we’ve known each other for a bit :)
Lol - to find your one comment in this thread wayyy down at the bottom was delightful. That demo you reference from techcrunch disrupt ( start of this video - https://youtu.be/Nrb3LN7X1Pg) - that is a great demo. I'm curious - is that an idea/moment in your life you look back on and has that staying power, something that randomly pops in your mind that fills you with pride, or not really?
We thought of that demo with like a week or two to go before the event when we realized we needed something more visceral than a blinking cursor :)
So, it stayed with the world because it went semi viral in some tiny circles. But it didn’t stay with me because I personally learned little from it.
The thing that stays with me is all the things I learned spending years trying to implement an API you can describe in ~30 seconds really well. It’s a rare opportunity to be able to go so deep on a problem in a career.
Thanks for the insight. A $XX million exa-data system is no doubt impressive :)
> Another big problem I found with modeling real apps was the five second transaction timeout. This is not, as you might expect, a configurable value. It's hard-coded into the servers and clients. This turns into a hugely awkward limitation and routinely wrecks your application logic and forces you to implement very tricky concurrency algorithms inside your app, just to do basic tasks. For example, computing most reports over a large dataset does not work with FoundationDB because you can't get a consistent snapshot for more than five seconds!
I'm pretty sure that the 5-second transaction timeout is configurable with a knob. You just need enough RAM to hold the key-range information for the transaction timeout period. Basically: throughput * transaction_time_limit <= RAM, since FDB enforces that isolation reconciliation runs in memory.
But, the other reason that 5 seconds is the default is that e.g. 1 hour read/write transactions don't really make sense in the optimistic concurrency world. This is the downside of optimistic concurrency. The upside is that your system never gets blocked by bad-behaved long-running transactions, which is a serious issue in real production systems.
Finally, I think that the current "Redwood" storage engine does allow long-lived read transactions, even though the original engine backing FDB didn't.
If it's configurable that's very new. It definitely has been hard coded and unconfigurable by design the entire history of the project that I've known it. They just tell you to work around it, not tweak it for your app.
Transactions holding locks for too long are indeed a problem though in Oracle transactions can have priorities and steal each other's locks.
It looks like it might be knobs (which can be changed via config file) called MAX_WRITE_TRANSACTION_LIFE_VERSIONS and MAX_READ_TRANSACTION_LIFE_VERSIONS now (defined in ServerKnobs.cpp)? It's in microseconds and probably needs to be synced client and server.
I don't know the details know, but it was definitely configurable when I wrote it :) I remember arguing for setting it to a default of 30/60 seconds we decided against as that would have impacted throughput at our default RAM budget. I thought might have been a good tradeoff to get people going, thinking they could tune it down (or up the RAM) if they needed to scale up perf later.
Hah, well I'll defer to your knowledge then :) I don't remember seeing any kind of negotiation protocol between client and server to find out what the timeout is, which would be needed for it to be properly configurable. But it could be easily added I guess. I admit I never understood why changing it wasn't a proper feature.
FoundationDB's original promise was to combine a distributed storage engine with stateless layers on top to expose a variety of useful data structures (including SQL). The company was acquired before it could release the layers part of that equation. Apple open-sourced the core storage engine a few years later so FDB has kind of had a second life since then.
In that second life, the vast majority of the powerful databases around the industry built on FoundationDB have been built by companies making their own custom layers that are not public. This release is cool because it's a rare case that a company that has built a non-trivial layer on top of FDB is letting that source code be seen.
The group to which the FoundationDB storage engine itself appeals is fairly narrow--you have to want to go deep enough to build your own database/datastore, but not so deep to want to start from scratch. But, for this group, there is still nothing like FoundationDB in the industry--a distributed ACID KV store of extreme performance and robustness. So, yes, it's still the hotness in that sense. (As others have mentioned, see e.g. Deepseek's recent reveal of their 3FS distributed filesystem which relies on FDB.)
There have been some 3rd party toy projects in the past years, but pretty sure nothing was ever released by FoundationDB/Apple relating to SQL (until this additional SQL interface on the Apple "record layer").
I was curious to see how audible square wave duty cycle would be (I figured not much) but sadly the audio examples are clearly broken on this page--choosing the same one multiple times gives totally different sounds.
Changing the duty cycle of a square wave is called Pulse Width Modulation and is an extremely audible and iconic sound. If you have ever heared music any on the Commodore 64, you will familiar with its sound. PWM is also available in many professional synthesizers of the same era.
Yes! My dad has an old Commodore 64 and I vaguely remember a skiing game. I think it's so cool what folks were able to accomplish musically on such limited systems at the time
As I read it, the article is simply trying to help people understand what kind of work is valuable to a company and therefore what they should focus on to make themselves valuable. I presume that making yourself valuable pays dividends, including promotions! Somehow the idea of going to work and not trying your best because “you’re not getting paid … for that” just feels so cynical and divorced from how I’ve seen successful people grow and make big bucks in tech.
(And this is all a bit separate, of course, than the debate about whether staying at a company or job hopping is better for career trajectory.)