Summarizer

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. Very important with this, is that not every work place sees your job as that, and you might get hired for the former while you believe it to be the latter. Navigating what is actually expected of you is probably good to try to figure out during the interview, or worst case scenario, on the first day as a new hire.

This is huge advice for people who want to climb a given career ladder. The overwhelming majority of organizations will say they want you focused on real user problems, but actually want you to make your boss (and their boss) look good. This usually looks more like clearing tasks from a list than creating new goals. At Google there are both kinds of teams.

Rightly said. I spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time. I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work. I then posted on LinkedIn about this achievement to get my share of appreciation. :)

LoL managers.

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems. The main benefit of understanding the purpose and real world usage of your software is that you can ask the right questions while planning and implementing the software/feature/bug-fix and that you don't make any wrong assumptions. In a situation where you have conflicting requirements or concerns regarding the change, you'll eventually be hit with "PM knows the product & customer better" or the explicit "your job is to deliver what is asked".

What about the second order effects? Ignoring the customers becomes a habit, which doesn’t lead to success. But then, caving to each customer demand will make solution overfit. Somewhere in there one has to exercise judgement. But how does one make judgment a repeatable process? Feedback is rarely immediate in such tradeoffs, so promotions go to people who are capable of showing some metric going up, even if the metrics is shortsighted. The repeatable outcome of this process is mediocracy. Which, surprisingly enough, works out on average.

Please stop abusing co-opting and denigrating the title of engineer.

15 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you in those positions - but once you are in those positions - only that mattered is politics and asskissing. I know so many people smarter than me, always stayed lower b/c they didn’t know how to play politics. Only reason i never got higher was I didn’t know how to play politics and kiss ass any more or any better. The top people are all who kissed each others ass and looked out only for their cohort (e.g. people who were in same positions as them in early 2013). So teach your kids to kiss ass and play poltiics.

So teach your kids to kiss ass and play poltiics. Or to stay far away and do something useful with their lives.

This is what I really don’t get about these types of folks. Do they really want to remember their life’s work as “kissing ass and playing politics”? I get the “work to live” and all that, but you’re basically tossing away half your life…for what, money? How much money do you need!?

For some, that's not only their competency but they enjoy it. Is building relationships and status less worthwhile than building code or bridges or houses or painting pictures? People get to choose the game they play.

Because that's not how they perceive their works. Instead it is "advocating for one's own team and passion", "helping others advance their career", "networking and building long-term connections".

I’ll never understand this WHY X - BECAUSE Y - WELL Y IS TOO MUCH, Z IS MORE THAN ENOUGH comment trifecta. Obviously a lot of people are not super happy, otherwise they wouldn’t kiss asses and play politics to get more money.

Other than the big house, which can easily be achieved in much of the country, nothing in the list above incentivizes me to either work harder or kids ass.

You need to have the right personality. Either actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort. We don't get to choose our personalities, though some limited modifications are possible - see treatments for personality disorders, for example.

> actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort Ie. Somewhat serious mental disorders as requisite for leadership. I wonder how we got onto this darkest timeline?

Humans were like this since the inception of times. Chieftains, Khans, Czars, Kings, etc.

If it's adaptive it's not a disorder.

sweet , a new way to justify addiction

Evolution. It is a brutal process.

Well, I think that it depends on perspective and motivations. Kissing asses/politics can be treated as skill used for different purposes. Imagine your ambition is to build bridge, skyscraper or fancy opera house. To be chosen as the one for such projects, you must play many games including politics. (I assume good intentions, selfish ones are possible too, but are they worth discussing?)

It isn't the highest paying path in life, but this is what I chose as well. Working for small companies with good people is infinitely better than working at massive companies with decent people. No matter how many good intentions there are, the politicking is utterly exhausting and unfulfilling. Then again, I'm the kind of person who moved to the countryside to get away from the city life, so YMMV.

we are human being interacting with other human beings. what you call "kissing ass" is just learning to influence and work with other humans. It is by far the most useful skill to have in workplace. But don't worry. continue your disdain of it, includeing calling it negative names, and watch your career stagnate.

> It is by far the most useful skill to have in workplace. This might be defacto true in most workplaces, but defending "politics over competence" boils down to "I deserve the rewards from other people's work". People oppose it because it is morally wrong, not because they think it is an inaccurate description of reality.

It’s not politics over competence. It’s getting things done in the real world

