Amazon is a shit company with a shit culture and a shitty founder. This company is like a virus. Wherever it goes, it kills off the local business population. Never work for such a company.
I’ve worked at Amazon. I made it a few years, but was almost pipped in the first few months. Management dropped a huge project on me, a brand new tier 1 service, with full dns resolution, api, database, distributed system, along with micro services. The deadline was three months. Brand new tech stack. When I was struggling to meet the deadline, we started having “performance conversations”.
I ended up switching teams and had a decent time at the company, but the nightmare situations are very real. You are replaceable and there’s no mercy
Maybe a silly question on my part; did you manage to learn a lot?
In the past, I thought of putting myself in positions like these to increase my understanding in short time, at the short term expense of personal life. I wonder if that's just a stupid thought that leads to nothing but burnout, or actually a viable short-term strategy to get up to speed with some of the tech stack you know but haven't really used in prod at the scale of Amazon.
Nowadays, I have health issues (go figure) so it's off the table and all I can do is wonder :).
My go-to aphorism in for questions like these is "you learn more from success than from failure".
People like to talk about how great a teacher failure is, and how it teaches you valuable lessons... and it's true! Failure does teach you lots of valuable things, including things that you don't learn by succeeding. However, succeeding at something challenging generally teaches you more.
Or to cast it in ML terms... you need examples of both success and failure in your data set, but the "success" data points are more valuable.
Isn't that simply because you experience failure many more times than you experience success. In fact on your path to success you are almost guaranteed to experience multiple failures. So by that metrics one success teaches you the lessons of many failures.
I’ll be honest, I learned an absurd amount. Like more in those six months than in four years if previous work. It was real software development, with actual distributed systems problems. But was also scarring, I have huge trust issues with management now
> I would have a lot of trust issues with management if they pulled this shit on me.
You should have trust issues with "management" in any corporation because these people have the interest of the shareholders at heart, not of the workers. It's just sad some of us have to go through a traumatic burnout to learn this lesson.
Of course, what i said doesn't apply in a self-organized workers cooperatives where management is the workers.
Yes, exactly my point. I was not commenting that it is normal to have a rather traumatic experience but that it ought to be normal (and frankly, healthy) to have "trust issues with management".
The details can be debated, but to ordinary worker instances both shareholders and management inherit from RichAsshole class who both have the same implementation for the Empathy interface:
I'm convinced human beings are naturally designed to operate at 120% for 6-12 week long periods. \
Hunter gatherer survivalist genes just kick in.
YMMV, but I consider it a healthy thing for, at least for some part of your career, to work "Amazon hard." Aka, all the reasons that people list when they say you should really try working for a startup.
When you push yourself to your limits at your profession, a lot of stuff clicks into place and you learn so much.
You can't procrastinate, you can't do it wrong, there just isn't the time.
> When you push yourself to your limits at your profession, a lot of stuff clicks into place and you learn so much.
Maybe a cynical take, but if you’re pushing limits then you’re probably just learning the right corners to cut, shortcuts to take, and how to exploit/manipulate people to get what you want fast. If you didn’t learn any of that, then—well, someone else just learned all that at your expense and you’re setting yourself up to just be exploited again and again.
> there just isn't the time
Yeah, that’s the root cause. Why is there no time? Is someone’s life on the line for this deadline or is it just that the manager is eyeing a sweet bonus for delivering early. 99.9% of the time it’s the latter. So why learn how to get manipulated? Learning to work at a consistent pace is far more sustainable. Tortoise and the hare.
Human beings are not designed to operate at 120% for 6-12 week long periods; they're designed to survive it. The difference is important.
Working at such a rhythm helped me learn much. It also durably damaged my body (both because it chipped away at my health and because it made me forego health check-up), my mental health, and made me lose personal connections. To this day, I'm still picking up the pieces.
Human beings are also "designed" to survive long period of hunger if need be, but no one would argue that going without for a week is a fine and healthy way to lose weight.
I guess I should say the healthy thing to do is to work at 100% of your capacity, whilst going to bed at 9pm and doing 25 minutes of exercise every morning?
> I'm convinced human beings are naturally designed to operate at 120% for 6-12 week long periods. \
The only thing worth working 120% for is raising your newborn child. Or maybe making a civilization-altering breakthrough in the natural sciences, like Fusion energy.
Everything is simply 'meh' in comparison and not worth sacrificing your health for. And I say this as a person who doesn't even particularly like or want kids.
In my experience you can learn from such stress situations, but the goal of a company is usually not to form a bootcamp for new employees, but to have it's devs create great, lasting, secure and stable software.
And like any great, secure, lasting and stable engineering giving you the knowledge and time is key here.
When a company overloads the safety officer with tasks, so they and up not being able to do their work propperly and an incident happens, the company is at fault because it failed to provide the officer with the resources needed for the job.
If they don't give a dev the resources to do their job it is not different in my eyes. The fact that there might be some magical dev who would be able to get something working out of the same circumstances doesn't matter — maybe it has a company crippling flaw in it because of all the haste.
Amazon's mentality is pretty clever I think. The entire company is designed to repeatedly test all its employees till failure by piling on the workload until they say uncle, then backing off 20% if they push-back.
It's a crazy approach that probably falls apart if you're unsuccessful. But they're very successful so they can just keep burning money to attract new hires. Also, I imagine it's a huge career builder if you work in FMCG or development to have "Amazon retail" or "Amazon Web Services" on your resume. Since everyone uses those platforms.
I imagine what is left at the end is a residue of "born again" workaholics, who're probably pretty great at their jobs. Who then ascend to and form middle management.
And the global express trundles on, powered by these workaholics.
You may/may not learn, but living in situations like the OP was put in is horrible. Every day feels like hell, and if you burn out it may take years to recover.
This is my personal experience, which is why I'd advise people not to go through with the above thought experiment.
Then again, I keep interviewing people with 5-10 years of experience, who will go something like this:
> How would you manage a server? (leaving out a ton of context about what it means to "manage a server")
> Very easy, SSH connection is very fast, reliable, ...
> Awesome, love me some SSH, how about 5 servers?
> Hmm, probably write shell scripts.
> How about 50 servers?
> Shell scripts?
> Even with 500 servers?
> Hire more people..?
And I keep feeling that these people don't have 10 YoE, they have 1-2 YoE times some coefficient.
I feel like if you're in a "successful rut", that's what it will do to you. You feel like you're successful, but in fact, you have fallen horribly behind, without even knowing it.
Your quality of life is probably fine, until you're laid off one day.
Agree. There are people with 10 YOE and ppl who have repeated 1 YOE 10 times.
Some people get complacent once they get a job and stop learning. The trick is to keep on learning. I have worked for a company like Amazon with aggressive schedules where we used to work for 12 hrs/day. One time I didnt go home for 3 days. I can say I learnt a lot, but there are better companies with mature planning where you would still learn the same amount.
How different ppl react to toxic environments is also different. Some people may thrive, while some may wither.
I say it is a random walk searching for the best place (for you) to work. You keep iterating until you find what you want.
In many companies software got so specialized devs won't ever get close to infrastructure stuff.
They ask for a VM or a DB to the DevOps / SRE team, wait a bit days and get a URL. If a team uses CI/CD and K8s, they will write a yaml file from a template, wait a few minutes and app will be deployed.
Not sure what answer you expect here? Just because you have 10 years of experience doesn’t mean you’ve ever worked with more than 25 servers at a time (at least I haven’t).
I consider it a source of pride, I think. You absolutely don’t need mega scale for most things (or maybe mega scale, but still not many servers)
Whether someone is in a rut or not is a separate issue than whether they've worked with terraform. The key here isn't what technology they've used, it's a mindset towards automation.
I recently came off a project that was technically using "GitOps" but where every deployment involved copying and pasting dozens of files across 3 or 4 repos, and the whole thing was very error prone, and if you didn't change exactly the right things your service would just silently fail to deploy, or be unreachable, with zero feedback.
I've worked at a company with a bespoke CI/CD system hacked together with PHP scripts and Jenkins servers, but where every single process was ruthlessly automated, reversible, with multiple layers of fallback, failure recovery, garrulous feedback, and built-in approvals that you could automate, or if you didn't remember, you'd get a helpful reminder in email and a link to a page to fill in the required information. People could, and did, know how to do a deployment on it their first or second day.
Guess which one was more pleasant to deploy with?
It's the automation mindset that's important. You can find people with the right mindset who haven't had a chance yet to play with ansible or terraform, and you can find people who manage to create nightmarish complexities of manual processes out of ansible and terraform. Unfortunately, I haven't yet found this to correlate much with years of experience.
I updated a custom package on 500 ESX servers using ssh. Just kicked it off asynchronously, used ssh to execute a single command and not get an interactive terminal, and logged the results to check for failures. I was in the support org, so I was pretty constrained on tool choice.
I worked for three years in a extremely customer driven company.
The last 1.5 of those I worked with what I consider two amazingly brilliant a####les.
I ended up leaving the most amazing place I had ever worked at until then (worldwide traveling, learning new stuff, actual high performance systems).
It has taken years to recover and I still cover myself more than I should.
My boss (who I liked) tried to get me back twice after he realized I had not been the problem and the two others had left but by then my salary had increased so much I was out of reach for him (edit:,) and telling my family I'd go down a double digit percentage in salary to work for someone who had not stood up for me back the was out of the question.
I was naive but it wasn’t really negotiable. Don’t meet the deadline by a large margin? Expect to be out of the company relatively soon. I think this particular team was much more hardcore than other parts of the company. Most of the horror stories come from the core amazon services
At least everywhere I have worked, deadlines generally come down from on high, often with no real developer input. If you are lucky, your manager will be successful in fighting for more time. If you somewhat lucky, the missed deadline will be ignored. If you are unlucky, the deadline will approach and people will suddenly disappear.
I mean the project management triangle comes into play then, and when it comes to SWE, throwing more money at a problem usually doesn't make it go faster.
Basically the higher-ups have to decide what is most important; if the deadline is fixed, then the scope HAS TO BE flexible.
There's a basic communication problem IME. When I've been in this position (an impossible deadline) it's been because some Sr VP or C-suite type decides that something HAS to be done by a certain date. Like, they want to unveil a new product/feature at CES or some other trade conference so the date is fixed. So this filters down through 3-4 layers of management to you, the dev lead who actually has to build the thing. You take one look at it and it is basically impossible and you can list the 17 reasons why. BUT the problem is that the person that needs to be convinced is the Sr VP/C-suite type. So your analysis has to go back up, filtered through 3-4 layers of managers, each less technical than the last. And of course nobody in that chain wants to disappoint their boss so they hedge/soft-pedal your analysis at every layer. Now the SVP/C-suite type, who typically does in fact have good reasons for wanting this project done by whatever deadline they set originally, only gets a watered-down, possibly incoherent version of you analysis of why the project is impossible by the given deadline. Not surprisingly, they don't find it convincing.
tl;dr; everything in a large corporation is a game of telephone where everyone is incentivized to muddle the message. So any deadline/commitment handed through multiple levels of management is really difficult to negotiate. And the more unrealistic it is, the harder it is the negotiate. Nobody wants to tell their boss that the thing they want done in 3 months will actually take 2 years.
In the beginning, there was a plan,
And then came the assumptions,
And the assumptions were without form,
And the plan without substance,
And the darkness was upon the face of the workers,
And they spoke among themselves saying,
"It is a crock of shit and it stinks."
And the workers went unto their Supervisors and said,
"It is a pile of dung, and we cannot live with the smell."
And the Supervisors went unto their Managers saying,
"It is a container of excrement, and it is very strong,
Such that none may abide by it."
And the Managers went unto their Directors saying,
"It is a vessel of fertilizer, and none may abide by its strength."
And the Directors spoke among themselves saying to one another,
"It contains that which aids plants growth, and it is very strong."
And the Directors went to the Vice Presidents saying unto them,
"It promotes growth, and it is very powerful."
And the Vice Presidents went to the President, saying unto him,
"This new plan will actively promote the growth and vigor
Of the company With very powerful effects."
And the President looked upon the Plan
And saw that it was good,
And the Plan became Policy.
And this, my friend, is how shit happens.
In big companies, there is program management which comes up with the overall schedule. There will be buffer time, but you still have to work within the given time whatever challenges there may be.
I mean, you even attempted it. I would've looked at it and told them their deadline or scope was unrealistic.
I mean I don't want to do any project with a deadline, ever again, if possible, and I haven't even been exposed to the level of stress and pressure that people get at certain companies.
I thought deadlines had gotten rid of a decade ago in software engineering with the rise of agile software development and the realization that software is difficult to neatly scope, and development time is almost impossible to predict.
I’m in the same boat as you, haven’t worked on anything with a deadline for the past 2 and a half years and I never want to go back to it, totally pointless arbitrary dates that are never met.
A side effect of working for asshole companies like that for years is I’ve slowly developed a zero fucks attitude and an immunity to threats and carrots dangled in front of me.
I can sit there as a project is falling over the edge of a cliff with total inner peace.
My interest stops at the pay cheque and by the clock.
I imagine that's a good place to be, but I don't know if it's possible without going through a lot of trauma and building up substantial mental scar tissue.
Getting on 15 years into my career and not sure I'll ever get there. On the other hand, I actually work on a project I care about and for a company that treats me like a human being and not a "resource". Think I'm OK with that.
> I can sit there as a project is falling over the edge of a cliff with total inner peace.
This is what I'm (slowly) learning as well, even though I'm not entirely sure I want to. Working on projects where you care but almost nobody else does does that to you, but I'm afraid I won't be able to make it back to a position where I can care for projects.
Don’t sweat it; it might be healthy. I have made it a feature of my life that I don’t actually care about work and will not be changing it. It turned out that I’d spent at least 20 years being tricked into caring for things which ultimately someone else leveraged most of the benefit for with measly returns by proportion on that investment of time back to me. Never a thank you, always difficult to extract any entitlements from it.
Another thing to note is my father who had completely invested his entire life into this way of thinking and is currently spending his retirement with bad mental and physical health. That’s the end game these working practices tend to lead into.
It’s true that you should work to live, not live to work.
You can care about your career and your self improvement while still maintaining healthy boundaries around the mental effort expended for your job. We’re in it for a long time but jobs come and go
Why not? You can care about delivering beautiful code. You can care about ensuring the workplace is a pleasant place to work for all. You can care about your relationships you’re building. You may even be a huge fan of the product you’re building. That doesn’t mean you need to shit a brick when someone comes running in with their hair on fire—it’s not a binary proposition. Caring about things can be done “a la carte” and you can simply just not care about the bullshit
Exactly. You can even care about your product and its users, but not care that it went down for a couple hours last tuesday or launched 4 weeks later than a made-up deadline.
At least to me, of the best things about this attitude is that the working culture starts to matter a lot when you search for jobs. That's what you care about. You look for places where relationship building is important and people try to get along and support each other. Other stuff starts to matter less. Lots of places basically put so much pressure on you to deliver that being a decent human being becomes impossible.
If my choice is between working at a boring job where I can support my colleagues, and an exciting job with cool tech where people are having mental breakdowns and nobody has the mental space to support them, I'll take the boring job where people don't care about stupid directives and dealines from above.
I agree, and I still don’t have an answer for this dilemma. I don’t know if I’m the problem, or if it is the structure of our society.. In the meantime the only thing that I know is that I have to choose between not caring and feeling like I’m wasting most of my day, and caring with the potential abuse of an employer
Next time around I'll be sure to get born wealthy so I don't have to worry about it. But it's incredibly privileged to be able to do the sort of work we do compared to standing in a factory production line or working away from family. I enjoy my work, but I know if the company fails it's not my fault and I will be working somewhere else tomorrow.
I think it's healthy to not care about something you have no real stake in. But you can compensate for that condition in a day job with hobbies or pets or friends or generally something to care about outside of work. I personally do a number of regular social things outside work as well as occasionally writing and producing music on a purely amateur basis, where the only reason to do them is _because_ I care.
What I’ve found is that you can care about things like craftsmanship, problem solving, and quality while not being bothered by the day to day short term project level thinking.
The problem is that writing good code requires more time than writing shitty one.. and if there is a lot of external pressure to finish the project, it’s quite difficult for me to stay focused on quality
That's fair, and I'm not saying it's as easy as flipping a switch. We are all social human beings wired to easily get caught up in the day to day panic, especially when someone is breathing down your neck. But you need to consider that somebody breathing down your neck does _not_ have your best interests in mind. You are master of your own career, and any shitty code you deliver will have your signature on it. It's all about setting boundaries and being able to push back when people are unreasonable. This is where the "not caring" is an invaluable skill. You are an immovable mountain in the face of a hurricane.
At the end of the day, YOU are the professional. If an amateur decides that you are going too slow, that doesn't mean anything--they can feel free to hire more engineers or whatever needs to be done, but the onus is on _them_ to ante up. No matter how much you love your job, you're probably going to have multiple throughout your career so you need to focus on yourself first and foremost.
I was lucky enough to experience a 2 year long project in which everything that went wrong was blamed on the developers. Project managers breathing down your neck, feeling so pressured you barely dare take a bathroom break, the whole shebang.
Quit working for them and now I'm a freelance dev.
They asked me to get back on the project and I said fine, that'll be €700/day. After some grumbling they realized they had no other option so they agreed.
The project is still failing due to bad management but I no longer care. I believe to now feel the same sense of calm around chaos and failure like you do.
A lot of developers have real mental scars from bad projects like this, because they get duped into thinking it's a matter of personal pride to see it trough.
It's not. Your primary concern should always be personal health.
Well, cobol is special of course. The more specialized you are... But for a generic c++, java or c# or web dev I would say you can't charge specialist money at all in the EU.
Well it's a negotiation. Those guys succeeded at asking for 2500, but you would start at a number they are guaranteed to say no to, and work your way down.
Like the going rate for a senior here is 900, and a good senior is 1200+. So your starting offer would be at least 1800, probably 2000s to round it up.
Which is the high end of your zone of possible agreement (900-1200) plus 50% for danger money, plus a few hundred to round it up to 2k.
Then you see what happens when you throw out the big number.
I prefer to be paid based on how valuable my work is to the employer, not the cost of living wherever I happen to be or even my personal financial needs.
Sure, so do I, but when I tell my manager I'm worth X amount, he'll say that's just not where local salaries are at for my job category and responsibility.
Implying that other developers in my area are available for less than I ask.
I mean, if a person is able to extract 700€ per day, kudos to them but that's still above the 90th percentile of senior developers in Europe.
I had a buddy do exactly that. His manager told him he was already paid above market. Inside a month he showed her that she was wrong and we had a gaping hole to fill in the team.
What do other companies say? "Nah you're not" is a pretty standard response to "I'm worth more than this" but consider the source. For some reason many companies would far rather let a good employee leave than raise their pay to market rate.
It would be the top range (if at all possible) for a developer working as a permanent employee. Usually the only way to make this kind of money is to go self-employed
Heh, as a salaried dev who gets 1700 - 1800 Euros per month (so around 90 Euros per day) after taxes in Latvia, some of the numbers in this thread are pretty sobering, even if you take the costs of being self employed or taxes into account.
If you take the run of the mill Java dev salary here, the net value is somewhere between 900 - 3000 Euros or so, across all levels of seniority [1]. Really makes one consider the benefits of working for companies in other countries, assuming that there are no cultural or time zone issues that cannot be dealt with.
Or, you know, to acquire skills that are high in demand but relatively low in supply.
There are some great remote work opportunities these days. It might be worth starting to look at other European countries who are hiring.
Take Ireland for example. You're not going to be making US level money but I'd say you could easily double what you're making now and there's the potential to go much higher than that.
Yep, and it seems like the pandemic largely showed that there are quite a few jobs out there that can be done remotely with decent success in many environments.
Well, at least as long as the culture fit is there etc., admittedly remote isn't for everyone, but on the flip side, geography/commute being less of an issue for the remainder of people is great!
From the Stackoverflow survey, it would be below the national average (the mean), but I don't think there's actually many regions that pay the national average. SV pays more and most of the rest pays less.
Keep in mind consultants don't get 401K plans or many other things, AND they have to save about 15-20% of their income as "in between jobs" money, in case they don't line work up.
If you earn 30% more than a salaried employee you are barely breaking even most of the time.
Hold on, 700€ x 215 days worked (you don't count vacation time when freelance) = 150 500. Now, give it half to the taxman, and you're left with 75 250€ / year.
And that's without the expenses, extra healthcare coverage, insurance etc.
So pretty average when you considering that junior developer salaries are within this reach in EU capitals.
Even allowing that junior salaries reach this high (that's in the range for a senior in Berlin at least), that would be the PRE-TAX figure. Remove 40% (again, approximate taxes in Berlin, potentially more if you pay the "church" tax) and you've got 45150€, a significant difference.
I used 4 weeks, and by my experience that's generous (not talking about paid leave - all the freelancers I know are workaholics and don't take much leave, but maybe that's a US thing).
5*48 = 240 days, which works out to around 84000 EUR. Or 120,000 EUR - 30%.
Regardless, 700 EUR/day seems in the ball-park for a generic all-around developer.
£500/day is the absolute minimum for developer/DevOps outside London, £600/day much more common and including the cheap end for London. Senior is more often £800/day. You don't see values above that advertised, but people do obviously negotiate higher for specialist work; I have seen a mainframe developer charging £1500/day (on the low end of his range). Anything higher than that has always been a large consultancy rather than a freelancer. In my specialist niche I'd be asking for £1500/day top-end, expecting £800-1200 with negotiation depending on flexibility.
To give a point of reference, an employed senior engineer in mechanical/aerospace in western Europe makes about 250-300€/day, before taxes. So 175-200€/day after taxes.
Amazon's orientation and internal culture is structured to make one think that it is a matter of personal pride and worth and if you do not align you are worthless.. it is a mind F** for fresh college hires.. I like to think Amazon is the tech industries' Pedo***..
This is exactly why I think contract work is the most honest form of employment in the software industry. "Mission statements" and "customer zeal" are meaningless when you're having to do endless weekend and evening hours. If it means so much to you, pay me by the hour first, then we can talk about devotion to the customer.
Customers always seemed to want to pay me fixed amounts for jobs and be absolutely no good at estimating them. I got paid 28 days contract fees for a job that took 3 hours once. They paid up and asked me to not come in for the last 3 weeks so their other employees didn’t catch on to what had happened…
It is true, a lot of tech companies will give you very good medical coverage without pay period fees but at the end of the day this boils down to money. Your salary is adjusted based on the company paying whatever rates they pay to offer you great insurance.
When doing contract work, you might be paying $500 / month out of pocket for medical insurance but your hourly rate is likely higher than your hourly rate as a W-2 employee even after factoring in company holidays, PTO and 401k matching. You also have the option of not buying insurance if you really wanted to.
Most insurance in the US is horrendous too. The whole system is optimized to provide you the least amount of coverage while making the process as inefficient as possible for you. I spent literally 12 hours on the phone over a few calls trying to get basic information from a few different dental insurance providers, in the end I got nothing concrete out of it and the only way I could have gotten concrete numbers is if I submit a form that takes 30 days to get processed except in the US you only have 30 days a year where you're allowed to enroll into insurance. Basically it was impossible for me to pick insurance based on coverage because it's impossible to know the coverage without first signing up and then you're stuck in it for a year in which case everything resets the next year and the process has to start again from scratch.
Here's how you pick dental insurance: it doesn't matter much because it isn't insurance at all. It's just a maintenance plan. The purpose of insurance is to buffer you against sudden large costs by having the insurance pay them while collecting enough of a premium from everyone that they come out ahead. The purpose of a dental plan is to pay for typical costs and completely bail on you if your costs go over a fixed amount per year (typically $1000-$3000). Look closely: every dental plan you are being offered likely has an annual maximum benefit per year of somewhere in this range ($1500 is common). I've had the insurance company cheerily say "yes, that procedure that costs $54000 is covered at 100%! ... up to your annual maximum, which is $1500. You will be responsible for the rest."
Yeah it's very limited in general. You can't even get certain standard types of cleanings with 100% coverage because it's not a supported dental code.
It would be way more efficient for employers not to offer dental insurance and instead give employees a tax-free $1,000 yearly stipend which allows employees to use this for personal and family dental care as an expense report which in turn ends up being a business write off for the employer. Now there's no limitations on what work can get done and no wasting your life trying to chase down dental / FSA details. A higher end dental insurance plan through a company is over $1,000 a year too, so this stipend approach would save employers money and it saves employees a lot of money too because you could easily end up paying $600-700 post-tax money out of pocket for standard cleanings a few times a year when insurance won't cover them (even if that insurance costs $1,000 a year). It's a win / win scenario for both the employer and employee.
Just factor that into your cost of business. Your day rate should be 3x your salary rate in part for this reason as well as the unpredictability of future employment.
Happy I live in the UK when I see things like this posted. I was offered a job years ago in the US which I declined and would never want to be held to ransom over my health potentially.
One of the things I surprisingly (?) learned at a small startup as the first employee.
It was me and the two founders that I already knew from working together in the past. I expected that my opinion matters, I tried to improve the product, the service, the engineering, but anytime I recommended something it was ignored. After some months, I learned to just shut up and code. This experience taught me that no matter how close you are to the decision makers, influencing them is still hard. Since then, I just don't care. Sure, I'll do my best, but I do it for me and to get another offer in two years.
Now, I work at a big company, I'm like 5-8 levels removed from the decision makers, and I just don't care. I still try to do my best, if I have any concerns, I might mention it once, but if decision makers are not interested in my feedback, I don't mind. I work my hours, do my best, I don't take anything personally, but I also don't care if there is an outage at Friday (that could have been prevented if only we addressed the issues I brought up a couple of times) or if the feature we are developing never gets to production or if the feature fails (predictably, but a CxO has the amazing idea to pursue some obviously bad product decision).
It's difficult to not show the rest of the team how much I don't care. It's very different to show everyone openly you don't gaf (that's not accepted) and just simply not giving a f while pretending you care (that's okay), so I learned to "mask" my true emotions.
I don't think so. They didn't throw in the towel yet, it doesn't look rosy (at least to me). One of them is still a friend of mine. I learned a lot, so I'm glad it happened, but I'm also glad that I left.
This is a great comment and how one should evolve to stay sane and healthy.
My BS filter is highly developed now.
"We will have the project done by the end of the month.
Failure is not an option. We dont fail. We are xxxxxx.
Come hell of highwater we will get it done.
Lets do it". High fives.
"If you get this done you will get ...... " ($$, vacation, yacht)"
"Give it 110% people"
"If we dont get this done ....... "
This means:
"This project is screwed. Nothing the team can do will save it.
I do the right thing; I talk to the PM or whoever is in charge
and politely but honestly share my professional assessment
of the project.
This is most often totally ignored.
Which is fine.
It is no longer my problem
and nobody can come with "I thought you told me you would get this done ,.... "
or some such variant.
I will do a good job and try within my own parameters of sanity and health
and time.
After a rather unpleasant and unwelcome time I found myself in the army,
having people yell at me all day (and night at times)
Even when you have not slept for 48 hours, still screaming.
I can't say anything positive about the army but it did give me thick skin.
I am entirely unfazed and bored by some office drone talking to me loudly.
Even if said drone starts turning purple.
> ""With all due respect, sir, you're beginning to bore the hell out of me.""
(Clint Eastwood as Gunnery Sergent Thomas Highway in Heartbreak Ridge (1986))
Bravo! I'm working with and for genuinely great people, but my past experiences with such "stick and carrot" bullshit mean I still treat my employer (i.e. the legal entity) as the schoolyard bully: don't cross their radar.
Never dealt with PIP, but anyone worthwhile will just quit and get a lateral or better job. That's what I did when one of my employers extended the mandatory 6 month probationary period because she just wasn't sure about me.
I don't need that stress. I just hopped over to another company, cut my commute, and made about 20% more salary.
I don’t understand this though? Eventually someone’s head needs to roll. If you fail your project and get fired, how is your manager immune from consequence? They failed too (probably more).
Yeah, vibes with my experience working there. Toxicity beyond pale. Good riddens, they contact me every week to try to get me back. Fuck off Amazon, you have no integrity, you abuse your employees from white collar to blue collar. You literally fired people who emailed Jeff Bezos to report abuses, after you told them to, when the NY Times "crying at desk" expose came out. Bezos instilled this shite culture into Amazon. And his midlet pawns carried out his half-baked decrees like those fucking wet noodle "Leadership Principles" which make no actual sense and aren't principles at all in any sense of the word. Brian Cantrill (of 0x1de computers) gives a great breakdown of how sacrosanct Amazon's leadership principles are: https://youtu.be/9QMGAtxUlAc
Principles are things like Integrity, Honesty, Respect -- not Amazon's fuckwit bulletpoints like "Be right a lot" or "Frugality."
Technologically, AWS is built like a fucking house of cards with spit, tape, and glue. There is no real cohesion or organization, just a bunch of teams doing their own practices and gluing their rando codebase into the Yellow Console. Sorry, but just making the frontend look unified doesn't undo what the backend spaghetti is... That's why the outages of late will continue. It's all bubbling up from the absolute toxicity in lack of basic humanism at the core.
I logged in simply to comment a huge "thumbs-up" to any Brian Cantrill reference. I've got an entire playlist of all his various talks around the interwebs, just to listen (and re-listen) in the background while coding. It checks off all the education, tech, history and, critically, humor boxes.
When you're running a world wide service with lots of moving and connected parts this dramatically increases the danger you'll have catastrophes that will cost much or most of that market share.
As a thought experiment, suppose all of AWS was down for a full week? What would happen after that?
More realistically, how many times can us-east-chaos-monkey bring down various global services before a lot of its users start making moves to mitigate or eliminate their exposure to AWS?
For a more concrete example, I'm working on a project that has an easy but critical use of cloud services. The more I read about Amazon following Microsoft into Ballmer era stack ranking madness, and the most AWS fails objectively fails, the lower the priority it gets for which cloud platform to support first and best.
Funnily enough Amazon has its own internal repo, including NPM. And it can be a pain in the ass to add anything to it, especially npm packages. So sometimes you would have to spend 5 minutes, or sometimes an hour, to import a single existing public NPM package into the internal repo.
This is a phenomenon common to all low grade/incompetent dev managers: When a dev asks for a team change they view it as a slap in the face because it has happened to them so often in the past and they take it as a personal offence. The fact is they are lousy managers and usually incompetent and nobody wants to work in their team.
So they go on the offensive and try to manage the dev out before senior management realises that yet another dev doesn’t want to work with them.
It’s difficult to not feel empathy for people you have a relationship with. Even if a manager is incompetent, they will get the benefit of the doubt from vs a lowly engineer whom the Senior Manager does not have a personal relationship with.
There are very few Senior Managers who take the time to look beyond what’s immediately presented to them.
So M2s+ are expected to have empathy for M1s, but M1s are not expected to have empathy for engineers. And, M2s+ having been M1s prior to being promoted, have to develop empathy when becoming M2s+.
Have I described correctly the situation?
Legend:
M2 - senior management, has other managers reporting to them
M1 - first layer of management, has workers / engineers as direct reports
I think both are expected to have empathy. It goes south when one of them doesn’t have empathy for their -1 because they get the benefit of the doubt from their +1 in general.
TFA mentions a PIP quota and implies that OP was used to fill the quota, so I'm pretty sure upper management won't blink at this happening. They expect people to get PIP'd, and they have no visibility on the actual internals, so to them OP is just as good as anybody else who got PIP'd.
The upper management only gives a blink when it becomes more known by the public. They don't want to hear (just not to be in the responsibility zone) and when it's widely known they would go whitewashing or PR stunts.
Why they had to invent "to be the best employer of the world" as a leadership principle?
The more people should stand up and make the stupid policies known, that's the only way this can stop. Otherwise this policies will be the norm for many companies since "it can work"
Upper mgmt generally doesn't give a shit about what the public knows. Amazon is famous for employees pissing in bottles because they don't get enough breaks. No one cares enough to make the warehouse conditions humane. They just do enough PR to feel good about it. The job still sucks, and the pay still sucks.
The only thing that management cares about is how much they're paid, and how much power they have. Look at how Elon Musk behaves. He gets mad/irritated when told by regulators that he can't exercise the power he feels is his right. I actually don't think he gives a hoot about how much money he has, except as a tool for accomplishing what he wants.
Others are more into the wallet than the ego. Do you think Zuckerberg gives a crap about what privacy advocates think? Most people have a fair idea of how far FB spies on them, and Zuck knows they don't care as long as they can share cat pictures with their friends, or post Let's Go Brandon stuff. But you can bet that he's supremely pissed about losing so much money due to Apple's privacy changes.
In my experience it almost never works like this. The fish rots from the head.
I've found bad managers are able to exist, even thrive, due to a culture of loyalty. Having worked in several countries this is a very Corporate America thing (IME). Loyalty is the only trait that matters. Fealty might be a more accurate description.
So that bad manager's manager looks at a situation where people are leaving. Those people are disloyal and thus bad. The bad manager is completely loyal and thus good.
This is true. I suffered a lot until I learned that showing loyalty is necessary for having a career in a big company.
Most people don't care at all about doing a good job. They just want more money. To get along with them, you must help them get more money. If you oppose them on anything, they will make you suffer. And if they have the skills, they will manipulate and gaslight you. You can't make anyone do their work well. People work well when the organization is set up for it. If you can't tolerate your teammates' behavior, just move to a different team or company.
The logic there is that this person was already going to leave your team either way, so if you PIP them they will just leave the company and you don't need to PIP someone else instead. Still a sociopathic thing to do though.
I wonder what the logic there is. If someone isn't doing well on a team, shuffling them to a new project might help. But the downside is managers might be annoyed by a new person on the team who is a suspected low-performer. Could lead to a game of hot-potato where people try to avoid having PIPs added to their team through politics.
I had a boss who lost a new hire to another team. This new hire was an outstanding performer, and the boss simply couldn't see what he had done to cause this. He seriously was in a funk about it for 6 months. Anytime it came up, he went through the stages of grief. Turns out the employee simply didn't like the caliber of teammates, nor the pace of work. He was able to move to a team that tended towards more of a cowboy mentality.
The same manager never fired anyone he hired. He fired a few that he had inherited (even calling them 'deadwood') around other employees. Employees who had worked with the 'deadwood' for decades. But his hires? They could be the worst performers, and even though they were contract to hire, he always hired them. To not hire them would be to admit his hiring practices were crappy. And considering he had little technical knowledge, he was susceptible to hiring people who kissed the ring (and stroked the ego).
Some managers are just bad. Peter Principal and all that. Some are great at telling everyone what they want to hear, both up the chain and down.
I've spent 8 years at Amazon and for the most part I enjoyed it (mostly AWS teams). Never ever I felt anything even remotely similar to what has been described in all those stories. Not sure if I just got lucky or it's not bad everywhere and people with bad experiences are just more vocal.
Never worked for AWS, but I'd imagine its different depending on division/team. Before starting a job once I had an ex-colleague warn me against the company, saying he had friends there and it was brutal (none in the team I was joining, but its a big company). Turned out to be the opposite for me, and in fact was far nicer than the company I worked for when I was working for him.
Big companies are often far less consistent across teams than you'd expect/they'd like it to be, for better or worse
It can even be different in the same team. It's about who wins the bully lottery just like in school. Some will go through school totally oblivious to the fact that some people gets so bullied that they decide to end their lives a few years down the road.
Once I came in to work in the evening, I had forgotten to bring my phone with me. There I find one of my coworkers crying his heart out because the women treat him like shit. I had not noticed a thing until then. They thought he was sent there to optimize them away and was making his life hell. He had sold his appartment and moved to our little town to work but couldn't take it and moved back again.
Well he was the only male except for me so there was noone else to treat him badly. He was just taking over the invoicing that noone had time for anyway so I have no idea why they were treating him so bad. The ones that were doing the invoices were always complaining that they had to do that on top of their normal job. Some people just can't handle new people showing up and think it's a threat to them. Turns out they were right to feel threatened though, the company shut down the whole branch a few years later and moved everything.
> Turned out to be the opposite for me, and in fact was far nicer than the company I worked for when I was working for him.
The company is the same for everyone (ie un-humanistic in its management), and if and when your personal circumstances change, you'd then perhaps see what others currently in it are moaning about.
I worked in a role at Amazon that required me to interact with a different team every 1-3 weeks. I would often sit directly with the teams as I was doing work with them for the duration.
There are teams at Amazon full of some of the best technical and professional managers on the planet. There are teams at Amazon that are so brutally driven that they will sacrifice anything, even accepting an incomplete pentest audit and a forgoing week's worth of sleep, to hit a launch date.
I personally had a close friend on my team get PIPed and it was obviously a play from management to get rid of him. I have another friend who had to take months off after leaving because of the abuse she experienced. I have other close friends who have stayed for years.
It's such a big organization and the leadership chains are so decentralized that you get a wide variety of emergent patterns, and the decentralization makes it hard for people across the organization to know about the experiences of other teams.
Edit: in general I wouldn't say the horror stories are the norm at all from what I've seen.
I also worked at Amazon, my team was great, and I had a great time. But, I also acknowledge the immense amount of toxicity that comes with "getting promoted" at Amazon. Many manager are on a visa, and get pressured to "deliver results" or they lose their visa. So these managers push insane deadlines, people burn out, the ones not in a visa leave, the others need to deal with the huge ops load, the frequent on-call rotation, and with an angry manager.
Is it really so dysfunctional there that if this happens to you (manager puts you on PIP upon being notified you're doing an internal transfer) there's no one to talk to to make this right?
Maybe his manager is a piece of shit, but I can't believe there's no one to report to above him that can see this for what it is and make it right?
HR at Amazon is a shit show. I had $100 of pizza stolen from the fridge at Amazon and I mentioned it casually to HR, as something notable but not too important. And HR then decided to tell my manager without my knowledge. The manager then berated me over communicating about a "trivial matter." So yeah, wouldn't put much stock in HR at Amazon.
You should've played the game and claimed you've never said what HR says you've said and in fact (here goes the distraction part of the lie) you heard another guy was talking about pizza, so HR must've overheard that conversation and misremembered the details.
I know it's not the point, but how/why did you have $100 worth of pizza in the refrigerator?
Edit: I'm trying to imagine scenarios where that could happen, I have two so far. You ordered pizza for a meeting that got canceled, and the office refrigerator was huge. Or you ordered from a fancy pizza place that had waygu or something as a topping. I'm sorry, I don't know why this is bothering me so much.
I mean ... one of my guilty pleasures is leftover pizza straight out of the fridge. Something about that chilled, congealed fat and sugar ... mmmmmmmmm
Ok, so that explains how they fit in the refrigerator. Though it's still confusing why you would buy 5 pizzas and put them in the fridge. Is it common around there to buy pizza in advanced and reheat it? Or were they just leftovers, and I was thinking too much about it?
The issue with Amazon is that due to its size, working on a team is essentially like working for a separate company. If you are moving across big orgs, you are just a blip in the system should something like this come up. And just like a group of startups, some are going to be run worse than others.
Additionally, because of the internal transfer policy and teams frequently switching out members, a lot of work is designed to be picked up by a new person, especially at the SD1/SD2 levels, so people are generally replaceable. Couple that with the fact that the interview process only tests for academic knowledge, without really proving that you can set up infra and services in production. And even more on top on top of that, Amazon gets a never ending candidate pool. So you get a combination of both poor performance that actually need to get PIPed out mixed in with poor teams that are ran like crap because managers themselves are not really technical and end up not delivering and then having to PIP people out.
That being said, because of this sort of structure, if you know how to make moves and "read the room" so to speak, Amazon is the best company for finding that sweet spot of maximizing revenue/actual hour worked. If you are a talented software engineer, not just a developer and generally know how to navigate around managers, you can hit senior engineer or manager levels quite easily, and then cruise control your way at $300k a year, and with an added benefit of lots of remote positions right now (since wfh is a big selling point in order to not get rejected by good candidates). From talking to people at Google/Facebook, those kind of moves are a lot harder to do.
> If you are a talented software engineer, not just a developer and generally know how to navigate around managers, you can hit senior engineer or manager levels quite easily,
How do you “navigate” your way around an 11:30 PM email that contains a 5:30 AM deadline, as mentioned elsewhere in this thread?
Pre-declare available working hours, and adhere to them.
I have a cronjob that signs out of {slack, email, zoom, ...} at a particular time of day, my work accounts aren't attached to my personal devices, and i respond promptly to communication during working hours. I genuinely don't see work-related comms when i'm not working, and my work availability is in my slack profile, my internal email signature, and in my outlook calendar.
> The issue with Amazon is that due to its size, working on a team is essentially like working for a separate company.
Not really; esp when the processes and priorities are alike across the company (with exception of few organizations that are experimenting newer processes at any given point in time).
> Amazon is the best company for finding that sweet spot of maximizing revenue/actual hour worked.
I don't think a single tenured co-worker who, during the pandemic, moved to Airbnb, Uber, Google, Stripe, and heck, even Coinbase, look back fondly upon the management structure they were subject to at Amazon, now that they've seen how other companies in the space are setup.
> If you are a talented software engineer ... cruise control your way at $300k a year.
I guess it is hard to pinpoint one particular thing, when it is the overall system of ruthless management which causes grief among engs who dare have a performance blip... on top of the constant stream of stories/rumours they hear of their co-workers / from their co-workers... I guess it only makes them want to move to some place where there is less of such constant barrage of negativity (tangential: https://hbr.org/2016/06/the-management-thinker-we-should-nev...). Personally though, I quit AWS three ago, and haven't looked back, though I did like my time there (and have very little to complaint about).
At the risk of sounding like someone who clearly doesn’t have the skills you’re talking about, what do you mean by “reading the room” here? Knowing when to push things, when to drop them, being trusted enough by management that they don’t blame you for failing to meet absurd requests?
One piece of advice I always offer to younger software engineers about corporate politics is to ALWAYS try your best to make sure you have a relationship with your manager's manager. Cutting out links in the corporate telephone game is invaluable sometimes.
Agree. It is unlikely the manager did this out of pettiness. He probably got pressured by his L7/L8 to fire someone for his org to meet the URA goal. He made the obvious choice and picked the guy applying for internal transfer. Why lose two people when you could just lose one?
IBM and Microsoft used to do that a little bit more than a decade ago. Not surprisingly it turnes out that counting LOC leads to shitty spaghettincode and copy paste all over the place and complete ignore of DRY principle
I mostly worked in IBM research but once spent a few months on assignment in a product developed group in the mid 1990s. At the weekly group meeting, each developer would mention throw many lines of code had been reused. Turned out that there was a big monetary incentive to reuse code so developers would randomly include enormous libraries to pad out their numbers!
At a Tier 1 Investment Bank, there was a manager (ED/MD) from Bear Stearns who said explicitly in his first meeting with the whole department that he will track and rank people in the IT org based upon their lines of code and fire the losers. Everyone. Business analyst? Better find a way to get some code in. PM? Better make that spreadsheet a Java app.
Managers even bought Java textbooks to put on their desk as some kind of totem as if their days weren't 100% filled with political skirmishes.
Don't think it ever came to pass but this nonsense reaches the highest levels of the wealthiest orgs.
i've never seen people to include the large swaths of generated code into their LOC. Exactly because it takes away whatever little meaning LOC has and makes it absolutely meaningless.
It’s absolutely a useful metric. I have managed many developers who insist their low LOC is in no way indicative of their productivity. They’ll say others are padding their code with comments, or writing bloated inefficient code, or that they themselves were tackling very tough problems that result in small (but tricky) fixes. Yes, we’ve all encountered that killer deadlock or memory leak deep in the runtime that takes three weeks to debug and then it’s a 2-line fix. But some people pretend that’s how all their work is, when in reality they take a week to fix a css misalignment, or take a week to refactor some simple python script and add one new command-line argument, and they average 50 LOC or whatever.
> But some people pretend that’s how all their work is, when in reality they take a week to fix a css misalignment, or take a week to refactor some simple python script and add one new command-line argument, and they average 50 LOC or whatever.
You already know what the problem with these people is (e.g. they can take a week to add a new command-line argument). Tying that to the LOC count is counterproductive.
Shitty managers like you who try to go against the well-known wisdom and try to use LOC as a metric are what leads to the problem of shitty developers trying to game that count and posting ridiculous metrics like "I checked in 51k LOC in January". Developers who treat their work as a craft will avoid shitty teams like that even if they otherwise do well on the LOC metric.
That's rude and against HN guidelines. Don't make this personal. I'm not attacking you.
You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case?
As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into? And when this developer has been saying in every team meeting and 1:1 the last month that they've been working on tough problems. I'm not going to put them on a performance plan over their LOC, but I'm sure going to dive in if I notice a small number there, and we're going to have a conversation about it if it turns out they're not delivering.
PS: above is not hypothetical. It's happened many times in cases when I take on a new team or a developer moves under me. A couple of cases were great turnaround stories, with the developer extremely grateful that their manager was actually helping them improve their engineering. In one case the guy was let go, because he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).
A manager can keep track of job performance by looking at how many tasks are being completed.
If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.
If you think LOC is a useful metric, I would disagree that someone calling this "bad management" is attacking you. A hospital manager that measures staff performance by incisions per day is clearly misguided.
> A hospital manager that measures staff performance by incisions per day is clearly misguided.
Wrong analogy. I have two physicians on my staff. They both have the same years of experience, the same role, get paid the same. One sees 20 patients a day. The other sees 2 a day. That's not a red flag? I should ignore that and assume that somehow every single one of their patients is 10x more difficult, and not even bother to look into it? Because if you would agree I should look into it, then the number-of-patients was a useful metric.
A metric is just data point, no more, and not a complete picture.
> If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.
I must not have been clear. I'm not arguing for bloated code. Lean code is good, of course.
I'm talking about the all-too-common developer who has some number of tasks to complete, and tells his teammates (and me, their manager) that the work is very complex, and so they land (let's say) one bug-fix a week, giving the impression that each bug-fix (or feature, whatever) was challenging. But on inspecting their code, the code itself is fine --nothing necessary wrong with it-- but the changes are all trivial and really shouldn't take a $180K/year developer two weeks or even one to crank out. LOC isn't the full picture but it's often correlated and if nothing else, it's an obvious red flag for me to investigate.
To put it simply: If you're a high-paid engineer, you can deliver big features slowly or big tough bug-fixes slowly (and the LOC doesn't matter if the problem was actually difficult), or you can crank out lots of small features and small easy fixes quickly. But if you're barely outputting any code, and trickle out a meager amount of code, and the few lines of code you merge into the repo are all trivially simple, that's not acceptable. That engineer can't cling to "Don't judge me by my LOC!" I'm not -- I'm judging by the small amount of actual value they're delivering.
> Don't make this personal. I'm not attacking you.
I am sorry for the adjective, what I meant was "extremely incompetent". That is still harsh, but hopefully conveys my opinion regarding your grasp of management in a more objective manner. It's not meant to be personal, I would say the same thing about someone attempting to use the OCaml compiler to run a Python program, and telling me that's how they do things at their daily job.
> Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case?
I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.
> As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into?
Is this person engaging at all with their teammates? Have they been active on design docs or architecture? Have they been responding to queries from sales engineers? (a lot of time at an old job was literally telling Sales "yes, our product can do that"). Have they been maybe going through a big life change?
Without all of these, it's not possible to get a complete picture of why there is a problem. And a lot of them are more specific and better questions to ask than "how many lines were in the diff?"
That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".
> he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).
Since you have shown precisely this in your post (e.g. you didn't say anything about his lack of design or documentation or engagement with teammates; all of which I would certainly expect at that level), I think you need to reexamine your worldview, or at least the way in which you present it.
> I am sorry for the adjective, what I meant was "extremely incompetent"
LOL. Oh, you!
> I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.
Reductio ad absurdum. A new feature is expressed quite literally as code in a repository. All other things equal (i.e., if one person isn't busy with design docs, or mentoring teammates, etc) if one developer cranks out 5K lines of solid (not bloated, well-tested, etc) code in a quarter, while the other person eked out 150 lines in 3 months, that's an indicator of a potential productivity issue. How can one argue it's not even a hint of a possible problem?
> Is this person engaging at all with their teammates?
No
> Have they been active on design docs or architecture?
No
> Have they been responding to queries from sales engineers?
No
> Have they been maybe going through a big life change?
Sometimes yes. And when I find out that's why they stopped submitting code, I tell them to take the time they need to take care of themselves and their family. And we offload their work to someone else for a few weeks or however long until they're back.
> That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".
I wonder if maybe you had a terrible manager who was like this. Because you're interpreting my statements in the most cartoonish way possible, like I'm here saying "more code good developer, less code bad developer."
This thread started with someone saying LOC tells you nothing. I claim it tells you something, and then it's the job of the eng manager to figure out what. I totally agree that a shitty manager who literally connects LOC to productivity, is doing it wrong. But again: a good manager should be looking at the code from their team, and making sure the amount and complexity matches their expectation of what that person is supposed to be delivering.
Sorry, I wasn't clear. I'm talking about 50 LOC every 2 weeks or so. Like, seriously low LOC of seriously low-complexity (sometimes trivial) code.
I don't actually have a numerical target people should hit. Not at all. It's more like this: on several occasions now (all too common), I've taken over management of a team, and in our initial team meetings and 1:1s, some developer talks about what they're working on and say it's really challenging but they're making progress and making progress and making progress. Then a couple of weeks in, I look at their commit history, and they've committed 6 times in the last 3 months. I give them benefit of the doubt, those must have been 6 meaningful commits. Then the first thing that stands out, the first red flag: each commit is like 25-50 lines. At this point, I have very strong reason to think we have a problem. But of course, to confirm, you look at the code itself, and one commit is just adding a command-line argument/option to a python script. Another commit tweaks some CSS. Or does a bit of dict/list operations that any developer should be able to knock out in 30 minutes.
My first hint that I need to dig in was the low LOC. Obviously, no one goes to a performance plan because they're not "hitting numbers." And obviously, someone whose job is architecture, system design, etc, isn't coding all day, so I'm not at all concerned with how much code they're cranking out. But for those whose job is, primarily, to code, well if you're writing low-complexity code (which is OK in a lot of cases) but you're writing very little low-complexity code... that's a problem.
PS: For a couple of years on my last multi-hundred-developer project, I ran a twice-yearly Code Reduction Week, and I emcee'd the All-Hands where we celebrated the developers who deleted the most code.
LOC isn't a meaningful metric. Flat out. You can think it is, but it's such a toxic, nonsensical concept that you deserve to get pushback for mentioning it. It's a waste of time in the presence of actually useful criteria product/project-related metrics.
Teams of people build things. LOC don't add up to a hill of beans.
When that one person on the team barely commits any code, and isn't busy with design docs or anything else, they just don't commit hardly any code, taking a week to land 10 lines that adds a new argparse option that you could have written in 5 minutes, then I'll be curious to understand how their tiny amount of LOC isn't relevant.
I think maybe you haven't seen how unproductive some people can be. And one hint of their productivity, is that they don't have much code to show for. If someone can explain to me how they're writing significant amount of new software with less code than this comment I'm typing right now, I'd be interested to learn how they did it.
That’s such a horrible metric. I try to mentor my colleagues to solve problems using what’s already there. If they take a week to launch a feature without increasing the code size, I’m incredibly proud of them.
One of my own major wins last year was a big update to a project to strip out legacy cruft and tech debt, and scrapped maybe 5,000 LOC. The end result was smaller, faster, easier to test, and more robust. I count that as a win, by pure LOC, it was a massive failure. (Unless you don’t count code removals against an IC’s score, in which you’re optimizing for churn.)
I agree with everything you say. I will congratulate any team member who submits a -2000 LOC commit, and at my last gig I used to run a twice-yearly code-reduction competition.
My point is rather this, and I suppose I'm not being clear: If a developer only ever submits tiny amounts of code --and they have no other responsibilities like design docs, mentoring team members, etc-- that's an indicator of a performance problem that should be looked into and discussed with the engineer in case there's an issue.
I'm in no way suggesting that, e.g., the developer who submitted 12K LOC last year is doing a "better" job than their teammate who only submitted 11K LOC. I'm talking about that person on the team who only writes 500 lines of new code in an entire year, and they trickle out tiny simple commits ever couple of weeks. Every team that I've taken over as a manager, I find one person like this, who pushes barely any code, and the code they do push is trivial, and they aren't doing anything else either.
People here are somehow suggesting that LOC is so meaningless, that somehow apparently a person can implement a new map routing algorithm in 10 lines, or implement a new 3D rendering engine in 10 lines, or create a new data-ingestion and validation pipeline in 10 lines -- because apparently LOC is a "meaningless" number.
If you submit 51k lines of code in a month you are not productive. You are a liability. Producing 5-10 lines of quality code per hour is considered good in my world.
People say that working for Amazon for a year is enough “training” to serve as a resume badge. However, I’d like to provide a counter to that: when I see Amazon on a resume, I actually discount the candidate. In my opinion, the branding has suffered tremendously and I view the candidate as a compensation maximizer beyond all costs- why else would you join Amazon despite the well known horror stories, as well as their complete disdain for human life in the name of “customer obsession?”
Um, you realize people need a job to put a shelter over their head and food in their mouth--right? For everyone below vice president Amazon is just a J-O-B to them. It's not their lifestyle, it's not their worldview. You're missing out on an unbelievable amount of good candidates with that view.
I have noticed on HN a weird idea that most programmers are insanely rich and can pick and choose any job they like (I even saw one person say "lets be honest, none of us need a job..."), so I guess they're going by the logic that if you work for them you either endorse their worldview or don't care, which as you say I doubt is true for the majority of us
You can look up the average salaries for Amazon folks on sites like glassdoor. They're known for being competitive but not particularly larger or better than any other tech company. They pay well enough to live in a high cost of living area like Seattle but that's about it. Someone who spends a couple years at amazon is not going to be 'insanely rich'.
Well, not insanely rich. But let’s not pretend that the profession doesn’t compensate way above average and lots of options to choose from. definitely favorable for labor in this market, which is unlike most other labor markets.
I probably wouldn't want to work for a manager who filtered out names from their list based on previous employers alone. That seems like petty and self-sabotaging behavior.
I joined Amazon after being laid off towards the beginning of the pandemic when many companies had hiring freezes in place and having happened to be contacted by a recruiter during the same day. I also left for mostly the same reasons everyone else does.
Some people work a short period to get a taste of the tech stack and pace of a FAANG while other people post to HN about upcoming interviews at Meta and how they may hate the company's morality but want that big fat comp package. Everyone has their own reasons for taking a particular job and sometimes that calculation needs include the cost of associating your work history with the brand of the company you are working for, but if you think that what you are doing and the impact it has on the rest of the world is important then that warm and fuzzy feeling is a part of the compensation you are maximizing. In the long run no one will care, so anyone who is not maximizing compensation is probably a fool.
Big companies are actually like a conglomeration of small companies under an umbrella company. The culture is 20% upper management, 80% local management, and so your experience will differ greatly from department to department.
Bad managers exist in most companies. They can and do target people for personal reasons, and usually the targeted person doesn't have the protection or political clout to defend themselves, so they're killed off and life goes on.
I had a similar experience at Canonical of all places, which was a real drag because they were one of the few fully remote companies at the time, and I like the company.
It's always kind of amazing the level of privilege that can be displayed in HN comments.
Not everyone has the opportunities you have had. Some people actually have to struggle to climb for X reasons, and make tradeoffs to enable them to survive / grow.
Some people actually need money and can't just ignore wads of cash being thrown at them for the first time in their lives.
I personally wouldn't choose to get blackballed by every MAGMA/MAAAM if I was living in the US and taking that sort of career path. Glad some folks are making this decision.
Why are people who do this never named? They should be named. This type of behavior perpetuates because despite this employee revealing a company issue.. the individual perpetrator can still hide behind anonymity. CALL these ass holes out.
The problem is that society doesn’t really stand behind whistleblowers.
We claim to, but at the end of the day want someone else to do the standing behind them while we go back to our lives. And we don’t want whistleblowers around as we fear that we will be their next target. Whistleblowers, in their effort to restore trust, become automatically untrusted by large swaths of society.
Naming makes you persona non grata to a lot of people.
There should be a way to name these people anonymously. Maybe drop the ass holes name on blind or make a "shitbosses.com" where we name these jackasses and vote.
Anduril is hiring and if you're coming on board watch out if he's going to be your manager. He indeed PIPs you if you try to switch teams, just like this amazonian ass hole.
All we want is change in the industry. This is enough for that I believe. Your name on the internet, your employees calling you out (anonymously). It's social proof. That effects your awareness and also your future job opportunities.
Presumably Glassdoor started as a place to leave honest feedback about companies. But they had to make money somehow, and individuals aren't going to pay to access those reviews. So their customers are now the companies themselves, who can buy "employer accounts". While it still exists, their business model did a 180 degree shift.
I think if we do something similar to blind. One review per company email address it guarantees that each review is from one anonymous person in the company. This prevents smear campaigns and ensures that you get a clear and accurate picture of someone.
Regularly used ratemyprofessor back in college, years ago.
We need something like that. Rate my manager/head of engineering @ some large org. Also get a legal team ready for all the lawsuits that will come your way for whoever wants to pursue this idea. I'm all for supporting it though.
That website didn't seem to do much for bad college professors - if anything, the ones who are called out seem to consider their negative ratings a badge of honor.
I used it. It was accurate though. The website attempted to serve two purposes. To warn potential students and to allow the professors to be more self aware.
It failed on the second purpose, but at least it helped me avoid or anticipate a hard or incompetent professor.
That's a really interesting idea, it would also be interesting to set up an experiment to see if you can tell the difference between good teams and bad teams by interviewing there.
Yes definitely. Though I see mutual ass hole manager buddies leaving good reviews for each other to help bump themselves up. As long as several bad reviews are in there you'll have an idea.
2) I remember during the #metoo era there was a Google doc spreadsheet of bad men going around where people could add names anonymously.
It got to be thousands of names long, and at least a few of the men didn't deserve to be on it.
I think blind does this. But it's mostly like a forum. I don't think there's a review website that specializes in reviewing managers at companies.
Reviewers would have to register by company email of course to make sure they're legit.
>It got to be thousands of names long, and at least a few of the men didn't deserve to be on it.
I think there needs to be a voting process to make sure it's not a smear campaign generated by a small minority. If the votes cross a certain threshold all the negative reviews are revealed.
There are a lot of ass holes in the world. Not saying the post you linked to is an ass hole... but Ass holes do tend to empathize with other ass holes. I think the majority of people don't see it in the same light.
Yeah that's true. We really need some service like blind where people can anonymously review and score managers. We need votes to prove that a manager is an ass hole. One anecdotal story isn't enough.
Maybe the service leaves the manager anonymous until the review amount crosses a certain threshold... 3 to 4 guys calling him out?
So one email per company is allowed one vote. Similar to how blind allows one account per email. That prevents abuse. You don't like the guy, you can vote once because you have an email address at the company. If 3 or 4 people don't like the guy then the system assumes there is genuinely a problem with him and it reveals itself.
That means one person can't run a smear campaign. At least 2 or 3 other people have to agree with you, and if they do then it's legit. The system masks the persons negative reviews until that manager has accumulated greater than 3 or 4.
Three or four negative reviews from people in the company is NOT a minor issue.
Every employee can be reviewed! It's fair. Here's the thing though, I said you need 3 to 4 negative reviews before the entire review profile becomes public.
Each engineer has one manager, thus they have one review. The profile doesn't open up until after the engineer worked for several managers and 3 or 4 of them leave bad reviews.
It's fair. But managers are more at risk. Still this process keeps everyone in line. Don't be a jackass is the key metric here.
We are talking about people in the top 8% of the income bracket in US. Not a single engineer in Amazon that has or is getting PIPed is losing their livelihood. If you have Amazon on your resume, no matter what, you will have no issues finding another job, because the acceptance rate by itself to Amazon is <10% of all candidates, which acts as a very good filter and indicator for other companies that your more competent than a large percentage of work force there, so you automatically get a shot at an interview and likely a job offer if you are actually competent.
The biggest drawback of something like this is maybe having to wait an extra few months before buying that sweet BMW M3 that you wanted.
If anything, this kind of stuff should be viewed as games, because that's all this is. Supply/demand of labor mixed in with a few political and psychological things. The manager is not even close to being an asshole, he is just playing the game like all the employees are. Lets not pretend that the majority of people wanting to work at Amazon care enough about changing the world, they just want that MAANG salary.
Cool, basically, "I can abuse you in any way I want because I`m paying you a good money".
So, why this is shitty?
Mainly because thats inside thing, and there no way to learn it during interview.
>> Not a single engineer in Amazon that has or is getting PIPed is losing their livelihood.
>If anything, this kind of stuff should be viewed as games, because that's all this is. Supply/demand of labor mixed in with a few political and psychological things. The manager is not even close to being an asshole, he is just playing the game like all the employees are.
Firing people and putting them on PIP is just a game because amazon is such a great company to have on your resume? It's just a game because his livelihood is not effected?
What universe do you live in?
Let me tell you about how the world works. If you fire people for trying to transfer teams. If you lie and make up stories about performance because someone tried to transfer teams. You're an ass hole through and through. No one is being hated here. Just being called out, and people are expressing their extreme dislike for such behavior.
I can't believe you called it a game. This must be how ass hole managers justify their actions to themselves. It's like a bully in school calling it all a game because the person being bullied still has parents that feed him. Let's be real. It's not a game. Not. at. all.
When talking about labor management, there is a big difference in it from the perspective of someone making 40k a year with a more demanding job, where they depend on that job for basic necessities and family support, and from the perspective of SDEs that have very kushy lives with very little risk, ESPECIALLY at MAANG level.
As such, if some Amazon manager wants to fire, PIP, overload with work, or do whatever he thinks is necessary to its not imorral or makes him an asshole. An employee can just quit and find a different job quite easily and retain his kushy life.
And to be clear this works both ways - if SDEs want to avoid Amazon or share their experiences, thats all fine as well.
But to start going after personal qualities of managers because someone cant keep their 200k/year position makes you the enitlted asshole, not me.
(I didn't read the article; the page seems to be down).
A lot of these cases end up with the manager not necessarily having a lot of blame since they might not have full information on what's happening. They might also be in a similar performance crisis of their own.
If the entire company is having cultural problems and PIP horror stories are common, then the fault is from the people on the top and not from the M1 that laid out the PIP.
That's like blaming your parents for you turning out to be an ass hole. I think the manager still needs to be called out regardless and if his boss is an ass then the boss needs to be called out.
I think that will be extremely unfair to the manager who is just acting on stupid company policies. Managers have a very difficult job of walking a tight rope. Why single out one person and ruin their career?
So firing someone for trying to switch teams is company policy? I doubt it. Many managers are ass holes because that's the definition of their personality.
I feel ass holes should definitely be singled out so that they can't be managers again for the future.
(1) If the manager did PIP purely as a way to prevent team transfer, then yes I agree that it is clear bad behavior that should be punished. But I am not sure if that is the case. Say this guy was the lowest performer in the manager's team and was on track to being PIPed anyway. Should the manager now be forced to PIP someone else just because this guy is moving to another team?
(2) There are way too many PIP horror stories from Amazon. It is evident that managers even hire people just to PIP them later. In that kind of environment, such bad behavior is encouraged and normalized. Then this particular manager might not be significantly worse than any other person put in a similar position. If the culture is to blame, then scapegoating one manager will just deflect the blame.
Same thing happened to me. After 8 years working at amazon including multiple raises and promotions, I got piped. I was trying to transfer to a new team led by a new senior manager who was a peer of mine at one point. Exiting the pip requirements were vaguely defined and included tasks with dependencies I knew wouldn’t be fulfilled. So I took the 50k they offered me to leave and I left.
There are some great directors and executives at Amazon. I enjoyed my time there. There are also some toxic, toxic people with too much power and ambition.
I'm also curious about that. I'm just starting out in industry and am confused if most people are expected to do that. Do future recruiters go through your old linkedin posts for stuff like this? Or is it just a general update for their personal circle - basically the corporate version of instagram stories.
Recruiters won't even read my programming languages. I have gone to so many interviews where they didn't even check that the skills they wanted were on my resume.
It's just people being happy about something that's happened for them. Given how capricious a company like Amazon is, though, the professional speech is probably to avoid giving Amazon a different reason to complain.
It's gonna be a different situation for someone taking their first programming job out of college, and someone who's been doing it for long enough that they don't care (and would probably fire a company like Amazon before being fired themselves).
Are you not on Linkedin? This self-aggrandizing cringe is 95% of the content in the feed, I'm always amazed people can write this with a straight face.
After grinding leetcode for months, and going through 4 interviews, you feel like you’ve “finally made it” which is why people post cringey posts like that.
Because they've finally transformed themselves into the husk of a human and are now ready for their new soul crushing dev role at Amazon? More seriously most linkedin posts I see are recruiters feeling sorry for themselves despite their bad behavior and looking for social support because of their plight.
It’s normalized on the platform because that’s how people higher up the food chain speak like. Eg when a VP switches companies. Most of the time these things are written by a PR person to be as grateful and inoffensive as possible. But then it caught on because everyone loves to humblebrag.
True. Reminds me of the time stackoverflow had hired someone for "developer relations". I think the title was "VP", and the recruit was described as "a veteran story-teller". Now having a VP send emails to developers is already a bit of stretch, and why you'd need someone at the level of Hans Christian Andersen to do so is anybody's guess, but the press release started: "We're beyond excited to ...". Was the CEO really yapping around the office, drooling from the mouth, barely controlling his bladder out of joy over this new hire? So yes, hyperbole just seems not to cut it any longer, and the answer is going into overdrive.
Exaggeration, trying too hard to sound smart, and ugly euphemism are all hallmarks of business language. That's why it's so gross when it leaks into real life.
I guess linkedin has a different vibe over here. I've seen some self-congratulatory and groveling posts, but nowhere near this level of influencer-style humblebragging.
The second post in your second link is shocking too:
> One night, when I was a dev manager at Amazon, another dev manager in Seattle sent me a 20-page design document at 11:30 pm and told me that he wanted me to get him feedback by 5:30 am the next day.
How fucking rude is that? It’s indicative of an absolutely staggering level of toxicity.
Honestly, what a waste. Imagine how much better Amazon could be if they didn’t treat their staff like cattle.
fair. just to clarify though - i find the expectation to be always online / checking work email at all hours also a sign of a toxic workplace. definitely could have phrased my original comment better.
That’s when you CC (don’t BCC, you want them to know) yours and theirs managers on the email that says that says plainly, “If you expected this to be done by 5:30 am, you should have sent two days before. Perhaps this can help you be more efficient with your time.” and include a link to a YouTube — or better yet, an internal training video — on effective time management or setting deadlines.
Seriously. You publicly stick the knife in for this shit.
And I wouldn't be surprised if that Seattle dev manager got pressured from above themselves. But at some point, someone has to set boundaries. If that manager then got pissy about it not being finished, there's a few lines to be used. One is "I was asleep". Another is "Night shifts and overtime are not in my contract", or "I do not get paid enough to do night shifts".
And another one, "A lack of planning on your part does not necessitate an emergency on mine".
But here's what I think is going on: Amazon's higher-ups (the level(s) above these people) are intentionally making these managers put pressure on each other to keep them overworked and sedate. I feel like this is the case for a LOT of US work culture across a lot of areas. It applies to low wage jobs with a high chance of being fired as well. Keep people stressed about the short term and they won't have the headspace to worry about things outside of their sphere of influence. This allows the rich to get richer and the politicians to become more powerful (and incompetent).
Honestly, in some orgs in my company "I was asleep" would be the only acceptable answer. All the others would put you on a path of getting fired. If the whole org operates like this, no one cares about your witty remarks.
If you really don't want to work like this (and I don't), have a 1:1 with the manager, discuss boundaries, and if you can't come to an agreement, change teams or jobs.
And better yet, ask these during the interview! One question I often asked:
"In my current job, I typically leave my laptop at work when I leave at 5-6pm (unless there's a genuine ongoing emergency). Would that work in this role?"
Maybe said manager used to be a banker? Would certainly explain the casual attitude towards dropping docs at 1130PM, and demanding feedback 6 hours later.
We get paid to do a job. And sometimes that requires odd things like helping out with urgent problems at odd times. At that point it really is too-"fucking"-late (too borrow your crassness) to complain about project planning, politeness and schedules because everyone involved already knows those failed.
If it was me asking for feedback, I wouldn't have sent it if I wasn't in a pickle that I probably had no control over. Okay, so you didn't read the mail and you only get to it the next day at 8 when your working hours started, cool leave it at that.
His post 5 months after joining was a repost of someone criticizing Amazon. And then he ended up getting PIPed recently. His linked profile is all over the place too with work experience, he never held a job longer than 4 months.
Dunno if I would automatically side with his story from that.
The Full stack developer and ML engineer seem like full positions, considering he listed internships specifically in his prior experience as explicit internships.
Also he has a background in bio, and managed to land a full stack and ML engineer positions, implying he is self taught, and therefore should be already fairly intelligent...but he decided to go get his MS in CS, without even doing any research project and just opting for the GTA instead of GRA route.
None of us can really know for sure, Im just saying it smells a little fishy. If his resume came across my desk, Id have some specific questions about his experience. If you are that smart to have a background in bio, and land the jobs that he did, your career would look very different.
> If you are that smart to have a background in bio, and land the jobs that he did, your career would look very different.
Is that really so impressive? Bio people do a lot of coding, and good dev practices can be learned on the job. ML is probably also something he played with during his studies. Full stack + some ML experience is probably enough for a junior ML engineer.
During his studies and very early career? That's completely normal and I don't understand why more people don't do it.
Studies don't give you any idea of what a job is actually like. They also don't give you a reliable indication that you'll like a field. Choosing bio out of high school, then moving to CS for any reason, then trying a few jobs using these skills is a normal and healthy way of searching for a job he really likes.
I don't have an MSc (just something similar) but I have no idea what GTA and GRA means in this context. Also none of my CS BSc+MSc friends ever mentioned a research project (or do you mean the thesis?) Also I haven't seen where the person in the original post was studying, but this might be kinda different per country?
> but he decided to go get his MS in CS, without even doing any research project and just opting for the GTA instead of GRA route.
This is pettiness taken to the max.
Most research people do in grad school will not have applicable use to employers. And for an MS, people will simply learn more by going the coursework route. Going the research route is good only for PhD admissions.
And finally, many universities in the US do not even offer a research route for the CS MS. They tell you to apply straight for a PhD.
If you're going to ask tough questions, at least know your domain!
> if I submited 51k lines of code in January and my whole team submitted 68k, do not call me a "Least Effective".
Hmm, I think I've known this type of fuckabout whose massive submissions totally screw any hope of team cohesiveness and trust. Ok, slugger you can write shitloads of lines of code. Is it any good? Why would I want that much code when a factor of 10 less is more manageable?
I'm a data person so I haven't cut any big code with Python, but the package management issues I have had have gone away with conda virtual environments.
well, pip will happily brick your system if you let it on many Linux distros. Or at least it used to... I don't trust it enough to use it outside a virtualenv.
I'm from China, I've had only good experiences with Indians. Most of the people I would deem as ass hole level on the scale of Ganesh were in fact white.
It would be idealistic to think that all races have an equal portion of ass holes though. I will say that a large portion of SDM's are Indian so your sample is indeed biased.
One reason might be that Indian managers are sometimes ass holes to Indian subordinates in particular, maybe because they are aware that Indians are stuck in perpetual H1B status so they can be abused.
There are bad managers from all regions and races. On blind they were asking if it was an Indian. It does not matter if it was Indian or not. It only matters that it is an "Amazon" manager.
There are pretty terrible managers from all races tbh. You tend to have a lot more Indians in tech so it’s statistically more likely you’re gonna run into quite a few bad ones.
Or maybe because they are immigrants the stakes are higher for them? If they lose the job they may lose visa, so they higher tolerance for BS from management.
Or maybe grow up in a culture that value respect more, so you are biased against questioning the authority.
Or maybe this story is inaccurate/made up. He was put on PIP and requested a transfer at the same time.
Or maybe it's a peter principle at play.
Anyway, I don't think it's fair to post someone's linkedin like that.
(dare I ask what a dev plan (pip) is?) quick google check...
Development plan is a regular plan which you do with your manager, where you are focusing on your career progress. You focus on your strengths and weaknesses. Based on this plan you will get tasks which will utilize skills you are good at and also help you to improve skills you want to have improved.
PIP is a plan which is assigned to employees with unsatisfactory results. It's a few months long plan where you got assigned some tasks you should complete. If you are not able to complete them in time, you are fired.
Performance improvement plan. Either a manager writes a plan of measurable goals focused on improving, or a manager and the target employee both work on the plan together. It can be used for actual performance improvement or it can be used as something the employee cannot meet as a way to fire them or get them to a different team.
You would be nuts to treat it as anything other than loading the bullet into the gun that terminates you. All it is is to make sure that the bullet is legal.
I suspect it's partially a way to protect from lawsuits so it's difficult to file a suit you were fired for idk, your religious views, refusing romantic advances, refused to do something illegal etc. etc.
While the US has been traditionally fire at will, over the latter half of the 20th century exceptions had to be made where you can’t fire people for various discriminatory things or becoming a parent anymore. In the early 20th century organisations also couldn’t fire people for unionizing anymore. And not all unions accept fire at will policy.
Companies may additionally prefer to have more standardized procedures. Hiring is expensive, training is expensive, and cohesion can only be gained over a long time. By needing multiple steps to fire someone you reduce the chance you throw the baby out with the bathwater. And even if you’re sure someone is a negative factor and want to fire them with little prior notice, the people who you think are good are not mind readers and might even have a different opinion of their colleague and will question their own employment security.
You should try to consider it from the company's perspective as well-- hiring an engineer is very expensive, takes a long time, and any new engineer has takes time before they can start to fully contribute to a codebase.
If you're a manager in a situation where an employee has a problem and aren't meeting the job requirements, you'd probably much rather that they fix the problem and contribute to the team than fire them.
That doesn't mean that all of these plans are done in good faith, or that some managers aren't terrible. And for an employee on a PIP, they should think hard about leaving the company (or at least the team); it'll be better for their career.
But I don't think one can say that it's nothing more than a legal way to fire someone (especially since you can fire someone in most states in the US without cause, and spurious allegations of racial or other discrimination would need documentation that would be hard to produce if it didn't actually happen).
Whilst I think you are right, being put on a PiP should still be seen as a big warning. Especially since there are many ways to help someone improve in performance. There is little need for formalization in a benign pip. The main reason a pip is formalized is to prepare for firing.
I don't think being put on a pip means firing is certain and imminent. I do think being put on a pip means firing is on the table and a serious threat. In that sense the analogy of 'putting a bullet in the chamber' is accurate if maybe a bit strong.
Pip is to create document trail (so when they get sued they can show evidence ) and to force people into submission and resignation. So this way they can handle things quietly and dirty things kept undercover.
> that they fix the problem and contribute to the team than fire them.
> And for an employee on a PIP, they should think hard about leaving the company (or at least the team); it'll be better for their career.
Considering both of these statements, a PIP is never the right answer if your objective is legitimate performance improvement.
Even if you're an unexperienced (or outright stupid) manager that doesn't understand this and wants to use a PIP as a legitimate performance improvement tool, the target employee is never going to be on good terms with you or your company and it's very unlikely you'll actually get the desired results. If you do, it's only because the employee has literally no choice but that loyalty will be out the window as soon as he is in a better position to make a move.
Companies don't treat engineers as expensive to hire or difficult to hire in any other context (beyond complaining about it)), so I am extremely skeptical that they do here.
I think there are exceptions to this. At my last full-time role I was PIP-ed, and if I'm being completely honest, it wasn't undeserved. I had been burnt out for 2-3 years, had tried to quit 2 years prior but they offered me a 10% raise to stay
Honestly, I should have still quit, because it was burn-out over the role rather than compensation-related. But I stayed, and slacked a lot. Tracked my hours towards the end and I might get 12 actual hours of work done some weeks, including meetings. Still got most of my work done, but often with delays. It wasn't a perfect job, but the team was great and I liked the company culture.
My manager was very clear with me when I was PIPed that he really wanted us to work together to get me back on track. HR wouldn't consider letting me work part-time despite multiple conversations (it went against the company policy, and other people would start asking for it), but he tried to convince me to take paid time off instead. I decided to quit anyway, because I figured I was done spending most of my day configuring automated test pipelines and wanted to spend more time writing code that wasn't bash.
When I put in my notice, the manager tried to convince me to stay again, said they really wanted me just on track, and reiterated again that up to 4 months of paid leave was an option. Seemed really forlorn about the situation during the exit interview.
I honestly believe I could have worked my way out of the PIP, and the management would have preferred that outcome. Employing me at my current level of performance wasn't delivering the value they were paying for though, and quitting was ultimately the best situation for everyone involved.
It’s how you fire people in tech companies. You put them on a PiP, give them some tasks to do and then fire them when they don’t deliver. Obviously nobody survives the PiP because for an engineer not on a pip, taking 9 weeks on an 8 week project is pretty good, but on a pip 9 weeks for an 8 week project is a failure to deliver and you’re out. Obviously this is evil bullshit, but I’ve been in this industry for a very long time and this is what seems to happen.
> Obviously nobody survives the PiP because for an engineer not on a pip
I can't speak for other companies but I work at Google and I've met several people over the years who've confided with me that they've been on PIP (either in the past or at the moment when talking to me). While (thankfully) I haven't been on PIP myself (yet!) so I can't speak from personal direct experience, I can confidently say that all the people I know personally that were on PIP have successfully re-focused their career, haven't gotten fired, and are still working at the company years later.
Obviously it might be survivorship bias and I might simply not be meeting those that do not succeed, but at least I can confidently say that being put on PIP itself is not necessarily just an excuse to get you fired.
It was a bit of a blanket statement from me, I’m sure people do survive in good companies, but this is a genuine observation. I’ve never been anywhere near the bottom of the ranking. So I have, over the years, been dragged into a lot of conversations about the people who do end up at the bottom. I’ve heard “Don’t worry, we’ll PiP them out” more than once.
I worked with several people at Amazon that were on a PIP and were able to move past it. (They were also people that were both talented enough to be successful in their roles, but needed a nudge because they were not meeting expectations at the time.)
I think we generally do not hear about the cases where a PIP was used and the employee was genuinely not meeting expectations, or when a PIP was used and the employee course corrected and went on to have a successful career.
That's not how you fire people in tech companies. Not all tech companies are Faang/American. I've been working in several "tech companies" in Europe and it was not a thing. Let's not normalise this awful, inhuman process like there is no other alternative.
I think it it depends on the company and manager. I got a PIP once (at a FAANG, in the US), and it really felt like my manager had put a lot of effort into designing something that was achievable and customized to my situation. "Passing" the PIP would have required only a slight ramping up of my admittedly very low performance at the time.
My manager either wanted me to start doing my job again, or leave and create a space on the team for someone who would. He seemed slightly biased in favor of keeping me on the team. It didn't seem like a fun situation for him to deal with at all.
I ended up leaving, but it's because I was disengaged and didn't see a way out of it. (And I had great offers elsewhere.) Not because my manager was being abusive.
As much as I feel sorry for this person and their experience, it seems to me this wasn't the best way to handle this situation.
It would have been more pragmatic to fire up leetcode, take a few interviews, and leave the job professionally. This probably would have come with a small pay bump, even with this persons limited professional experience.
Maybe I'm just lucky and I've never had a bad experience like this, but I couldn't see myself posting something like this professionally.
I get where you're coming from. But I have to tell you, even though both you and I would never hire (I'm not a technically a "never hire", but definitely less likely) this guy has balls of steel and speaks his mind and the truth.
I "won't hire" him for selfish reasons, but this guy is a patriot and speaks out against bully's. I hate to admit it, but people like us perpetuate the behavior.
I wasn't suggesting anyone should "just be quiet", in fact, I'm happy this person was able to express themselves and their situation openly on LinkedIn.
My point was simply this wasn't a very pragmatic approach to handling the situation. Some employers may not like to see this type of content on their professional profile and it may hurt their career.
That's what majority of the people think and do, those who find themselves in the similar situations and that's how companies like Amazon can continue doing this shady practices.
Guys, what do you think of a ratemyprofessors.com for bosses at companies? Optional anonymous reviews and to be fair and balanced the boss can respond to each review.
That way people can do what jiawei did but without the risk of professional self harm.
Nah but the resolution there is company wide. I'm talking about a service that reviews individuals. Plenty of bad people in otherwise great companies.
The point of the review in my idea is not just to inform potential candidates, but to push individual managers to become better. When your actions have real consequences towards your reputation then you will be mindful of your actions.
Glassdoor is filled with Spam from fake accounts and smurfs though. I knew for a fact that a company I worked for had people monitoring their Glassdoor page, with the recruiting team being given the task of Smurfing some good reviews.
Blind is pretty great but probably overly cynical. It’s not been “discovered” just yet.
The reason this kind of bullshit continues to happen is because nobody calls it out. Calling it out and shaming it publicly is the only way to eventually resolve this problem.
Someone in a position of relative power (being able to quit and publicly call out their employer) calling it out also makes the situation better for those that may not be able to afford that risk.
I feel for the guy—taking the post at face value, it sounds like he had a shitty team and a shitty manager. At the same time, this post does not make me want to hire him and in fact quite the opposite. He seems to be fairly junior, but even at that level I cringe at measuring ones self in terms of lines of code written (though lines of code deleted is a metric I can get behind).
He's the hero we don't deserve. Nobody wants to hire him because every manager is sort of afraid they themselves are sort of ass holes and will get called out. I think a good number of people who think this are right on themselves being ass holes.
His job history agrees with you. It has been less than 2 years since he graduated, in which he has held 4 jobs. 3 months at his first job, then 4 months, 5 months and 10 months at Amazon.
I would not take his given statement at face value.
Agreed, from my personal experience, I think the criticisms of Amazon are valid. But at the same time, if you have switched jobs 3 times in 18 months, you need to do some research and take some time to understand that you have a responsibility to find a job that is a good fit for you. If you think lines of code is the most important metric in how good someone is as a developer, then great, look for a job where management feels the same way.
His profile said he graduated in 2021. He joined Amazon in May 2021. 5 months was a teaching assistant at his university. 4 months was the right months for a summer internship.
People usually call those internships but he's gone and described them as full jobs. Unfortunate. The timing lines up for a winter and then summer internship / coop role.
So you need to be an experienced dev to speak up against a toxic work environment? I do also cringe when I see comments like yours attacking the guy for doing something you wouldn't do. He probably mentioned the amount of lines of codes as a way of saying he did put a lot of effort(is common knowledge that on itself is a shitty metric). Maybe he, also wouldn't want to be hired by someone like you either, not would I.
I'm not saying he shouldn't speak up against a toxic work environment. I'm saying he's doing it on LinkedIn in a way that makes him look bad and could hurt his future career prospects.
Amazon is well known for training employees to defend the company on-line. Aren't you being too generous with an anonymous comment that you provide no link to? Is not possible that is just Amazon propaganda?
90% of the point of blind is to shit on your own company anonymously (at least, that's what I use it for). I find it hard to believe that it's false, given that probably hundreds of amazon employees have seen that post and no one's refuted it.
If Amazon is astroturfing blind, they're doing a spectacularly bad job at it, the general consensus (from Amazon employees even) is that it's a hellhole compared to its peers.
"After years of ridicule and harsh press coverage, Amazon has finally disbanded its Twitter army. Part of a perplexing guerrilla PR campaign, the Amazon FC Ambassadors were a group of Twitter accounts belonging to employees who were paid to respond to posts criticizing the company." https://slate.com/technology/2022/01/amazon-fc-ambassadors-t...
Let's assume that it's 100% true. This guy is young and it'd be better for him to delete this. I'm totally going to cyberstalk this guy to see where he goes.
My number one rule is not to sh*t on former companies with my main account.
> I'm totally going to cyberstalk this guy to see where he goes.
That is a felony in many places in the world. Companies do this kind of harassing, thou. That is one of the reasons that companies need to be taxed way more and use that money to assure that people that lose their jobs can still live a decent life.
There only way citizens well have freedom of speech is if they are not at the mercy of corporations.
Not sure there's enough context here to make a judgement. 24 change requests in a year seems okay? How complex were they? 50% no-approval sounds ok if he was the sole maintainer of a particular part of the code/etc.
Maybe someone who's knowledgeable with the development of CDKs can shed some light on how reasonable those numbers are.
Will Ye
Will Ye
Engineering @ Cohere (cohere.io)
5mo
Back when I worked at Amazon as a software engineer, the CRAZIEST thing happened to me. Here’s the story…
I was working from home with my girlfriend (at the time), when suddenly I get an urgent ping from my coworker: “Our service is experiencing a SEV 2! We need all hands on deck!” Uh oh, our team’s application has gone down!
However, as I scrambled to figure out how to fix the issue, I smelled something burning from another room and heard a fire alarm go off. “Will! There’s a fire! Help!” I heard my girlfriend shout. Now I was stuck in a conundrum — restore a critical Amazon service, or put out the fire in my apartment?
It was at that time I remembered Amazon’s famous leadership principle “Customer Obsession”. There are customers who depend on my team’s application — I can’t let them down! So I ignored the fire and my girlfriend’s pleas, and started debugging the production issue.
But all of a sudden, the smoke in my apartment cleared and the fire alarm fell silent. My girlfriend walked into the room, and to my astonishment, peeled off a wig and revealed herself to be Jeff Bezos himself! “I’m proud of you for being obsessed with our customers,” he said, and gave me a $5 Amazon gift card. He then leaped out of my window and hopped into a waiting Amazon Prime delivery van that quickly peeled away.
Even though I no longer work at Amazon, I’m so grateful for these experiences that taught me lessons I’ll never forget. Agree?
I like that we've come to a point where people are shitposting on LinkedIn as a counter-point to these insipid:
> "TODAY I interviewed a SINGLE mom that had her BABY on her lap and apologized when it started crying. I gave her the JOB on the spot because motherhood is HARD. Let's all give single mom a break and be more human in the process! :clap: :clap:"
I've unfollowed so many people at this point because I use it as an address book for coworkers and recruiters and these virtue signalling posts are not even trying to look human.
Keep in mind the only people using LinkedIn as anything other than "resume holder" or "mediocre job board" are also the type of people to think "Agree?" is some sort of enlightening prompt.
it's a marketing hack, LinkedIn's algorithm boosts posts with lots of comments and engagement. So people post those artificial questions at the end which are basically preaching to the choir
the fact people actually fall for it is depressing
> “Customer Obsession”. There are customers who depend on my team’s application — I can’t let them down!
That is also:
- Success and Scale Bring Broad Responsibility (We must begin each day with a determination to make better, do better, and be better for our customers)
- Deliver Results (Despite setbacks, they rise to the occasion and never settle)
- Bias for Action (We value calculated risk taking)
- Think Big (They think differently and look around corners for ways to serve customers)
- Are Right, A Lot (They have strong judgment and good instincts)
- Ownership (They never say "that's not my job")
- Dive Deep (No task is beneath them)
Clearly, Will Ye Will Ye is operating at an Amazon final-stage boss level, if only they knew [0]!
Don't blame the leadership, as apparently this is exactly what they need to be doing: To paraphrase [High Output Management], the job of an executive is: to define and enforce culture and values for their whole organization, and to ratify good decisions.
Lmao this is great because on my "virtual on-site" final round of interviews at Amazon, the fire alarm of the person who was interviewing me went off. She switched to audio on the call and continued to try to work through the little coding challenge as she was shouting implementation details above the echo-y wails of a fire alarm raging in a crowded stairwell. Baffled, concerned for her safety and bewildered by her priorities, I hung up and pretended the call had dropped. No offer. No interest
My apartments fire alarm went off during my virtual on-site with Amazon too. There was about 10 minutes left and the interviewer said I should go and he had what he needed. Got an offer the next day!
Exactly. I’ve been here for two years, not a long time by any means, and I don’t personally know a single instance of anyone getting pipped.
I’ve never felt pressured to work overtime, haven’t had to race to meet an unreasonable deadline, and I’ve been rated exceeds on both of the performance evals I’ve been though.
The Amazon I’ve experienced is much different than the one I read about before joining.
So, here's an interesting question: I recently got an email from a recruiter for Amazon saying I could interview for whatever org and whatever team I wanted. What are some sane, reasonable teams? Which teams are the most insane and unreasonable?
There is no easy way to answer this question. The best you can do is talk to people working on that group and ask the question. However, even with this knowledge there is no guarantee, because Amazon is always changing and doing reorgs, so what is a great group today can become a nightmare tomorrow.
It can be drastically different from team to team.
After I joined Amazon in 2007, I referred a friend from Uni who joined a few years later.
I had a fairly laid back experience - after a good start, I became depressed and burned out, but somehow none of my managers seemed to care all that much since I was at least getting some stuff done, until I finally got put on a PIP several years in - which I think was probably deserved, although the handling around it was crap. And even then, when that manager moved to a new team, my new manager told me I was doing fine and not to worry about it.
My friend, on the other hand, who was the most diligent and hard working of my entire friends group in Uni, was assigned to a different team a few desks over. She fell afoul of stack ranking (the idea that you should rank everybody in a team and fire the worst) and was pressured until she quit.
I also heard a bunch of horror stories from devs across the company - unreasonable deadlines, regular Sev-2s and firefighting when on-call, a manager evading blame for a disastrous project launch and dropping it all on one engineer.
I think the main problem that I saw was that there wasn't much training for managers on how to be a good manager, and bad managers never seemed to face consequences.
I finally quit after eight years (funnily enough, after ending up working for the manager who made my friend quit) and I'm a hell of a lot happier nowadays. Amusingly, I'm still facing tight deadlines and sometimes random overtime, but I have a great boss who is willing to fight against these things for me, and that makes a big difference.
Assuming it was a fire drill -- back in the olden times before the new normal, when I worked at the office, fire drills were mandatory exercises. That's the whole point of them: you don't get to ignore them. We were always told in no unclear terms that we were expected to take part in the drill, no exceptions, and people even got told off if they took the time to shut down their computers or go back for backpacks or whatever, because "in a real fire there's no time for that".
I suppose people working in critical positions were cut some slack. I can't imagine doing interviews is one of those positions.
As it happens, many years ago I worked for Amazon and encountered a small microwave fire in the break room. I dealt with it myself, but I realized I had no idea what the appropriate way to notify somebody about a fire. I inquired and discovered that in the event of a fire, the correct behavior would have been to return to my desk and file a Sev-2 incident with the Facilities team. This should in theory page someone who could respond to the building being on fire. I asked if they meant Sev-1, but they said Sev-1 would be reserved for a fire that was impacting website traffic.
If anyone's curious, the correct response to a fire, presuming you couldn't immediately extinguish it, is to pull the fire alarm and evacuate the building.
And in case anyone thought this was an isolated incident, I have heard from 3 different people about this happening to them. As soon as they try to transfer they get put on a PIP.
Some people meet this with a healthy level of scepticism, which is great. However I used to work at Amazon, working on the performance evaluation and HR tools used within the company. It was a couple of years back, but I am fairly certain that the same tools are still used, given that all of them were developed from scratch. At the time it was in line with the company's PR of removing its toxic work culture.
It's worth mentioning that it wasn't uncommon for people to move around teams, and to be honest HR is not the most exciting field for software development anyways. So, as expected, the HR dev teams had people move around quite a bit. Nothing toxic so far.
One of the projects I worked on was what used to be called the dev list or personal improvement plan (pip) now renamed to Pivot. Most likely the exact same same tool. Management wanted to update the processes in order to automate as much as possible and reduce the risk of managers putting someone in pip, just because they didn't like them. However the process was set up in such a way that a manager can progress an employee through a pip for waaaay too long, until a failsafe, or a second pair of eyes even takes a look at it. I, personally, voiced my concerns about it, but it was shrugged off as "it shouldn't happen", "managers wouldn't do that" and "it's fine" by the project stakeholders.
The project starts, development is going a usual and a couple of years go by. I moved to another project within the HR space. Most of the team developing the tool has also moved on to greener pastures. Apart from that one guy, who has been there since its inception. He went from being a backend engineer, learning React and painstakingly working on a messy frontend codebase, eventually leaving him the only person competent enough to make changes to it. Eventually he was fed up and wanted to move to a different team. Lo and behold - his manager, the manager of the team building the pip tool, put him in pip to prevent him from moving. Haven't seen someone decide and actually leave a company as quickly as he did. So if the manager of the pip company can use it to blackmail people not to leave, I can't even imagine what it's like for the rest of the company.
Some people meet this with a healthy level of scepticism, which is great.
However I used to work at Amazon, working on the performance evaluation and HR tools used within the company.
It was a couple of years back, but I am fairly certain that the same tools are still used, given that all of them were developed from scratch.
At the time it was in line with the company's PR of removing its toxic work culture.
It's worth mentioning that it wasn't uncommon for people to move around teams, and to be honest HR is not the most exciting field for software development anyways.
So, as expected, the HR dev teams had people move around quite a bit.
Nothing toxic so far.
One of the projects I worked on was what used to be called the dev list or personal improvement plan (pip) now renamed to Pivot. Most likely the exact same same tool.
Management wanted to update the processes in order to automate as much as possible and reduce the risk of managers putting someone in pip, just because they didn't like them.
However the process was set up in such a way that a manager can progress an employee through a pip for waaaay too long, until a failsafe, or a second pair of eyes even takes a look at it.
I, personally, voiced my concerns about it, but it was shrugged off as "it shouldn't happen", "managers wouldn't do that" and "it's fine" by the project stakeholders.
The project starts, development is going a usual and a couple of years go by.
I moved to another project within the HR space.
Most of the team developing the tool has also moved on to greener pastures.
Apart from that one guy, who has been there since its inception.
He went from being a backend engineer, learning React and painstakingly working on a messy frontend codebase, eventually leaving him the only person competent enough to make changes to it.
Eventually he was fed up and wanted to move to a different team. Lo and behold - his manager, the manager of the team building the pip tool, put him in pip to prevent him from moving.
Haven't seen someone decide and actually leave a company as quickly as he did.
So if the manager of the pip company can use it to blackmail people not to leave, I can't even imagine what it's like for the rest of the company.
That was a very readable comment. I'm reminded of the times I've posted here about "If it's 3 paragraphs or longer, my coworkers won't read it" only to get responses like "Must be poor writing on your part!"
It looks totally fine on a monitor, but because of the narrow width on cell phone displays, a paragraph can extend beyond the display's height, and it psychologically has an impact on people.
I really didn't think the "linkedin-style spacing" was necessary. The OP was not exactly short, but had a good enough sense of spacing and used paragraph breaks appropriately.
Had a similar experience where I tried to switch to another team. But wasn't able to move because I missed expectations the prior year or something along those lines. Was never put on pip, but I left 2 months later. Team had horrible 50%+ attrition that year.
“ eventually leaving him the only person competent enough to make changes to it”
erm, this makes it sound like he was a not a very good engineer. Your code should always be written so that if you get hit by a bus one day, the rest of your team could pick right up where you left off
Unfortunately this is a quite common scenario in big enterprises, such as Amazon, Google and the lot. Main reason is the promotion process.
Usually you need to gather evidence that you've contributed significantly to a project. And the easiest way to do that is to work on new projects. Maintaining an existing codebase is usually a thankless job, which is also hard to get you promoted.
And once the new project is released it eventually gets abandoned and people move to the next one, which would help them get promoted. Think of all the Google projects that have been discontinued, which were also a product of similar processes.
770 comments
[ 2.9 ms ] story [ 400 ms ] threadFuck you bezos!
I ended up switching teams and had a decent time at the company, but the nightmare situations are very real. You are replaceable and there’s no mercy
In the past, I thought of putting myself in positions like these to increase my understanding in short time, at the short term expense of personal life. I wonder if that's just a stupid thought that leads to nothing but burnout, or actually a viable short-term strategy to get up to speed with some of the tech stack you know but haven't really used in prod at the scale of Amazon.
Nowadays, I have health issues (go figure) so it's off the table and all I can do is wonder :).
People like to talk about how great a teacher failure is, and how it teaches you valuable lessons... and it's true! Failure does teach you lots of valuable things, including things that you don't learn by succeeding. However, succeeding at something challenging generally teaches you more.
Or to cast it in ML terms... you need examples of both success and failure in your data set, but the "success" data points are more valuable.
This is the normal approach. You are experienced and wise now.
I kinda agree with the OP, I would have a lot of trust issues with management if they pulled this shit on me.
You should have trust issues with "management" in any corporation because these people have the interest of the shareholders at heart, not of the workers. It's just sad some of us have to go through a traumatic burnout to learn this lesson.
Of course, what i said doesn't apply in a self-organized workers cooperatives where management is the workers.
The shareholders try to build a social control structure that aligns these, but it never fully succeeds.
Hunter gatherer survivalist genes just kick in.
YMMV, but I consider it a healthy thing for, at least for some part of your career, to work "Amazon hard." Aka, all the reasons that people list when they say you should really try working for a startup.
When you push yourself to your limits at your profession, a lot of stuff clicks into place and you learn so much.
You can't procrastinate, you can't do it wrong, there just isn't the time.
Maybe a cynical take, but if you’re pushing limits then you’re probably just learning the right corners to cut, shortcuts to take, and how to exploit/manipulate people to get what you want fast. If you didn’t learn any of that, then—well, someone else just learned all that at your expense and you’re setting yourself up to just be exploited again and again.
> there just isn't the time
Yeah, that’s the root cause. Why is there no time? Is someone’s life on the line for this deadline or is it just that the manager is eyeing a sweet bonus for delivering early. 99.9% of the time it’s the latter. So why learn how to get manipulated? Learning to work at a consistent pace is far more sustainable. Tortoise and the hare.
Working at such a rhythm helped me learn much. It also durably damaged my body (both because it chipped away at my health and because it made me forego health check-up), my mental health, and made me lose personal connections. To this day, I'm still picking up the pieces.
Human beings are also "designed" to survive long period of hunger if need be, but no one would argue that going without for a week is a fine and healthy way to lose weight.
I guess I should say the healthy thing to do is to work at 100% of your capacity, whilst going to bed at 9pm and doing 25 minutes of exercise every morning?
The only thing worth working 120% for is raising your newborn child. Or maybe making a civilization-altering breakthrough in the natural sciences, like Fusion energy.
Everything is simply 'meh' in comparison and not worth sacrificing your health for. And I say this as a person who doesn't even particularly like or want kids.
And like any great, secure, lasting and stable engineering giving you the knowledge and time is key here.
When a company overloads the safety officer with tasks, so they and up not being able to do their work propperly and an incident happens, the company is at fault because it failed to provide the officer with the resources needed for the job.
If they don't give a dev the resources to do their job it is not different in my eyes. The fact that there might be some magical dev who would be able to get something working out of the same circumstances doesn't matter — maybe it has a company crippling flaw in it because of all the haste.
It's a crazy approach that probably falls apart if you're unsuccessful. But they're very successful so they can just keep burning money to attract new hires. Also, I imagine it's a huge career builder if you work in FMCG or development to have "Amazon retail" or "Amazon Web Services" on your resume. Since everyone uses those platforms.
I imagine what is left at the end is a residue of "born again" workaholics, who're probably pretty great at their jobs. Who then ascend to and form middle management.
And the global express trundles on, powered by these workaholics.
Then again, I keep interviewing people with 5-10 years of experience, who will go something like this:
> How would you manage a server? (leaving out a ton of context about what it means to "manage a server")
> Very easy, SSH connection is very fast, reliable, ...
> Awesome, love me some SSH, how about 5 servers?
> Hmm, probably write shell scripts.
> How about 50 servers?
> Shell scripts?
> Even with 500 servers?
> Hire more people..?
And I keep feeling that these people don't have 10 YoE, they have 1-2 YoE times some coefficient.
I feel like if you're in a "successful rut", that's what it will do to you. You feel like you're successful, but in fact, you have fallen horribly behind, without even knowing it.
Your quality of life is probably fine, until you're laid off one day.
Some people get complacent once they get a job and stop learning. The trick is to keep on learning. I have worked for a company like Amazon with aggressive schedules where we used to work for 12 hrs/day. One time I didnt go home for 3 days. I can say I learnt a lot, but there are better companies with mature planning where you would still learn the same amount.
How different ppl react to toxic environments is also different. Some people may thrive, while some may wither.
I say it is a random walk searching for the best place (for you) to work. You keep iterating until you find what you want.
They ask for a VM or a DB to the DevOps / SRE team, wait a bit days and get a URL. If a team uses CI/CD and K8s, they will write a yaml file from a template, wait a few minutes and app will be deployed.
Not sure what answer you expect here? Just because you have 10 years of experience doesn’t mean you’ve ever worked with more than 25 servers at a time (at least I haven’t).
I consider it a source of pride, I think. You absolutely don’t need mega scale for most things (or maybe mega scale, but still not many servers)
I recently came off a project that was technically using "GitOps" but where every deployment involved copying and pasting dozens of files across 3 or 4 repos, and the whole thing was very error prone, and if you didn't change exactly the right things your service would just silently fail to deploy, or be unreachable, with zero feedback.
I've worked at a company with a bespoke CI/CD system hacked together with PHP scripts and Jenkins servers, but where every single process was ruthlessly automated, reversible, with multiple layers of fallback, failure recovery, garrulous feedback, and built-in approvals that you could automate, or if you didn't remember, you'd get a helpful reminder in email and a link to a page to fill in the required information. People could, and did, know how to do a deployment on it their first or second day.
Guess which one was more pleasant to deploy with?
It's the automation mindset that's important. You can find people with the right mindset who haven't had a chance yet to play with ansible or terraform, and you can find people who manage to create nightmarish complexities of manual processes out of ansible and terraform. Unfortunately, I haven't yet found this to correlate much with years of experience.
The last 1.5 of those I worked with what I consider two amazingly brilliant a####les.
I ended up leaving the most amazing place I had ever worked at until then (worldwide traveling, learning new stuff, actual high performance systems).
It has taken years to recover and I still cover myself more than I should.
My boss (who I liked) tried to get me back twice after he realized I had not been the problem and the two others had left but by then my salary had increased so much I was out of reach for him (edit:,) and telling my family I'd go down a double digit percentage in salary to work for someone who had not stood up for me back the was out of the question.
And yes, I've been a manager in a company where the phrase "managed out of the business" was used. I no longer work there.
Basically the higher-ups have to decide what is most important; if the deadline is fixed, then the scope HAS TO BE flexible.
tl;dr; everything in a large corporation is a game of telephone where everyone is incentivized to muddle the message. So any deadline/commitment handed through multiple levels of management is really difficult to negotiate. And the more unrealistic it is, the harder it is the negotiate. Nobody wants to tell their boss that the thing they want done in 3 months will actually take 2 years.
I mean I don't want to do any project with a deadline, ever again, if possible, and I haven't even been exposed to the level of stress and pressure that people get at certain companies.
I thought deadlines had gotten rid of a decade ago in software engineering with the rise of agile software development and the realization that software is difficult to neatly scope, and development time is almost impossible to predict.
I can sit there as a project is falling over the edge of a cliff with total inner peace.
My interest stops at the pay cheque and by the clock.
Getting on 15 years into my career and not sure I'll ever get there. On the other hand, I actually work on a project I care about and for a company that treats me like a human being and not a "resource". Think I'm OK with that.
This is what I'm (slowly) learning as well, even though I'm not entirely sure I want to. Working on projects where you care but almost nobody else does does that to you, but I'm afraid I won't be able to make it back to a position where I can care for projects.
Another thing to note is my father who had completely invested his entire life into this way of thinking and is currently spending his retirement with bad mental and physical health. That’s the end game these working practices tend to lead into.
It’s true that you should work to live, not live to work.
If you don't care about what you're doing, you're spending most of your influence on the world on something you don't care about.
If my choice is between working at a boring job where I can support my colleagues, and an exciting job with cool tech where people are having mental breakdowns and nobody has the mental space to support them, I'll take the boring job where people don't care about stupid directives and dealines from above.
At the end of the day, YOU are the professional. If an amateur decides that you are going too slow, that doesn't mean anything--they can feel free to hire more engineers or whatever needs to be done, but the onus is on _them_ to ante up. No matter how much you love your job, you're probably going to have multiple throughout your career so you need to focus on yourself first and foremost.
Quit working for them and now I'm a freelance dev.
They asked me to get back on the project and I said fine, that'll be €700/day. After some grumbling they realized they had no other option so they agreed.
The project is still failing due to bad management but I no longer care. I believe to now feel the same sense of calm around chaos and failure like you do.
A lot of developers have real mental scars from bad projects like this, because they get duped into thinking it's a matter of personal pride to see it trough.
It's not. Your primary concern should always be personal health.
Why did you undercharge by so much.
I know the EU dev market isn't great but those are rookie numbers for "danger money."
Three of the "retired, then handed enough money to unretire" COBAL guys at my old place were doing 2500 a day.
Like the going rate for a senior here is 900, and a good senior is 1200+. So your starting offer would be at least 1800, probably 2000s to round it up.
Which is the high end of your zone of possible agreement (900-1200) plus 50% for danger money, plus a few hundred to round it up to 2k.
Then you see what happens when you throw out the big number.
Consider that most parts of the world have lower cost of living than the Bay Area.
Implying that other developers in my area are available for less than I ask.
I mean, if a person is able to extract 700€ per day, kudos to them but that's still above the 90th percentile of senior developers in Europe.
They can attempt to prove it.
I have no idea what typical salaries are in the EU, but that’s on the low end of mid-career for much of the US.
If you take the run of the mill Java dev salary here, the net value is somewhere between 900 - 3000 Euros or so, across all levels of seniority [1]. Really makes one consider the benefits of working for companies in other countries, assuming that there are no cultural or time zone issues that cannot be dealt with.
Or, you know, to acquire skills that are high in demand but relatively low in supply.
[1] - https://www.algas.lv/en/salaryinfo/information-technology/ja...
Take Ireland for example. You're not going to be making US level money but I'd say you could easily double what you're making now and there's the potential to go much higher than that.
Well, at least as long as the culture fit is there etc., admittedly remote isn't for everyone, but on the flip side, geography/commute being less of an issue for the remainder of people is great!
If you earn 30% more than a salaried employee you are barely breaking even most of the time.
And that's without the expenses, extra healthcare coverage, insurance etc.
So pretty average when you considering that junior developer salaries are within this reach in EU capitals.
I used 4 weeks, and by my experience that's generous (not talking about paid leave - all the freelancers I know are workaholics and don't take much leave, but maybe that's a US thing).
5*48 = 240 days, which works out to around 84000 EUR. Or 120,000 EUR - 30%.
Regardless, 700 EUR/day seems in the ball-park for a generic all-around developer.
£500/day is the absolute minimum for developer/DevOps outside London, £600/day much more common and including the cheap end for London. Senior is more often £800/day. You don't see values above that advertised, but people do obviously negotiate higher for specialist work; I have seen a mainframe developer charging £1500/day (on the low end of his range). Anything higher than that has always been a large consultancy rather than a freelancer. In my specialist niche I'd be asking for £1500/day top-end, expecting £800-1200 with negotiation depending on flexibility.
Junior developers make 75.000€ after taxes? They make about 50 - 60.000€ BEFORE taxes.
Probably higher now.
The least you could do for "danger money" is 1200 EUR a day (and limit yourself to 4 days a week, but that's another story).
Customers always seemed to want to pay me fixed amounts for jobs and be absolutely no good at estimating them. I got paid 28 days contract fees for a job that took 3 hours once. They paid up and asked me to not come in for the last 3 weeks so their other employees didn’t catch on to what had happened…
Guess who got called in on the weekend for log4j?
Guess who only heard about the problems on Monday at 9am?
You guessed it, the call was made to not pay the (documented) day rate for contractor call outs on weekends. Full-timers got "days in lieu."
When doing contract work, you might be paying $500 / month out of pocket for medical insurance but your hourly rate is likely higher than your hourly rate as a W-2 employee even after factoring in company holidays, PTO and 401k matching. You also have the option of not buying insurance if you really wanted to.
Most insurance in the US is horrendous too. The whole system is optimized to provide you the least amount of coverage while making the process as inefficient as possible for you. I spent literally 12 hours on the phone over a few calls trying to get basic information from a few different dental insurance providers, in the end I got nothing concrete out of it and the only way I could have gotten concrete numbers is if I submit a form that takes 30 days to get processed except in the US you only have 30 days a year where you're allowed to enroll into insurance. Basically it was impossible for me to pick insurance based on coverage because it's impossible to know the coverage without first signing up and then you're stuck in it for a year in which case everything resets the next year and the process has to start again from scratch.
Pick the air carrier with the cheapest flight to Mexico.
It would be way more efficient for employers not to offer dental insurance and instead give employees a tax-free $1,000 yearly stipend which allows employees to use this for personal and family dental care as an expense report which in turn ends up being a business write off for the employer. Now there's no limitations on what work can get done and no wasting your life trying to chase down dental / FSA details. A higher end dental insurance plan through a company is over $1,000 a year too, so this stipend approach would save employers money and it saves employees a lot of money too because you could easily end up paying $600-700 post-tax money out of pocket for standard cleanings a few times a year when insurance won't cover them (even if that insurance costs $1,000 a year). It's a win / win scenario for both the employer and employee.
I try to be professional, hard working and I even do some unpaid overtime when deadlines are strict.
But the moment you pressure and stress me to do more it's the moment I say no and all my commitment goes away.
I'm not here to clean up poor management, project planning and low budget.
It was me and the two founders that I already knew from working together in the past. I expected that my opinion matters, I tried to improve the product, the service, the engineering, but anytime I recommended something it was ignored. After some months, I learned to just shut up and code. This experience taught me that no matter how close you are to the decision makers, influencing them is still hard. Since then, I just don't care. Sure, I'll do my best, but I do it for me and to get another offer in two years.
Now, I work at a big company, I'm like 5-8 levels removed from the decision makers, and I just don't care. I still try to do my best, if I have any concerns, I might mention it once, but if decision makers are not interested in my feedback, I don't mind. I work my hours, do my best, I don't take anything personally, but I also don't care if there is an outage at Friday (that could have been prevented if only we addressed the issues I brought up a couple of times) or if the feature we are developing never gets to production or if the feature fails (predictably, but a CxO has the amazing idea to pursue some obviously bad product decision).
It's difficult to not show the rest of the team how much I don't care. It's very different to show everyone openly you don't gaf (that's not accepted) and just simply not giving a f while pretending you care (that's okay), so I learned to "mask" my true emotions.
My BS filter is highly developed now.
"We will have the project done by the end of the month. Failure is not an option. We dont fail. We are xxxxxx. Come hell of highwater we will get it done. Lets do it". High fives.
"If you get this done you will get ...... " ($$, vacation, yacht)"
"Give it 110% people"
"If we dont get this done ....... "
This means: "This project is screwed. Nothing the team can do will save it.
I do the right thing; I talk to the PM or whoever is in charge and politely but honestly share my professional assessment of the project.
This is most often totally ignored. Which is fine. It is no longer my problem and nobody can come with "I thought you told me you would get this done ,.... " or some such variant.
I will do a good job and try within my own parameters of sanity and health and time.
After a rather unpleasant and unwelcome time I found myself in the army, having people yell at me all day (and night at times) Even when you have not slept for 48 hours, still screaming.
I can't say anything positive about the army but it did give me thick skin.
I am entirely unfazed and bored by some office drone talking to me loudly. Even if said drone starts turning purple.
> ""With all due respect, sir, you're beginning to bore the hell out of me."" (Clint Eastwood as Gunnery Sergent Thomas Highway in Heartbreak Ridge (1986))
That's why a PIP puts said pay checque on the line though.
I don't need that stress. I just hopped over to another company, cut my commute, and made about 20% more salary.
Also see, when everything is a priority/emergency, nothing is....
The squeaky wheel has to be actively on fire to get attention at this point.
I don’t understand this though? Eventually someone’s head needs to roll. If you fail your project and get fired, how is your manager immune from consequence? They failed too (probably more).
Sounds generally like most jobs.
Principles are things like Integrity, Honesty, Respect -- not Amazon's fuckwit bulletpoints like "Be right a lot" or "Frugality."
Technologically, AWS is built like a fucking house of cards with spit, tape, and glue. There is no real cohesion or organization, just a bunch of teams doing their own practices and gluing their rando codebase into the Yellow Console. Sorry, but just making the frontend look unified doesn't undo what the backend spaghetti is... That's why the outages of late will continue. It's all bubbling up from the absolute toxicity in lack of basic humanism at the core.
Still making more money than GCP and Azure (both of which are worse to use, IMHO) so...who cares?
As a thought experiment, suppose all of AWS was down for a full week? What would happen after that?
More realistically, how many times can us-east-chaos-monkey bring down various global services before a lot of its users start making moves to mitigate or eliminate their exposure to AWS?
For a more concrete example, I'm working on a project that has an easy but critical use of cloud services. The more I read about Amazon following Microsoft into Ballmer era stack ranking madness, and the most AWS fails objectively fails, the lower the priority it gets for which cloud platform to support first and best.
So they go on the offensive and try to manage the dev out before senior management realises that yet another dev doesn’t want to work with them.
There are very few Senior Managers who take the time to look beyond what’s immediately presented to them.
Have I described correctly the situation?
Legend:
M2 - senior management, has other managers reporting to them
M1 - first layer of management, has workers / engineers as direct reports
Why they had to invent "to be the best employer of the world" as a leadership principle?
The more people should stand up and make the stupid policies known, that's the only way this can stop. Otherwise this policies will be the norm for many companies since "it can work"
The only thing that management cares about is how much they're paid, and how much power they have. Look at how Elon Musk behaves. He gets mad/irritated when told by regulators that he can't exercise the power he feels is his right. I actually don't think he gives a hoot about how much money he has, except as a tool for accomplishing what he wants.
Others are more into the wallet than the ego. Do you think Zuckerberg gives a crap about what privacy advocates think? Most people have a fair idea of how far FB spies on them, and Zuck knows they don't care as long as they can share cat pictures with their friends, or post Let's Go Brandon stuff. But you can bet that he's supremely pissed about losing so much money due to Apple's privacy changes.
I've found bad managers are able to exist, even thrive, due to a culture of loyalty. Having worked in several countries this is a very Corporate America thing (IME). Loyalty is the only trait that matters. Fealty might be a more accurate description.
So that bad manager's manager looks at a situation where people are leaving. Those people are disloyal and thus bad. The bad manager is completely loyal and thus good.
Seriously.
Most people don't care at all about doing a good job. They just want more money. To get along with them, you must help them get more money. If you oppose them on anything, they will make you suffer. And if they have the skills, they will manipulate and gaslight you. You can't make anyone do their work well. People work well when the organization is set up for it. If you can't tolerate your teammates' behavior, just move to a different team or company.
The manager might not be incompetent, but they sure are an asshole
Well, for starters, this LinkedIn post.
The same manager never fired anyone he hired. He fired a few that he had inherited (even calling them 'deadwood') around other employees. Employees who had worked with the 'deadwood' for decades. But his hires? They could be the worst performers, and even though they were contract to hire, he always hired them. To not hire them would be to admit his hiring practices were crappy. And considering he had little technical knowledge, he was susceptible to hiring people who kissed the ring (and stroked the ego).
Some managers are just bad. Peter Principal and all that. Some are great at telling everyone what they want to hear, both up the chain and down.
Big companies are often far less consistent across teams than you'd expect/they'd like it to be, for better or worse
Once I came in to work in the evening, I had forgotten to bring my phone with me. There I find one of my coworkers crying his heart out because the women treat him like shit. I had not noticed a thing until then. They thought he was sent there to optimize them away and was making his life hell. He had sold his appartment and moved to our little town to work but couldn't take it and moved back again.
The company is the same for everyone (ie un-humanistic in its management), and if and when your personal circumstances change, you'd then perhaps see what others currently in it are moaning about.
There are teams at Amazon full of some of the best technical and professional managers on the planet. There are teams at Amazon that are so brutally driven that they will sacrifice anything, even accepting an incomplete pentest audit and a forgoing week's worth of sleep, to hit a launch date.
I personally had a close friend on my team get PIPed and it was obviously a play from management to get rid of him. I have another friend who had to take months off after leaving because of the abuse she experienced. I have other close friends who have stayed for years.
It's such a big organization and the leadership chains are so decentralized that you get a wide variety of emergent patterns, and the decentralization makes it hard for people across the organization to know about the experiences of other teams.
Edit: in general I wouldn't say the horror stories are the norm at all from what I've seen.
Maybe his manager is a piece of shit, but I can't believe there's no one to report to above him that can see this for what it is and make it right?
Edit: I'm trying to imagine scenarios where that could happen, I have two so far. You ordered pizza for a meeting that got canceled, and the office refrigerator was huge. Or you ordered from a fancy pizza place that had waygu or something as a topping. I'm sorry, I don't know why this is bothering me so much.
The value of pizza is inversely correlated to the time it's been out of the oven. Once it's in the refrigerator it's worth max 1%
So to me it makes perfect sense that it's $100
I had gotten them for myself and a friend. They are small pies so a single person can easily eat two of them.
Additionally, because of the internal transfer policy and teams frequently switching out members, a lot of work is designed to be picked up by a new person, especially at the SD1/SD2 levels, so people are generally replaceable. Couple that with the fact that the interview process only tests for academic knowledge, without really proving that you can set up infra and services in production. And even more on top on top of that, Amazon gets a never ending candidate pool. So you get a combination of both poor performance that actually need to get PIPed out mixed in with poor teams that are ran like crap because managers themselves are not really technical and end up not delivering and then having to PIP people out.
That being said, because of this sort of structure, if you know how to make moves and "read the room" so to speak, Amazon is the best company for finding that sweet spot of maximizing revenue/actual hour worked. If you are a talented software engineer, not just a developer and generally know how to navigate around managers, you can hit senior engineer or manager levels quite easily, and then cruise control your way at $300k a year, and with an added benefit of lots of remote positions right now (since wfh is a big selling point in order to not get rejected by good candidates). From talking to people at Google/Facebook, those kind of moves are a lot harder to do.
How do you “navigate” your way around an 11:30 PM email that contains a 5:30 AM deadline, as mentioned elsewhere in this thread?
I have a cronjob that signs out of {slack, email, zoom, ...} at a particular time of day, my work accounts aren't attached to my personal devices, and i respond promptly to communication during working hours. I genuinely don't see work-related comms when i'm not working, and my work availability is in my slack profile, my internal email signature, and in my outlook calendar.
Not really; esp when the processes and priorities are alike across the company (with exception of few organizations that are experimenting newer processes at any given point in time).
> Amazon is the best company for finding that sweet spot of maximizing revenue/actual hour worked.
I don't think a single tenured co-worker who, during the pandemic, moved to Airbnb, Uber, Google, Stripe, and heck, even Coinbase, look back fondly upon the management structure they were subject to at Amazon, now that they've seen how other companies in the space are setup.
> If you are a talented software engineer ... cruise control your way at $300k a year.
Well, there's this: https://nitter.net/quinnypig/status/1386803846970675200
PIP is a tool in manager's hands and above L6 no one gives a squat. They even encourage using it.
that is well beyond real.
Thankfully he realized the idea was terrible/other events made it irrelevant, but it was discussed and code written to support doing it.
It's not just:
git contrib --linecount jdoe
Managers even bought Java textbooks to put on their desk as some kind of totem as if their days weren't 100% filled with political skirmishes.
Don't think it ever came to pass but this nonsense reaches the highest levels of the wealthiest orgs.
You already know what the problem with these people is (e.g. they can take a week to add a new command-line argument). Tying that to the LOC count is counterproductive.
Shitty managers like you who try to go against the well-known wisdom and try to use LOC as a metric are what leads to the problem of shitty developers trying to game that count and posting ridiculous metrics like "I checked in 51k LOC in January". Developers who treat their work as a craft will avoid shitty teams like that even if they otherwise do well on the LOC metric.
That's rude and against HN guidelines. Don't make this personal. I'm not attacking you.
You think I'm taking an extreme position ("Managers should measure developers by their LOC"), which I am not. Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case?
As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into? And when this developer has been saying in every team meeting and 1:1 the last month that they've been working on tough problems. I'm not going to put them on a performance plan over their LOC, but I'm sure going to dive in if I notice a small number there, and we're going to have a conversation about it if it turns out they're not delivering.
PS: above is not hypothetical. It's happened many times in cases when I take on a new team or a developer moves under me. A couple of cases were great turnaround stories, with the developer extremely grateful that their manager was actually helping them improve their engineering. In one case the guy was let go, because he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).
If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.
If you think LOC is a useful metric, I would disagree that someone calling this "bad management" is attacking you. A hospital manager that measures staff performance by incisions per day is clearly misguided.
Wrong analogy. I have two physicians on my staff. They both have the same years of experience, the same role, get paid the same. One sees 20 patients a day. The other sees 2 a day. That's not a red flag? I should ignore that and assume that somehow every single one of their patients is 10x more difficult, and not even bother to look into it? Because if you would agree I should look into it, then the number-of-patients was a useful metric.
A metric is just data point, no more, and not a complete picture.
> If someones LOC is very low, but they complete all their tasks on time, not only is there no problem, it is even beneficial as the work is being done without creating too much burden for future development. If someone commits a large amount of code without completing any tasks, that's clearly not useful.
I must not have been clear. I'm not arguing for bloated code. Lean code is good, of course.
I'm talking about the all-too-common developer who has some number of tasks to complete, and tells his teammates (and me, their manager) that the work is very complex, and so they land (let's say) one bug-fix a week, giving the impression that each bug-fix (or feature, whatever) was challenging. But on inspecting their code, the code itself is fine --nothing necessary wrong with it-- but the changes are all trivial and really shouldn't take a $180K/year developer two weeks or even one to crank out. LOC isn't the full picture but it's often correlated and if nothing else, it's an obvious red flag for me to investigate.
To put it simply: If you're a high-paid engineer, you can deliver big features slowly or big tough bug-fixes slowly (and the LOC doesn't matter if the problem was actually difficult), or you can crank out lots of small features and small easy fixes quickly. But if you're barely outputting any code, and trickle out a meager amount of code, and the few lines of code you merge into the repo are all trivially simple, that's not acceptable. That engineer can't cling to "Don't judge me by my LOC!" I'm not -- I'm judging by the small amount of actual value they're delivering.
I am sorry for the adjective, what I meant was "extremely incompetent". That is still harsh, but hopefully conveys my opinion regarding your grasp of management in a more objective manner. It's not meant to be personal, I would say the same thing about someone attempting to use the OCaml compiler to run a Python program, and telling me that's how they do things at their daily job.
> Are you actually taking the opposite extreme position, that a developer's LOC tells you absolutely nothing about their productivity? That there's not even a correlation or a hint of a connection, in the general case?
I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.
> As a manager, if one person on the team is committing several times a week, and their code is, even at a glance, non-trivial, meanwhile another developer merged 3 times in the last month and the git diffs are 20 lines each, would you say that the 15 LOC a week (or whatever small number) shouldn't be a major concern that I should look into?
Is this person engaging at all with their teammates? Have they been active on design docs or architecture? Have they been responding to queries from sales engineers? (a lot of time at an old job was literally telling Sales "yes, our product can do that"). Have they been maybe going through a big life change?
Without all of these, it's not possible to get a complete picture of why there is a problem. And a lot of them are more specific and better questions to ask than "how many lines were in the diff?"
That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".
> he refused to accept the concept that he needed to deliver more than a couple of trivial python commits a month to justify his $250K/year salary (long story, I didn't hire him).
Since you have shown precisely this in your post (e.g. you didn't say anything about his lack of design or documentation or engagement with teammates; all of which I would certainly expect at that level), I think you need to reexamine your worldview, or at least the way in which you present it.
LOL. Oh, you!
> I am taking the slightly less strong stance that a developer's LOC tells you no more about their productivity than any other random metric, e.g. the number of lines they type into Slack, the number of bugs they file in the internal bugtracker, or how many geek jokes they made that month.
Reductio ad absurdum. A new feature is expressed quite literally as code in a repository. All other things equal (i.e., if one person isn't busy with design docs, or mentoring teammates, etc) if one developer cranks out 5K lines of solid (not bloated, well-tested, etc) code in a quarter, while the other person eked out 150 lines in 3 months, that's an indicator of a potential productivity issue. How can one argue it's not even a hint of a possible problem?
> Is this person engaging at all with their teammates?
No
> Have they been active on design docs or architecture?
No
> Have they been responding to queries from sales engineers?
No
> Have they been maybe going through a big life change?
Sometimes yes. And when I find out that's why they stopped submitting code, I tell them to take the time they need to take care of themselves and their family. And we offload their work to someone else for a few weeks or however long until they're back.
> That is the crux of why I think manager who use LOC as a metric are incompetent managers. They have and project to others a simplistic view of "developer in, code out".
I wonder if maybe you had a terrible manager who was like this. Because you're interpreting my statements in the most cartoonish way possible, like I'm here saying "more code good developer, less code bad developer."
This thread started with someone saying LOC tells you nothing. I claim it tells you something, and then it's the job of the eng manager to figure out what. I totally agree that a shitty manager who literally connects LOC to productivity, is doing it wrong. But again: a good manager should be looking at the code from their team, and making sure the amount and complexity matches their expectation of what that person is supposed to be delivering.
> slide 20 of https://www.slideshare.net/ddskier/calculating-the-cost-of-m... ("A world-class developer (e.g. Facebook or Google senior engineer) will write 50 LOC per day")
I also found some two scholarly estimates, one at 81 LOC/day and the other at 16 SLOC.
On this topic, don't forget that negative LOC can be good, as in the -2000 LOC story at https://www.folklore.org/StoryView.py?story=Negative_2000_Li... .
Sorry, I wasn't clear. I'm talking about 50 LOC every 2 weeks or so. Like, seriously low LOC of seriously low-complexity (sometimes trivial) code.
I don't actually have a numerical target people should hit. Not at all. It's more like this: on several occasions now (all too common), I've taken over management of a team, and in our initial team meetings and 1:1s, some developer talks about what they're working on and say it's really challenging but they're making progress and making progress and making progress. Then a couple of weeks in, I look at their commit history, and they've committed 6 times in the last 3 months. I give them benefit of the doubt, those must have been 6 meaningful commits. Then the first thing that stands out, the first red flag: each commit is like 25-50 lines. At this point, I have very strong reason to think we have a problem. But of course, to confirm, you look at the code itself, and one commit is just adding a command-line argument/option to a python script. Another commit tweaks some CSS. Or does a bit of dict/list operations that any developer should be able to knock out in 30 minutes.
My first hint that I need to dig in was the low LOC. Obviously, no one goes to a performance plan because they're not "hitting numbers." And obviously, someone whose job is architecture, system design, etc, isn't coding all day, so I'm not at all concerned with how much code they're cranking out. But for those whose job is, primarily, to code, well if you're writing low-complexity code (which is OK in a lot of cases) but you're writing very little low-complexity code... that's a problem.
PS: For a couple of years on my last multi-hundred-developer project, I ran a twice-yearly Code Reduction Week, and I emcee'd the All-Hands where we celebrated the developers who deleted the most code.
Teams of people build things. LOC don't add up to a hill of beans.
I think maybe you haven't seen how unproductive some people can be. And one hint of their productivity, is that they don't have much code to show for. If someone can explain to me how they're writing significant amount of new software with less code than this comment I'm typing right now, I'd be interested to learn how they did it.
One of my own major wins last year was a big update to a project to strip out legacy cruft and tech debt, and scrapped maybe 5,000 LOC. The end result was smaller, faster, easier to test, and more robust. I count that as a win, by pure LOC, it was a massive failure. (Unless you don’t count code removals against an IC’s score, in which you’re optimizing for churn.)
My point is rather this, and I suppose I'm not being clear: If a developer only ever submits tiny amounts of code --and they have no other responsibilities like design docs, mentoring team members, etc-- that's an indicator of a performance problem that should be looked into and discussed with the engineer in case there's an issue.
I'm in no way suggesting that, e.g., the developer who submitted 12K LOC last year is doing a "better" job than their teammate who only submitted 11K LOC. I'm talking about that person on the team who only writes 500 lines of new code in an entire year, and they trickle out tiny simple commits ever couple of weeks. Every team that I've taken over as a manager, I find one person like this, who pushes barely any code, and the code they do push is trivial, and they aren't doing anything else either.
People here are somehow suggesting that LOC is so meaningless, that somehow apparently a person can implement a new map routing algorithm in 10 lines, or implement a new 3D rendering engine in 10 lines, or create a new data-ingestion and validation pipeline in 10 lines -- because apparently LOC is a "meaningless" number.
Unless this is generated boilerplate, it just isn't possible to create that much code, that quickly, and have it be correct.
Some people work a short period to get a taste of the tech stack and pace of a FAANG while other people post to HN about upcoming interviews at Meta and how they may hate the company's morality but want that big fat comp package. Everyone has their own reasons for taking a particular job and sometimes that calculation needs include the cost of associating your work history with the brand of the company you are working for, but if you think that what you are doing and the impact it has on the rest of the world is important then that warm and fuzzy feeling is a part of the compensation you are maximizing. In the long run no one will care, so anyone who is not maximizing compensation is probably a fool.
Big companies are actually like a conglomeration of small companies under an umbrella company. The culture is 20% upper management, 80% local management, and so your experience will differ greatly from department to department.
Bad managers exist in most companies. They can and do target people for personal reasons, and usually the targeted person doesn't have the protection or political clout to defend themselves, so they're killed off and life goes on.
I had a similar experience at Canonical of all places, which was a real drag because they were one of the few fully remote companies at the time, and I like the company.
Not everyone has the opportunities you have had. Some people actually have to struggle to climb for X reasons, and make tradeoffs to enable them to survive / grow.
Some people actually need money and can't just ignore wads of cash being thrown at them for the first time in their lives.
You're fighting ignorance with more ignorance.
We claim to, but at the end of the day want someone else to do the standing behind them while we go back to our lives. And we don’t want whistleblowers around as we fear that we will be their next target. Whistleblowers, in their effort to restore trust, become automatically untrusted by large swaths of society.
Naming makes you persona non grata to a lot of people.
Heck I'll stand behind my words. If you ever apply to a company called Anduril. Watch out for a childish manager named Calvin Hareng. This MF: https://www.zoominfo.com/p/Calvin-Hareng/-1964480350
Anduril is hiring and if you're coming on board watch out if he's going to be your manager. He indeed PIPs you if you try to switch teams, just like this amazonian ass hole.
We need something like that. Rate my manager/head of engineering @ some large org. Also get a legal team ready for all the lawsuits that will come your way for whoever wants to pursue this idea. I'm all for supporting it though.
It failed on the second purpose, but at least it helped me avoid or anticipate a hard or incompetent professor.
2) I remember during the #metoo era there was a Google doc spreadsheet of bad men going around where people could add names anonymously. It got to be thousands of names long, and at least a few of the men didn't deserve to be on it.
Reviewers would have to register by company email of course to make sure they're legit.
>It got to be thousands of names long, and at least a few of the men didn't deserve to be on it.
I think there needs to be a voting process to make sure it's not a smear campaign generated by a small minority. If the votes cross a certain threshold all the negative reviews are revealed.
This isn't random people from the internet voting against the manager. It's people in the company who know him, and dislike him.
https://news.ycombinator.com/item?id=30204121
Unless we can know for sure, or at least from a less biased source, we probably shouldn't doxx the manager?
Maybe the service leaves the manager anonymous until the review amount crosses a certain threshold... 3 to 4 guys calling him out?
Submit this to ycombinator!
But seriously: there isn't a way. This is why sites like Glassdoor are garbage and teacher rating sites have ruined careers over minor issues.
That means one person can't run a smear campaign. At least 2 or 3 other people have to agree with you, and if they do then it's legit. The system masks the persons negative reviews until that manager has accumulated greater than 3 or 4.
Three or four negative reviews from people in the company is NOT a minor issue.
Wouldn’t managers just make a service where they review and score engineers too?
Each engineer has one manager, thus they have one review. The profile doesn't open up until after the engineer worked for several managers and 3 or 4 of them leave bad reviews.
It's fair. But managers are more at risk. Still this process keeps everyone in line. Don't be a jackass is the key metric here.
We are talking about people in the top 8% of the income bracket in US. Not a single engineer in Amazon that has or is getting PIPed is losing their livelihood. If you have Amazon on your resume, no matter what, you will have no issues finding another job, because the acceptance rate by itself to Amazon is <10% of all candidates, which acts as a very good filter and indicator for other companies that your more competent than a large percentage of work force there, so you automatically get a shot at an interview and likely a job offer if you are actually competent.
The biggest drawback of something like this is maybe having to wait an extra few months before buying that sweet BMW M3 that you wanted.
If anything, this kind of stuff should be viewed as games, because that's all this is. Supply/demand of labor mixed in with a few political and psychological things. The manager is not even close to being an asshole, he is just playing the game like all the employees are. Lets not pretend that the majority of people wanting to work at Amazon care enough about changing the world, they just want that MAANG salary.
>> Not a single engineer in Amazon that has or is getting PIPed is losing their livelihood.
Can you provide source for this claim?
Firing people and putting them on PIP is just a game because amazon is such a great company to have on your resume? It's just a game because his livelihood is not effected?
What universe do you live in?
Let me tell you about how the world works. If you fire people for trying to transfer teams. If you lie and make up stories about performance because someone tried to transfer teams. You're an ass hole through and through. No one is being hated here. Just being called out, and people are expressing their extreme dislike for such behavior.
I can't believe you called it a game. This must be how ass hole managers justify their actions to themselves. It's like a bully in school calling it all a game because the person being bullied still has parents that feed him. Let's be real. It's not a game. Not. at. all.
As such, if some Amazon manager wants to fire, PIP, overload with work, or do whatever he thinks is necessary to its not imorral or makes him an asshole. An employee can just quit and find a different job quite easily and retain his kushy life.
And to be clear this works both ways - if SDEs want to avoid Amazon or share their experiences, thats all fine as well.
But to start going after personal qualities of managers because someone cant keep their 200k/year position makes you the enitlted asshole, not me.
A lot of these cases end up with the manager not necessarily having a lot of blame since they might not have full information on what's happening. They might also be in a similar performance crisis of their own.
If the entire company is having cultural problems and PIP horror stories are common, then the fault is from the people on the top and not from the M1 that laid out the PIP.
I feel ass holes should definitely be singled out so that they can't be managers again for the future.
(2) There are way too many PIP horror stories from Amazon. It is evident that managers even hire people just to PIP them later. In that kind of environment, such bad behavior is encouraged and normalized. Then this particular manager might not be significantly worse than any other person put in a similar position. If the culture is to blame, then scapegoating one manager will just deflect the blame.
I do agree that it is unfair. You have 100 axe murderers. You put one in jail, the rest get away with it. That is unfair.
There are some great directors and executives at Amazon. I enjoyed my time there. There are also some toxic, toxic people with too much power and ambition.
How it is going - https://archive.fo/pdYHy#selection-525.105-525.423
It's gonna be a different situation for someone taking their first programming job out of college, and someone who's been doing it for long enough that they don't care (and would probably fire a company like Amazon before being fired themselves).
> One night, when I was a dev manager at Amazon, another dev manager in Seattle sent me a 20-page design document at 11:30 pm and told me that he wanted me to get him feedback by 5:30 am the next day.
How fucking rude is that? It’s indicative of an absolutely staggering level of toxicity.
Honestly, what a waste. Imagine how much better Amazon could be if they didn’t treat their staff like cattle.
Seriously. You publicly stick the knife in for this shit.
And another one, "A lack of planning on your part does not necessitate an emergency on mine".
But here's what I think is going on: Amazon's higher-ups (the level(s) above these people) are intentionally making these managers put pressure on each other to keep them overworked and sedate. I feel like this is the case for a LOT of US work culture across a lot of areas. It applies to low wage jobs with a high chance of being fired as well. Keep people stressed about the short term and they won't have the headspace to worry about things outside of their sphere of influence. This allows the rich to get richer and the politicians to become more powerful (and incompetent).
If you really don't want to work like this (and I don't), have a 1:1 with the manager, discuss boundaries, and if you can't come to an agreement, change teams or jobs.
And better yet, ask these during the interview! One question I often asked:
"In my current job, I typically leave my laptop at work when I leave at 5-6pm (unless there's a genuine ongoing emergency). Would that work in this role?"
If it was me asking for feedback, I wouldn't have sent it if I wasn't in a pickle that I probably had no control over. Okay, so you didn't read the mail and you only get to it the next day at 8 when your working hours started, cool leave it at that.
Dunno if I would automatically side with his story from that.
Also he has a background in bio, and managed to land a full stack and ML engineer positions, implying he is self taught, and therefore should be already fairly intelligent...but he decided to go get his MS in CS, without even doing any research project and just opting for the GTA instead of GRA route.
None of us can really know for sure, Im just saying it smells a little fishy. If his resume came across my desk, Id have some specific questions about his experience. If you are that smart to have a background in bio, and land the jobs that he did, your career would look very different.
Is that really so impressive? Bio people do a lot of coding, and good dev practices can be learned on the job. ML is probably also something he played with during his studies. Full stack + some ML experience is probably enough for a junior ML engineer.
Studies don't give you any idea of what a job is actually like. They also don't give you a reliable indication that you'll like a field. Choosing bio out of high school, then moving to CS for any reason, then trying a few jobs using these skills is a normal and healthy way of searching for a job he really likes.
Could you elaborate more on this? I'm assuming this is a detail of the US education system of which I don't know anything :)
This is pettiness taken to the max.
Most research people do in grad school will not have applicable use to employers. And for an MS, people will simply learn more by going the coursework route. Going the research route is good only for PhD admissions.
And finally, many universities in the US do not even offer a research route for the CS MS. They tell you to apply straight for a PhD.
If you're going to ask tough questions, at least know your domain!
A CS degree opens doors. And you don't know what he planned when he started his degree.
Asking about someone's experience when interviewing them is reasonable. Calling short jobs during university fishy isn't.
At best you're arguing that Amazon is dysfunctional in a slightly different way than the rest of this thread thinks.
[1] https://news.ycombinator.com/item?id=19828317
Edit: I think it's https://www.linkedin.com/posts/hire-jiawei-wang_hi-linkedin-...
Ugh this hits too close to home.
Hmm, I think I've known this type of fuckabout whose massive submissions totally screw any hope of team cohesiveness and trust. Ok, slugger you can write shitloads of lines of code. Is it any good? Why would I want that much code when a factor of 10 less is more manageable?
(although to be fair pip and the python package ecosystem has come a long way in the last few years)
So - curious; where does that break down?
I think the lesson of this story is to apply for another role after the performance review season.
Or to not express intention to transfer to current manager?
I really hope that these stories make up a biased sample.
It would be idealistic to think that all races have an equal portion of ass holes though. I will say that a large portion of SDM's are Indian so your sample is indeed biased.
Or maybe grow up in a culture that value respect more, so you are biased against questioning the authority.
Or maybe this story is inaccurate/made up. He was put on PIP and requested a transfer at the same time.
Or maybe it's a peter principle at play.
Anyway, I don't think it's fair to post someone's linkedin like that.
Development plan is a regular plan which you do with your manager, where you are focusing on your career progress. You focus on your strengths and weaknesses. Based on this plan you will get tasks which will utilize skills you are good at and also help you to improve skills you want to have improved.
PIP is a plan which is assigned to employees with unsatisfactory results. It's a few months long plan where you got assigned some tasks you should complete. If you are not able to complete them in time, you are fired.
Companies may additionally prefer to have more standardized procedures. Hiring is expensive, training is expensive, and cohesion can only be gained over a long time. By needing multiple steps to fire someone you reduce the chance you throw the baby out with the bathwater. And even if you’re sure someone is a negative factor and want to fire them with little prior notice, the people who you think are good are not mind readers and might even have a different opinion of their colleague and will question their own employment security.
If you're a manager in a situation where an employee has a problem and aren't meeting the job requirements, you'd probably much rather that they fix the problem and contribute to the team than fire them.
That doesn't mean that all of these plans are done in good faith, or that some managers aren't terrible. And for an employee on a PIP, they should think hard about leaving the company (or at least the team); it'll be better for their career.
But I don't think one can say that it's nothing more than a legal way to fire someone (especially since you can fire someone in most states in the US without cause, and spurious allegations of racial or other discrimination would need documentation that would be hard to produce if it didn't actually happen).
I don't think being put on a pip means firing is certain and imminent. I do think being put on a pip means firing is on the table and a serious threat. In that sense the analogy of 'putting a bullet in the chamber' is accurate if maybe a bit strong.
> And for an employee on a PIP, they should think hard about leaving the company (or at least the team); it'll be better for their career.
Considering both of these statements, a PIP is never the right answer if your objective is legitimate performance improvement.
Even if you're an unexperienced (or outright stupid) manager that doesn't understand this and wants to use a PIP as a legitimate performance improvement tool, the target employee is never going to be on good terms with you or your company and it's very unlikely you'll actually get the desired results. If you do, it's only because the employee has literally no choice but that loyalty will be out the window as soon as he is in a better position to make a move.
Honestly, I should have still quit, because it was burn-out over the role rather than compensation-related. But I stayed, and slacked a lot. Tracked my hours towards the end and I might get 12 actual hours of work done some weeks, including meetings. Still got most of my work done, but often with delays. It wasn't a perfect job, but the team was great and I liked the company culture.
My manager was very clear with me when I was PIPed that he really wanted us to work together to get me back on track. HR wouldn't consider letting me work part-time despite multiple conversations (it went against the company policy, and other people would start asking for it), but he tried to convince me to take paid time off instead. I decided to quit anyway, because I figured I was done spending most of my day configuring automated test pipelines and wanted to spend more time writing code that wasn't bash.
When I put in my notice, the manager tried to convince me to stay again, said they really wanted me just on track, and reiterated again that up to 4 months of paid leave was an option. Seemed really forlorn about the situation during the exit interview.
I honestly believe I could have worked my way out of the PIP, and the management would have preferred that outcome. Employing me at my current level of performance wasn't delivering the value they were paying for though, and quitting was ultimately the best situation for everyone involved.
I can't speak for other companies but I work at Google and I've met several people over the years who've confided with me that they've been on PIP (either in the past or at the moment when talking to me). While (thankfully) I haven't been on PIP myself (yet!) so I can't speak from personal direct experience, I can confidently say that all the people I know personally that were on PIP have successfully re-focused their career, haven't gotten fired, and are still working at the company years later.
Obviously it might be survivorship bias and I might simply not be meeting those that do not succeed, but at least I can confidently say that being put on PIP itself is not necessarily just an excuse to get you fired.
I think we generally do not hear about the cases where a PIP was used and the employee was genuinely not meeting expectations, or when a PIP was used and the employee course corrected and went on to have a successful career.
The objectionable part is the magnitude, not the subject matter.
It's just named differently and adds more paperwork (more performance warnings, "talks" with your manager, etc.) before you get terminated.
My manager either wanted me to start doing my job again, or leave and create a space on the team for someone who would. He seemed slightly biased in favor of keeping me on the team. It didn't seem like a fun situation for him to deal with at all.
I ended up leaving, but it's because I was disengaged and didn't see a way out of it. (And I had great offers elsewhere.) Not because my manager was being abusive.
It would have been more pragmatic to fire up leetcode, take a few interviews, and leave the job professionally. This probably would have come with a small pay bump, even with this persons limited professional experience.
Maybe I'm just lucky and I've never had a bad experience like this, but I couldn't see myself posting something like this professionally.
But seriously, I'd rather have a coworker that speaks up when they feel things are wrong. Nothing unprofessional about that.
I "won't hire" him for selfish reasons, but this guy is a patriot and speaks out against bully's. I hate to admit it, but people like us perpetuate the behavior.
The rest of us are just (well paid) cowards.
“Perhaps they should just be quiet”?
When are the abused allowed to speak?
Edit: nevermind. Comment history suggests I’ll never get a response.
My point was simply this wasn't a very pragmatic approach to handling the situation. Some employers may not like to see this type of content on their professional profile and it may hurt their career.
David vs Goliath story
That way people can do what jiawei did but without the risk of professional self harm.
The point of the review in my idea is not just to inform potential candidates, but to push individual managers to become better. When your actions have real consequences towards your reputation then you will be mindful of your actions.
Blind is pretty great but probably overly cynical. It’s not been “discovered” just yet.
Someone in a position of relative power (being able to quit and publicly call out their employer) calling it out also makes the situation better for those that may not be able to afford that risk.
I would not take his given statement at face value.
Even though Amazon has a history of such events, we should care about the bigger picture, yet be skeptical about the individual claims anyway!
> The guy made 24 CRs in his entire career at amazon, all in just one CDK package.
> 50% of his CRs are merged without approval.
> So, yeah, there you go !
Amazon is well known for training employees to defend the company on-line. Aren't you being too generous with an anonymous comment that you provide no link to? Is not possible that is just Amazon propaganda?
90% of the point of blind is to shit on your own company anonymously (at least, that's what I use it for). I find it hard to believe that it's false, given that probably hundreds of amazon employees have seen that post and no one's refuted it.
If Amazon is astroturfing blind, they're doing a spectacularly bad job at it, the general consensus (from Amazon employees even) is that it's a hellhole compared to its peers.
I left amazon 5 and a half years ago, but never heard anything while I was there about defending the company online.
Could you elaborate on this?
- https://www.google.com/search?q=amazon+ambassadors
My number one rule is not to sh*t on former companies with my main account.
That is a felony in many places in the world. Companies do this kind of harassing, thou. That is one of the reasons that companies need to be taxed way more and use that money to assure that people that lose their jobs can still live a decent life.
There only way citizens well have freedom of speech is if they are not at the mercy of corporations.
Maybe someone who's knowledgeable with the development of CDKs can shed some light on how reasonable those numbers are.
I've only seen it written in typescript so node-module and package-locks are a thing.
Will Ye Will Ye Engineering @ Cohere (cohere.io) 5mo Back when I worked at Amazon as a software engineer, the CRAZIEST thing happened to me. Here’s the story…
I was working from home with my girlfriend (at the time), when suddenly I get an urgent ping from my coworker: “Our service is experiencing a SEV 2! We need all hands on deck!” Uh oh, our team’s application has gone down!
However, as I scrambled to figure out how to fix the issue, I smelled something burning from another room and heard a fire alarm go off. “Will! There’s a fire! Help!” I heard my girlfriend shout. Now I was stuck in a conundrum — restore a critical Amazon service, or put out the fire in my apartment?
It was at that time I remembered Amazon’s famous leadership principle “Customer Obsession”. There are customers who depend on my team’s application — I can’t let them down! So I ignored the fire and my girlfriend’s pleas, and started debugging the production issue.
But all of a sudden, the smoke in my apartment cleared and the fire alarm fell silent. My girlfriend walked into the room, and to my astonishment, peeled off a wig and revealed herself to be Jeff Bezos himself! “I’m proud of you for being obsessed with our customers,” he said, and gave me a $5 Amazon gift card. He then leaped out of my window and hopped into a waiting Amazon Prime delivery van that quickly peeled away.
Even though I no longer work at Amazon, I’m so grateful for these experiences that taught me lessons I’ll never forget. Agree?
> "TODAY I interviewed a SINGLE mom that had her BABY on her lap and apologized when it started crying. I gave her the JOB on the spot because motherhood is HARD. Let's all give single mom a break and be more human in the process! :clap: :clap:"
I've unfollowed so many people at this point because I use it as an address book for coworkers and recruiters and these virtue signalling posts are not even trying to look human.
Such an utterly shallow pretence for engaging a discussion.
the fact people actually fall for it is depressing
There are supposed to be emoji's in there
Recruiter/spammer
Thanks for clearing it up, btw. :)
I’m a software engineer who likes to have fun on LinkedIn, not a recruiter/spammer. And yes, I was actually an SDE at Amazon!
This makes it.
Don't date women that are easily confused with Bezos in drag?
That is also:
- Success and Scale Bring Broad Responsibility (We must begin each day with a determination to make better, do better, and be better for our customers)
- Deliver Results (Despite setbacks, they rise to the occasion and never settle)
- Bias for Action (We value calculated risk taking)
- Think Big (They think differently and look around corners for ways to serve customers)
- Are Right, A Lot (They have strong judgment and good instincts)
- Ownership (They never say "that's not my job")
- Dive Deep (No task is beneath them)
Clearly, Will Ye Will Ye is operating at an Amazon final-stage boss level, if only they knew [0]!
[0] https://news.ycombinator.com/item?id=30051100
— What do executives do, anyway?, https://apenwarr.ca/log/20190926
I’ve never felt pressured to work overtime, haven’t had to race to meet an unreasonable deadline, and I’ve been rated exceeds on both of the performance evals I’ve been though.
The Amazon I’ve experienced is much different than the one I read about before joining.
After I joined Amazon in 2007, I referred a friend from Uni who joined a few years later.
I had a fairly laid back experience - after a good start, I became depressed and burned out, but somehow none of my managers seemed to care all that much since I was at least getting some stuff done, until I finally got put on a PIP several years in - which I think was probably deserved, although the handling around it was crap. And even then, when that manager moved to a new team, my new manager told me I was doing fine and not to worry about it.
My friend, on the other hand, who was the most diligent and hard working of my entire friends group in Uni, was assigned to a different team a few desks over. She fell afoul of stack ranking (the idea that you should rank everybody in a team and fire the worst) and was pressured until she quit.
I also heard a bunch of horror stories from devs across the company - unreasonable deadlines, regular Sev-2s and firefighting when on-call, a manager evading blame for a disastrous project launch and dropping it all on one engineer.
I think the main problem that I saw was that there wasn't much training for managers on how to be a good manager, and bad managers never seemed to face consequences.
I finally quit after eight years (funnily enough, after ending up working for the manager who made my friend quit) and I'm a hell of a lot happier nowadays. Amusingly, I'm still facing tight deadlines and sometimes random overtime, but I have a great boss who is willing to fight against these things for me, and that makes a big difference.
Found the Timestream guy
I suppose people working in critical positions were cut some slack. I can't imagine doing interviews is one of those positions.
"He was then PIP'd for accepting the gift card and not being frugal"
IT Crowd reference: https://www.youtube.com/watch?v=ab8GtuPdrUQ
Though it may also be common to request a transfer when you sense your boss doesn't value you.
It's worth mentioning that it wasn't uncommon for people to move around teams, and to be honest HR is not the most exciting field for software development anyways. So, as expected, the HR dev teams had people move around quite a bit. Nothing toxic so far.
One of the projects I worked on was what used to be called the dev list or personal improvement plan (pip) now renamed to Pivot. Most likely the exact same same tool. Management wanted to update the processes in order to automate as much as possible and reduce the risk of managers putting someone in pip, just because they didn't like them. However the process was set up in such a way that a manager can progress an employee through a pip for waaaay too long, until a failsafe, or a second pair of eyes even takes a look at it. I, personally, voiced my concerns about it, but it was shrugged off as "it shouldn't happen", "managers wouldn't do that" and "it's fine" by the project stakeholders.
The project starts, development is going a usual and a couple of years go by. I moved to another project within the HR space. Most of the team developing the tool has also moved on to greener pastures. Apart from that one guy, who has been there since its inception. He went from being a backend engineer, learning React and painstakingly working on a messy frontend codebase, eventually leaving him the only person competent enough to make changes to it. Eventually he was fed up and wanted to move to a different team. Lo and behold - his manager, the manager of the team building the pip tool, put him in pip to prevent him from moving. Haven't seen someone decide and actually leave a company as quickly as he did. So if the manager of the pip company can use it to blackmail people not to leave, I can't even imagine what it's like for the rest of the company.
However I used to work at Amazon, working on the performance evaluation and HR tools used within the company.
It was a couple of years back, but I am fairly certain that the same tools are still used, given that all of them were developed from scratch.
At the time it was in line with the company's PR of removing its toxic work culture.
It's worth mentioning that it wasn't uncommon for people to move around teams, and to be honest HR is not the most exciting field for software development anyways.
So, as expected, the HR dev teams had people move around quite a bit.
Nothing toxic so far.
One of the projects I worked on was what used to be called the dev list or personal improvement plan (pip) now renamed to Pivot. Most likely the exact same same tool.
Management wanted to update the processes in order to automate as much as possible and reduce the risk of managers putting someone in pip, just because they didn't like them.
However the process was set up in such a way that a manager can progress an employee through a pip for waaaay too long, until a failsafe, or a second pair of eyes even takes a look at it.
I, personally, voiced my concerns about it, but it was shrugged off as "it shouldn't happen", "managers wouldn't do that" and "it's fine" by the project stakeholders.
The project starts, development is going a usual and a couple of years go by.
I moved to another project within the HR space.
Most of the team developing the tool has also moved on to greener pastures.
Apart from that one guy, who has been there since its inception.
He went from being a backend engineer, learning React and painstakingly working on a messy frontend codebase, eventually leaving him the only person competent enough to make changes to it.
Eventually he was fed up and wanted to move to a different team. Lo and behold - his manager, the manager of the team building the pip tool, put him in pip to prevent him from moving.
Haven't seen someone decide and actually leave a company as quickly as he did.
So if the manager of the pip company can use it to blackmail people not to leave, I can't even imagine what it's like for the rest of the company.
I wish to thank you for proving my case.
It looks totally fine on a monitor, but because of the narrow width on cell phone displays, a paragraph can extend beyond the display's height, and it psychologically has an impact on people.
erm, this makes it sound like he was a not a very good engineer. Your code should always be written so that if you get hit by a bus one day, the rest of your team could pick right up where you left off
Sounds like if you work at Amazon you might choose to walk in front of a bus one day...
Usually you need to gather evidence that you've contributed significantly to a project. And the easiest way to do that is to work on new projects. Maintaining an existing codebase is usually a thankless job, which is also hard to get you promoted.
And once the new project is released it eventually gets abandoned and people move to the next one, which would help them get promoted. Think of all the Google projects that have been discontinued, which were also a product of similar processes.