(Every gang leader and dictator ever): That's right!

You say that as if politics is optional. It isn't, decisions need to be made and politics is the process of making those decisions: who decides, and why. In academia, for example, there is less politics because the publishing system sort of becomes the decision process. You apply with your ideas in the form of papers, the referees decide if your ideas are good enough (and demonstrated well enough) for the wider audience to even get to see. Then some politics, a popularity contest. But crucially this system famously leads to a LOT of resources being wasted, good research that never goes anywhere because nobody cares about it, or bad research that does nothing but everyone cares (cold fusion). Politics is just a name for how we decide things. And yes, it sucks, but that's because we suck.

With this understanding of academia, you are perfectly suited to doing software development for them, because if you think there is "less politics" in academia, you are being foolish. Academia is notorious for politics, especially around tenure and grants, scholarships, etc. Publication politics are just a small part of that, but even there, working out which name goes in what order of the authorship of the paper is political.

Sometimes. Sometimes it's just bullshit . Learn the lingo, the language, the proper way of posturing and the correct way to shirk responsibility and that's what matters in certain orgs. I sound really bitter, but I'm not, I'm actually quite good at the game and I've proven that, I just don't really like the game because it doesn't translate into being able to take pride in what I've done. It's all about serving egos. Your own and others. Every french multinational I've worked for is entirely built on this.

> I'm actually quite good at the game and I've proven that, Good. I failed and very likely about to face consequences.

Nobody that actually matters will hold it against you. Fuck the posers. Do real shit.

You're not wrong. You're just missing the thing people are complaining about: The existence of people who succeed in pushing for inferior solutions, and managing to leave before it becomes clear (which can take years in a large company). My previous company is in a bad position and many such folks are finally being outed. But it takes lots and lots of screwing up before the fat is trimmed.

> The existence of people who succeed in pushing for inferior solutions, and managing to leave before it becomes clear Guess this is just random evolution at play. Some companies will pay a bigger price than others. And not everyone even recognizes it and pinpoint it like you did. But overall influencing people is on net good skill for the individual. And what is good for the geese is good for the gander??

I've literally never had the thought of "how do I influence other people." Why is that considered a valuable skill? It just sounds like a nicer version of "manipulation".

If other people are not smart enough to see why your ideas are superior then you need to explain it to them or otherwise convince them to go along somehow. Most of my "influencing" is just repeatedly explaining things to people and letting them think through all the bad ideas and dead ends themselves.

> I've literally never had the thought of "how do I influence other people." Why is that considered a valuable skill? If you're a software developer you must have thought "current priorities are not right, we should do X for the users / Y to get better quality" and tried to influence your management to get those priorities moved. Maybe by starting a campaign with your users so the demands come from multiple services and not just you, or by measuring quality indicators and showing how what you want to implement would improve them etc. That's why you want to start getting coffee with people, maybe go outside with the smokers. It can take months of "work" to get people to propose the idea you want done. But this kind of influencing won't help your career.

Do you consider educating people “manipulation”?

Nah, people say this all the time but organisations where these sorts of gratuitous social games are absent tend to BTFO of organisations where they're present/expected.

Or continue being an ass and kissing asses, and watch the workforce unionize and see how the people YOU disdain shows you who has the real power

> The top people are all who kissed each others ass and looked out only for their cohort (e.g. people who were in same positions as them in early 2013). So teach your kids to kiss ass and play poltiics. After more than 20 years in big tech, I agree, this is basically it. Your work can only get you so far. If it makes you feel any better, you can reframe politics as 'people systems' and work on optimizing the relationships in the system. Or whatever. But the gist of it is to find a powerful group and try to become a member of that group.

> So teach your kids to kiss ass and play poltiics. Teach your kids to kick ass, and to distrust politicians.

>b/c they didn’t know how to play politics Or they refuse to play that bs game

True. I used to count myself in that category. Do the work and stay away from games. I was also thinking of myself as clever, self-respecting by doing hard work and leaving daily politicking for others. And now sometime back I got like 2-3 dressing downs from managers, reason being I am not taking leadership feedback seriously enough and mending my ways. This despite I am only one with left with knowledge of legacy system. Clearly I am pretty dispensable while thinking otherwise all along. No outside prospects considering market situation, miserable current workplace ultimately due to my choices. So in end just no winning for me by not playing game.

Politics and leadership is a responsibility. By avoiding it, you're setting a bad example. Once you know how an organization works, you should help lead it. If we consider a family, you're essentially saying you'll only "do the work": brush teeth, feed kids, clean up, but not take on any responsibilities for the actual goals of the family. Not pushing to have your kids learn things, just executing somebody else's ideas, driving them to sports; not improving the living situation by perhaps investigating if you should get a bigger car. Nothing leading, only executing the ideas of your spouse. I exaggerate of course, but there is something there.

Thats sociopathy in corporate world. Big companies have often 20-40% of such individuals, ie finance has way more (as I see daily) and concentration rises as you rise up in ranks. The thing is - you don't have to play that game. Sure, you will miss some promotions to largely meaningless titles, much more stress and pressure in such work, and a bit of money but in most companies the money is not worth it (ie work 50% more to get 20% more compensation, in net income rather 10% more since extra income will be hit with high marginal tax bracket in most countries). But main reason is - what you do 40+ hours weekly for decades (and especially how you do it) seeps back in into you even if you actively try to prevent that. Is it really worth tainting your personality permanently with more sociopathic behavior and thinking, with subsequent negative effect on all personal relationships and even things like personal happiness? I am old enough to see these trends among peers, they are very gradual but once you know what to look for, rather obvious. When poor such a deal is easy to rationalize since poverty can be crippling, but once beyond that quality of life should be top priority, we are here for rather short time. Otherwise most probably regrets happen later, just listen well to old folks what they are proud of and what not so much.

This kind of thinking is how you get cults of personality. If he puts his name to this kind of slop, I’ve probably not missed much.

It is good only if the whole team believes it. If the team mates have a different mindset, they see it as half baked or hacky. And if there is ever some bad feedback, they just use it as a "I told you so" and throw you under the bus.

If your self-esteem is sufficiently resilient, you can exploit the same human tendencies behind Cunningham's Law (the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer). Check your crappy end-to-end proof of concept into the team repository, and your teammates will be so horrified and outraged that they'll fix it faster than any sprint could have planned.

This resonates a lot. The shift from "was I right?" to "does this actually help people?" changes everything. I've found that the engineers who got promoted fastest weren't always the smartest problem solvers, they were the ones who genuinely cared about the end outcome. The hardest part is that user focus is sometimes at odds with technical cleanliness. You can ship something inelegant but useful, or elegant but slightly off from what people need. Most orgs mess this up by choosing elegance.

Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. I think there are multiple reasons for this, but they are mostly overlapping with preserving internal power structures. PM's don't want anecdotal user evidence that their vision of the product is incomplete. Engineering managers don't want user feedback to undermine perception of quality and derail "impactful" work that's already planned. Customer relations (or the support team, user study, whatever team actually should listen to the user directly) doesn't want you doing their job better than they can (with your intimate engineering and product knowledge). And they don't want you to undermine the "themes" or "sentiment" that they present to leadership. Legal doesn't want you admitting publicly that there could be any flaw in the product. Edit: I should add that this happens even internally for internal products. You, as a customer, are not allowed to talk to an engineer on the internal product. You have to fill a bug report or a form and wait for their PMs to review and prioritize. It does keep you from disturbing their engineers, but this kind of process only exists on products that have a history of high incoming bug rate.

> Engineers have a perception that most other roles are lesser Do they? I always felt I was at the bottom of the chain. "Moving up" means leaving engineering and going into management. > and if only they were allowed to be in charge things would go better. Could this be an oversimplification? Engineers understand how the product is built because they are the ones building it. And sometimes they are exposed to what other people (e.g. product people) have decided, and they know a better way. As an engineer, I am always fine if a product person listens to my saying that "doing it this way would be superior from my point of view", somehow manage to prove to me that they understood my points, but tell me that they will still go a different direction because there are other constraints. Now I have had many product people in my career who I found condescending: they would just dismiss my opinion by saying "you don't know because you don't have all the information I have, and I don't have time to convince you, so I will just go for what you see as an inferior way and leave you frustrated". Which I believe is wrong. Overall, I don't make a hierarchy of roles: if I feel like someone is in my team, I play with them. If I feel like they are an adversary, I play against them. I don't feel like I am superior to bad managers or bad product people; I just feel like they are adversaries.

There are many leaders that use information as a tool that serves their own needs. They may have the context, but they are either too focused on their own job to share it, or actively manage dissemination so they can manipulate the organization. In my experience, this is the typical operating mode, though I do not think it is sinister or malicious - just natural.

> Every previous job I've had has a similar pattern. The engineer is not supposed to engage directly with the customer. Chiming in to say I’ve experienced the same. A coworker who became a good friend ended up on a PIP and subsequently fired for “not performing” soon after he helped build a non technical team a small tool that really helped them do their job quicker. He wasn’t doing exactly as he was told and I guess that’s considered not performing. Coincidentally the person who pushed for him to be fired was an ex-Google middle manager. I’ve also seen so commonly this weird stigma around engineers as if we’re considered a bit unintelligent when it comes to what users want. Maybe there is something to higher ups having some more knowledge of the business processes and the bigger picture, but I’m not convinced that it isn’t also largely because of insecurity and power issues. If you do something successful that your manager didn’t think of and your manager is insecure about their own abilities, good chance they’ll feel threatened.

"10. In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency. The engineers who stay sane and effective zero in on their sphere of influence. You can’t control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you. This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can." ------------------------ Point 10 makes it sound like the culture at Google is to stay within your own bailiwick and not step on other people's toes. If management sets a course that is hostile to users and their interests, the "sane and effective" engineers stay in their own lane. In terms of a company providing services to users, is that really being effective? User interests frequently cross multiple bailiwicks and bash heads with management direction. If the Google mindset is that engineers who listen to users are "weird" or not "sane"/"effective", that certainly explains a lot.

PM is a fake job where the majority have long learned that they can simply (1) appease leadership and (2) push down on engineering to advance their career. You will notice this does not actually involve understanding or learning about products. It's why the GP got that confused reaction about reading user reports. Talk to someone outside big company who has no power? Why?

Sounds like you just got stuck with a shit PM to be honest.

Almost every job in the US is primarily about pleasing leadership at the end of the day. If companies didn’t want that sort of incentive structure to play out then they would insulate employees from the whims of their bosses with things like contracts or golden parachutes that come out of their leaderships budget. They pretty much don’t though, so you need to please your leadership first to get through the threat of at will employment, before considering anything else. If you’re lucky what pleases your leadership is productive and if your super lucky what pleases them even pleases you. Gotta suck it up and eat shit or quit if it doesn’t though

I was going post exactly this! He was talking about those engineers that really exemplified, from his point of view, good engineers. And dealing with engineering managers that didn't see much use in such activity might be part of "figur[ing] out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity".

To me; point #3 is the big one and it is in conflict with point #1

> 1. The best engineers are obsessed with solving user problems. The author lost me right here. Not because he’s wrong about this in general - he is not. But it seems to not be any kind of differentiator at Google. Maybe the opposite is true- make it as screwed up as physically possible, then make it a little worse, then release it - that seems a lot closer to the lesson Google engineers learn. As long as you are “first” and shipped it. Then get promoted, move on and meanwhile your crap code eventually gets the axe a decade later.

Eh, sure. But at the same time lessons aren't learned by reading what someone else has to say. They're learned by experience, and everyone's is different. An engineer with "14 years at Google" hardly makes them an expert at giving career advice, but they sure like to write like it does. This type of article reads more like a promotion piece from self-involved people, than heartfelt advice from someone knowledgeable. This is evident from the author's "bio" page: written in 3rd person, full of aggrandizing claims of their accomplishments, and photos with famous people they've met. I'm conditioned to tune out most of what these characters have to say. If this is the type of people who excel in Big Tech, it must be an insufferable place to be.

Mood. As someone who normally leaves after two years because the opportunity never raises to what was offered in the job spec these really don't for for me these bullet points as well wouldn't work for office culture in the EU. 15 Years worth of jobs and none gel. I'm a contractor now which feels more me. I have a contract length, don't have to deal with red tape political bullshit. Turn up, do work and leave when contract had ended.

Sun Tsu said you have to either give your opponent an out or completely destroy them. I’ve always said that you can only skin a sheep once but can shear them over and over. Or to be more blunt, it’s better to be effective than right. It’s about keeping the bigger/long term goals in mind. That means relationships and being an asshole.

Nothing novel, but all true, well expressed, and worth repeating. This should be part of every CS curriculum. #2 and #14 are tough pills to swallow. It's not enough to be right, or even have a long track record of being right. You usually have to convince others that it was their idea all along, but still advocate for yourself at performance review time.

He led Chrome DevRel for many years - if you were learning about new web platform technologies circa 2010-2015 you probably ran across his writing. The bio is cringe, but the important thing to realize about these professional-networking bios is that they are sales pitches, intended to sell a person (and specifically, their experience and connections) to a large corporation who will pay them even more money. An ordinary person, with ordinary authentic emotions, is not the intended audience. They're specifically selling to people whose job is to deal with bullshit.

Seems reasonable. Many points maybe more applicable Google/Google-like companies. With layoffs and overall job shortages a lot of workplaces are having a cake and eating it too. They demand fast delivery and taking shortcuts (calling it creative thinking ) and once things blow up directly due to shortcuts put blame on developers / testers for taking shortcuts and compromising quality in the process.

> The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected. > The engineer who starts with a solution tends to build complexity in search of a justification. I do agree this is a good point, I just find it funny that it comes from "staying 14 years at Google". This is literally the reason why I left Google first, and Meta second. Finding simple solutions will get you absolutely nowhere in a place like those. You have to find complex solutions with a lot of stakeholders, alignment, discussions, escalations... Why ship one button if you can ship 100 and get you, your team and your manager promoted in the process?

> In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional. Very true in large organisations. But... in a company whose stated mission is to " organize the world's information and make it universally accessible and useful " ... this feels like a failure. When a truly data driven company manages to quantify impact by more than the volume of hot air emitted :) then it's going to eat the world. Perhaps it's for the best that nobody does that?

> 13. The work that makes other work possible is priceless - and invisible. > Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. ... The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact. Timebox it. Rotate it. Turn it into artifacts ... make it legible as impact, not as personality trait. I see my own experience in this, but I don't think he's identified the problem correctly. Timeboxing, rotating, etc, is easy. Convincing management that it is as important as non-glue work and therefore worth allocating your time for it is the hard part. And if you can't do that, you end up stuck in the situation described. The other option is to just let things fail of course, but then you have to convince both management AND the rest of your team to do this, otherwise someone else will just pick it up between the cracks too.

These lessons should be learned by every junior engineer and shared with every other engineer. I agree with the point, “Your network outlasts every job you’ll ever have,” that you mentioned. I literally know developers who aren’t actually good at what they do, but they always manage to find another job.

#3 hit hard. You can edit a bad page, but you can't edit a blank one. I've wasted weeks overthinking architecture for things I'd never built. Shipping something ugly and learning from real feedback taught me more than any amount of planning. Also #6 is underrated. Early on I thought good work speaks for itself. It doesn't. Took me years to realize decisions happen in rooms I'm not in. If no one can explain your impact when you're gone, it doesn't exist. Thanks for sharing this.

This and the other top story on HN right now ( I charged $18k for a Static HTML Page) [0] make it clear the the most important thing as a software developer is jumping through hoops and being agreeable. It does not matter if it makes sense to you. I’ve come to accept that I can’t always predict what is actually valuable for the business and should just go with the flow and take their money. The leetcode-style interview selects for this by presenting as an arbitrary hoop you have to jump through. [0]: https://news.ycombinator.com/item?id=46469877

Number 14 really speaks towards the subtle difference between being domineering in conversation and genuinely a sme in an area with little overlap in other people's domain knowledge. I feel like being extremely transparent in explaining the rationale and to a degree teaching really reinforces that boundary. If you get to a point of silent resentment 'debt' in spite of efforts to empathise, consider perspective, and provide clarity, then you have a collaboration problem on the other end. How you choose to address that is dependent on your political capital, and sometimes you need to accept it. Young me naively believed people were like rational automatons who would speak up when appropriate, not take thinga personal, and aspire to the true north that I aspired to as a colleague, and that is no baseline for a healthy collaboration.

It's frustrating to read this advice, which to me can be summarized as "don't think too hard, dumb it down, keep it simple, be a people-person" and then look at their hiring process full of advanced data structures and algorithms. Why hire top tech talent if you just need to keep a simple vibe and not over-think clever solutions?

I'm going to pick out 3 points: > 2. Being right is cheap. Getting to right together is the real work > 6. Your code doesn’t advocate for you. People do > 14. If you win every debate, you’re probably accumulating silent resistance The common thread here is that in large organizations, your impact is largely measured by how much you're liked. It's completely vibes-based. Stack ranking (which Google used to have; not sure if it still does) just codifies popularity. What's the issue with that? People who are autistic tend to do really badly through no fault of their own. These systems are basically a selection filter for allistic people. This comes up in PSC ("perf" at Meta, "calibration" elsewhere) where the exact same set of facts can be constructed as a win or a loss and the only difference is vibes. I've seen this time and time again. In one case I saw a team of 6 go away and do nothing for 6 months then come back and shut down. If they're liked, "we learned a lot". If they're not, "they had no impact". Years ago Google studied the elements of a successful team and a key element was psychological safety. This [1] seems related but more recent. This was originally done 10-15 years ago. I agree with that. The problem? Permanent layoffs culture, designed entirely to suppress wages, kills pyschological safety and turns survival into a game of being liked and manufacturing impact. > 18. Most performance wins come from removing work, not adding cleverness One thing I really appreciated about Google was that it has a very strict style guide and the subset of C++ in particular that you can use is (was?) very limited. At the time, this included "no exceptions", no mutable function arguments and adding templtes had an extremely high bar to be allowed. Why? To avoid arguments about style issues. That's huge. But also because C++ in particular seemed to attract people who were in love with thier own cleverness. I've seem some horrific uses of templates (not at Google) that made code incredibly difficult to test for very little gain. > 9. Most “slow” teams are actually misaligned teams I think this is the most important point but I would generalize it and restate it as: most problems are organizational problems. At Meta, for example, product teams were incentivized to ship and their impact was measured in metric bumps. But there was no incentive to support what you've already shipped beyond it not blowing up. So in many teams there was a fire and forget approach to filing a bug and forgetting about it, to the point where it became a company priority to have SLAs on old bugs, which caused the inevitable: people just downgrading bug priorities to avoid SLAs. That's an organizational problem where the participants have figured out that shiping is the only thing they get rewarded for. Things like documentation, code quality and bug fixes were paid lip service to only. Disclaimer: Xoogler, ex-Facebooker. [1]: https://www.aristotleperformance.com/post/project-aristotle-...

I hate that he is right. It speaks deeply about how broken the incentives are for humanity and labour and why AI will ultimately destroy jobs, because AI won't need to deal with all the sacred rituals around politics and control and human management. For each stupidity that we worship just to "preserve company culture", we step into the inevitable doom like having a Google principal engineer worship Opus on X like it's the first time they went to prom and saw someone hot. It is sickening and it is something we have internalized and we will have destroyed ourselves before we settle on the new culture of requesting excellence and clarity beyond the engineers who have to deal with this mess.

Yeah, "resume driven development" is a second major force pushing complexity that I didn't mention. People want to be able to get experience with as many buzzwords and technologies and stacks as they can for obvious personal self interest reasons. The incentive is real. A great programmer who does a great job simplifying and building elegant maintainable systems might not get hired because they can't say they have X years experience with a laundry list of things. After all, part of their excellence was in making those things unnecessary. It's a great example of a perverse incentive that's incredibly hard to eliminate. The net effect across the industry is to cost everyone money and time and frustration, not to mention the opportunity cost of what might have been had the cognitive cycles spent wrangling complexity been spent on polish, UI/UX, or innovation. There's also a business and VC level version of this. Every bit of complexity represents a potential niche for a product, service, or startup. You might call this "product portfolio driven development" which is just the big brother of "resume driven development."

That's a solid set of lessons. My favorite is that Software doesn't advocate for you, people do.

Here's the lessons all ex-Google colleagues I've worked with have brought with them to their new jobs: 1. Use Bazel for everything. Doesn't matter that the documentation sucks and it's unbelievable bloat for smaller companies: use it anyway. Use it for everything. 2. Write things from scratch. Need a protobuf parser in C? Just write one up instead of using any of the battle-tested open source options. 3. Always talk down to frontend engineers and treat them as lesser/ not real engineers. Real engineers are backend engineers. Frontend is so easy that they can do a perfectly fine job if needed. Make sure to use Bazel for all frontend builds. 4. Did I mention Bazel? It's the solution to all problems for all companies.

I feel like the best lesson in here wasn’t numbered, but in the opening statement: > the longer I’ve stayed, the more I’ve realized that the engineers who thrive aren’t necessarily the best programmers - they’re the ones who’ve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity. I have been banging on about this for _years_. I’ve seen engineers much smarter than me and who write much better code fall afoul of this too. Being personable and easy going and insightful for one hour in a meeting can do more for your reputation within a company than a month of burning yourself out completing more tickets than anybody else. I really wish more people understood this. At the end of the day, a manager or a project director who _wants_ you to join a meeting just because you’re a joy to be around and you may have some insight, shows you’re more valued than the best coder on the team if they’re a pain to bring into a meeting because they’re hard to talk to.

I manager that invites people in meeting based on how obedient they are, is a bad manager. Multiplied by the number of reports. Fix that.

I didn’t mention obedience, I mentioned pleasantness. Not sure what you’re on about with reports either. You ok?

Main lesson from 14 years anywhere should be don't spend more than two years at one job. Because otherwise you start thinking that politics matters.

What a mediocre article. Its just enough for people to agree and nod and go "wow yeah true!!" while offering almost zero value to people who don't already agree. These are not useful to juniors. Yes, almost all of this is true and well said, but it offers no additional value. It's like a smell test: Show this article to engineers and those who disagree with lots of points should be given a senior mentor. These points are really good, but they often miss context and further info and caveats. I would have liked if the Author just added a little bit more content. Like, for example, the point about "Being right is cheap. Getting to right together is the real work". Yes, it's certainly true that a decision made in agreement is better than one that isn't. However, how do you get there? Does everyone else give up their (weakly held, according to the article) opinions? I would argue it should be acceptable for your opinions to hold, to be factually based, and still to not align with the final decision made. Any respectable engineer should be fine with this. > Your code doesn’t advocate for you. People do. It depends on how much code you output relative to others, for example, and how performance is measured, how much time is actually spent in meetings (and how much of that is wasted or could-have-been-an-email). I've been told at a previous job that the quality and amount of code I output made them reconsider their entire salary- and bonus-structure (and they did restructure it but by the time it went into effect I had gotten a better offer and left). I just had more programming experience than most other developers there (through open source and my own projects), even though I was junior to most of them. Your code can advocate for you, and so can your general output, your contributions, etc. It's not all politics in all companies, though I'm sure the author's point applies at FAANG. Furthermore, I don't know if this point results in actionable advice for juniors, for example. To not bother writing good code? To not bother with doing the best you can? To not honing your skill and instead go to public speaking courses? I'm not sure. Good-ish article, just not enough novel substance IMO, and reads a bit like AI slop. Also choked on this: > Colleagues often remark on Osmani’s humility and generosity despite his fame in the field.

Seems like the author had lost his personality during that 14 years trying to appease the strange people at the top or figure out the allpermeating bs they force on people.

Oh my god. I have never seen an about/bio page even half as gross and cringey as his. https://addyosmani.com/bio/ It's so obscene that it seems like it's a parody > Colleagues often remark on Osmani’s humility LOL! Who writes these things about themselves with a straight face?! It also shows that taking credit for others' work is 100% his MO. > Osmani’s team created Workbox, a set of libraries for generating service worker scripts that handle caching and offline functionality with minimal fuss. Workbox simplified what used to be a complex task of writing low-level code to intercept network requests. No, Jeff Posnick (who I suppose technically was on addy's team) created workbox and it has been basically abandonned since he left Google. Or was it Sundar Pichai's team who made workbox? Or does Brendan Eich deserve the credit? I have to assume the rest of the bio, and his career, has been built off of usurping credit. He always rubbed me the wrong way, and this vindicates that sense. What a psychopath!

Oh my god. I have never seen an about/bio page even half as gross and cringey as this. It's so obscene that it reads like a parody > Colleagues often remark on Osmani’s humility LOL! Who writes these things about themselves with a straight face?! It also shows that taking credit for others' work is 100% his MO. > Osmani’s team created Workbox, a set of libraries for generating service worker scripts that handle caching and offline functionality with minimal fuss. Workbox simplified what used to be a complex task of writing low-level code to intercept network requests. No, Jeff Posnick (who I suppose technically was on addy's team) created workbox and it has been basically abandonned since he left Google. I have to assume the rest of the bio, and his career, has been built off of usurping credit. He always rubbed me the wrong way, and this vindicates that sense. What a psychopath!

it's a bit weird to talk about yourselves in third person

And have a look at the bio: https://addyosmani.com/bio/ > His story isn’t just about writing code, but about inspiring a community to strive for a better web. And perhaps the most exciting chapter is still being written, as he helps shape how AI and the web will intersect in the coming decade. Few individuals have done as much to push the web forward while uplifting its developers, and that legacy will be felt for a long time to come.