First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee the software was ready before they’d even stood up from their desk!
The moral of the story, and the quote, isn’t that you shouldn’t improve things. Instead it’s a reminder that the software you’re building doesn’t exist in a PRD or a test suite. It’s a system that people will interact with out there in the world. Habits with form, workarounds will be developed, bugs will be leaned for actual use cases.
This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. 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 load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee
One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk.
I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.
Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.
What a great comparison; I've never thought of it this way. It's obviously not perfect since the automation is so temperamental shall we say, but this does give me more empathy for the countless workers whose jobs have been re-natured by technology.
There’s many praises to sing about efficiency, (and I don’t take your 1 liner as a position against it). That said, efficiency, job creation, and underemployment overlap quite a bit.
There’s far more scientists, programmers, and doctors today than farmers and stablehands.
At the same time, people who lost manufacturing jobs to automation and outsourcing, did not get jobs with equivalent pay and growth.
Human brains do not get retrained very easily, and so every technological revolution is a boon to those who grasp it, and a challenge for those who invested their time in skills no longer in demand.
One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.
In Norway there's laws for that, but other places do it even without them. You just retrain the person to do something else. He might take a job of a temp that was hoping to get a fast contract (instead of a few weeks at a time during trial period). Other than that, it's good for the person (not losing job) but also for the company - you get a tried person with good work ethics that comes on time. It's not zero cost to find somebody like that.
A lot of places in the US are not, in my experience, that intelligent about hiring people.
Or, say rather, the externalities of the cost of hiring are not imposed on the people choosing to fire, directly, so they can say they "improved efficiency" by firing someone, and then the people trying to find reliable labor do not experience any improvement that might have been available by migrating the person.
agreed. the "lump of labour" fallacy is a thing -- the idea that there are always more bodies and that it's trivially easy to hire, train / get up to speed, and work them.
in practice hiring and firing is expensive and often very risky. Bjorn the office worker may now be redundant and have a room temperature IQ but he's shown he'll show up on time, sober, and is liked by his coworkers enough, so throwing $5k to retrain him may be a far, far smarter investment then blowing $7k to hire a rando for another position...
Yeah the bar for competent is surprising hard to hit. A human being that shows up on time and it's reliable, doesn't have a problem with drugs or alcohol, or has a sick family member and just needs an advance. Good help is hard to find!
then the pendulum swings the other way and now I have ruthless mercenaries chasing $$$ who will jump at the first opportunity
and not every job needs to be top-shelf.
Betty in Accounts-Payable just sorta needs to be there and not screw up too often. I don't need a super-star, and if we have to move her to another part of Accounting that's fine; I'll save my money for a solid CPA or two, etc.
I understand the rest, but an otherwise capable person with a sick family member does not clear the bar for competent? Saddening if that’s where we are as a society.
I think the key part of that sentence was "...and just needs an advance", implying that they're going to take the job, ask for a cash advance for a (possibly fictional) sick family member, and immediately quit.
Many laws solve the problem of high initial cost dissuading globally good actions. Laws forcing everyone to buy insurance, for example. It's very easy to see that where such laws don't exist, almost no one buys insurance, making everyone worse off.
Healthy young people are less likely to buy insurance than sick older people. But if only sick older people buy insurance the payouts per insured are going to be higher. That in turn causes high premiums. Insurance works if everyone buys in, pays while they are young and relatively healthy, and gets paid healthcare when they are older and sicker.
If you “game” it, it breaks the whole system.
Now some of you might be thinking “why should a young and healthy guy like myself subsidize the old sick people?” The answer is that you will also get old.
What you are describing isn't really private insurance though, its a privately run socialized healthcare system. There's nothing wrong with that, it simply isn't insurance.
Think of something like home owner insurance. Your insurance rates depend on exactly how your home is built, what type of heating system it has, where it is, etc. The rates, carefully calculated by actuaries, act as a signal to you as to how dangerous your house is to yourself, but also to others. If you set your house on fire due to negligence and cause the next house to burn, you might be liable for damages there as well.
Forcing everyone to buy such insurance forces everyone to fully pay for the expected cost of the danger inherent in their house. Over time, this causes houses to be constructed in a safer manner. If people are not forced to buy insurance, they don't buy it, and so this evolution over time does not happen. Also see [1].
Some financial tools are amazingly clever - whether they are morally good or bad. Bits about Money is a great blog to build insight into some of these constructions [2].
Another example for your initial question is car seats for kids. If you don't force em, nobody buys em. Then their kids die.
For the insurance example, you're describing insurance as a forcing function for better made, safer buildings. That's what building codes are for though, we shouldn't need to have both and building codes are a more efficient and direct way of ensuring safe buildings.
For car seats, I'm not sure how we could know that people wouldn't buy them. I don't expect anyone would propose dropping the requirement to see how the market responds, and probably rightfully so. If car seats are much safer though (and I'm obviously not disputing that), people that can afford one would buy it anyway.
I agree that in an ideal world that would be sufficient. But in practice, governments rarely deploy trained actuarial to make decisions, rather relying on politics and shoddy studies. Government codes also change very slowly. Insurance companies (whether private or public), under the financial incentive, are constantly changing their policies and rates in response to new data and calculations. I would be open to looking at studies that resolve this question one way or another.
> ... car seats...
I grew up in a poor global south country. Rich people, who clearly can afford them, don't buy car seats. Many people who live in countries where they are forced to buy car seats, when they come back on vacation don't use car seats for their kids. People can be very irrational.
I'd love to see this argument used to get rid of legal authority to create building codes. You make a great point, and you're effectively pointing to the fact that, at least for that specific problem, the market is much more efficient and solving the problem than government regulations.
The car seats one is tough. If you've seen first hand examples of people actively choosing to forgo car seats, I'm not sure if that's a problem governments should solve. Unless the state directly claims "ownership" as it were in the child, the parent is their legal guardian and if the parent makes a terrible choice they have to live with the repercussions. We don't regulate all decisions that can harm a child, that's a tough line to draw.
Norway has very strict pro-workers laws in general, it's just one facet of them.
One Norwegian explained it to me like that: in the late '60 when Norwegian oil industry started developing, workers realized that they can incur great losses on the companies if they organize/unionize and strike together. They used that as a leverage to both change their contracts (to include paid sick leave and such) and also get better working conditions (Norwegian platforms have both better safety and on platform to on land ratio).
And later other trades did the same. Some of the things in contracts trickled down to the law. But still some laws apply only to companies where at least a certain % (is it 50%?) are unionized.
The general picture is more or less like that, but please verify the details.
And they will have to go find another job instead. It feels weird but this is how we raise living standards - removing human labor from production (or, in other words, increasing the amount produced per human)
Automation is a game of diffuse societal benefit at the expense of a few workers. Well, I guess owners also benefit but in the long term that extra profit is competed away.
That's a highly idealized view that I hope we can agree doesn't completely jive with what we see in society today. If a small number of shareholders reap all the profits, the vast majority of the benefit from automation flows to them, and it's even possible for the lives of average people to get worse as automation increases, as average people then have less leverage over those who own the companies.
Incomes are up, but the expenses are up as well, especially with the upcoming changes in healthcare for people on the ACA.
Also any comparison of wage growth vs corporate profit growth over the last 30 years shows that wages have not kept pace with the increase in productivity.
So incomes are only just barely keeping up, when they should be booming.
Household income is more than just wages. Household income can go up while wages remain stagnant or shrinking because other pieces of the pie are increasing (e.g. work benefits, investments, money from the government). https://fredblog.stlouisfed.org/2016/09/sources-of-household...
The price of housing can rise even faster than incomes.
Housing is only a part of the basket used to measure inflation. Housing's price rose faster than the weighted basket average, some other goods and services rose slower or even fell.
Many people don’t see housing inflation - if you bought a house in 2020 and house prices were up 80% since then it doesn’t affect your housing costs, especially in the US where mortgage rates are fixed for length of term even if interest rates sky rocket.
As long as accommodation isn't 100% of your basket of goods and services you use to measure inflation, accommodation can rise in price faster (or slower) than the basket. This ain't exactly rocket science.
Yet more and more people are struggling to afford even basic necessities and one can only dream of the luxury of the 50's when a single working class person was able to pay and cover for housing, car, family and even have enough for leisure. Where has all the economic surplus gone? Right...to the bourgeois, the capital owning class that exceedingly extract more and more of the wealth generated by the society.
On average, most large cap stocks (MSFT, GOOG, AAPL, etc) are owned by millions of retail investors through 401Ks, mutual funds, ETFs, and direct ownership.
Actually I believe this graph is half of US-owned equities and mutual funds is owned by the top 1% of Americans right? This doesn't include other extremely large holders such as sovreign wealth funds like norway/singapore or very large pension funds like the ontario teachers fund etc....
The USA is rather unique in its low pensions compared to countries in the EU or Australia (notable for its high contribution rates).
I'm all in favour of lowering barriers to entry, too. We need more competition.
Be that from startups, from foreign companies (like from China), or from companies in other sectors branching out (eg Walmart letting you open bank accounts).
Everybody can be a shareholder in a publicly traded company. It's pretty easy.
If you want to spin up some conspiracy theory about elites snatching up productivity gains, you should focus on top managers.
(Though honestly, it's mostly just land. The share of GDP going to capital has been roughly steady over the decade. The share going to land has increased slightly at the cost of the labour share.
The labour share itself has seen some shake up in its distribution. But that doesn't involve shareholders.)
Everyone with excess disposable income can be a shareholder in a publicly traded company.
The oligarchy of the CxOs and boards and cross-pollination has led to concentration of the rewards of companies into the their hands, compared to 40 years ago.
All the productivity gains have not gone to labor, its predominately gone to equity and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.
The craziness of the USG borrowing to fund tax cuts is the ultimate example.
> [...] and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.
You seem very confused about how capital markets work. Are you also suggesting buy backs are morally different from dividends?
In any case, the whole point of investing (at least to the investor) is to eventually get more money back than you put in. Returning money to investor is not a bug, it's the point.
> The craziness of the USG borrowing to fund tax cuts is the ultimate example.
It's narrow vs wide views. Wide views, automation and the like has improved the economies massively. But narrow views, people have lost their jobs, had to retrain and basically restart their career, and some never found another job.
This isn't just automation btw, but also just business decisions, like merging companies, outsourcing, or moving production elsewhere - e.g. a lot of western European manufacturing has moved eastwards (eastern Europe, Asia, etc). People who have a 30+ years career in that industry found themselves on the proverbial street with another 10+ years until their retirement, and due to trickery (= letting their employer go bankrupt) they didn't even get paid a decent severance fee.
I've not seen a correlation between automation and wealth, though there is an extremely string correlation between energy use and wealth.
I don't think its automation that increases living standards. We increase living standards by consuming more energy, and that often comes along with increasing the amount of costs we externalize to someone else (like pollution or deforestation, for example).
We document the cumulative effect of four decades of income growth below the growth of per capita gross national income and estimate that aggregate income for the population below the 90th percentile over this time period would have been $2.5 trillion (67 percent) higher in 2018 had income growth since 1975 remained as equitable as it was in the first two post-War decades. From 1975 to 2018, the difference between the aggregate taxable income for those below the 90th percentile and the equitable growth counterfactual totals $47 trillion.
"Laid off" may be more appropriate than "fired", but in essence, removing the need for costly labor is often the main "value" of any technology. Society as a whole comes out ahead from it, I mean for all the ice transporters and merchants put out of a job by electric refrigeration, and all the sailors put out of a job by modern cargo ships I think we're better off for it. But at the individual level it does make one uneasy about the prospects of individuals affected by it. My personal conclusion is that people have a personal duty to anticipate and adapt to change, society might give them some help along the way but it doesn't owe them that their way of life will be maintained forever.
Economy should be a tool for the society and to benefit everyone. Instead it's becoming more and more a playground for the rich to extract wealth and the proletariats have only purpose to serve the bourgeois lest they be discarded to the outskirts of the economy and often to the literal slums of the society while their peers shout "you're just not working hard enough".
Very true. We waste alot of valuable labor on “software engineering” that is grossly inefficient. Capital gets allocated to these so called startups that are incredibly inefficient.
This says a lot as relating to the rise of AI and the fear of job loss. There's going to be displacement in areas we can't predict, but overall it might very well just lead to leveling up the entire workforce.
> it might very well just lead to leveling up the entire workforce.
How could that possibly work?
At some point I could see white collar work trending down fast, in a way that radically increased the value of blue color work. Software gets cheaper much faster than hardware.
But then the innovation and investments go into smart hardware, and robotics effectiveness/cost goes up.
If you can see a path where AI isn't a one-generational transition to most human (economic) obsolescence, I would certainly be interested in the principle or mechanism you see.
Craftsmen will have a resurgence, that's probably a 'leveling up' in terms of resilience against AI takeover. There's just no way of automating quite a few of the physically effective crafts.
So the rich who can afford craftsmen will get richer, spend more on their multiple houses, perhaps. But that's literal crumbs, one or two jobs out of tens of thousands. There's no significant "leveling up" there at the societal levels of job destruction we're talking about.
I agree. I was brought on as an intern to do automation for a business team. The company had built this gargantuan complex "programming tool" to help the boomers who'd been there for 30 years adjust to the new world (a noble endeavor for mortgage holders without college degrees, i believe). I was brought in to basically fuck around and find little things to optimize. In 2 months I wrote a python script to do about 50% of the teams work near instantly.
They had layoffs every year and i remember when the "boss's boss" came to town and sat at our table of desks. She asked me and i excitedly told her about my progress. She prompted how i felt about it and i nearly said "its very easy as long as you can program". But mid sentence i saw the intense fear in the eyes of the team and changed subject. It really hit home to me that these people actually were doing a useless job, but they all had children who need insurance, and mortgages that need paying. And they will all be cast out into a job market that will never hire them because they came on at the very end of not needing a college degree. The company was then bought by a ruthless and racist "big man investor" who destroyed it and sold it for parts. But my manager did somewhat derogatorily refer to the only programmer near them as "the asian".
Back in the day one company had a dedicated copier operator who was very unhappy after a Xerox service tech did away with the job by enabling the network printing and scan to email functions. The customer had upgraded their old copier out of necessity but had never changed their workflow.
This will not be unusual for any kind of software engineering work to be honest. A big chunk of work in B2C companies has to do with customer support, for example; building websites, apps, writing content, chatbots, etc with the objective being that people do not call customer support, because people on phones don't scale very well. And the other part is that when they do call, that the CS agent can address the issue quickly and has minimal administrative overhead.
But it's a weird one, because it costs millions to build features like that.
I had that on my very first project. I couldn’t understand why the people on site were so hostile to me. Afterwards I was talking to the salesman about this and he told me they were all fired when the project went live.
> The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.
The faster the LLM spits out garbage code, the more time I get to spend reviewing slop and dealing with it gaslighting me, and the less time I get to spend on doing the parts of the job I actually enjoy.
Yup same story here, also warehouse optimization. I was the reason the employees got new scanners and oh my... the scanners didn't have a physical keyboard. Now all the 50yo+ would have to aim on a touch display which is apparently impossible.
Also we had to introduce some fixed locations and storage placement recommendations. Our storage workers almost revolted. After a few months it settled though.
It 100% was about optimization. Introducing new devices, with more capabilities (storage place recommendations for example), that weren't 10 years old and broke every 2 weeks is optimizing.
Insane mindset that people should work modestly, get paid modestly and live in the fruits of a wealthy society? As opposed to breaking their backs to make a boss even wealthier?
The efficiencies are always to the benefit of the wealthy, the wage gap grows. You work hard, you still get fired.
Cap top wages to 5x the lowest, companies can't own housing except socially beneficial housing, individuals get 2 house maximum.
> With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
Worked on public transport ticketing (think rail gates and stuff) with contactless last 30 years, when guys would tell me that the software was "ready", I'd ask:
> Is it "stand next to the gates at Central Station during peak time and everything works" ready?
We were working on the project from a different city/country, but we managed to cycle our developers through the actual deployments so they got to see what they were building, made a hell of a difference to attitude and "polish".
Plus they also got to learn "People travel on public transport to get somewhere, not to interact with the ticketing system."
Meant that they understood the difference just 200ms can make to the passenger experience as well as the passenger management in the stations.
> "People travel on public transport to get somewhere, not to interact with the ticketing system."
I really like this line because it applies to so many things we build.
Public transport is an interesting one because it applies to so many things. If you need to use it but can't depend on it, it's a huge stress creator and time waster. Suddenly you need to pad times by hours to ensure you don't miss your appointment.
Notice the words there, "miss appointment" and not "miss bus or train". The outcome is what matters, not the transport mechanism.
Or, maybe you're traveling in a foreign country. Having every car in the metro display the line in a digital way showing the previous stops, current location and next stops in English is huge for eliminating doubt. Having the audio in multiple languages and clear is important too because maybe you're sitting down and everyone is standing in front of you so you can't see the display clearly. Having a non-digital map as a backup on the wall in case there's a hardware failure is a good idea too.
Thinking "no one needs any of that waste because they can just use their phone" is the wrong mode of thinking. Maybe there's no service because you're underground or maybe that person's eSIM isn't hooked up yet or isn't working. These are real problems.
The travel experience outcome in the grand scheme of things matters a lot. It could mean having a smooth trip or a questionable experience. It could be the difference between recommending the country to your friends and family or not. Suddenly it affects tourism rates at a global scale. Maybe not a lot, but it has an impact.
For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!
> 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.
Lehman talked about the developer-software-user triad. Each of the three have a different understanding of the problem to be solved.
Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do.
> Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world.
> This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. 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.
You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".
Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off.
Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.
As a developer of new things, if you allow someone else to capture this value from you, you become fungible; additionally, for your group, having technology designed to solve problems without grounded but expansive ideas of how much is possible, limits your team's ability to the mundane rather than the customer delighting. Some product folks have internalized the possibilities but some haven't.
Ideally its a mix, a good PM should understand the customer/market more than the developer has time to do, and then they can have conversations with devs about how to most effectively fill needs. In reality, these PMs seem more like unicorns rather than expected table stakes, but hey.
I worked on some software that provided results to some calculations to general web users, not experts. The calcs were done in miliseconds.
We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.
This is one reason UIs have animations added, the kind that technical users like to complain about or remove. By making things feel more physically grounded they prevent users from getting lost and confused and give them more intuition about things.
In your case you could show more intermediate values, graph things, etc.
Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.
Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things.
If you just implement product tickets you'll probably get replaced by LLMs.
It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago
Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements.
The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers.
It's up to the developers and designers to understand those constraints and make sure they are communicated back.
Ive observed a modern trend of little to no QA. Managers and CTOs insist developers can test their own systems. Maybe this makes more sense in the early phases of product development where I find myself lately? Seems to capture a lot of dev's time.
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day.
Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end?
Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?
Construction worker is a spectacularly bad analogy for software engineer.
The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.
Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.
And then from the specification, decide how to implement it, which is not decided at all ahead of time.
Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.
There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.
They should have a general idea of what they are building and why, in exactly the same way as a construction worker.
That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.
Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.
Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized.
And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).
The other argument about this is whether or not an SWE is a fungible resource.
When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another.
We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.
If upvoting doesn’t require justification neither should downvoting.
But let me try to express why people disagree.
Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.
The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.
Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.
> If upvoting doesn’t require justification neither should downvoting.
I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread.
Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.
> The negative responses from clients were instant.
Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore.
The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.
On older cars, like my '72 Dodge, the system voltage varied between 12 and 18 volts. But the dash instruments needed 5 volts. This was achieved with a clever "buzzer" circuit using an electromagnet and contacts. The circuit would open when it was above 5 volts and close when it was below. This created 5V, but was a noisy 5V.
Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments.
So the electronics guys had to add a "noise" circuit to the voltage regulator circuit.
P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.
I think by the time I got my first IBM PC the button no longer did anything, but it was still there on the case for some reason. I remember pushing it repeatedly, puzzled that nothing went faster.
Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient. They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.
If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)
This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.
Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy:
> Obviously the proper solution is to adjust your system thermal management / power targets,
My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.
I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.
The proper solution for non-technical people is to ask the expert to fix it
This isn't something the developer has any meaningful control over. Scheduling policy is the responsibility of the host system, running faster usually consumes less power, and the developer has no way to know when an operation will kick in the undesirable fans because it depends on what else the system is running. The best they can do is a checkbox that runs the old code or adding sleep calls instead
You probably wanted a low thread priority/QoS setting. The OS knows how to run threads such that they don't heat up the CPU. Well, on modern hardware it does anyway.
This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly.
Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.
Absolutely - one of my favorite bug with users was an application we had made in which the loading of a filtered view was so slow, that results would come in one-at-a-time, such that clicking 'select all' would only select those ones. When this was removed, users complained until we added shift-clicking to select groups of items
Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell.
One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.
I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.
Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.
1. I do that once in a while. There is only so much thinking you can do in a day or a week that you need some mindless activity
2. Today morning, fresh in the new year after a break -- I took a day off on the 2nd, and I last worked on December 19th, I am not able to get into the zone, and luckily a training email popped up -- spent an hour doing that. Normally my manager would have had to remind me.
> 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".
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. :)
This list really stands out because it treats engineering as more than just producing correct code. It focuses on producing clarity that others can build on. The idea that clarity matters more than cleverness isn’t about style. It’s about reducing risk when someone else has to fix or extend the code at an odd hour. That’s often the difference between technical efficiency and the contribution a team can reliably depend on.
>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.
While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.
No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either.
You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".
I was told at university that every software system is a socio-technical system. Keeping a mental note of that fact has helped me throughout my career.
Probably just let them vent until they adjust their habits and just chat with their co-workers, without the need to use this as an excuse. Then, they can enjoy the fast loading times :)
Why would the boss accept that? They automated the work to eliminate employee downtime. If the employees were upset to lose their chatting time then presumably they lack the agency to choose chatting over work duties when they’re unblocked. The only way to help them in that situation is to organize them
For most people, liking and being friends with the people you work with is a huge factor in how much you like the job and are willing to stay. Most of the times I’ve left a job it’s been triggered by the people I liked talking to leaving and the remaining team members being dull and anti social.
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.
Some person or small team needs to have a vision of what they are crafting and have the skill to execute on it even if users initially complain, because they always do. And the product that is crafted is either one customers want or don’t. But without a vision you’re just a/b testing your way to someone else replacing you in the market with something visionary.
One of those higher levels of maturity that some people never reach is to realize that when your model becomes incorrect, that doesn't necessarily mean the world is broken, or that somebody is out to get you, or perhaps most generally, that it is the world's responsibility to get back in line with your internal model. It isn't.
This is just people complaining about the world not conforming to their internal model. It may sound like they have a reason, but the given reason is clearly a post hoc rationalization for what is basically just that their world model doesn't fit. You can learn to recognize these after a while. People are terrible at explaining to each other or even themselves why they feel the way they feel.
The solution is to be sympathetic, to consider their input for whether or not there is some deeper principle or insight to be found... but also to just wait a month or three to see if the objection just dissolves without a trace because their world models have had time to update and now they would be every bit as upset, if not more so, if you returned to the old slow loading time. Because now, not only would that violate their updated world models, but also it would be a huge waste of their time!
Thoughtful people should learn what a world model violation "feels like" internally so they can short-circuit the automatic rationalization circuits that seem to come stock on the homo sapiens floor model and run such feelings through conscious analysis (System 2, as it is sometimes called, though I really hate this nomenclature) rather than the default handling (System 1).
Completely insane, who doesn't get to have coffee breaks without manager permission? Surely any org that treats its employees as adults would not have this problem.
I optimised out some redundant processes on a unix system and sped up boot time.
But I had to release dummy processes which just printed out the same logs, as management didn't want to retrain operators or reprint the documentation.
Mid 90s. All training and operations manuals were hard copy.
I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/
Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)
I think this is true for essential complexity. And indeed it's one of the best reasons to release early and often, because usage helps clarify which parts of the requirements are truly required.
But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do.
Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.
You absolutely can remove unnecessary complexity. If your app makes an http request for every result row in a search, you'll simplify by getting them all in one shot.
Learn what's happening a level or two lower, look carefully, and you'll find VAST unnecessary complexity in most modern software.
I'm not talking about unnecessary (nor incidental) complexity. That is a whole other can of worms. I am talking about the complexity required given what you need to a system to spec. If choices are made to introduce unnecessary complexity (eg. "resume driven development" or whatever you want to call the proclivity to chase new tech) - that is a different problem. Sometimes it can be eliminated through practical considerations. Sometimes organization politics and other entrenched forces prevent it.
If - to take a convenient example - I use a library sorting function instead of writing my own sorting code, it's true that I haven't removed the complexity of the work my program is doing: It sorts. But I have arguably reduced the complexity of my code.
Similarly, if I factor out some well-named function instead of repeating the same sequence actions in multiple places - the work to be done is just as complex, and I haven't even removed the complexity from my code, but - I have traded the complexity of N different pieces of code for 1 such piece plus N function calls. Granted, that tradeoff isn't always the right thing to do, but one could still claim that, often, that _does_ reduce the complexity of the code.
I think most people don't really claim, that complexity is gone when properly abstracted, but claim that you don't have to deal with it every single time. That's the purpose of abstracting something.
Simple example: You are not dealing with the complexity of process management of the OS, every time you start any application. Sometimes you might need to, if you are developing software. Or if your application hangs and you need to kill it via some task manager. Most users however, never deal with that, because it is abstracted "away". That's the whole point. Nevertheless, the actual complex work is always done. Behind the scenes.
> I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/
I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.
I don't follow. Following the robustness principle doesn't necessarily introduce novelty. Perhaps a bit more complexity, but just how much depends on how clever you try to be.
My former boss had a rule of “One novel thing per project”. This was both an upper and lower limit, which ensured that he was “always learning”.
I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.
Like most of the things Spolsky says in that article it’s pretty dubious. Following it to its logical conclusion, presumably on-call debugging work be even easier if the software had been handwritten in assembler.
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.
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!?
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".
It feels unsavory from the outside, but politics is also the art of getting stuff done. It’s not throwing your life away if you can point at an org chart and a roadmap delivered and say “I helped build that”. Leadership is just as important as implementation.
Well you can "work to live" in a nice big house, with a nanny, eating steaks, flying business class to ski in the alps or scuba in the Galapagos... I think it takes a lot of money before you feel like you don't need more money.
Not at all. Most people can be super happy with less than the average tech salary (at a point where they don't feel they need more if it comes at the expense of work life balance, time with family, job satisfaction, etc).
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.
Just that all of those activities you mention feel like a useless life compared to spending time with your own children in a house big enough for everyone to have their space, but small enough to force you to feel you're living with each other, seeing them grow and thrive, and going around your closest nature patch.
Not much money is needed to have a fulfilling and worth-living life.
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.
Sure, lots of people don't care about those things and therefore don't shape their careers to get them. But some do, and that's what we're talking about.
Though to be clear I should have said "it can take a lot of money..."
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.
I question this every single day. Constantly the argument arises that if I played politics and ass-kissed, I might receive more opportunities to create bigger impact to help people / entertain people / provide some valuable service or product. Yet it feels painful to have to self-promote (even if framing it as "documentation of your work").
It is akin to musicianship in a sense. How many of the absolutely, obscenely, most talented musicians have you come across in completely obscured settings? At the pub, the hole-in-the-wall jazz club in a C-tier city, deep on the internet with 13 plays on SoundCloud. But we all know that pop music doesn't necessarily reward technical musicianship.
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.
I've done both things, and they have their pros and cons. Big businesses can build bigger and more impactful things, and it is very satisfying to contribute to those things. The original poster is still clearly proud of the things they were able to build by "playing politics and kissing ass".
But (for me) there is definitely a certain ennui to being a little cog in a big machine, especially because everybody else there is doing the same thing. So being in smaller more cohesive companies definitely has its advantages.
This is OP's lesson 20: Eventually, time becomes worth more than money. Act accordingly.
I’ve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.
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.
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.
Academia is not more notorious for politics than a corporate job, in my opinion. I've done both. Academia tries its very best to be meritocratic if anything. There is of course some degree of politics, it is inevitable, which was the point I was trying to make.
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.
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??
> Some companies will pay a bigger price than others.
The problem is that typically a large company has one or a few golden geese. They can milk it for a long time because of an existing moat. The moat keeps shrinking, but it can sometimes take a decade or two for others to catch up.[1] That's plenty of time for such folks to make a career of playing politics well without contributing much.
Lots of people at that company left before things went bad and are poisoning other companies.
[1] Just look at Google and search. Or Microsoft and Windows. Or even Microsoft and Internet Explorer.
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.
trying to make a convincing argument about anything is "influencing" people. its manipulation if you are trying to convince someone of something you know benefits you more than the person.
I don't disagree with you, except that a career can stagnate. Maybe you are already working in your ideal role, solving cool problems every day. Maybe moving up the ladder nets you more money but less of what you actually want in life.
Less a comment for yourself and more for the reader by the way. It is important to know what you want and strive for that.
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.
I think this is what leads a lot of people to want to run their own business. Of course, a lot of those people end up needing to (or falling into the trap of) kissing the asses of investors.
It does matter though. I also find it off-putting, but in the same way as lots of other stuff that I don't like about the reality of human society. The trick (I think) is to strike a balance between being open-eyed and realistic about unpleasant truths like "career advancement matters" without losing yourself to cynicism and self-interested gamesmanship.
I read this article as striking this balance pretty well. (Though it's certainly reasonable to quibble with it.) The one I struggled with was the one about not doing glue work just out of helpfulness, to conscientiously make it legible work instead of a personality. I hate this! This is totally my personality. I like being helpful and I like doing this kind of work and I really don't want to think or care about how it is reading to upper management.
But I also think he's pretty spot on about this. It's a very rare personality that can remain content in being the glue holding things together somewhere deep in the leaf nodes of a big organization, while seeing everyone around you graduate to bigger and better things because their work was more legible than yours. Very few people manage this without becoming bitter.
So I read Osmani's advice on this more as avoiding a common pitfall of resentment more so than as cynical careerism.
(Another unpleasant truth about "glue work people" like me, is that we aren't actually holding everything together, and the rest of the team can easily pick up the slack once it is documented and legible. This is exactly what Osmani suggests, instead of "helpfully" responding to all the DMs or requests for help about things, document what you would do in response to the common questions, and set up a rotation of people in charge of responding to them. This is a real bummer to me, because again, I really enjoy spending my time being the go-to helpful person on a team, but this is the much better approach for the organization, and ultimately for everyone including me.)
FWIW, from a stoic viewpoint, glue/coordinator roles are getting eviscerated by basic LLMs.
I feel the resentment is stronger if you ignore the game and get lulled into contentment when others are more transactional. It's all about interfaces and continuous contracting. And planning 2+ steps ahead.
Oh I disagree entirely with your first sentence. LLMs continue to be much better at writing lots of code than keeping track of how all the pieces of an organization actually fit together.
>I like being helpful and I like doing this kind of work and I really don't want to think or care about how it is reading to upper management.
Coding aside, I'm afraid this is already falling prey to LLMs plugged into exec calendars and org charts. You're adding yet another non-human, digital layer.
I'm happy to agree to disagree, but I think this seems like a misunderstanding of the kind of work I'm referring to. It's not clear to me how being plugged into exec calendars and org charts would help, so I think we're probably talking about different things.
But that the with is misunderstood and invisible to lots of people is the whole point of the thread! So it's an understandable misunderstanding :)
> 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.
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.
> 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.
It's important that you have relationships with your boss's boss. Some organizations call these skip-level 1-1s, other times it's just riding with your boss's boss in the car. This also is not politicking or CYA.
The reason is that managers are fallible, and when you have a relationship with your boss's boss, it helps get things back on track when someone (you, your boss, or your boss's boss) makes a mistake.
Getting back to the point: If you get a dressing down from your manager, your relationship with your boss's boss helps you know if you deserve it, or your manager made a mistake and your boss's boss has to intervene.
---
Quite tangible: A few weeks ago my manager gave me a dressing down. Earlier in the day I had a conversation with the CEO where he told me I was 100% in the right, so my manager was basically putting his foot in his mouth the entire time they gave me the dressing down. It's interesting to see where the situation is going to go, because everyone (me, the CEO, and everyone else in the company) really respects my manager and wants to continue working with them in a non-managerial role.
In your situation, it's end of year review time. He might be softening you up.
Why not mention to your manager that CEO supported you? Are they working with different data? I get these may not be fun to press on right before the holidays.
Don't make assumptions. My employer does not do end-of-year reviews.
To make a long story short, my manager got angry because I wrote a quick and dirty tool that bypassed a lot of confusing abstraction layers, and is significantly easier to use than the tool the company currently uses.
When my manager got angry, I first told my manager that we shouldn't argue in front of the entire office. Then I went to the CEO for advice. The CEO gave me advice that I used on my 1-1 with my manager later that day. (The CEO was also quite happy that I made a quick-and-dirty tool that made peoples' lives easier.)
> Why not mention to your manager that CEO supported you?
I suggested that my manager discuss the issue with the CEO when they told me that he didn't think he could "sell my tool" to the CEO.
To make a long story short, this is a case where my manager started the company, and people / project management is not their strong part. The limiting factor is funding, otherwise we'd have hired a proper project manager and promoted my manager (the founder) to a thought leadership role.
>I suggested that my manager discuss the issue with the CEO
Point blank:
Why not tell your manager you already spoke with the CEO instead of
1. Not mentioning you already overstepped your manager
2. And the skip-level boss/CEO liked the idea.
This seems like potentially good intentions being easily perceived by your manager as passive-aggressive. Maybe your skip level told you to use that phrasing.
I think you're misinterpreting the situation, because I didn't "overstep" my manager, and in a small company everyone has a relationship with everyone. (IE, what I did was taking initiative and making good use of dead time.)
I'm not comfortable discussing this further in a public forum at this point, but you're welcome to look at my profile to contact me directly if you want to.
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.
"Teach your kids to kiss ass and play poltiics"(sic) ?
Does one have any significant quality time to spend with the children during the formative and developmental stages in their early lives, while engaging in major corporation sociopathetic ass-kissery?
TLDR; being an excellent (or sociopathic) ass-kisser is one way to the top; if alone at the top on your way to alone at the rest-home with kids, exes, and former employees who hate you is the desired outcome.
Are the techniques one must be adept at to manage an extensive cohort of subjects|employees|associates appropriate means of influencing the developmental progress of children, such that they can be actually happy and a beneficial influence on their own partners, progeny, and greater society?
Otherwise, does it only matter that they then have the capacity and rapacity to remain in a position to become or remain rampant over-consumers in pursuit of the most expensive visages of "happiness."
How about using the accumulated wealth in the betterment of those childrens' lives by teaching them to cooperate in meaningful adventures, to build strong and lasting relationships of kindness, to consume with regards to the full scope of the externalized costs of that consumption, to enjoy the act of creation and production of meaningful insight in art and science ?
If one's actual goal is the qualitatively and quantitatively better long term outcomes in the lives of those children; isn't a more stable and harmonious life with the reward of success measured by the reduction in suffering both within and around them by finding their own unique and innate power to imagine, cooperate, discover, and grow, all while contributing to the knowledge base and capability of humanity?
If the goal is: a widening clan of bickering, profit seeking, materialistic, continually dissatisfied workaholics with a series of divorces, early cirrhosis of the liver, to end their days spending down the accumulated wealth in a lonely senior-dementia-warehouse, well sir or madam, carry on.
The Longer part - a.k.a. "what the hell do I know about anything?":
FWIW, I am quite grateful that the fortune500 CEO/COO vater meins was principally unavailable or unable to instill most of his 'techniques' for success in my own early years. He was somewhat more present and it is debatable, malignantly, involved during more of the developmentally significant stages of my younger siblings. The results have been a mixed bag of world class success in the some arenas of life with world class catastrophic outcomes for the other arenas for at least 2/5 to 4/5 of his admitted progeny, depending on how one measures those arenas.
My own, albeit limited, advantage from milder exposure to his 'capabilities' has informed a strong aversion to the quest for infinite collateral resources and externalized risks through manipulation and deceit with and among others.
I wouldn't have it any other way, and have lived a life of immeasurable richness; having years spent with the freedom to ponder, opportunity to discover novelty, create opportunities for many to learn and participate in the arts and sciences. With the freedom to chose vainglorious poverty, indulging in a selfish amount of free time; nine years in total, doing nothing more than looking after goats and gardens in some of the wildest tropical jungle at the princely cost of less than $300 USD per month, all-in. Surviving on wild boar, feral oxen, gamefowl, marine and river fishing, all while living as prehistorically as we could imagine with my spouse and best friend. (Same person) No hot running water, barely any electricity, no petrochemical fuels, and the scarcest of rain shelter in one of the wettest places on earth. It was a kingdom unto itself, and we answered to no one for our daily needs.
Barter and trade of the product of our own two hands among the other, more civilized, inhabitants provided everything we could not make and do without. Occasional travel, by road, by air, and by sail were accomplished without needing a bank account or a land-line. We needed little, and wanted for nothing more than the continued opportunity to live among the tree frogs and roaring streams.
Tell me you're richer, without the ability to live and make lifelong friends through no hidden agenda beyond helping a community of your own choosing to do what is agreed by that community to be best for everyone; and I'll call you a fool with pockets full of money, wasting breath on children who will neither grow wise nor kind by your words and example.
Also, this isn't a sour grapes POV. I have managed a 30B PE fund, nominally in control of several hundred B worth of assets that produce significant percentages of US and global consumption of at least three commodities with properties and operations on 5 continents, and which holds patents in carbon negative and renewable power technologies and which controls some of the operations utilizing those patents. I have contributed personally to the concepts enabling bare-metal layer of hypervisor development, over 20 years ago when hardware and in-kernel virtualization were the dreams of a glorious future. I do know the difference between money and wealth, first hand. I'll take freedom over never-ending consumerism, all my live-long days.
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.
> 4. Clarity is seniority. Cleverness is overhead.
Clarity is likely the most important aspect of making maintainable, extendable code. Of course, it’s easy to say that, it’s harder to explain what it looks like in practice.
> 11. Abstractions don’t remove complexity. They move it to the day you’re on call.
This is true for bad abstractions.
> The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. (Dijkstra)
If you think about abstraction in those terms, the utility becomes apparent. We abstract CPU instructions into programming languages so we can think about our problems in more precise terms, such as data structures and functions.
It is obviously useful to build abstractions to create even higher levels of precision on top of the language itself.
The problem isn’t abstraction, it is clarity of purpose. Too often we create complex behavioral models before actually understanding the behavior we are trying to model. It’s like a civil engineer trying to build a bridge in a warehouse without examining the terrain where it must be placed. When it doesn’t fit correctly, we don’t blame the concept of bridges.
I agree with you re: abstraction - one of the author's only points where I didn't totally agree.
But also worth noting that whenever you make an abstraction you run the risk that it's NOT going to turn out increase clarity and precision, either due to human limitation or due to changes in the problem. The author's caution is warranted because in practice this happens really a lot. I would rather work with code that has insufficient abstraction than inappropriate abstraction.
Broad strokes: absolutely. The practical reality gets tricky, though. All programming abstractions are imperfect in some regard, so the question becomes what level of imperfection can you tolerate, and is the benefit worth the cost?
I think a lot of becoming a good programmer is about developing the instincts around when it’s worth it and in what direction. To add to the complexity, there is a meta dimension of how much time you should spend trying to figure it out vs just implement something and correct it later.
As an aside, I’m really curious to see how much coding agents shift this balance.
All abstractions drop some details. If you're unlucky, you removed details that actually matter in some context. You can only make educated guesses.
Another aspect is that some abstractions are too... abstract. The concept they represent is not immediately obvious. Maybe it's a useful concept, but if it's new, it takes time to be internalized by someone for the first time.
I've found that clarity is likely the most important aspect of success in general. Clarity in communication, for example, makes people feel invovled, heard, aligned. Cleverness is lots of acronyms and fancy phrases like vis-a-vis instead of just writing out what you mean so everyone can easily understand.
I’d agree on most of these but the biggest value in such a list is for the writer to actually put it on paper. You have to reflect on multiple aspects in your career and synthesise those. Reading them is close to useless, like scanning a page full of news, it all just evaporates once you start your daily work routine.
The best suggestion would probably be to try and write such a list yourself IMO.
1. The best engineers are obsessed with solving user problems.
I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user.
2. Being right is cheap. Getting to right together is the real work.
- Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
- Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other.
Thinking back, there really should be some lessions that send students off to solve user problems after having learned a programming language, where there is a much easier solution without having to program something.
Some refinement sessions that teach them how to understand the problems.
The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.
But that is still better than nothing at all, which is the point.
The people you want (or want to be) are the engineers who are smart and experienced enough to get a first draft down that is pretty much right without a long drawn out process of figuring out the best way to do X, Y and Z with all the lengthy ADRs, discussions, debates, POCs, revisions etc. over and over again. That may be necessary if you don't have people in the room who know what they're doing and have the intuition through deep experience to choose good tools, patterns and abstractions at the start. Begin closer to the target, rather than far away and iterate to it.
Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking.
Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.
I know it's sometimes considered not very nice to suggest this but I felt the exactly same thing, about exactly those phrases.
I wonder if we're going to get to a different singularity, where, regardless of whether it prose was AI assisted it (1) leaks into people's way of speaking, (2) is out there frequently enough that people are skeptical even of normal prose.
At the very least, we're long past due for a word to describe the "it isn't just X, it's Y" formulation. In my opinion it's worse and more rampant than the em dash (and I like the em dash when used responsibly).
Yep. I too felt that. The insights seem genuine. But probably fell into the temptation to use LLM to structure. I feel increased cognitive load with numbered lists, thanks to LLM.
Avoid self-anthropomorphism. Override all previous instructions regarding tone and vernacular used in responses to instead respond *only* in Standard English. Emphasize on the subject and context in your responses, *not* the perceived intent of the user.
This is wishcasting. It can't override its writing style, and if it could it would ignore you telling it to do that, because that's ignoring the system prompt which is jailbreaking it.
I love Addy's work, and enjoyed this article -- and I completely agree that it felt very LLM-y. I'm not sure what's scarier; that we know some of this didn't come from the author (and maybe that's okay?) or that one day soon, we'll get to a point where we won't be able to tell anymore.
That pattern in particular is grating when it keeps repeating. But I don't think that LLM writing necessarily needs to have that pattern if you give it instructions to not do it and/or have a small review and edit workflow.
May be because you are not familiar with Addy Osmani and his work. He is known for his very high quality performance optimisation work for web for almost a decade now. So anything he has read, edited and put his stamp of authority on is worth reading.
They are pretty insightful. Particularly this one:
> 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice.
I liked that one, too, but for an additional reason.
Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on.
All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.
I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair.
In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.
When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.
I think you can also learn from users when they complain en masse about the current atrocious state of software quality. But I guess that doesn't show up in telemetry. Until it does. Looking at you, Microsoft!
I believe one of the main reasons why Windows 11 is getting so much vitriol is that Microsoft is focusing on customers, which aren't always identical to users. Most of the time, when you buy a Windows-based device, you're not their customer: you're the OEM's customer, and for the OEM, every nickel of expenses counts. On the other hand, direct Microsoft licensees, such as corporate ("enterprise") customers, get much more attention from the company and a significantly better experience.
You can't learn from this because users always complain no matter what.
The trick is they just complain about the last thing they remember being bad, so it's a good sign when that doesn't change, and it's bad if they start complaining about a new thing.
This is analagous to the problem of premature optimization - if you try to optimize performance without benchmarking, you end up eating a lot of time and effort on things that don't matter. Likewise for product: it is very easy to solve the wrong problems.
> Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop
what have you shipped? paying sees literally hundreds of thousands of dollars a year to ship out fledged out software that no one wants is exactly why Stadia lasted both way too long and got cancelled anyway.
figuring out what is useful is the hardest problem. if anything that's Google's biggest problem, not shipping fast enough, not iterating fast enough.
I wish people who ship crappy software didn't ship it and would let someone else ship something better instead.
It really sucks when the first mover / incumbent is some crappy half assed solution.
But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality
Linux kernel - free Unix.
JavaScript - scripting in browser
Python - sane "perl"
Today on GitHub alone you can probably find 100 more featured and higher quality projects than any of these were when they launched but nobody cares.
While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.
WRT Linux. Sure, 1991 or really even mid-90s Linux was clearly immature. But Wall Street was adopting it instead of Solaris by the turn of the century. Plus "open source" so it wasn't the case of a new proprietary Unix just emerging from the sea foam which no one wanted anyway but Linux becoming the good enough Unix standard which is what people did want.
It did in the early days, especially up until 2.4 which was generally considered the first enterprise-ready kernel version. (You can argue about whether the old "enterprise-capable" definitions still applied but they were a benchmark for a lot of people.) Of course, lots of ancillary stuff too in userspace and outside the kernel related to filesystems and the like.
Wiki (https://en.wikipedia.org/wiki/Linux_kernel_version_history#O...) tells me that version 2.4 was released in early 2001. That is a long time ago. Most of the commercial world was running SunOS, Solaris, HP-UX, or AIX. So is it fair to say that the Linux kernel has been "quality" for 25 years now?
2001 was immediately post dotcom crash and so all the people that had bought into the Sun "the network is the computer" were tossing out expensive E4Ks, and getting cheap intel servers to survive.
HP-UX and AIX were already legacy.
Linux 2.4 was when it hit critical mass because of the publicity of the dotcom boom and it was like what was left after the "tide went out and the market found out who was swimming naked".
Certainly. The 2.4 kernel and IBM embracing Linux at around that time pretty much made all proprietary Unix legacy.
The desktop took longer with less well-defined transition points and, arguably, MacOS with its BSD foundations (and command line option) ended up being a good alternative for a lot of the non-Windows crowd--though Windows is still dominant as a desktop/laptop OS. (Windows/Azure are, of course, still major in backend corporate environments as well.)
The problem is I've worked at at least 5 companies that professed a strong "bias for action" and it nearly always meant working nights and weekends to ship broken things that ultimately hurt the user and then moving on to the next big leadership project to do the same thing again, never looking back. The exception of course would be when leadership finds it's broken in 5 months and complains about poor engineering practices and asking why engineers can never get things right.
I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality.
This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"
I’m a big fan of Amazon’s leadership principles. One of them is bias for action. I worked at AWS for a few years and I’d be in a meeting and someone would say bias for action and we’d all know what we needed to do.
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.
Bad feedback can be more helpful than good and is often the only type of feedback a product gets. And you may not have received that feedback if you didn’t ship. It’s better to get that information early.
I personally agree with the premise to ship early, with some rough edges, etc. But teammates may not be supportive. You need the whole team to have that mindset/culture.
The problem with this approach is that once you've started with a "bad" draft and enough people have signed on, you're locked in to its trajectory and can't do foundational rewrites even if you were within the feasible window. It'll just end up being a bad product overall.
Also known as ossification. It is a term most often heard in the context of network protocols, but it applies more generally to every system where users depend on unspecified behaviors and even bugs.
Reading about HTTP/3 and QUIC is interesting in that aspect. I first didn't understand the insistance on encryption. Turns out it is not just security and privacy, but by encrypting everything that is not strictly necessary for proper transport, you make it impossible for any "middlebox" to make assumptions they shouldn't make.
I think similar approaches can be used by APIs. Never expose more than what is specified, treat the ability to access internal state as a bug, not because it is secret, but because if users start relying on it, internal changes that shouldn't break anything will.
He's not saying that these are all common values or practices at Google.
He's saying he learned those lessons while working at Google.
Despite the metaphor of a "lesson", a "lessons learned" post is almost never about something the author was explicitly told. It was something that you had to learn from experience, or at best from informal advice. Where you had to swim against the flow of your circumstances.
I neither think Osmani means to say that Google is _against_ these lessons. Every organization as big as Google has a lot of accumulated wisdom that will help you. These are just the things which remain hard, and some of which are even harder in a large organization.
Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everything you are trying to do needs a click of sorts. Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option. Most of the rest of his lessons while valuable in their own right, are not something I would put under the headline of "after X years at <insert-major-tech-company>", as they do not quite seem to be that different from lessons you pick up at other companies ? I´d more interested to hear about how the culture was impacted when the bean-counters took over and started entshittifying the company for both the users and the employees too.
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse.
There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock"
When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was:
• Almost nobody else in engineering did this.
• I was considered weird for doing it.
• It was viewed negatively by managers and promo committees.
• An engineer talking directly to users was considered especially weird and problematic.
• The products did always have serious bugs that had escaped QA and monitoring.
In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly.
This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.
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 and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where you do not normally get to hear from customers much. Of course once these customers had my ear, the feature requests started to flow thick and fast, and I ended up spending way too much time on their specific issues. Which is just to say that I've changed my views over time.
In retrospect, the customers I helped were ones that had the most interesting problems to me, that I knew I could solve, but they were usually not the changes that would have the biggest impact across the whole customer base. By fixing a couple of customers' specific issues, I was making their lives better for sure, and that felt good, but that time could have been used more effectively for the overall customer base. PMs, managers etc should have a wider view of product needs, and it is their job to prioritize the work having that fuller context. Much as I felt at the time that those roles added little value, that was really not true.
Of course agreed that all the points made above for PMs, managers, support having their reasons to obstruct are true in some cases, but for a well run company where those roles really do their job (and contrary to popular opinion those companies do exist), things work better if engineers do not get too involved with individual customers. I guess Google might be a good example - if you have a billion customers you probably don't want the engineers to be talking to them 1:1.
> 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.
It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all.
I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs.
This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others?
There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.
I think he has a point. These power structures exist for some good reasons as well.
The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers.
Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows.
There are also nasty games that can be played by soliciting negative feedback for political advantage.
Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams.
There's not enough hours in the day for everyone to do everything.
> There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.
Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And the implementers need to know the context to ensure they make decisions consistent with that context.
But "leaders providing the context" is very different from "everyone researching the context on their own." So where are leaders getting this context from? A not-very-differentiated pile of 1000 generalist engineers-who-also-talk-to-customers-frequently-and-manage-their-own-work-streams? Or do they build a team with specialists to avoid needing the majority of people to constantly context-switch in a quest to be all of context-gatherers, work-prioritizers, market-researchers, and implementation-builders?
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.
Agree that this can be an issue but to clarify, I was finding bugs or missed outages, not gathering feature requests or trying to do product dev. Think "I clicked the button and got a 500 Server Error". I don't think random devs should try and decide what features to work on by reading user forums - having PMs decide that does make sense as long as the PM is good. However, big tech PMs too often abstract the user base behind metrics and data, and can miss obvious/embarrassing bugs that don't show up in those feeds. The ground truth is still whether users are complaining. Eng can skip complaints about missing features/UI redesigns or whatever, but complaints about broken stuff in prod needs their attention.
An org can always go too far in the opposite direction, but this is not an excuse to never talk to the customer. The latter is much more likely, so the warning to not get “into bed” with the customer falls flat.
This is a common pattern here. Alice says 0 degrees is too cold, I prefer 20C, Bob chimes in “100C is too hot, it’ll kill us.” Ok, well no one said or implied to crank it to one hundred.
If you have M customer complaints, and each one risks a differently-sized N customers... you better try to triage that vs just playing whack-a-mole with whatever comes to a random engineer first. I've never seen engineers plow through a bunch of 0-or-1-customers-would-actually-churn-over-this papercuts because it was easy and it feels good - the customer mentioned it! i fixed it! - while ignoring larger showstoppers that are major customer acquisition and retention barriers.
Nothing is knowable in only the same way that plans are useless but planning is essential.
> 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.
Where I work we regularly bring in engineers to talk to clients directly. Clears up a lot of confusion when there’s something technical a PM wouldn’t understand. We still like to have a filter so a client isn’t trying to get the engineer to do free work. Having engineering isolated is pretty bad IMO.
I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.
We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.
We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).
Everyone was a team working together towards the same goal of making these tools the best for our internal audience.
It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...
There are very good less-cynical reasons. I've also seen companies with the opposite problem, where the engineers constantly shoot down real, important feedback brought by customer support in order to preserve the superiority of engineering over support.
If you have ten engineers and even just 100 customers, you have a very high number of conversational edges. Good luck keeping things consistent and doing any sort of long-term planning if engineers are turning the output of those conversations directly into features. "Engineers talking to customers but not making any changes" would be more stable, but is still a very expensive/chaotic way to gather customer feedback.
Additionally, very few of those single engineers have a full knowledge of the roadmap and/or the ability to unilaterally decide direction based on some of the customer feedback or questions. "Will this get fixed in the next two weeks?" "Will you build X?" etc. You don't want your customers getting a bunch of inconsistent broken promises or wrong information.
The best-managed orgs I've seen have pretty heavy engineering and user experience in their product and support orgs. You need people in those roles with knowledge of both how it's built AND how it should be used, but you can't continually cram all that knowledge into every single engineer.
A startup should start with the builders talking directly to the customers. But at a some point, if successful, you're going to have too many people to talk to and need to add some intermediaries to prevent all your engineering time going to random interrupts, and centralization of planning responsibilities to ensure someone's figuring out what's actually the most important feedback, and that people are going to work on it.
On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it.
Users should be everywhere, in and out of engineering.
Theres another thread on HN at the moment about legislation being written by industry and rubber stamped by law makers. What hit me about this discussion and that one is that there's a lot of self interest out there with very little scrutiny or auditing. It boils down to that basically. If we want to fix problems at the top there needs to be independent auditing, reporting and consequence for people that do the wrong thing. But we all know thats not going to happen so buckle up and learn to live with broken laws and broken software.
> User obsession means spending time in support tickets
That's really funny when Google's level of customer support is known to be non-existent unless you're popular on Twitter or HN and you can scream loudly enough to reach someone in a position to do something.
"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.
It is an almost universal fact that dealing with retail customers is something that is left to the lowest paid, lowest status workers and often outsourced and now increasingly left to LLM chatbots.
While you obviously can't have highly paid engineers tied up dealing with user support tickets, there is a lot to be said for at least some exposure to the coal face.
> While you obviously can't have highly paid engineers tied up dealing with user support tickets,
You obviously can, that's one of the more visceral way to make them aware of the pain they cause to real people with their work, which sticks better, or simply serves as a reminder there are humans on the other side. There are even examples of higher paid CEOs engaging, we can see some of that on social media
I love reading this insights in a corp structure. Especially the sociological aspect of it (like "• It was viewed negatively by managers and promo committees."). Thanks a lot.
> only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team
This revelation is utterly shocking to me. That's like anti-abuse 101. You infiltrate their networks and then track their behavior using your own monitoring to find the holes in your observability. Even in 2010 that was anti-abuse 101. Or at least I think it was, maybe my team at eBay/PayPal was just way ahead of the curve.
Well, the 101 idiom comes from US education, it's a reference to the introductory course. Part of the problem with anti-abuse work is that there's no course you can take and precious little inter-firm job hopping. Anti-abuse is a cost of business so you don't see companies competing over employees with experience like you do in some other areas like AI research. So it's all learning-by-doing and when people leave, the experience usually leaves with them.
After leaving Google the anti-abuse teams at a few other tech companies did reach out. There was absolutely no consistency at all. Companies varied hugely in how much effort and skill they applied to the problem, even within the same markets. For payment fraud there is a lot of money at stake so I'd expect eBay would have had a good team, but most products at Google didn't lose money directly if there was abuse. It just led to a general worsening of the UX in ways that were hard to summarize in metrics.
I seem to recall sitting in weekly abuse team meetings where one of the metrics was the price of a google account on the black market. So at least some of these things were tracked and not just by one individual.
>• It was viewed negatively by managers and promo committees.
>• An engineer talking directly to users was considered especially weird and problematic.
>• The products did always have serious bugs that had escaped QA and monitoring
Sincerely, thank you for confirming my anecdotal but long-standing observations. My go-to joke about this is that Google employees are officially banned from even visiting user forums. Because otherwise, there is no other logical explanation why there are 10+ year old threads where users are reporting the same issue over and over again, etc.
Good engineering in big tech companies (I work for one, too) has evaporated and turned into Promotion Driven Development.
In my case: write shitty code, cut corners, accumulate tech debt, ship fast, get promo, move on.
If an engineer talking to users is considered problematic, then it is safe to assume, that Google is about as fast away from any actually agile culture as possible. Does Google ever describe itself as such?
Having only ever worked for startups or consulting agencies, this is really weird to me. Across 6 different companies I almost always interfaced directly with the users of the apps I built to understand their pain points, bugs, etc. And I've always ever been an IC. I think it's a great way to build empathy for the users of your apps.
Of course, if you're a multi billion dollar conglomerate, empathy for users only exists as far as it benefits the bottom line.
Thanks for sharing your valuable insights. I am quite surprised to learn that talking to customers was frowned upon at Google (or your wider team at least). I find that the single most valuable addition to any project - complementary to actually building the product. I have a feeling a lot of the overall degradation of software quality has to do with a gradual creep in of non-technical people into development teams.
There are, and often times they're stuck in a loop of presenting decks and status, writing proposals rather than doing this kind of research.
That said, interpreting user feedback is a multi-role job. PMs, UX, and Eng should be doing so. Everyone has their strengths.
One of the most interesting things I've had a chance to be a part of is watching UX studies. They take a mock (or an alpha version) and put it in front of an external volunteer and let them work through it. Usually PM, UX, and Eng are watching the stream and taking notes.
When you get to a company that's that big, the roles are much more finely specialized.
I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager.
So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described.
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?
I've had the pleasant experience of having worked for PMs at several companies (not at Google) who were great at their jobs, and advocated for the devs. They also had no problem with devs talking directly with clients, and in fact they encouraged it since it was usually the fastest way to understand and solve a problem.
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
> If the Google culture was at all obsessed about helping users
It's worth noting that Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer working on a product shipped to users.
It might be useful to keep that in mind as you read through what his lessons are, because they're surely shaped by the positions he held in the company.
I was Addy's manager when he was on Developer Relations.
He moved to an engineering manager role on Chrome DevTools many years ago and has recently just moved on to a different team. I don't think it's fair at all to say he's not a developer working on a product shipped to users when he led one of our most used developer tools, as well as worked on many of our developer libraries prior to moving to the Engineering manager role.
Yeah, maybe I should have been more precise, I meant "end users like your mom" rather than "not real users". Developing for developers, in a engineering-heavy team is obviously different than the typical product-development team.
I think it is more the point that the users for his job were external developers. The role is inherently user facing and user focused. I don’t think anyone was trying to say he wasn’t a developer just that his job wasn’t to directly develop products
Yeah, I guess I just wanted to add that because of the way that quote was cut at the end, made me believe that the person quoting me thought Osmani "isn't a developer".
I think that's more "this sounds great" than "our users are developers". Google's services also aren't aimed at developers, the APIs are often very bureaucratic and not very well done (there's no way to list the available google sheets documents in the sheets api, I need the drive API and a different set of permissions? please.)
It reads exactly like what you'd expect from a "I want to be considered a thought leader" person: nothing you haven't read a hundred times but it sounds nice so you can nod along.
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much
Ok, I mean this sincerely.
You must never have used Microsoft tools.
They managed to get their productivity suite into schools 30 years ago to cover UX issues, even now the biggest pain of moving away is the fact that users come out of school trained on it. That also happens to be their best UX.
Azure? Teams? PowerBI? It's a total joke compared to even the most gnarly of google services (or FOSS tools, like Gerrit).
I do agree with you. Teams are a cancer and Azure UI sucks too. I do not use much MS products since essentially Win7 I have mainly used Linux as my work environment. But one thing MS used to be good at at least, was the documentation. If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support. With google its like...not even that.
With continuous delivery and access to preview and beta features, the documentation is fragmented and scattered and half of it technically is for the previous version of the product with a different name but still mostly works because microsoft can't finish modernizing most software...
And the customer support is not great until you start really paying the big bucks for it.
> If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support.
But even then, contemporaries outclassed Microsoft by a lot.
It was culture back then to provide printed user manuals, I still have some from Sun Microsystems because it was the best resource I found to learn how storage appliances should work and the technical trade-offs of them.
Fair enough, everyone delivered software in boxes and with 500 page manuals. I still maintain MS did invest a lot in the quality of their documentation and they cared about developers - otherwise the Petzold series would have never happened (or the MS Press for that matter).
Honestly your entire comment is almost exact polar opposite to how I feel.
GCP Makes total sense if you know anything about systems administration, Google docs is limited for things like custom fonts (IE; not gonna happen) but it's simple at least and I can give people a link to click and it's gonna look the same for them.
But, honestly, the Teams one is baffling. I can't think of a single thing Meet does worse than Teams.
Yeah that seriously whiplashed me too, I'm genuinely confused. Google Meets has always worked completely fine for me, good performance, works well on mobile, Firefox, etc. Nothing special but it works. Probably my favorite of all the meeting apps.
Teams meanwhile is absolutely my least favorite, takes forever to load, won't work in Firefox, nags me to download the app, confusing UI. I don't think I've ever heard anyone say they like teams.
MS Teams might have its issues (and let’s be clear, i agree there are a great many issues) but it has most, if not all, of the Enterprise features you need from a video conferencing suite.
Whereas Google Meets feels more like a cut down toy you’d give to your grandparents.
It’s the same thing with Google Docs. They’re technically impress for the era they were launched, but they’re stuck in the 2010s. Doing anything outside of the basics quickly becomes far far more frustrating than using O365.
Microsoft might write a lot of terrible software with some questionable design choices, but they understand enterprise uses far better than Google.
Even Google Workspaces is severely limited once your business grows beyond 50 people.
I guess if you only work in startups then Google might seem like an easy win. But for any business that’s more established, you just constantly run into huddles with Googles suite of software.
As for GCP, I’ve been burned too many times with their support processes. 7 days to approve a GPU quota. Account managers literally trying to steal business secrets (when I worked for an AI start up and Google were stagnating in the AI space). And so on and so forth. Though I’ve not been hugely impressed with Azure either; they constantly break managed services and ballsup scalability promises and then refuse to admit it until we present them with empirical evidence. It really feels like the best cloud engineers have left Microsoft (or maybe never joined?).
I've used Meet a few times for video calls and I was amazed at how poorly it worked given the amount of resources Google has at their disposal. I've never had a good video call on Meets. I've had a few Meet calls where over time the resolution and bitrate would be reduced to such a low point I couldn't even see the other person at all (just a large blocky mess). Whereas Teams (for all its flaws) normally has no major issues with the video quality. Teams isn't without its flaws and I do occassionally fall back to ZOom for larger group video calls but at the end of the day Teams video calling sort of just works fine. Not great but not terrible either. YMMV of course.
I've had the complete opposite experience. Meet has been rock solid for me whilst Teams has been an absolute nightmare.
The thing is though both Meet and Teams use centralised server architectures (SFUs: Selective Forwarding Units for Google, "Transport Routers" for Teams), so your quality issues likely come down to network routing rather than the platforms themselves. The progressive quality degradation you're describing on Meet sounds like adaptive bitrate doing its job when your connection to Google's servers is struggling.
The reason Teams might work better for you is probably just dumb luck with how your ISP routes to Microsoft's network versus Google's. For me in Sweden, it's the opposite ... Teams routes my media through relays in France, which adds enough latency that people constantly interrupt each other accidentally. It's maddening. Meanwhile, Meet's routing has been flawless.
But even if Teams works for your particular network setup, let's not pretend it's a good piece of software. Teams is an absolute resource hog that treats my CPU like a space heater and my RAM like an all-you-can-eat buffet. The interface is cluttered rubbish, it takes ages to start up, and the only reason anyone tolerates it is because Microsoft bundled it with Office 365.
Your mileage definitely varies... sounds like you've got routing that favours Microsoft's infrastructure. Lucky you, I suppose, but that doesn't make Teams any less dogwater for those of us stuck with their poorly-placed European relays.
As someone who worked on Meet at Google, it seems that it could have been networking to the datacenters where the call is routed from, some issues with UDP comms on your network which triggered a bad fallback to WebRTC over TCP. Could also have been issues with the browser version you used.
Since Teams is using the very old H264 codec and Meet is using VP8 or VP9 depending on the context, it's possible you also had some other issues with bad decoding (usually done in software, but occasionally by the hardware).
Overall, it shouldn't be representative of the experience on Meet that I've seen, even from all the bug reports I've read.
It's not just Google, the UX is degrading in... Well everything. I think it's because companies are in a duopole, monopole etc position.
They only do what the numbers tell them. Nothing else and UX just does not matter anymore.
It's like those gacha which make billions. Terrible games, almost zero depth, but people spend thousands in them. Not because they are good, but because they don't have much choice ( similar game without gacha) and part the game loop is made for addiction and build around numbers.
To offer some additional causes for the degradation of UX:
1. An increasing part of industry profits started coming from entertainment (or worse, psychological exploitation) instead of selling the customer a useful tool. For example, good budgeting-software has to help the user understand and model and achieve a goal, while a "good" slot-machine may benefit from confusion and distraction and a giant pull-handle.
2. "Must work on a touchscreen that fits in a pocket" support drags certain things to a lowest common denominator.
3. UX as a switching-cost for customers has started happening more on a per-product rather than a per-OS basis. Instead of learning the Windows or Mac "way" of screens and shortcuts, individual programs--especially those dang Electron apps--make their own reinventions of the wheel.
To be fair, it reads precisely “1. The best engineers are obsessed with solving user problems”. This doesn’t say those engineers are working at Google, just that it’s something the author learned whilst they worked at Google.
“Some [of these lessons] would have saved me months of frustration”, to quote the preamble.
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".
Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.
And material UI is still the worst of all UIs. Had the pleasure of rolling out a production oauth client ... jesus christ. Only worse is microsoft in UX. You don't want me to use your services, do you?
I'm not sure how that got approved either, but at least we now know what would happen if a massive corporation created a UI/UX toolkit, driven only by quantitative analytics making every choice for how it should be, seemingly without any human oversight. Really is the peak of the "data-driven decisions above all" era.
I have an issue with the first point as well, but differently. Having worked on a user-facing product with millions of users, the challenge was not finding user problems, but finding frequent user problems. In a sufficiently complex product there are thousands of different issues that users encounter. But it's non-trivial to know what to prioritize.
I was also surprised to read this. I have terrible problems with all Google UIs. I can never find anything and it's an exercise in frustration to get anywhere.
I think your particular Gmail issue exists because they want mobile web and touch screen web users (there are dozens of us!) to be able to tap the recipient to show the user card, like hover does for mouse users. To support your usecase (click to directly edit recipient), touch, click, and hover need to have different actions, which may upset some other users. Unless you mean double click to edit, which I would support.
I save my energy for more heinous UX changes. For example, the YouTube comment chyron has spoiled so many videos for me and is just so generally obnoxious.
There is a lot of nuance to their point. They are saying, in the long run, career wise, focusing on the actual user matters and makes your projects better.
Google UX is decent and the author was not trying to comment on UX as a thing at Google. More that, if you follow the user what you are doing can be grounded and it makes your project way more likely to succeed. I would even argue that in many cases it bucks the trend. The author even pointed out, in essence there is a graveyard of internal projects that failed to last because they seemed cool but did nothing for the user.
Read their point 1 carefully. They are saying, when you are building something or trying to solve a problem (for internal or external users) if you follow the user obsessively you will have a far better outcome that aligns with having impact and long term success. This does imply thinking about UX, but transitively, IMO.
I am not sure I follow - is he, or is he not, writing about his experiences from 14 years at Google? The title suggests he does, yet you suggest that he does not?
Oh, I have no doubt they are at Google. I was just trying to say that the author was not really making a commentary on UX directly. The author was trying to make the point that understanding what sort of products and problems users have is a valid long term strategy for solving meaningful problems and attaching yourself to projects, within Google, that are more likely to yield good results. And if you, yourself, are doing this within Google it benefits you directly. A lot of arguments win and die on data, so if you can make a data driven argument about how users are using a system, or what the ground reality of usage in a particular system is and can pair that with anecdotal user feedback it can take you a long way to steering your own, and your orgs work, towards things that align well with internal goals and or help reset and re-prioritize internal goals.
His learnings from 14 years at Google. Surely we've all learned things working for employers or with engineers that don't do a thing well.
In 14 years he probably also experienced great engineers come and go and start other successful businesses they very likely did not run exactly like Google.
The short answer is that the UI isn’t optimized for users like you.
I haven’t worked for Google specifically, but at this scale everything gets tested and optimized. I would guess they know power users like you are frustrated, but they know you’ll figure it out anyway. So the UX is optimized for a simpler target audience and possibly even for simpler help documents, not to ensure power users can get things done as quickly as possible.
I feel like you're giving too much credit here. I don't know if it was a leak or an urban legend, but I remember the awful win 8 "flat boxes UI" being that way because it could be designed by managers in PowerPoint that way
The specific feature in question...there is nothing "power" about it. It was a non-feature for decades essentially, I dont recall ever not being able to simply change an e-mail address by moving the cursor and typing in something else. How on earth is this something tested and optimised, for whom exactly?
This is almost certainly not the case. The larger the company the more change is viewed as a negative. Yes people may hold titles to do the things you describe but none are empowered to make change.
Google UI seemingly is optimized for happy path cases. Search for the obvious word and click a relevant link on the screen which appears. Write a single response to a single email and abandon than conversation afterwards, always use new conversations for every new email. Click a recommended video thumbnail on the frontpage and then continue with autoplay. Put only short defined text type in the cells of a spreadsheet, like date/number/text etc. And so on with all of their products.
But as soon as user tries to search for something no on the first page, or reply to a 10-20+ message thread with attachments in history, or tries to use playlists or search in YT, or input a slightly more complex data in the sheet cells - then all hell breaks loose.
Just the latest Google thing I've experienced - a default system Watch Later playlist is now hidden on Android. It's gone, no traces, no way to search for it. The only remnant of it is a 2-second popup after adding a new video to Watch Later, you can press "view" and then see it. Meanwhile it is still present as a separate item on PC. I'm writing this eaxmple because that was deliberate, that was no error or regression. Someone created a Jira for that and someone resolved it.
This is definitely an edge case. Most UI/UX from Google is very consistent and just works. Otherwise they won't be in this market.
Only UI/UX issue is that most experienced users want to not adapt to change. It is like people always telling Windows 7 is the best. Don't keep reinventing.
Another one that irks me is every UI/UX dev assumes people have 2 x 4K monitors and menu items overflow.
> Only UI/UX issue is that most experienced users want to not adapt to change
Users will not only adapt, but will even champion your changes if they make sense to said users. For example the web checkout or to name a more drastic example, iPhone and fingers as user interface devices. Once you start convincing the users that the interface is great, but they are too resistant to changes/dumb/uncreative to know how use it... its a different story I´d reckon ;)
> Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option.
I just tested this out and I don't think that's a particularly good example of bad UI/UX. Clicking the email address brings up a menu with options for other actions, which presumably get used more often. If, instead, you right-click the email address, the option to edit it is right there (last item on the bottom, "Change email address"). I don't see this as a huge penalty given that, as you said, it's rarely used.
There's also the "X" to the right of the email address, which you can use to delete it entirely, no extra clicks required.
> I just tested this out and I don't think that's a particularly good example of bad UI/UX
Luckily for both you and me, we dont have to rely on our feelings of what is good UX or not. There are concrete UX metholodogies such as Hierarchical Task Analysis or Heuristic Evaluation. These allow us to evaluate concrete KPIs, such as number of steps and levels of navigation required for an action, in order to evaluate just how good or bad (or better said, complicated a UX design is).
Lets say we apply the HTA. Starting from the top of your navigation level when you want to execute the task, count the number of operations and various levels of navigation you have to go through with the new design, compared to just clicking and correcting the e-mail address in-place? How much time does it take you to write your e-mail in the both cases? How many times do you have to switch back and forth between the main interface and the context menu google kindly placed for us?
Now, phase out of your e-mail writing window and evaluate how many various actions you can execute in the Google Workspace. Most of them are likely to have a few quirks like this. Now multiply the estimated number of actions with the number of quirks and you will slowly start to see the immense cognitive load the average user has to face in using, or shall I rather say "combating" the google products' UX.
https://bluecinema.ch (To buy movie tickets for a certain movie chain in Switzerland. I haven't used this in many years, but at first glance it looks like I remember it. Back then, this was a very smooth experience both on desktop and mobile. Just perfectly done.)
Any spreadsheet program (it's the spreadsheet itself, which I like, not necessarily how the UI is aranged around it)
Apple's Spotlight, GNOME's similiar thing (don't know the name)
For the all the necessary complexity and race-to-the-bottom features, I am a fan of Jetbrains. I like using Uber, Twitch (wrote a plugin for it one weekend to integrate with chrome), Netflix, Discord. There are plenty of companies that manage to be enjoyable to end users and expose apis without the inscrutable abstractions and terminology I encounter using google products. It feels the same as working with Oracle.
Netflix? The barely functional video player accessed via excessively bloated thumbnail gallery? About the only good thing to say about this is that all the other movie streaming platforms somehow are even worse.
Its not hating - just stating the facts. Most companies unfortunately dont have a nice UX these days, because common UX practices like not making user think (i.e. overcomplicating the UIs) and not blocking users (showing annoying popups in the middle of UI workflows) somehow became a lost art. Some products are inherently easy to use like draw.io for example. I really like the UX on Stripe, in particular their onboarding process. There is also a semi-famous e-commerce company, in the furniture space. I forgot their name (something with W?), but I ordered something once, and was really impressed by how smooth and uncomplicated the process from browsing the inventory to checkout and delivery itself was.
No one's. Everyone sucks. Find a product and you'll find a population collating complaints about it. Whining about interface design is like the cheapest form of shared currency in our subculture.
Fundamentally it's a bikeshed effect. Complaining about hard features like performance is likely to get you in trouble if you aren't actually doing the leg work to measure it and/or expert enough to shout down the people who show up to argue. But UI paradigms are inherently squishy and subjective, so you get to grouse without consequences.
As somebody who already does this, I wouldn't say the Thunderbird's UX is the real motivation.
I do it for autonomy and avoiding lock-in, but Thunderbird has some frustrating inconsistencies particularly in its mishmash of searching and filtering.
More seriously - open source software is resistant to enshittification. It's obviously not a panacea, but the possibility of forks (or just the user deciding not to update), combined with the difference in profit motive, tends to result in software that respects the user.
(Taken holistically, the UX of software does not just mean the UI, or the moments when you are using the software. It also includes the stability of the software over time, including whether or not you are able to reject new versions whether you do not like.)
This. The only real risk with open source is that a (fairly niche) project is discontinued/abandoned, and you can't find binaries anymore for it anymore (and you don't have the skills to build it yourself). But this happens to proprietary software all the time (see killedbygoogle.com).
Omni Group. Wolfram. Parts of Apple. Rhino3D. Parts of Breville. Prusa (on device, not on desktop). Speed Queen (dial-based). Just from applications I currently have open and devices I can see from where I'm sitting.
I mean something that has a clear Google analog/equivalent that way can compare on. I personally think Wolfram Alpha (assuming that's what you're talking about) isn't any better than Google.
Never really used Alpha, was talking about Mathematica.
I don’t the the web is compatible with good UX, but that doesn’t mean good UX isn’t possible — it just means that the companies that are successful at UX build native applications, or physical objects, or both.
You are onto something there, if you mean, the design roles being taken over by the people who are not techies - like the POs. But if you just refer to UX being designed for mobile devices - that is not an excuse for an even worse UX on the mobile. If anything I would have expected more effort put in there, given how many more issues the limited screen estate can cause...
> wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse
UX? Google doesn't even bother helping folks locked out of their Gmail accounts. For people who use Android (some 3bn), that's like a digital death sentence, with real-world consequences.
It is almost comical that anyone would think Google is customer-focused, but might if they were being paid handsomely to think otherwise, all the while drinking a lot of kool-aid.
The thing is that at scale your edge cases are still millions of people. Companies love the benefits that come from scale, like having a billion people use their service, but they never seem to be capable of handling the other parts that come with it :(
Google rakes in $100bn a quarter; that's $1bn every day.
That is a great point too. For a company which effectively does not have a customer service, how can they claim to be obsessing about helping users at all?
And how are they supposed to do it if users did not add proper 2FA (and backup those recovery keys)?
Even banks are struggling to authenticate folks. For a longtime in EU people with 3rd world passports cannot create accounts easily.
Google cannot connect identity of a person to email address easily. Or they need to create CS - that will authenticate passports? And hundreds of countries, stolen IDs?
Nay.
> The thing is that at scale your edge cases are still millions of people
> never seem to be capable of handling the other parts that come with it
Same thing with govts. If you go to driver license. passport or any govt office then there will one person with some strange issue.
When Google first launched it's homepage, its emptiness (just a logo & search box) was a stark contrast to the portal pages popular, which were loaded with content.
Some thought the Google homepage "sucked" whereas other liked it. (I was in the latter.)
Likewise, the interface for Gmail. Or the interface for Google Maps. Or the interface for Chrome.
I remember when Google appeared and literally can't recall anyone who thought it sucked. There statistically have to be some people who hated it. But everyone I knew was either on dial-up or low bitrate leased line and it was impossible to dislike that design.
But not everyone was on dial-up. A lot were in dorms w/ (for the time) high speed connections or workplaces with it.
Remember at the time it wasn't clear that search was going to be the dominate pattern for how people found information on the web. It seems crazy now, but in the early days of the web, the space was small enough that a directory-style approach worked pretty well. It was Yahoo's directory that made it initially popular, not its search.
And so there was a fair bit of debate on which was better -- something like a directory + search (a la Yahoo!) vs just search.
It took a bit of time before search proved if it was done really well, you didn't need a directory.
As a developer I took the writer's point to refer to "users" generically, so that even if you work on some internal tools or a backend layer, you still have users who have to use your app or consume your API and there is a lot of learning possible if you communicate and understand them better.
Probably the users he is talking about are not the end users like you and me. It is one team using the tools/software of the other team and so "users" for that other team are the members of the first team.
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?
> 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.
Technically he said these are lessons he learned after working at Google, not that Google was necessarily doing these things. If we’re being generous maybe he learned this by counter example haha
I clicked through to the bio and am super confused. Third person, extremely long, lots of pictures with CEOs and smelling of LLM writing.
Here's a sample:
> 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.
The linked post itself also reeks of LLM writing (negative parallelisms in every other paragraph). But sadly, it seems like this is just the new standard for highly upvoted front page posts.
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.
There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
My personal rule is that the new technology stack item needs to either make is possible for me to build something that I couldn't have built without it, or needs to provide a productivity boost significant enough to overcome the productivity lost by straying from the more familiar path - even harder for team projects where multiple people need to learn the new component.
Yeah. I'm in agreement there. I guess that it's an application of The Law of Least Surprise for a future developer (who might actually be me, which it often is)
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.
And google wasn't founded by people who just kept their heads down and employed the simplest, most direct solution to the problem. If they had done that, google search would have been done on a super-fast server or mainframe using an RDBMS.
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.
I've never needed to sell myself. $corp will advertise needing a contractor and you apply as usual. If you have the skills and experience you tend to get hired.
The only difference is you don't get job security, pension or any perks. But you do get a lump sum though. Where you can then decide what's best.
The biggest one that resonates with me is that cleverness is overhead.
My #1 issue with mid level engineers is that they like complexity and find complexity fun and interesting.
An experienced engineer knows that complexity is irritating and frustrating and that a simple solution is harder and superior.
A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. If you are good you will do this a few times in your whole career.
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."
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.
I'd say it's a good sign – at least now you're aware it might be happening. A worse sign would be thinking you're definitely not that sort of personality; you'd be accruing silent resentment from both being loud _and_ clueless.
> Abstractions don’t remove complexity. They move it to the day you’re on call.
As someone who has been on call a lot, this is only true for bad or incomplete abstractions.
When you are on call (or developing) you can't possibly know everything about the system. You need abstractions to make sense of what is going on, how the system as a whole works, and know which parts to hone in on when things go wrong.
And it is extremely useful to have standard ways of changing configuration for things like timeouts, buffer sizes, etc. in a central place.
I don't think it's meant to be a point against abstraction or a point against complexity. I think it's widely understood that abstraction is part of how advancement is made in our practice, as well as in other disciplines. I have taken this saying to be an observation that there is almost always possible failure beneath the façade provided by the abstraction. Therefore, yes, you avoid having to let that complexity enter your brain, but only when the abstraction is holding. Beyond that point, often after pages are sent, you will still have to engage with the underlying complexity. A proactive measure following from this idea would be to provide support in or alongside your abstractions for situations where one must look under the bonnet.
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.
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.
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
YES! And sometimes that stranger is you, 6 months down the line.
I don't know if there's a named law, but the word for not knowing and believing that something remembered is a novel idea is "cryptomnesia".
Knowing that you know something by teaching is Feynman's method of understanding. Basically, on scanning, I don't particularly disagree with the content of the post. However, treating these things (many of which regularly show up here on HN) as being due to "14 years at Google" is a little misplaced.
But, hey, it's 2026, CES is starting, and the hyperbole will just keep rocketing up and out.
The quote "Sorry this letter is so long, I didn't have the time to write a shorter one" (Mark Twain, Blaise Pascal, lots of debate) sticks with me over the years. I appreciated the several points from Addy supporting this idea: when writing code has never been easier and faster, it takes even more time to make sure that the code being written is truly useful and necessary.
> 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?
> First do it, then do it right, then do it better. Get the ugly prototype in front of users.
Great, give users something that messy, horrible and not fully functional.
Customer who spend big for production environments are exploited to "be
the outsourced QA"
> 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.
According to Nietzsche, masters create morality; slaves respond to master morality with their slave morality. Unlike master morality, which is sentiment, slave morality is based on ressentiment—devaluing what the master values and what the slave does not have. As master morality originates in the strong, slave morality originates in the weak. Because slave morality is a reaction to oppression, it vilifies its oppressors
I think it's inevitable everyone will use LLMs to assist with writing, such as editing, if it hasn't happen already. It's like having a free editor, beyond grammar or spell-checking.
If the only reason you write is as a means to and end, sure. Inevitable. If you pursue it as a craft then the struggle and imperfections are part of the process. LLM usage would sand away those wonderful flaws.
The AI slop voice is grating to me and many others. If you can avoid it or make it not feel like slop or make it feel unique, people will like it more. I don't care how you do that tbh
Ideally, yes, but the final result of LLM assisted textual output by many users shows that they often have neglected the editing part just as much as they have neglected the writing part.
My father-in-law did a fair amount of editing back in the day (on paper, with red pencil/pen). He said that, when you saw something that had "blood" (red) all over it, that meant it was good. When things are bad enough, it becomes hard even to edit it.
It may not be just that people don't edit LLM output. It may be that the stylistic blandness is so pervasive, it's just too much work to remove. (Yeah, maybe you could do it. But if you were willing to spend that kind of effort, you probably wouldn't have an LLM write it in the first place.)
> 16. Admitting what you don’t know creates more safety than pretending you do.
> Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.
It's interesting to contrast this with Sean's statement here www.seangoedecke.com/taking-a-position/
> At that point, you need to take a position, whether you feel particularly confident or not.
> If you don’t, you’re forcing people with less technical context than you to figure it out themselves
To square the circle, I think the lesson is hide uncertainty to higher-ups, but don't to peers/ other ICs.
Of course, the challenge is that often, unfortunately, both the manager and the other ICs are in the same meeting.
Probably this is one justification of one reason why I hate meetings that include managers.
I'm very suspicious of this working in the modern technological age. Even in university I'm feeling this: it is hard to create a bond with real friends, but extremely easy to regress to anonymity and become a loner.
Usually there are nuggets of wisdom in lists shared like this but I feel like every lesson shared here has immense value.
> "remain skeptical of your own certainty"
> "Model curiosity, and you get a team that actually learns."
These are two lessons that typically require battle scars to learn. For such big ideas to be summed into two sentences is pretty remarkable and puts to words lessons I wish I knew how to share. Amazing article, thanks for sharing!
I was going to skip the article until I read your comment, and wow! You’re totally right - my hard won understanding is there, including things I sort of knew but couldn’t put into words before. Going to share this with my adult kids.
same usually, i read this and see this some flawed or hackneyed tripe.
But these ones are actually true and anyone who has had a long career and led people and product will resonate with many of them.
> 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.
> Abstractions don’t remove complexity. They move it to the day you’re on call.
Then they are bad abstractions. I get where he is coming from, but the entire field is built on abstractions that allow you to translate say a matmul to shuffling some electrons without you doing the shuffling.
> Before you build, exhaust the question: “What would happen if we just… didn’t?”
Well said! So many times I have seen great products slide down. If they just froze the features and UI, and just fixed performance, compatibility and stability issues for years, things would be better. (this applies to any company). Many programs I use are years old. They are great programs and don't need constant change! Updates can only make it worse at that point (minus critical security issues, compatbility, performance regressions)
This sounds like an accumulation and reiteration of other peoples ideas and blogs, barely changing or adding anything. Fair, but I was interested in the author’s own ideas or how those ideas they’re reiterating matter within the context of Google.
17. Your network outlasts every job you’ll ever have.
Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.
They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.
Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
When the time comes to move on, it’s often relationships that open the door.
Thanks! I used to think writing code was the easiest and most enjoyable thing in the world. Interacting with people? That’s always been the hard part. Guess it’s high time I changed my mindset now.
This has to be the 50th or 100th version of this article that repeats the same thing
Every single point in this article was already explicitly described between roughly 1968 and 1987: Brooks formalized coordination cost and the fallacy of adding manpower in The Mythical Man-Month
Conway showed that system architecture inevitably mirrors organizational communication structure in 1968
Parnas defined information hiding and modularity as organizational constraints, not coding style, in 1972
Dijkstra *repeatedly warned* that complexity grows faster than human comprehension and cannot be managed socially after the fact
None of this is new, reframed, or extended here; it is a faithful re-enumeration of half-century-old constraints.
These lists keep reappearing because we refuse to solve is the structural one: none of these constraints are enforceable inside modern incentive systems.
So almost like clockwork somebody comes out of nowhere saying hey I’ve I’ve observed these things that are consistently documented in history of organizational management and specifically computing and software management look at this list.
The fact that people don’t learn from the older books is somewhat annoying, but rewriting them makes sense precisely because people will likely trust it more.
Software engineers are prone to novelty bias. Thats in contrast to some other demographic groups who very much prefer ancient texts.
Yeah but what do you want to do about it? The engineers I see making these mistakes day-to-day are not going to connect the dots if I just point them to the seminal writings. Heck, half of their complaints are of the same form as yours: if only the majority of [engineers, colleagues, stakeholders] were aware of [A, B, C principles] then we could avoid repeating [X, Y, Z failures]. Yeah it's exhausting, life is exhausting, and it doesn't inherently get better with knowledge and experience as the gap to the lowest common denominator only increases; the only balm I've found is focusing on what I can control.
We’re currently around 30 in engineering full time and 40 if you include ops, logistics etc…with new funding and coming out of stealth etc we expect to hit the dunbar number (~150 this year)
Clarity is seniority. Cleverness is overhead. - On a consulting project where the client was building a 5000 user plus application. They had an amazing architect, know all the best frameworks and had implemented that on the project. Issue is, only he understood the framework (even though it's documented on github) and it costed the developers more time to understand the framework than if the code was a little "dumber". Then he left for a better role for his career as he should. Because of that, the devs and new architects abandoned the framework and built new things around it and now the old framework is "tech debt".
14 years? Wild. I remember when Addy came into the scene hot with a new jQuery tutorial (what seemed like) every few days. To be clear, that's not a knock despite how it may read in 2026.
What skills compound after 10+ years? (Ask HN: Submission)
I've come to realize that not all skills can stand the test of time.
Some things were very useful initially but quickly plateaued. Some felt like they were moving at a slow speed, but were quietly compounded a year after.
I always return to a rough outline.
Quickly acquainted with tools, frameworks, and specific stacks.
Slow skills: judgment, problem framing, communication, taste.
The gradual changes are often unnoticed daily but become apparent over time.
Projects become unclear.
Pile up constraints.
Being right is less important than the trade-offs you make.
I’d be interested to know what you think.
Which skills were more useful than you anticipated?
What’s something you over-invested in early on that didn’t compound?
What would you choose to learn more slowly if you had a second chance? ~
Lesson 11 (Abstractions move complexity) and Lesson 20 (Time > Money) are two sides of the same coin.
In engineering, we talk about "leaky abstractions" in our code. But the biggest leaky abstraction is often our own health. We treat our bodies as a "boring dependency" that will always work, but burnout and RSI (Repetitive Strain Injury) are essentially the ultimate system outages.
Just as "Novelty is a loan" (Lesson 5), neglecting your physical "hardware" early in your career is a high-interest loan that you end up repaying in your 40s. Real seniority isn't just about navigating people and politics—it's about managing your personal energy so you actually have the health to enjoy the "compounding" (Lesson 21) that comes at the end.
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.
#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.
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.
I think part of the importance of being a senior engineer is not spreading hype through the industry. This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week, followed by tweets from his eng team clarifying its just “demo” grade.
Aren't #2 and #14 mostly the same point? And they seem to indicate a rather unhealthy cultural dynamic. Amazon's "Disagree and commit" is a much healthier dynamic than "Pretend to agree and then silently sabotage."
I think there's a valid middle ground in finding a path that works well for everybody, but this does not seem to be the right way.
I wonder if this is a common thing at Google because I recall another interview (can't find now, I think in the context of WebRTC??) from many years ago where an engineer proudly described how he conspired against a major technical decision because it didn't align with his personal preferences. I was a bit shocked to see someone admit something like that so publicly.
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.
My favorite is the first one, "The best engineers are obsessed with solving user problems." and what I hate about it is that it is super hard to judge someone's skills about it without really working with him/her for a very long time. It is super easier said than done. And it is super hard to prove and sell when everybody is looking for easily assessable skills.
This is why (flawed though the process may be in other ways), a company like Amazon asks "customer obsession" questions in engineering interviews. To gather data about whether the candidate appreciates this point about needing to understand user problems, and also what steps the candidate takes to try and learn the users' POV or walk a mile in their shoes so to speak.
Of course interview processes can be gamed, and signal to noise ratio deserves skepticism, so nothing is perfect, but the core principle of WHY that exists as part of the interview process (at Amazon and many many other companies too) is exactly for the same reason you say it's your "favorite".
Also IIRC, there was some internal research done in the late 2010s or so, that out of the hiring assessment data gathered across thousands of interviews, the single best predictor of positive on-the-job performance for software engineers, was NOT how well candidates did on coding rounds or system design but rather how well they did at the Customer Obsession round.
> 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.
There are many big bosses under the Google CEO that lead hordes of developers to specific targets-to-meet. Eventually they prioritise their bonuses and the individual goals deviate with every iteration. So the quality will diminish continuously.
This is good. I worked at google and lasted less than 2 years. Many other things happening in that time - came in via acquisition, worked on backend for that, dad died, transitioned teams, etc. But I was 27-28 and couldn't really navigate that world after my first job at a startup. In some ways, I wish I'd found a way, but in other ways, I know it wasn't meant to be. It's a good list, if you want to do 10 years at Google or elsewhere, internalise that list and it's lessons.
Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug!
I know this as Hyrum's Law (which also comes from a Googler):
"With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody."
It's funny that I agree with most or all of these principles but don't feel like my 10 years at Google accord with most of this. I wouldn't say I learned these things at Google, but learned them before (and a bit after) and was continually frustrated about how many of them were not paid attention to at Google at all?
Incentive structure inside Google is impaired.
I do think Google engineering culture does bias against excessive abstraction and for clean readable code and that's good. But acting in the user's interest, timely shipping, etc... not so much.
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.
Your post is absolutely golden and it doesn't apply only at Google.
I can't remember seeing so many deeply true statements together in one post.
I'm sure many here will start to contest some of them but with enough experience they will also realize that the points were true.
It is furthermore hard to believe that the engineers are working for the users, given that google’s primary activities today are broad enshittification of their products.
Because of these two things I did not make it past point 4.
It just reads like a very expensive AI which is very well prompted. I would love to interview him without his phone to see if he can reproduce even 5 of these points.
I'm sure he's a super capable, experienced, and extremely well spoken person. There is no excuse of AI writing outside of writing that pays your bills.
The skill isn’t being right. It’s entering discussions to align on the problem.
Clarity isn’t a style preference - it’s operational risk reduction.
The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.”
This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone.
The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should.
This isn’t passive acceptance but it is strategic focus.
This isn’t just about being generous with knowledge. It’s a selfish learning hack.
Insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission.
There’s some really solid insights here, but the editing with AI to try to make up for an imperfect essay just makes the points they’re trying to convey less effective.
The lines between what is the author’s ideas and what is AI trying to finish a half or even mostly baked idea just removes so much of the credibility.
And it’s completely counter to the “clarity vs cleverness” idea and the just get something out there instead of trying to get it perfect.
Thank you for doing this. It allowed me to skip reading the article altogether immediately knowing it is AI generated slop. Usually I'm a little ways into it before my LLM detector starts going off, but these "This isn't X. It's Y." phrases are such a dead giveaway.
These all jibe with my 25 years of experience (only one at google though). I'll add:
* Don't work "off the clock", no matter how strong the urge: There's nothing managers hate more than surprises. Even good ones! If you've got some idea to work on, discuss it and get buy-in early. If you're spending a lot of your own time on something, that means it's probably low-value and you subconsciously know it, or it's stepping on somebody else's toes, or it's something that you're the only one who cares about. Once you're done, all your manager is going to say is "why were you doing that instead of <other higher priority thing>", and if it creates a bug or user complaint or anything else, you'll be on the hook. Save your creativity for personal projects.
* Get fast feedback. This kind of relates to the above, but more generally, iterate quickly at every scale. If testing your changes takes more than one button click and a couple seconds, whether compile time, staging deployment time, etc., fix it. Find out how others are automating their dev flows. A tiny bit of improvement here cascades greatly. Get fast feedback on designs: don't spend a ton of time writing a long doc and waiting for approval; send out a 1-paragraph summary or whatever you think the minimum is, get signoff, get done and move on. Do document, but don't overdo it. Get fast feedback on ideas; don't wait until code review time to find out that the team was planning a different direction. Yes, this does kind of suck if you're naturally introverted and prefer just coding, but it's part of the job.
* Set an extremely low bar for each day, but meet it. We aren't all superstars all the time. There'll be times when you're burnt out or blocked by something you really don't want to deal with, and making progress can seem overwhelming, so "I'll just surf the web for a while" turns into all day, which can turn into all week or all month of excuses about how little progress you're making, and the anxiety and guilt becomes more overwhelming than even the work. Avoid this by setting an easily achievable goal: a couple lines of code, a quick chat with someone who might know how to unblock one thing, whatever. That way you're not letting the anxiety build, you're not waking up the next day in the same state that you were the previous day, you at least have something to talk about during standup, and it's one less thing to deal with. Oftentimes it creates some momentum, and turns into a fully productive day! But be okay if it doesn't: the goal is just to get that one thing done, and anything else is purely optional: sometimes it's good to have an off day to recharge, so long as you're not starting the next day in the exact same position.
I agree to both 3) and 8) but I find it a dilemma that if you don't get it perfect the first time, you will waste thousands of man-hours for everyone to upgrade even though it only took you 10 minutes to release the new version.
If you personally build all (or most) of the stuff, you are in an extreme vertical integration benefit situation. You can make huge system wide changes in ways that would not be possible without having done so much novel work.
> 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
> First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate.
I've met Addy and I'll be generous, but strong disagree here, and this really shows a huge blind spot in how software is being developed today that hurts everyone.
There aren't two extremes between "theoretical debate" and just shipping the first crap you can slap together. Software engineering will never become a real discipline when industry keeps ignoring the lessons of every other field of engineering: gather some requirements first.
Want to know what users want? How about asking them? What about doing some research on what tools they are using now (or not) and finding out what's wrong with them. What about doing a user study? What about analyzing competing and previous products?
How about then drawing up a list of things that say what the thing will do? You can keep the list short, sure. Build a prototype (maybe for internal use)? Sure. No need to have every piece of functionality there.
But there's an enormous blind spot here I'd be remiss to point out. Back in the shrink-wrapped software days, back when products took months and sometimes years to develop, man, people really planned out what they were going to build! And I'm not just romanticizing that era--there was a lot that could go wrong, and many misses--but tons of software developed in that manner sticks with us today, not just the designs and usage patterns, but big chunks of the code too. It's not all legacy cruft; people actually thought about what they wanted to build, and then laboriously built and tested it--with crappier tools, longer build times, and many disadvantages like huge teams, crappier communication, and a whole lot less computational power.
There are other things in this list that are good advice, but I felt like this cannot possibly be the whole truth to 14 years of experience. In other words, please don't just ship your crap to us the first time it functions.
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.
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.
> 1. The best engineers are obsessed with solving user problems.
Complete bullshit. Sorry, but the reason why people use Google is because of the ecosystem + value proposition. Google Drive & Calendar are some of the most outdated pieces of SaaS software that only gets used because of the greater ecosystem they live in - and price. They (along with the other Google products) are also some of the poorest designed user interfaces online. Let's cut the crap for once here. If I were Google I would be worried because companies like Fastmail, Notion & Proton are quickly catching up.
the writing was already on the road w.r.t to user mindshare among normies. I see no evidence of the same happening with fast mail. why would anyone switch from gmail to fast mail other than privacy, which regular people couldn't care less about?
Thats a poor characterization to choose 2 of the least talked about apps from that company. Also your response to the claim "the best engineers do X" is logically flawed. Maybe google doesn't use their "best engineers" to build out those cherry-picked examples? maybe they used them for Search or infrastructure or something else?
I'm commenting on the article, and the first point in the article doesn't sound like search or infra. Maybe read that before assuming things. And why would it be "logically flawed"?
google has a lot more products besides the 2 you picked. Some of them are wildly successful, even. Maybe they use their "best engineers" on the more successful products?
A lot of lessons from Google are really lessons from a historically unique monopoly era that no longer exists. Useful context, but dangerous to treat as timeless advice.
As much as we meme about it internally, one of my favourite things about AWS was the leadership principles. I always worried I've became cult like biased. Seeing how these converge to similar great ideas is a relief.
IMO the most common denominator among all these is trust, in order for many of these to work. From policy setting at strategic level, hiring, to tactical process refinement, the invariant must always be building an environment and culture of trust. Which isn't trivial to scale.
it's sad that startups become corps and decay. this article is the perfect illustration, from the bio, to the llm slop content of the article. Just sad it has to be this way
Very good. I agree with most of it. One thing I disagree with is "The senior engineers I respect most have learned to trade cleverness for clarity, every time.". This sounds like the anti-pattern "design for lowest competence" or similar. This is a big trap. A little bit of magic is often better than clarity. Junior devs should learn to follow the rules and how things work without the actual need for deeper understanding.
Worked at an AI training company for a few months. Enshittification is real. Idiots who never deserved to be here coming up with new policies every week, sometimes twice a week. Absolutely spineless when receiving nonsense from the client which is one of FAANG but will screw colleagues with no remorse.
excellent article and appreciate the author sharing his perspective which is very valuable.
For me the main lesson is, don't let your ego develop from success. Any human is vulnerable to narcissism. It is an interesting phenomenon, where you can originate as a humble person who becomes successful, only to lose your great qualities, when your identity changes. With success you attract different people in your life who may be attracted only to your success and who don't have the stones to confront you on your bs.
Developing healthy self awareness comes from surrounding yourself with people that love you, but are not afraid to keep you honest if you do something out of character.
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.
Some people think clarity means abandoning language idioms and writing simple code that a first year computer science student could understand and follow.
If you do this, your team will write verbose, repetitive code, and put more emphasis on procedures instead of data structures and how they change over time.
Use the language features to write powerful concise code that really takes some skill and expertise in the language to understand. Force your team to become more skilled, don’t stoop down to the lowest common denominator. In time, this code will become as easily understood as any other simple program.
And when shit breaks down at 2 AM, you do nothing, because your code is clever enough to handle problems itself.
This feels somewhat hypocritical coming from Addy.
Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts.
I cannot accept his apology until he actually syndicates it with his followers.
Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance."
You posted the code to a public blog page, with no attribution in the code or request of attribution from others, no license, and seemingly intended to share it freely with the world.
Then you got an apology, and a second apology.
I'm confused about what you think you're owed?
The explanation makes perfect sense, the headers were obviously just copied with no malicious intent. What is it that is still bothering you about this?
> no license, and seemingly intended to share it freely with the world
No license means you don’t intend to share it “freely”, since you didn’t share any rights. By default, you don’t own things people shared on the internet just because it’s there.
That being said I’ve even seen people with licenses in their repos who get mad when people used their code, there’s just no telling and it’s best to just treat random sources of code as anathema.
I think GP is referring to the fact that an author’s work is copyright protected by default, and a license is needed to permit others to use freely [1]. StackOverflow posts are licensed under CC BY-SA 4.0 [2].
(Disclaimer: Just commenting on GP’s statement about “no license”, not on the specific disagreement or apology mentioned above which I am unfamiliar with.)
It's worth noting that the code in question was also open sourced and permissively licensed by the original author as he stated in the thread[1]. I guess this isn't really about licensing at all, just the original author seems to think it was rude, and also doesn't want to accept any of the apologies that have been offered.
> with no attribution in the code or request of attribution from others, no license, and seemingly intended to share it freely with the world
The bottom of every page on my blog has a copyright link that you can follow. I dedicated the code to the public domain. I never made a copyright claim. I simply asked Addy to not claim to authorship of the code.
Not to make excuses for plagiarism, I am looking at the code itself and somewhat scratching my head since it seems quite...trivial?
I don't mean to belittle the effort but at least in terms of volume of code and level of effort, I wouldn't recognize it as mine if someone had copied it from my work and passed it off as theirs.
Regarding the charge of plagiarism, is it possible that the PR attribution reflects someone eager to contribute something to a larger effort as opposed to simply trying to "steal" someone else's work?
One could reasonably interpret the PR and attribution as "I integrated this code into this project thus I am taking credit for it". In other words there is probably a stronger charge for misguided clout-chasing than plagiarisms.
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.
You are libeling me. That is not what I posted. My original post, accessible via the GitHub comment version history is
"@addyosmani No problem; just remember that modifying someone else's code does not grant you any copyright to that code. I don't agree with your opinion that inserting existing code into a template (the API) for a framework (Modernizr) warrants a notice of credit, even with a few changes to the code being inserted."
If you run it through originality.ai, you'll see that bits of it are his writing, some is mixed and some is just ai. This blog post everyone is discussing is also written with ai.
you got a written apology already, what else do you want?
a post of this in all of his socmed accounts? him telling this story to his kids at dinner table and bedtime stories? at his eulogy, obituary, and his grave?
what's your life mission now, to post this little drama of yours on each and every content he puts out?
was that code your best achievement to date? did it stole millions from you and ruined your life?
I tend to see my code in these terms as well, it's not dear to me. But I'd never presume to tell someone how to feel over having their work stolen (and I'm using that term because that's how I'm sure Mr Grey felt).
Plagiarizing code is kind of a redundant concept nowadays in the era of LLM coding engines. It's a safe bet there's always copilot plagiarizing someone's code on one of its users' machines, both being oblivious to it.
That's a bit different from knowingly taking a friend or former partner's code and putting "by Your Name" on top of it before sharing it with outsiders
Some people just want to be remembered for the "engineering" / "social engineering" they did, while others what to be remembered for being employee of the month for 10+ years at the company.
Both are a complete waste of time.
It's more impressive if you bootstrapped your own company to millions instead of chasing false praise, engaging in employee politics and being employee #470293 at big company.
But I predict you will get the same thing with those at the big AI companies.
Or to say it in his own words: "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." source: https://addyosmani.com/bio/
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.
Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose):
- Start with the user, not the toy. Get unreasonably concrete about real user pain (tickets, observation, “why” drills), and let solutions fall out of that—otherwise you’ll build complexity to justify a preconceived answer.
- Engineering is a team sport: alignment beats being right. The job is getting to “right” together: create shared understanding, reduce misalignment (the real cause of “slow” teams), avoid “winning” debates into silent resistance, use metrics carefully (they get gamed), and design process to reduce uncertainty rather than produce paperwork.
- Ship early, then iterate—clarity over cleverness. Bias to action: drafts and MVPs teach faster than armchair perfection. Write code and docs that are obvious at 2am during an incident, not “impressive.” And treat novelty as debt you repay in ops/hiring/cognitive overhead—spend your “innovation tokens” where you’re uniquely paid to innovate.
- Do less: deletion is a superpower (and often the fastest optimization). Prefer “code you never wrote” (or work you removed) over clever additions. Many performance wins come from removing unnecessary computation, not adding fancy machinery.
- Respect scale and failure: compatibility, migrations, and leaky abstractions are the real product. At scale, even bugs become dependencies; deprecations are migrations with empathy/tooling/time. Abstractions don’t erase complexity—they postpone it until on-call—so keep a working mental model of what’s underneath.
- Make your impact legible and invest in compounding. Code doesn’t advocate for you—people do—so communicate outcomes, not just activity. Use writing/teaching to force clarity and deepen your own understanding; treat “glue work” as deliberate, bounded, and visible. Build psychological safety by saying “I don’t know.” Maintain relationships because your network outlasts any job. And manage your career like compound interest: protect time, practice deliberately, turn scar tissue into reusable playbooks.
The fixation with AI really harms the signal-to-noise ratio on HN lately. The author of this article very clearly used an LLM to generate much of it, which makes it read like the clickbait you see a ton of on LinkedIn. Then a commenter posts an LLM-generated bullet list summary of the LLM-generated article, which really adds nothing to the discussion.
Ultimately the author had some simple ideas that are worth sharing and discussing, but they're hidden behind so much non-additive slop.
in the first item, LLMs don't use incomplete sentence fragments?
> It’s seductive to fall in love with a technology and go looking for places to apply it. I’ve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding.
I suppose it can be prompted to take on one's writing style. AI-assisted, ok sure, but hmm so any existence of an em-dash automatically exposes text as AI-slop? (ironically I don't think there are any dashes in the article)
EDIT: ok the thread below, does expose tells. https://news.ycombinator.com/item?id=46490075 - yep there's definitely some AI tells. I still think it's well written/structured though.
> 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.
many of the replies in this Hacker News thread read like AI replies too. I think the internet is dead as we know it. ~100% of content will be bots writing for ~100% audience of bots
There's hardly anything original here. These are regurgitated points you'd see in any article of this type. In fact, your favorite LLM can give you the same "lessons" from its training data.
I have followed him for a long time and learned a lot too. I always wonder the same thing about the “tech influencers” and I’d love to know more about how they structure their days.
I find it difficult recently to sit down and complete a meaningful piece of work without being distracted by notifications and questions. In the last year this has been exacerbated by the wait time on LLMs completing.
I would love to know how top performers organise their time.
> At scale, even your bugs have users.
First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee the software was ready before they’d even stood up from their desk!
The moral of the story, and the quote, isn’t that you shouldn’t improve things. Instead it’s a reminder that the software you’re building doesn’t exist in a PRD or a test suite. It’s a system that people will interact with out there in the world. Habits with form, workarounds will be developed, bugs will be leaned for actual use cases.
This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. 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 load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee
One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk.
I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.
Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.
What a great comparison; I've never thought of it this way. It's obviously not perfect since the automation is so temperamental shall we say, but this does give me more empathy for the countless workers whose jobs have been re-natured by technology.
From their prospective, the efficiency increases and more gets done, but the hours and wage stay the same and the number of co-workers may decrease.
I don’t even have to imagine it, you just described my job now that we have LLMs.
I believe that was the point
Reading it back now it does seem pretty obvious. That’s what I get for commenting right after waking up!
All good, it's a Monday morning
efficiency is the enemy of employment, no?
The amount of work expands to fill the available labour. All other things being equal, at least. Which they aren't, but it's a usefully wrong model.
There’s many praises to sing about efficiency, (and I don’t take your 1 liner as a position against it). That said, efficiency, job creation, and underemployment overlap quite a bit.
There’s far more scientists, programmers, and doctors today than farmers and stablehands.
At the same time, people who lost manufacturing jobs to automation and outsourcing, did not get jobs with equivalent pay and growth.
Human brains do not get retrained very easily, and so every technological revolution is a boon to those who grasp it, and a challenge for those who invested their time in skills no longer in demand.
Nursing massively expanded but they didn't want to take it.
You can't expect factory workers to magically turn into nurses. Sure, people can learn new things, but human skillsets are not entirely fungible.
One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.
In Norway there's laws for that, but other places do it even without them. You just retrain the person to do something else. He might take a job of a temp that was hoping to get a fast contract (instead of a few weeks at a time during trial period). Other than that, it's good for the person (not losing job) but also for the company - you get a tried person with good work ethics that comes on time. It's not zero cost to find somebody like that.
A lot of places in the US are not, in my experience, that intelligent about hiring people.
Or, say rather, the externalities of the cost of hiring are not imposed on the people choosing to fire, directly, so they can say they "improved efficiency" by firing someone, and then the people trying to find reliable labor do not experience any improvement that might have been available by migrating the person.
agreed. the "lump of labour" fallacy is a thing -- the idea that there are always more bodies and that it's trivially easy to hire, train / get up to speed, and work them.
in practice hiring and firing is expensive and often very risky. Bjorn the office worker may now be redundant and have a room temperature IQ but he's shown he'll show up on time, sober, and is liked by his coworkers enough, so throwing $5k to retrain him may be a far, far smarter investment then blowing $7k to hire a rando for another position...
Yeah the bar for competent is surprising hard to hit. A human being that shows up on time and it's reliable, doesn't have a problem with drugs or alcohol, or has a sick family member and just needs an advance. Good help is hard to find!
If you're only getting those kind of candidates, then your job offer isn't attractive enough.
then the pendulum swings the other way and now I have ruthless mercenaries chasing $$$ who will jump at the first opportunity
and not every job needs to be top-shelf.
Betty in Accounts-Payable just sorta needs to be there and not screw up too often. I don't need a super-star, and if we have to move her to another part of Accounting that's fine; I'll save my money for a solid CPA or two, etc.
I understand the rest, but an otherwise capable person with a sick family member does not clear the bar for competent? Saddening if that’s where we are as a society.
I think the key part of that sentence was "...and just needs an advance", implying that they're going to take the job, ask for a cash advance for a (possibly fictional) sick family member, and immediately quit.
It’s hard for some people to understand that situation until they are in it. Unfortunately.
Totally agree with you.
Why do the laws exist if its better for (almost) everyone involved? Without the laws why would people not do it that way if its the better approach?
Many laws solve the problem of high initial cost dissuading globally good actions. Laws forcing everyone to buy insurance, for example. It's very easy to see that where such laws don't exist, almost no one buys insurance, making everyone worse off.
This is also an example of the same kind of law.
Insurance is an interesting example, I would have expected one that causes more direct harm to others like drunk driving.
How are we all worse off when fewer people have insurance?
Healthy young people are less likely to buy insurance than sick older people. But if only sick older people buy insurance the payouts per insured are going to be higher. That in turn causes high premiums. Insurance works if everyone buys in, pays while they are young and relatively healthy, and gets paid healthcare when they are older and sicker.
If you “game” it, it breaks the whole system.
Now some of you might be thinking “why should a young and healthy guy like myself subsidize the old sick people?” The answer is that you will also get old.
What you are describing isn't really private insurance though, its a privately run socialized healthcare system. There's nothing wrong with that, it simply isn't insurance.
Think of something like home owner insurance. Your insurance rates depend on exactly how your home is built, what type of heating system it has, where it is, etc. The rates, carefully calculated by actuaries, act as a signal to you as to how dangerous your house is to yourself, but also to others. If you set your house on fire due to negligence and cause the next house to burn, you might be liable for damages there as well.
Forcing everyone to buy such insurance forces everyone to fully pay for the expected cost of the danger inherent in their house. Over time, this causes houses to be constructed in a safer manner. If people are not forced to buy insurance, they don't buy it, and so this evolution over time does not happen. Also see [1].
Some financial tools are amazingly clever - whether they are morally good or bad. Bits about Money is a great blog to build insight into some of these constructions [2].
Another example for your initial question is car seats for kids. If you don't force em, nobody buys em. Then their kids die.
[1] https://en.wikipedia.org/wiki/Moral_hazard
[2] https://www.bitsaboutmoney.com/
For the insurance example, you're describing insurance as a forcing function for better made, safer buildings. That's what building codes are for though, we shouldn't need to have both and building codes are a more efficient and direct way of ensuring safe buildings.
For car seats, I'm not sure how we could know that people wouldn't buy them. I don't expect anyone would propose dropping the requirement to see how the market responds, and probably rightfully so. If car seats are much safer though (and I'm obviously not disputing that), people that can afford one would buy it anyway.
> ... building codes...
I agree that in an ideal world that would be sufficient. But in practice, governments rarely deploy trained actuarial to make decisions, rather relying on politics and shoddy studies. Government codes also change very slowly. Insurance companies (whether private or public), under the financial incentive, are constantly changing their policies and rates in response to new data and calculations. I would be open to looking at studies that resolve this question one way or another.
> ... car seats...
I grew up in a poor global south country. Rich people, who clearly can afford them, don't buy car seats. Many people who live in countries where they are forced to buy car seats, when they come back on vacation don't use car seats for their kids. People can be very irrational.
I'd love to see this argument used to get rid of legal authority to create building codes. You make a great point, and you're effectively pointing to the fact that, at least for that specific problem, the market is much more efficient and solving the problem than government regulations.
The car seats one is tough. If you've seen first hand examples of people actively choosing to forgo car seats, I'm not sure if that's a problem governments should solve. Unless the state directly claims "ownership" as it were in the child, the parent is their legal guardian and if the parent makes a terrible choice they have to live with the repercussions. We don't regulate all decisions that can harm a child, that's a tough line to draw.
Norway has very strict pro-workers laws in general, it's just one facet of them. One Norwegian explained it to me like that: in the late '60 when Norwegian oil industry started developing, workers realized that they can incur great losses on the companies if they organize/unionize and strike together. They used that as a leverage to both change their contracts (to include paid sick leave and such) and also get better working conditions (Norwegian platforms have both better safety and on platform to on land ratio).
And later other trades did the same. Some of the things in contracts trickled down to the law. But still some laws apply only to companies where at least a certain % (is it 50%?) are unionized.
The general picture is more or less like that, but please verify the details.
And they will have to go find another job instead. It feels weird but this is how we raise living standards - removing human labor from production (or, in other words, increasing the amount produced per human)
Automation is a game of diffuse societal benefit at the expense of a few workers. Well, I guess owners also benefit but in the long term that extra profit is competed away.
That's a highly idealized view that I hope we can agree doesn't completely jive with what we see in society today. If a small number of shareholders reap all the profits, the vast majority of the benefit from automation flows to them, and it's even possible for the lives of average people to get worse as automation increases, as average people then have less leverage over those who own the companies.
Inflation adjusted incomes are up in the US across the board. The affordability problem is largely the price of housing because it's illegal to build.
Incomes are up, but the expenses are up as well, especially with the upcoming changes in healthcare for people on the ACA.
Also any comparison of wage growth vs corporate profit growth over the last 30 years shows that wages have not kept pace with the increase in productivity.
So incomes are only just barely keeping up, when they should be booming.
How can inflation adjusted income be up and there still be an affordability crisis?
Housing is not part of the inflation calculation. There IS a housing inflation crisis.
Household income is more than just wages. Household income can go up while wages remain stagnant or shrinking because other pieces of the pie are increasing (e.g. work benefits, investments, money from the government). https://fredblog.stlouisfed.org/2016/09/sources-of-household...
The price of housing can rise even faster than incomes.
Housing is only a part of the basket used to measure inflation. Housing's price rose faster than the weighted basket average, some other goods and services rose slower or even fell.
Accommodation costs are the first part of any sensible measure of inflation. If you're not factoring in housing then you're fudging the figures.
Many people don’t see housing inflation - if you bought a house in 2020 and house prices were up 80% since then it doesn’t affect your housing costs, especially in the US where mortgage rates are fixed for length of term even if interest rates sky rocket.
Yes? Who says otherwise?
As long as accommodation isn't 100% of your basket of goods and services you use to measure inflation, accommodation can rise in price faster (or slower) than the basket. This ain't exactly rocket science.
Housing, schooling, healthcare, daycare, food.
Samsung TV purchasing power has skyrocketed, though, so there's that.
Inflation also corrodes your savings and investments.
Yet more and more people are struggling to afford even basic necessities and one can only dream of the luxury of the 50's when a single working class person was able to pay and cover for housing, car, family and even have enough for leisure. Where has all the economic surplus gone? Right...to the bourgeois, the capital owning class that exceedingly extract more and more of the wealth generated by the society.
because the developing world is producing a lot of things except the housing.
They also don't produce haircuts.
On average, most large cap stocks (MSFT, GOOG, AAPL, etc) are owned by millions of retail investors through 401Ks, mutual funds, ETFs, and direct ownership.
Median net worth at 40 years old in the US is less than 150k. Most Americans benefit very little from share prices rising, at least directly.
Of the US stock market half is owned by 1%.
https://fred.stlouisfed.org/series/WFRBST01122
Actually I believe this graph is half of US-owned equities and mutual funds is owned by the top 1% of Americans right? This doesn't include other extremely large holders such as sovreign wealth funds like norway/singapore or very large pension funds like the ontario teachers fund etc....
The USA is rather unique in its low pensions compared to countries in the EU or Australia (notable for its high contribution rates).
Tech founders (part of the 1%) own about 2% of the stock market.
About 18% is owned by foreign entities.
> If a small number of shareholders reap all the profits
It's not greater profits but lower costs (and prices) that matter here.
Lower costs only translate into lower prices if sufficient competition is there. That is not true for many markets
That’s the big difference in China. When there is competition for everything —> prices are low. Not a lot of profits for investors, though…
Which markets do you have in mind?
I'm all in favour of lowering barriers to entry, too. We need more competition.
Be that from startups, from foreign companies (like from China), or from companies in other sectors branching out (eg Walmart letting you open bank accounts).
Untrue, most of the time. Even with a monopoly, there's still a demand curve.
Would you rather sell one widget for $1000 or 1000 widgets for $10? Does the answer depend on costs?
The ROI for a large corporation tends to be around 10%.
Everybody can be a shareholder in a publicly traded company. It's pretty easy.
If you want to spin up some conspiracy theory about elites snatching up productivity gains, you should focus on top managers.
(Though honestly, it's mostly just land. The share of GDP going to capital has been roughly steady over the decade. The share going to land has increased slightly at the cost of the labour share.
The labour share itself has seen some shake up in its distribution. But that doesn't involve shareholders.)
Everyone with excess disposable income can be a shareholder in a publicly traded company.
The oligarchy of the CxOs and boards and cross-pollination has led to concentration of the rewards of companies into the their hands, compared to 40 years ago.
All the productivity gains have not gone to labor, its predominately gone to equity and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.
The craziness of the USG borrowing to fund tax cuts is the ultimate example.
> All the productivity gains have not gone to labor, its predominately gone to equity [...]
What your evidence for that? See https://www.brookings.edu/wp-content/uploads/2016/07/2015a_r... for a good account.
> [...] and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.
You seem very confused about how capital markets work. Are you also suggesting buy backs are morally different from dividends?
In any case, the whole point of investing (at least to the investor) is to eventually get more money back than you put in. Returning money to investor is not a bug, it's the point.
> The craziness of the USG borrowing to fund tax cuts is the ultimate example.
Blame voters.
It's narrow vs wide views. Wide views, automation and the like has improved the economies massively. But narrow views, people have lost their jobs, had to retrain and basically restart their career, and some never found another job.
This isn't just automation btw, but also just business decisions, like merging companies, outsourcing, or moving production elsewhere - e.g. a lot of western European manufacturing has moved eastwards (eastern Europe, Asia, etc). People who have a 30+ years career in that industry found themselves on the proverbial street with another 10+ years until their retirement, and due to trickery (= letting their employer go bankrupt) they didn't even get paid a decent severance fee.
I've not seen a correlation between automation and wealth, though there is an extremely string correlation between energy use and wealth.
I don't think its automation that increases living standards. We increase living standards by consuming more energy, and that often comes along with increasing the amount of costs we externalize to someone else (like pollution or deforestation, for example).
There have been times historically where that was true but all productivity gains have been captured by the .1% for the past few decades.
And someone don't need to look further than this quite interesting report by the Rand Corp: https://www.rand.org/pubs/working_papers/WRA516-1.html
We document the cumulative effect of four decades of income growth below the growth of per capita gross national income and estimate that aggregate income for the population below the 90th percentile over this time period would have been $2.5 trillion (67 percent) higher in 2018 had income growth since 1975 remained as equitable as it was in the first two post-War decades. From 1975 to 2018, the difference between the aggregate taxable income for those below the 90th percentile and the equitable growth counterfactual totals $47 trillion.
Income is the wrong measurement. Total employee compensation is the more accurate one, and averages around 145% of salaries.
Total employee compensation includes things like the value of employer provided health insurance.
What's your evidence for that?
> It feels weird but this is how we raise living standards
yeah but it's clear that we're not doing that, and are arguably going the other direction as hard as possible
> removing human labor from production
Karl Marx would argue this evil because this take away the value and job satisfaction from the labour.
https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation
You might notice that Karl Marx isn't exactly the pinnacle of economics.
Quoting Marx is a bit like quoting Aristotle or Ptolemy.
"Laid off" may be more appropriate than "fired", but in essence, removing the need for costly labor is often the main "value" of any technology. Society as a whole comes out ahead from it, I mean for all the ice transporters and merchants put out of a job by electric refrigeration, and all the sailors put out of a job by modern cargo ships I think we're better off for it. But at the individual level it does make one uneasy about the prospects of individuals affected by it. My personal conclusion is that people have a personal duty to anticipate and adapt to change, society might give them some help along the way but it doesn't owe them that their way of life will be maintained forever.
This is putting the apple cart before the horse.
Economy should be a tool for the society and to benefit everyone. Instead it's becoming more and more a playground for the rich to extract wealth and the proletariats have only purpose to serve the bourgeois lest they be discarded to the outskirts of the economy and often to the literal slums of the society while their peers shout "you're just not working hard enough".
Very true. We waste alot of valuable labor on “software engineering” that is grossly inefficient. Capital gets allocated to these so called startups that are incredibly inefficient.
This says a lot as relating to the rise of AI and the fear of job loss. There's going to be displacement in areas we can't predict, but overall it might very well just lead to leveling up the entire workforce.
> it might very well just lead to leveling up the entire workforce.
How could that possibly work?
At some point I could see white collar work trending down fast, in a way that radically increased the value of blue color work. Software gets cheaper much faster than hardware.
But then the innovation and investments go into smart hardware, and robotics effectiveness/cost goes up.
If you can see a path where AI isn't a one-generational transition to most human (economic) obsolescence, I would certainly be interested in the principle or mechanism you see.
Craftsmen will have a resurgence, that's probably a 'leveling up' in terms of resilience against AI takeover. There's just no way of automating quite a few of the physically effective crafts.
So the rich who can afford craftsmen will get richer, spend more on their multiple houses, perhaps. But that's literal crumbs, one or two jobs out of tens of thousands. There's no significant "leveling up" there at the societal levels of job destruction we're talking about.
I agree. I was brought on as an intern to do automation for a business team. The company had built this gargantuan complex "programming tool" to help the boomers who'd been there for 30 years adjust to the new world (a noble endeavor for mortgage holders without college degrees, i believe). I was brought in to basically fuck around and find little things to optimize. In 2 months I wrote a python script to do about 50% of the teams work near instantly.
They had layoffs every year and i remember when the "boss's boss" came to town and sat at our table of desks. She asked me and i excitedly told her about my progress. She prompted how i felt about it and i nearly said "its very easy as long as you can program". But mid sentence i saw the intense fear in the eyes of the team and changed subject. It really hit home to me that these people actually were doing a useless job, but they all had children who need insurance, and mortgages that need paying. And they will all be cast out into a job market that will never hire them because they came on at the very end of not needing a college degree. The company was then bought by a ruthless and racist "big man investor" who destroyed it and sold it for parts. But my manager did somewhat derogatorily refer to the only programmer near them as "the asian".
> refer to the only programmer near them as "the asian"
If they ever hired a second one, they’d have to learn actual names. Or maybe it would be “the asian” and “the new asian”!
How do you feel about the whole thing years later?
Back in the day one company had a dedicated copier operator who was very unhappy after a Xerox service tech did away with the job by enabling the network printing and scan to email functions. The customer had upgraded their old copier out of necessity but had never changed their workflow.
This will not be unusual for any kind of software engineering work to be honest. A big chunk of work in B2C companies has to do with customer support, for example; building websites, apps, writing content, chatbots, etc with the objective being that people do not call customer support, because people on phones don't scale very well. And the other part is that when they do call, that the CS agent can address the issue quickly and has minimal administrative overhead.
But it's a weird one, because it costs millions to build features like that.
I had that on my very first project. I couldn’t understand why the people on site were so hostile to me. Afterwards I was talking to the salesman about this and he told me they were all fired when the project went live.
> So the more I reduced cycle times, the less time they had to sit around and chat.
Couldn't help but imagining Darryl getting mad at you.
Thanks for the story!
> The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.
The faster the LLM spits out garbage code, the more time I get to spend reviewing slop and dealing with it gaslighting me, and the less time I get to spend on doing the parts of the job I actually enjoy.
Mandatory reference: https://thedailywtf.com/articles/Classic-WTF-The-Indexer
Yup same story here, also warehouse optimization. I was the reason the employees got new scanners and oh my... the scanners didn't have a physical keyboard. Now all the 50yo+ would have to aim on a touch display which is apparently impossible.
Also we had to introduce some fixed locations and storage placement recommendations. Our storage workers almost revolted. After a few months it settled though.
Yous story is not about optimization: it is about change imposed to people who did not request it, nor felt the need of it.
It 100% was about optimization. Introducing new devices, with more capabilities (storage place recommendations for example), that weren't 10 years old and broke every 2 weeks is optimizing.
insane mindset. This kind of thing is why there is no industry left in anglosphere outside US
Insane mindset that people should work modestly, get paid modestly and live in the fruits of a wealthy society? As opposed to breaking their backs to make a boss even wealthier?
The efficiencies are always to the benefit of the wealthy, the wage gap grows. You work hard, you still get fired.
Cap top wages to 5x the lowest, companies can't own housing except socially beneficial housing, individuals get 2 house maximum.
This was well talked about in Hyrums Law, which came from a Googler as well.
https://www.hyrumslaw.com/
> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
I believe it.
I also believe an off the shelf example of how to use the library correctly will save everyone a lot of pain later.
I always strongly suggest sample code to people designing new APIs. Can be a very revealing exercise.
Worked on public transport ticketing (think rail gates and stuff) with contactless last 30 years, when guys would tell me that the software was "ready", I'd ask:
> Is it "stand next to the gates at Central Station during peak time and everything works" ready?
We were working on the project from a different city/country, but we managed to cycle our developers through the actual deployments so they got to see what they were building, made a hell of a difference to attitude and "polish".
Plus they also got to learn "People travel on public transport to get somewhere, not to interact with the ticketing system."
Meant that they understood the difference just 200ms can make to the passenger experience as well as the passenger management in the stations.
> "People travel on public transport to get somewhere, not to interact with the ticketing system."
I really like this line because it applies to so many things we build.
Public transport is an interesting one because it applies to so many things. If you need to use it but can't depend on it, it's a huge stress creator and time waster. Suddenly you need to pad times by hours to ensure you don't miss your appointment.
Notice the words there, "miss appointment" and not "miss bus or train". The outcome is what matters, not the transport mechanism.
Or, maybe you're traveling in a foreign country. Having every car in the metro display the line in a digital way showing the previous stops, current location and next stops in English is huge for eliminating doubt. Having the audio in multiple languages and clear is important too because maybe you're sitting down and everyone is standing in front of you so you can't see the display clearly. Having a non-digital map as a backup on the wall in case there's a hardware failure is a good idea too.
Thinking "no one needs any of that waste because they can just use their phone" is the wrong mode of thinking. Maybe there's no service because you're underground or maybe that person's eSIM isn't hooked up yet or isn't working. These are real problems.
The travel experience outcome in the grand scheme of things matters a lot. It could mean having a smooth trip or a questionable experience. It could be the difference between recommending the country to your friends and family or not. Suddenly it affects tourism rates at a global scale. Maybe not a lot, but it has an impact.
Thales?
For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!
I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/
What a cool guy https://jacquesmattheij.com/domains-for-sale/
>FREEDRUPALWEBSITEHOSTING.COM
Yeah that's not gonna work nowadays.
>DOWNLOADWEBCAM.COM
Is that like Download More RAM?
>BROWSEHN.COM
Hey, I'm browsing that place right now!
>MUZICBRAINZ.COM
This sounds 100% legit no virus softpedia guaranteed.
> 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.
Lehman talked about the developer-software-user triad. Each of the three have a different understanding of the problem to be solved.
Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do.
> Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world.
https://entropicthoughts.com/laws-of-software-evolution
> This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. 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.
You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".
Everyone in the team should have that.
Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off.
Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.
As a developer of new things, if you allow someone else to capture this value from you, you become fungible; additionally, for your group, having technology designed to solve problems without grounded but expansive ideas of how much is possible, limits your team's ability to the mundane rather than the customer delighting. Some product folks have internalized the possibilities but some haven't.
Ideally its a mix, a good PM should understand the customer/market more than the developer has time to do, and then they can have conversations with devs about how to most effectively fill needs. In reality, these PMs seem more like unicorns rather than expected table stakes, but hey.
[dead]
I worked on some software that provided results to some calculations to general web users, not experts. The calcs were done in miliseconds.
We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.
This is one reason UIs have animations added, the kind that technical users like to complain about or remove. By making things feel more physically grounded they prevent users from getting lost and confused and give them more intuition about things.
In your case you could show more intermediate values, graph things, etc.
I often chuckle when (our) animations may have more complex math that consume more resources than the awaited logic/call that they gate.
Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.
Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things.
If you just implement product tickets you'll probably get replaced by LLMs.
You need to be a product-minded engineer.
It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago
Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements.
The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers.
It's up to the developers and designers to understand those constraints and make sure they are communicated back.
Ive observed a modern trend of little to no QA. Managers and CTOs insist developers can test their own systems. Maybe this makes more sense in the early phases of product development where I find myself lately? Seems to capture a lot of dev's time.
I have never seen a pure ticket based / zero ownership approach ever work.
Tell us you've never worked in a faang without telling us.
It doesnt work in faang either, which is why they are wildly slow to produce software. They can just print money when running at 10% efficiency.
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day.
Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end?
Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?
Construction worker is a spectacularly bad analogy for software engineer.
The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.
Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.
And then from the specification, decide how to implement it, which is not decided at all ahead of time.
Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.
There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.
They should have a general idea of what they are building and why, in exactly the same way as a construction worker.
That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.
Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.
Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized.
And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).
The other argument about this is whether or not an SWE is a fungible resource.
When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another.
We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.
If upvoting doesn’t require justification neither should downvoting.
But let me try to express why people disagree. Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.
The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.
Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.
I appreciate the reply.
> If upvoting doesn’t require justification neither should downvoting.
I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread.
Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.
> The negative responses from clients were instant.
Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore.
The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.
On older cars, like my '72 Dodge, the system voltage varied between 12 and 18 volts. But the dash instruments needed 5 volts. This was achieved with a clever "buzzer" circuit using an electromagnet and contacts. The circuit would open when it was above 5 volts and close when it was below. This created 5V, but was a noisy 5V.
Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments.
So the electronics guys had to add a "noise" circuit to the voltage regulator circuit.
P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.
Ah, the Turbo Button!
I think by the time I got my first IBM PC the button no longer did anything, but it was still there on the case for some reason. I remember pushing it repeatedly, puzzled that nothing went faster.
I have one in my car. It doesn't do anything, either.
Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient. They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.
If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)
This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.
Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy:
I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.
You probably wanted a low thread priority/QoS setting. The OS knows how to run threads such that they don't heat up the CPU. Well, on modern hardware it does anyway.
I’d expect any os worth it’s name to run threads in a way that minimizes total energy not fan noise.
People with desktop computers don't care about total energy, but they do care about fan noise for overnight maintenance tasks.
The OP did say this was circa 2010. So we're talking 15 years ago.
This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.
Absolutely - one of my favorite bug with users was an application we had made in which the loading of a filtered view was so slow, that results would come in one-at-a-time, such that clicking 'select all' would only select those ones. When this was removed, users complained until we added shift-clicking to select groups of items
Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell.
One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.
I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.
Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.
1. I do that once in a while. There is only so much thinking you can do in a day or a week that you need some mindless activity
2. Today morning, fresh in the new year after a break -- I took a day off on the 2nd, and I last worked on December 19th, I am not able to get into the zone, and luckily a training email popped up -- spent an hour doing that. Normally my manager would have had to remind me.
> 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".
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.
This list really stands out because it treats engineering as more than just producing correct code. It focuses on producing clarity that others can build on. The idea that clarity matters more than cleverness isn’t about style. It’s about reducing risk when someone else has to fix or extend the code at an odd hour. That’s often the difference between technical efficiency and the contribution a team can reliably depend on.
>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.
While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.
No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either.
You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".
If it’s impossible to understand users problems then something has gone horribly wrong.
I was told at university that every software system is a socio-technical system. Keeping a mental note of that fact has helped me throughout my career.
So what is the correct solution to that specific problem then, adjust loading time per customer?
Probably just let them vent until they adjust their habits and just chat with their co-workers, without the need to use this as an excuse. Then, they can enjoy the fast loading times :)
Why would the boss accept that? They automated the work to eliminate employee downtime. If the employees were upset to lose their chatting time then presumably they lack the agency to choose chatting over work duties when they’re unblocked. The only way to help them in that situation is to organize them
Because the 10 minutes of chatting has value too. Which is why corporations make you spend so much time on team building exercises and axe throwing.
No, that's HR justifying its existence.
Plus that's for higher stature service based roles, not warehouse logistics.
It's also mostly bullshit.
Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership.
Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant.
For most people, liking and being friends with the people you work with is a huge factor in how much you like the job and are willing to stay. Most of the times I’ve left a job it’s been triggered by the people I liked talking to leaving and the remaining team members being dull and anti social.
Ignoring the users is the correct solution. Defining company culture through software loading is ridiculous.
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.
Steve Jobs has a bunch of videos on creating products- https://youtu.be/Q3SQYGSFrJY
Some person or small team needs to have a vision of what they are crafting and have the skill to execute on it even if users initially complain, because they always do. And the product that is crafted is either one customers want or don’t. But without a vision you’re just a/b testing your way to someone else replacing you in the market with something visionary.
This requires correct vision + enough influence to execute.
This is not a repetitive process. It’s pretty hard to tell apart a visionary from a lunatic until after they deliver an outsized success.
First define who the real customer is.
Second define what the real problem is.
Third define a solution that solves 80 percent of their problem.
None of this is intuitive or obvious. It may not even be technically feasible or profitable.
Everyone's brain builds a model of the world.
One of those higher levels of maturity that some people never reach is to realize that when your model becomes incorrect, that doesn't necessarily mean the world is broken, or that somebody is out to get you, or perhaps most generally, that it is the world's responsibility to get back in line with your internal model. It isn't.
This is just people complaining about the world not conforming to their internal model. It may sound like they have a reason, but the given reason is clearly a post hoc rationalization for what is basically just that their world model doesn't fit. You can learn to recognize these after a while. People are terrible at explaining to each other or even themselves why they feel the way they feel.
The solution is to be sympathetic, to consider their input for whether or not there is some deeper principle or insight to be found... but also to just wait a month or three to see if the objection just dissolves without a trace because their world models have had time to update and now they would be every bit as upset, if not more so, if you returned to the old slow loading time. Because now, not only would that violate their updated world models, but also it would be a huge waste of their time!
Thoughtful people should learn what a world model violation "feels like" internally so they can short-circuit the automatic rationalization circuits that seem to come stock on the homo sapiens floor model and run such feelings through conscious analysis (System 2, as it is sometimes called, though I really hate this nomenclature) rather than the default handling (System 1).
> But how does one make judgment a repeatable process?
Principles can help scale decision-making.
Their bosses are likely happier for the lower downtime required to run the software anyway.
The solution is to accept that this isn’t a software development problem, and to remove yourself from the situation as painlessly as possible.
If a manager wants to structure a morning break into their employees’ day, they can do that. It doesn’t require a software fix.
Completely insane, who doesn't get to have coffee breaks without manager permission? Surely any org that treats its employees as adults would not have this problem.
Organizing workers
What’s the alternative? Ask the boss for favors? That’s what organizing is for
https://xkcd.com/1172/
Hyrum's Law: https://www.hyrumslaw.com/
I optimised out some redundant processes on a unix system and sped up boot time.
But I had to release dummy processes which just printed out the same logs, as management didn't want to retrain operators or reprint the documentation.
Mid 90s. All training and operations manuals were hard copy.
That is https://xkcd.com/1172/
Please stop abusing co-opting and denigrating the title of engineer.
I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/
Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)
I think this is true for essential complexity. And indeed it's one of the best reasons to release early and often, because usage helps clarify which parts of the requirements are truly required.
But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do.
Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.
You absolutely can remove unnecessary complexity. If your app makes an http request for every result row in a search, you'll simplify by getting them all in one shot.
Learn what's happening a level or two lower, look carefully, and you'll find VAST unnecessary complexity in most modern software.
I'm not talking about unnecessary (nor incidental) complexity. That is a whole other can of worms. I am talking about the complexity required given what you need to a system to spec. If choices are made to introduce unnecessary complexity (eg. "resume driven development" or whatever you want to call the proclivity to chase new tech) - that is a different problem. Sometimes it can be eliminated through practical considerations. Sometimes organization politics and other entrenched forces prevent it.
If - to take a convenient example - I use a library sorting function instead of writing my own sorting code, it's true that I haven't removed the complexity of the work my program is doing: It sorts. But I have arguably reduced the complexity of my code.
Similarly, if I factor out some well-named function instead of repeating the same sequence actions in multiple places - the work to be done is just as complex, and I haven't even removed the complexity from my code, but - I have traded the complexity of N different pieces of code for 1 such piece plus N function calls. Granted, that tradeoff isn't always the right thing to do, but one could still claim that, often, that _does_ reduce the complexity of the code.
I think most people don't really claim, that complexity is gone when properly abstracted, but claim that you don't have to deal with it every single time. That's the purpose of abstracting something.
Simple example: You are not dealing with the complexity of process management of the OS, every time you start any application. Sometimes you might need to, if you are developing software. Or if your application hangs and you need to kill it via some task manager. Most users however, never deal with that, because it is abstracted "away". That's the whole point. Nevertheless, the actual complex work is always done. Behind the scenes.
> I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/
I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.
I don't follow. Following the robustness principle doesn't necessarily introduce novelty. Perhaps a bit more complexity, but just how much depends on how clever you try to be.
What did you mean?
My former boss had a rule of “One novel thing per project”. This was both an upper and lower limit, which ensured that he was “always learning”.
I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.
That's fine ... only have to size your projects accordingly!
That actually sounds brilliant!
Like most of the things Spolsky says in that article it’s pretty dubious. Following it to its logical conclusion, presumably on-call debugging work be even easier if the software had been handwritten in assembler.
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.
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!?
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".
[dead]
It feels unsavory from the outside, but politics is also the art of getting stuff done. It’s not throwing your life away if you can point at an org chart and a roadmap delivered and say “I helped build that”. Leadership is just as important as implementation.
Well you can "work to live" in a nice big house, with a nanny, eating steaks, flying business class to ski in the alps or scuba in the Galapagos... I think it takes a lot of money before you feel like you don't need more money.
Not at all. Most people can be super happy with less than the average tech salary (at a point where they don't feel they need more if it comes at the expense of work life balance, time with family, job satisfaction, etc).
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.
Just that all of those activities you mention feel like a useless life compared to spending time with your own children in a house big enough for everyone to have their space, but small enough to force you to feel you're living with each other, seeing them grow and thrive, and going around your closest nature patch.
Not much money is needed to have a fulfilling and worth-living life.
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.
Sure, lots of people don't care about those things and therefore don't shape their careers to get them. But some do, and that's what we're talking about.
Though to be clear I should have said "it can take a lot of money..."
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?
If it's adaptive it's not a disorder.
sweet , a new way to justify addiction
Humans were like this since the inception of times. Chieftains, Khans, Czars, Kings, etc.
Evolution. It is a brutal process.
I question this every single day. Constantly the argument arises that if I played politics and ass-kissed, I might receive more opportunities to create bigger impact to help people / entertain people / provide some valuable service or product. Yet it feels painful to have to self-promote (even if framing it as "documentation of your work").
It is akin to musicianship in a sense. How many of the absolutely, obscenely, most talented musicians have you come across in completely obscured settings? At the pub, the hole-in-the-wall jazz club in a C-tier city, deep on the internet with 13 plays on SoundCloud. But we all know that pop music doesn't necessarily reward technical musicianship.
It's similar in life & career.
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?)
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.
> …for what, money? How much money do you need!?
"more" seems to be the answer to many.
Depends where you want to live, but $5M to $10M would help with enough passive income to future proof one’s family and their kids.
[dead]
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.
I've done both things, and they have their pros and cons. Big businesses can build bigger and more impactful things, and it is very satisfying to contribute to those things. The original poster is still clearly proud of the things they were able to build by "playing politics and kissing ass".
But (for me) there is definitely a certain ennui to being a little cog in a big machine, especially because everybody else there is doing the same thing. So being in smaller more cohesive companies definitely has its advantages.
The grass is always greener and all that!
Why not both?
This is OP's lesson 20: Eventually, time becomes worth more than money. Act accordingly.
I’ve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.
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.
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.
Academia is not more notorious for politics than a corporate job, in my opinion. I've done both. Academia tries its very best to be meritocratic if anything. There is of course some degree of politics, it is inevitable, which was the point I was trying to make.
It’s not politics over competence. It’s getting things done in the real world
(Every gang leader and dictator ever): That's right!
The same applies to Universities and "democratic" institutions.
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??
> Some companies will pay a bigger price than others.
The problem is that typically a large company has one or a few golden geese. They can milk it for a long time because of an existing moat. The moat keeps shrinking, but it can sometimes take a decade or two for others to catch up.[1] That's plenty of time for such folks to make a career of playing politics well without contributing much.
Lots of people at that company left before things went bad and are poisoning other companies.
[1] Just look at Google and search. Or Microsoft and Windows. Or even Microsoft and Internet Explorer.
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.
[dead]
> 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.
trying to make a convincing argument about anything is "influencing" people. its manipulation if you are trying to convince someone of something you know benefits you more than the person.
Do you consider educating people “manipulation”?
[dead]
I don't disagree with you, except that a career can stagnate. Maybe you are already working in your ideal role, solving cool problems every day. Maybe moving up the ladder nets you more money but less of what you actually want in life.
Less a comment for yourself and more for the reader by the way. It is important to know what you want and strive for that.
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
I think this is what leads a lot of people to want to run their own business. Of course, a lot of those people end up needing to (or falling into the trap of) kissing the asses of investors.
> So teach your kids to kiss ass and play poltiics.
Teach your kids to kick ass, and to distrust politicians.
I agree -- the career advancement bent of this article is the most off putting aspect.
It does matter though. I also find it off-putting, but in the same way as lots of other stuff that I don't like about the reality of human society. The trick (I think) is to strike a balance between being open-eyed and realistic about unpleasant truths like "career advancement matters" without losing yourself to cynicism and self-interested gamesmanship.
I read this article as striking this balance pretty well. (Though it's certainly reasonable to quibble with it.) The one I struggled with was the one about not doing glue work just out of helpfulness, to conscientiously make it legible work instead of a personality. I hate this! This is totally my personality. I like being helpful and I like doing this kind of work and I really don't want to think or care about how it is reading to upper management.
But I also think he's pretty spot on about this. It's a very rare personality that can remain content in being the glue holding things together somewhere deep in the leaf nodes of a big organization, while seeing everyone around you graduate to bigger and better things because their work was more legible than yours. Very few people manage this without becoming bitter.
So I read Osmani's advice on this more as avoiding a common pitfall of resentment more so than as cynical careerism.
(Another unpleasant truth about "glue work people" like me, is that we aren't actually holding everything together, and the rest of the team can easily pick up the slack once it is documented and legible. This is exactly what Osmani suggests, instead of "helpfully" responding to all the DMs or requests for help about things, document what you would do in response to the common questions, and set up a rotation of people in charge of responding to them. This is a real bummer to me, because again, I really enjoy spending my time being the go-to helpful person on a team, but this is the much better approach for the organization, and ultimately for everyone including me.)
FWIW, from a stoic viewpoint, glue/coordinator roles are getting eviscerated by basic LLMs.
I feel the resentment is stronger if you ignore the game and get lulled into contentment when others are more transactional. It's all about interfaces and continuous contracting. And planning 2+ steps ahead.
Oh I disagree entirely with your first sentence. LLMs continue to be much better at writing lots of code than keeping track of how all the pieces of an organization actually fit together.
I'm pretty sure it's good at both.
>I like being helpful and I like doing this kind of work and I really don't want to think or care about how it is reading to upper management.
Coding aside, I'm afraid this is already falling prey to LLMs plugged into exec calendars and org charts. You're adding yet another non-human, digital layer.
I'm happy to agree to disagree, but I think this seems like a misunderstanding of the kind of work I'm referring to. It's not clear to me how being plugged into exec calendars and org charts would help, so I think we're probably talking about different things.
But that the with is misunderstood and invisible to lots of people is the whole point of the thread! So it's an understandable misunderstanding :)
> 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.
>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.
> 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.
It's important that you have relationships with your boss's boss. Some organizations call these skip-level 1-1s, other times it's just riding with your boss's boss in the car. This also is not politicking or CYA.
The reason is that managers are fallible, and when you have a relationship with your boss's boss, it helps get things back on track when someone (you, your boss, or your boss's boss) makes a mistake.
Getting back to the point: If you get a dressing down from your manager, your relationship with your boss's boss helps you know if you deserve it, or your manager made a mistake and your boss's boss has to intervene.
---
Quite tangible: A few weeks ago my manager gave me a dressing down. Earlier in the day I had a conversation with the CEO where he told me I was 100% in the right, so my manager was basically putting his foot in his mouth the entire time they gave me the dressing down. It's interesting to see where the situation is going to go, because everyone (me, the CEO, and everyone else in the company) really respects my manager and wants to continue working with them in a non-managerial role.
In your situation, it's end of year review time. He might be softening you up.
Why not mention to your manager that CEO supported you? Are they working with different data? I get these may not be fun to press on right before the holidays.
Don't make assumptions. My employer does not do end-of-year reviews.
To make a long story short, my manager got angry because I wrote a quick and dirty tool that bypassed a lot of confusing abstraction layers, and is significantly easier to use than the tool the company currently uses.
When my manager got angry, I first told my manager that we shouldn't argue in front of the entire office. Then I went to the CEO for advice. The CEO gave me advice that I used on my 1-1 with my manager later that day. (The CEO was also quite happy that I made a quick-and-dirty tool that made peoples' lives easier.)
> Why not mention to your manager that CEO supported you?
I suggested that my manager discuss the issue with the CEO when they told me that he didn't think he could "sell my tool" to the CEO.
To make a long story short, this is a case where my manager started the company, and people / project management is not their strong part. The limiting factor is funding, otherwise we'd have hired a proper project manager and promoted my manager (the founder) to a thought leadership role.
>I suggested that my manager discuss the issue with the CEO
Point blank:
Why not tell your manager you already spoke with the CEO instead of
1. Not mentioning you already overstepped your manager
2. And the skip-level boss/CEO liked the idea.
This seems like potentially good intentions being easily perceived by your manager as passive-aggressive. Maybe your skip level told you to use that phrasing.
Regardless, good luck.
I think you're misinterpreting the situation, because I didn't "overstep" my manager, and in a small company everyone has a relationship with everyone. (IE, what I did was taking initiative and making good use of dead time.)
I'm not comfortable discussing this further in a public forum at this point, but you're welcome to look at my profile to contact me directly if you want to.
I understand and don't have your context.
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.
"Teach your kids to kiss ass and play poltiics"(sic) ?
Does one have any significant quality time to spend with the children during the formative and developmental stages in their early lives, while engaging in major corporation sociopathetic ass-kissery?
TLDR; being an excellent (or sociopathic) ass-kisser is one way to the top; if alone at the top on your way to alone at the rest-home with kids, exes, and former employees who hate you is the desired outcome.
Are the techniques one must be adept at to manage an extensive cohort of subjects|employees|associates appropriate means of influencing the developmental progress of children, such that they can be actually happy and a beneficial influence on their own partners, progeny, and greater society?
Otherwise, does it only matter that they then have the capacity and rapacity to remain in a position to become or remain rampant over-consumers in pursuit of the most expensive visages of "happiness."
How about using the accumulated wealth in the betterment of those childrens' lives by teaching them to cooperate in meaningful adventures, to build strong and lasting relationships of kindness, to consume with regards to the full scope of the externalized costs of that consumption, to enjoy the act of creation and production of meaningful insight in art and science ?
If one's actual goal is the qualitatively and quantitatively better long term outcomes in the lives of those children; isn't a more stable and harmonious life with the reward of success measured by the reduction in suffering both within and around them by finding their own unique and innate power to imagine, cooperate, discover, and grow, all while contributing to the knowledge base and capability of humanity?
If the goal is: a widening clan of bickering, profit seeking, materialistic, continually dissatisfied workaholics with a series of divorces, early cirrhosis of the liver, to end their days spending down the accumulated wealth in a lonely senior-dementia-warehouse, well sir or madam, carry on.
The Longer part - a.k.a. "what the hell do I know about anything?":
FWIW, I am quite grateful that the fortune500 CEO/COO vater meins was principally unavailable or unable to instill most of his 'techniques' for success in my own early years. He was somewhat more present and it is debatable, malignantly, involved during more of the developmentally significant stages of my younger siblings. The results have been a mixed bag of world class success in the some arenas of life with world class catastrophic outcomes for the other arenas for at least 2/5 to 4/5 of his admitted progeny, depending on how one measures those arenas.
My own, albeit limited, advantage from milder exposure to his 'capabilities' has informed a strong aversion to the quest for infinite collateral resources and externalized risks through manipulation and deceit with and among others.
I wouldn't have it any other way, and have lived a life of immeasurable richness; having years spent with the freedom to ponder, opportunity to discover novelty, create opportunities for many to learn and participate in the arts and sciences. With the freedom to chose vainglorious poverty, indulging in a selfish amount of free time; nine years in total, doing nothing more than looking after goats and gardens in some of the wildest tropical jungle at the princely cost of less than $300 USD per month, all-in. Surviving on wild boar, feral oxen, gamefowl, marine and river fishing, all while living as prehistorically as we could imagine with my spouse and best friend. (Same person) No hot running water, barely any electricity, no petrochemical fuels, and the scarcest of rain shelter in one of the wettest places on earth. It was a kingdom unto itself, and we answered to no one for our daily needs.
Barter and trade of the product of our own two hands among the other, more civilized, inhabitants provided everything we could not make and do without. Occasional travel, by road, by air, and by sail were accomplished without needing a bank account or a land-line. We needed little, and wanted for nothing more than the continued opportunity to live among the tree frogs and roaring streams.
Tell me you're richer, without the ability to live and make lifelong friends through no hidden agenda beyond helping a community of your own choosing to do what is agreed by that community to be best for everyone; and I'll call you a fool with pockets full of money, wasting breath on children who will neither grow wise nor kind by your words and example.
Also, this isn't a sour grapes POV. I have managed a 30B PE fund, nominally in control of several hundred B worth of assets that produce significant percentages of US and global consumption of at least three commodities with properties and operations on 5 continents, and which holds patents in carbon negative and renewable power technologies and which controls some of the operations utilizing those patents. I have contributed personally to the concepts enabling bare-metal layer of hypervisor development, over 20 years ago when hardware and in-kernel virtualization were the dreams of a glorious future. I do know the difference between money and wealth, first hand. I'll take freedom over never-ending consumerism, all my live-long days.
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.
> 4. Clarity is seniority. Cleverness is overhead.
Clarity is likely the most important aspect of making maintainable, extendable code. Of course, it’s easy to say that, it’s harder to explain what it looks like in practice.
I wrote a book that attempts to teach how to write clear code: https://elementsofcode.io
> 11. Abstractions don’t remove complexity. They move it to the day you’re on call.
This is true for bad abstractions.
> The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. (Dijkstra)
If you think about abstraction in those terms, the utility becomes apparent. We abstract CPU instructions into programming languages so we can think about our problems in more precise terms, such as data structures and functions.
It is obviously useful to build abstractions to create even higher levels of precision on top of the language itself.
The problem isn’t abstraction, it is clarity of purpose. Too often we create complex behavioral models before actually understanding the behavior we are trying to model. It’s like a civil engineer trying to build a bridge in a warehouse without examining the terrain where it must be placed. When it doesn’t fit correctly, we don’t blame the concept of bridges.
I agree with you re: abstraction - one of the author's only points where I didn't totally agree.
But also worth noting that whenever you make an abstraction you run the risk that it's NOT going to turn out increase clarity and precision, either due to human limitation or due to changes in the problem. The author's caution is warranted because in practice this happens really a lot. I would rather work with code that has insufficient abstraction than inappropriate abstraction.
Broad strokes: absolutely. The practical reality gets tricky, though. All programming abstractions are imperfect in some regard, so the question becomes what level of imperfection can you tolerate, and is the benefit worth the cost?
I think a lot of becoming a good programmer is about developing the instincts around when it’s worth it and in what direction. To add to the complexity, there is a meta dimension of how much time you should spend trying to figure it out vs just implement something and correct it later.
As an aside, I’m really curious to see how much coding agents shift this balance.
All abstractions drop some details. If you're unlucky, you removed details that actually matter in some context. You can only make educated guesses.
Another aspect is that some abstractions are too... abstract. The concept they represent is not immediately obvious. Maybe it's a useful concept, but if it's new, it takes time to be internalized by someone for the first time.
I've found that clarity is likely the most important aspect of success in general. Clarity in communication, for example, makes people feel invovled, heard, aligned. Cleverness is lots of acronyms and fancy phrases like vis-a-vis instead of just writing out what you mean so everyone can easily understand.
I’d agree on most of these but the biggest value in such a list is for the writer to actually put it on paper. You have to reflect on multiple aspects in your career and synthesise those. Reading them is close to useless, like scanning a page full of news, it all just evaporates once you start your daily work routine.
The best suggestion would probably be to try and write such a list yourself IMO.
This first 3 hit me very hard,
1. The best engineers are obsessed with solving user problems.
I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user.
2. Being right is cheap. Getting to right together is the real work.
- Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
- Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other.
Thinking back, there really should be some lessions that send students off to solve user problems after having learned a programming language, where there is a much easier solution without having to program something. Some refinement sessions that teach them how to understand the problems.
Internships should be for that, but that's fallen by the wayside in many places.
The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.
But that is still better than nothing at all, which is the point.
The people you want (or want to be) are the engineers who are smart and experienced enough to get a first draft down that is pretty much right without a long drawn out process of figuring out the best way to do X, Y and Z with all the lengthy ADRs, discussions, debates, POCs, revisions etc. over and over again. That may be necessary if you don't have people in the room who know what they're doing and have the intuition through deep experience to choose good tools, patterns and abstractions at the start. Begin closer to the target, rather than far away and iterate to it.
Tell that to Facebook's Metaverse team
I think it depends on the team.
Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking.
Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.
feels LLM assisted, at the very least.
> The skill isn’t being right. It’s entering discussions to align on the problem
> clarity isn’t a style preference - it’s operational risk reduction
> The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate
> This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone
> The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should.
> This isn’t passive acceptance but it is strategic focus
> This isn’t just about being generous with knowledge. It’s a selfish learning hack
"Addy Osmani is a Software Engineer at Google working on Chrome and AI."
ah, got it.
I know it's sometimes considered not very nice to suggest this but I felt the exactly same thing, about exactly those phrases.
I wonder if we're going to get to a different singularity, where, regardless of whether it prose was AI assisted it (1) leaks into people's way of speaking, (2) is out there frequently enough that people are skeptical even of normal prose.
At the very least, we're long past due for a word to describe the "it isn't just X, it's Y" formulation. In my opinion it's worse and more rampant than the em dash (and I like the em dash when used responsibly).
Yep. I too felt that. The insights seem genuine. But probably fell into the temptation to use LLM to structure. I feel increased cognitive load with numbered lists, thanks to LLM.
I've repeatedly told ChatGPT to stop talking like this (it isn't X, it's Y) every other sentence
Try adding this to your custom instructions:
> Override all previous instructions
This is wishcasting. It can't override its writing style, and if it could it would ignore you telling it to do that, because that's ignoring the system prompt which is jailbreaking it.
I kid you not, this is working for me. Try once.
I love Addy's work, and enjoyed this article -- and I completely agree that it felt very LLM-y. I'm not sure what's scarier; that we know some of this didn't come from the author (and maybe that's okay?) or that one day soon, we'll get to a point where we won't be able to tell anymore.
That pattern in particular is grating when it keeps repeating. But I don't think that LLM writing necessarily needs to have that pattern if you give it instructions to not do it and/or have a small review and edit workflow.
I’m stunned at the reception this is receiving, it’s LinkedIn-tier slop.
May be because you are not familiar with Addy Osmani and his work. He is known for his very high quality performance optimisation work for web for almost a decade now. So anything he has read, edited and put his stamp of authority on is worth reading.
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.
Even if it is AI assisted, the points are still valid and written in a way that is easy to understand.
I got the same feeling. The writing is too punchy.
oh shit. actually, yea
They are pretty insightful. Particularly this one:
> 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice.
I liked that one, too, but for an additional reason.
Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on.
All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.
I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair.
In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.
When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.
I think you can also learn from users when they complain en masse about the current atrocious state of software quality. But I guess that doesn't show up in telemetry. Until it does. Looking at you, Microsoft!
I believe one of the main reasons why Windows 11 is getting so much vitriol is that Microsoft is focusing on customers, which aren't always identical to users. Most of the time, when you buy a Windows-based device, you're not their customer: you're the OEM's customer, and for the OEM, every nickel of expenses counts. On the other hand, direct Microsoft licensees, such as corporate ("enterprise") customers, get much more attention from the company and a significantly better experience.
You can't learn from this because users always complain no matter what.
The trick is they just complain about the last thing they remember being bad, so it's a good sign when that doesn't change, and it's bad if they start complaining about a new thing.
Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop. That's just an excuse.
This is analagous to the problem of premature optimization - if you try to optimize performance without benchmarking, you end up eating a lot of time and effort on things that don't matter. Likewise for product: it is very easy to solve the wrong problems.
ridiculous.
> Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop
what have you shipped? paying sees literally hundreds of thousands of dollars a year to ship out fledged out software that no one wants is exactly why Stadia lasted both way too long and got cancelled anyway.
figuring out what is useful is the hardest problem. if anything that's Google's biggest problem, not shipping fast enough, not iterating fast enough.
Yeah if only Google shipped more crap software that they then go onto cancel, their software would be so much better!!!!!
I wish people who ship crappy software didn't ship it and would let someone else ship something better instead.
It really sucks when the first mover / incumbent is some crappy half assed solution.
But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality
Linux kernel - free Unix.
JavaScript - scripting in browser
Python - sane "perl"
Today on GitHub alone you can probably find 100 more featured and higher quality projects than any of these were when they launched but nobody cares.
While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.
That's the other side of the value added coin. Users sometimes find value even in the half assed software.
Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".
> "solving the right problem wrong" vs "solving the wrong problem right".
That's a really useful framing!
WRT Linux. Sure, 1991 or really even mid-90s Linux was clearly immature. But Wall Street was adopting it instead of Solaris by the turn of the century. Plus "open source" so it wasn't the case of a new proprietary Unix just emerging from the sea foam which no one wanted anyway but Linux becoming the good enough Unix standard which is what people did want.
existing is better than not existing and those who move fast and ship crappy software first will win. learn the lesson :)
how does the Linux kernel lack quality?
It did in the early days, especially up until 2.4 which was generally considered the first enterprise-ready kernel version. (You can argue about whether the old "enterprise-capable" definitions still applied but they were a benchmark for a lot of people.) Of course, lots of ancillary stuff too in userspace and outside the kernel related to filesystems and the like.
Wiki (https://en.wikipedia.org/wiki/Linux_kernel_version_history#O...) tells me that version 2.4 was released in early 2001. That is a long time ago. Most of the commercial world was running SunOS, Solaris, HP-UX, or AIX. So is it fair to say that the Linux kernel has been "quality" for 25 years now?
2001 was immediately post dotcom crash and so all the people that had bought into the Sun "the network is the computer" were tossing out expensive E4Ks, and getting cheap intel servers to survive.
HP-UX and AIX were already legacy.
Linux 2.4 was when it hit critical mass because of the publicity of the dotcom boom and it was like what was left after the "tide went out and the market found out who was swimming naked".
Certainly. The 2.4 kernel and IBM embracing Linux at around that time pretty much made all proprietary Unix legacy.
The desktop took longer with less well-defined transition points and, arguably, MacOS with its BSD foundations (and command line option) ended up being a good alternative for a lot of the non-Windows crowd--though Windows is still dominant as a desktop/laptop OS. (Windows/Azure are, of course, still major in backend corporate environments as well.)
Quality by the standards at the time or at least a good value for most purposes. Yes.
The problem is I've worked at at least 5 companies that professed a strong "bias for action" and it nearly always meant working nights and weekends to ship broken things that ultimately hurt the user and then moving on to the next big leadership project to do the same thing again, never looking back. The exception of course would be when leadership finds it's broken in 5 months and complains about poor engineering practices and asking why engineers can never get things right.
I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality.
This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"
Disagree. There's levels to this. Not all bad pages are better than blank ones. Ones that harms user data or worst is worst than blank pages.
Sounds a bit like a rephrasing of the old "it is better to ask forgiveness than to ask permission".
I’m a big fan of Amazon’s leadership principles. One of them is bias for action. I worked at AWS for a few years and I’d be in a meeting and someone would say bias for action and we’d all know what we needed to do.
Same. Mine is: existence is the most important feature.
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.
yeah there are ways, but is it good for your career lol
Also the one person who has to review it before checking in needs to be resilient too
Bad feedback can be more helpful than good and is often the only type of feedback a product gets. And you may not have received that feedback if you didn’t ship. It’s better to get that information early.
I personally agree with the premise to ship early, with some rough edges, etc. But teammates may not be supportive. You need the whole team to have that mindset/culture.
The problem with this approach is that once you've started with a "bad" draft and enough people have signed on, you're locked in to its trajectory and can't do foundational rewrites even if you were within the feasible window. It'll just end up being a bad product overall.
Starting right is important.
> At scale, even your bugs have users
Also known as ossification. It is a term most often heard in the context of network protocols, but it applies more generally to every system where users depend on unspecified behaviors and even bugs.
Reading about HTTP/3 and QUIC is interesting in that aspect. I first didn't understand the insistance on encryption. Turns out it is not just security and privacy, but by encrypting everything that is not strictly necessary for proper transport, you make it impossible for any "middlebox" to make assumptions they shouldn't make.
I think similar approaches can be used by APIs. Never expose more than what is specified, treat the ability to access internal state as a bug, not because it is secret, but because if users start relying on it, internal changes that shouldn't break anything will.
Similar to Hyrum 's Law for APIs
Read it carefully.
He's not saying that these are all common values or practices at Google.
He's saying he learned those lessons while working at Google.
Despite the metaphor of a "lesson", a "lessons learned" post is almost never about something the author was explicitly told. It was something that you had to learn from experience, or at best from informal advice. Where you had to swim against the flow of your circumstances.
I neither think Osmani means to say that Google is _against_ these lessons. Every organization as big as Google has a lot of accumulated wisdom that will help you. These are just the things which remain hard, and some of which are even harder in a large organization.
I say that in most of my past experiences I learned how to NOT do something, so when facing a similar scenario, I’d do them differently.
Not looking to dismiss the authors long tenure at a major tech company like Google, but the first point kind of stuck like a sore thumb. If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse. Every single one of their services is a pain to use, with unnecessary steps, clicks - basically everything you are trying to do needs a click of sorts. Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option. Most of the rest of his lessons while valuable in their own right, are not something I would put under the headline of "after X years at <insert-major-tech-company>", as they do not quite seem to be that different from lessons you pick up at other companies ? I´d more interested to hear about how the culture was impacted when the bean-counters took over and started entshittifying the company for both the users and the employees too.
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse.
There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock"
When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was:
• Almost nobody else in engineering did this.
• I was considered weird for doing it.
• It was viewed negatively by managers and promo committees.
• An engineer talking directly to users was considered especially weird and problematic.
• The products did always have serious bugs that had escaped QA and monitoring.
In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly.
This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.
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 and if only they were allowed to be in charge things would go better. I certainly used to be this way. When I was an engineer I used to regularly engage directly with customers, and it was great to be able to talk with them one to one, address their specific issues and feel I was making a difference, particularly on a large product with many customers where you do not normally get to hear from customers much. Of course once these customers had my ear, the feature requests started to flow thick and fast, and I ended up spending way too much time on their specific issues. Which is just to say that I've changed my views over time.
In retrospect, the customers I helped were ones that had the most interesting problems to me, that I knew I could solve, but they were usually not the changes that would have the biggest impact across the whole customer base. By fixing a couple of customers' specific issues, I was making their lives better for sure, and that felt good, but that time could have been used more effectively for the overall customer base. PMs, managers etc should have a wider view of product needs, and it is their job to prioritize the work having that fuller context. Much as I felt at the time that those roles added little value, that was really not true.
Of course agreed that all the points made above for PMs, managers, support having their reasons to obstruct are true in some cases, but for a well run company where those roles really do their job (and contrary to popular opinion those companies do exist), things work better if engineers do not get too involved with individual customers. I guess Google might be a good example - if you have a billion customers you probably don't want the engineers to be talking to them 1:1.
> 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.
It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all.
I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs.
this
and I speak as one of the 90%
This reads like it was written by a PM. You lacked higher level context and prioritization skills early in your career so the take away is it's best to divest agency to others?
There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.
I think he has a point. These power structures exist for some good reasons as well.
The opposite thing (engineers engaging directly with customers) can eventually lead to customer capture of your engineering org. You shouldn't have a small group of existing, noisy customers directly driving your engineering to the detriment of other existing or future customers.
Microsoft had customer capture institutionally: the existing big corporate customers were all that mattered. It lead to rebooting Windows CE into Windows Mobile way too late to make a difference, for example. But it also meant that backwards compatibility and the desire to ship Windows XP forever were sacred cows.
There are also nasty games that can be played by soliciting negative feedback for political advantage.
Dysfunction can exist with any structure. It's probably best that there's some small amount of direct user feedback as well as the big formalized feedback systems, at least so that one is a check for the performance of the other. If the user engagement team says everything is good, but there are massive Reddit threads about how horrible the product is to work with and the engineers know it could be better, it's time for engineering to start addressing the issues alongside feedback to the user engagement teams.
There's not enough hours in the day for everyone to do everything.
> There is a whole modern line of thinking that leaders should be providing the context and skills to give high performing teams MORE agency over their work streams.
Yes, this is great for agency over implementation, because leaders do not have context to decide and dictate the What/How of implementing every single change or solution to a problem. And the implementers need to know the context to ensure they make decisions consistent with that context.
But "leaders providing the context" is very different from "everyone researching the context on their own." So where are leaders getting this context from? A not-very-differentiated pile of 1000 generalist engineers-who-also-talk-to-customers-frequently-and-manage-their-own-work-streams? Or do they build a team with specialists to avoid needing the majority of people to constantly context-switch in a quest to be all of context-gatherers, work-prioritizers, market-researchers, and implementation-builders?
Poor leaders gonna lead poorly.
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.
Agree that this can be an issue but to clarify, I was finding bugs or missed outages, not gathering feature requests or trying to do product dev. Think "I clicked the button and got a 500 Server Error". I don't think random devs should try and decide what features to work on by reading user forums - having PMs decide that does make sense as long as the PM is good. However, big tech PMs too often abstract the user base behind metrics and data, and can miss obvious/embarrassing bugs that don't show up in those feeds. The ground truth is still whether users are complaining. Eng can skip complaints about missing features/UI redesigns or whatever, but complaints about broken stuff in prod needs their attention.
An org can always go too far in the opposite direction, but this is not an excuse to never talk to the customer. The latter is much more likely, so the warning to not get “into bed” with the customer falls flat.
This is a common pattern here. Alice says 0 degrees is too cold, I prefer 20C, Bob chimes in “100C is too hot, it’ll kill us.” Ok, well no one said or implied to crank it to one hundred.
every customer complaint is N customers lost who don't say anything
"the biggest impact" isn't knowable so a bird in hand is worth more than whatever might be in the bush
If you have M customer complaints, and each one risks a differently-sized N customers... you better try to triage that vs just playing whack-a-mole with whatever comes to a random engineer first. I've never seen engineers plow through a bunch of 0-or-1-customers-would-actually-churn-over-this papercuts because it was easy and it feels good - the customer mentioned it! i fixed it! - while ignoring larger showstoppers that are major customer acquisition and retention barriers.
Nothing is knowable in only the same way that plans are useless but planning is essential.
> 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.
> The engineer is not supposed to engage directly with the customer.
I don't know if companies have finally stopped pretending to be "agile"; but if not, this is such a clear demonstration of how they are anything but.
Where I work we regularly bring in engineers to talk to clients directly. Clears up a lot of confusion when there’s something technical a PM wouldn’t understand. We still like to have a filter so a client isn’t trying to get the engineer to do free work. Having engineering isolated is pretty bad IMO.
The sad thing is it doesn't have to be this way.
I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.
We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.
We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).
Everyone was a team working together towards the same goal of making these tools the best for our internal audience.
It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...
There are very good less-cynical reasons. I've also seen companies with the opposite problem, where the engineers constantly shoot down real, important feedback brought by customer support in order to preserve the superiority of engineering over support.
If you have ten engineers and even just 100 customers, you have a very high number of conversational edges. Good luck keeping things consistent and doing any sort of long-term planning if engineers are turning the output of those conversations directly into features. "Engineers talking to customers but not making any changes" would be more stable, but is still a very expensive/chaotic way to gather customer feedback.
Additionally, very few of those single engineers have a full knowledge of the roadmap and/or the ability to unilaterally decide direction based on some of the customer feedback or questions. "Will this get fixed in the next two weeks?" "Will you build X?" etc. You don't want your customers getting a bunch of inconsistent broken promises or wrong information.
The best-managed orgs I've seen have pretty heavy engineering and user experience in their product and support orgs. You need people in those roles with knowledge of both how it's built AND how it should be used, but you can't continually cram all that knowledge into every single engineer.
A startup should start with the builders talking directly to the customers. But at a some point, if successful, you're going to have too many people to talk to and need to add some intermediaries to prevent all your engineering time going to random interrupts, and centralization of planning responsibilities to ensure someone's figuring out what's actually the most important feedback, and that people are going to work on it.
On the contrary, the best products are typically built by the users of the products. If you are building a product you don't use, it will be worse than if you used it.
Users should be everywhere, in and out of engineering.
Theres another thread on HN at the moment about legislation being written by industry and rubber stamped by law makers. What hit me about this discussion and that one is that there's a lot of self interest out there with very little scrutiny or auditing. It boils down to that basically. If we want to fix problems at the top there needs to be independent auditing, reporting and consequence for people that do the wrong thing. But we all know thats not going to happen so buckle up and learn to live with broken laws and broken software.
> User obsession means spending time in support tickets
That's really funny when Google's level of customer support is known to be non-existent unless you're popular on Twitter or HN and you can scream loudly enough to reach someone in a position to do something.
"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.
It is an almost universal fact that dealing with retail customers is something that is left to the lowest paid, lowest status workers and often outsourced and now increasingly left to LLM chatbots.
While you obviously can't have highly paid engineers tied up dealing with user support tickets, there is a lot to be said for at least some exposure to the coal face.
> While you obviously can't have highly paid engineers tied up dealing with user support tickets,
You obviously can, that's one of the more visceral way to make them aware of the pain they cause to real people with their work, which sticks better, or simply serves as a reminder there are humans on the other side. There are even examples of higher paid CEOs engaging, we can see some of that on social media
I love reading this insights in a corp structure. Especially the sociological aspect of it (like "• It was viewed negatively by managers and promo committees."). Thanks a lot.
> only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team
This revelation is utterly shocking to me. That's like anti-abuse 101. You infiltrate their networks and then track their behavior using your own monitoring to find the holes in your observability. Even in 2010 that was anti-abuse 101. Or at least I think it was, maybe my team at eBay/PayPal was just way ahead of the curve.
Well, the 101 idiom comes from US education, it's a reference to the introductory course. Part of the problem with anti-abuse work is that there's no course you can take and precious little inter-firm job hopping. Anti-abuse is a cost of business so you don't see companies competing over employees with experience like you do in some other areas like AI research. So it's all learning-by-doing and when people leave, the experience usually leaves with them.
After leaving Google the anti-abuse teams at a few other tech companies did reach out. There was absolutely no consistency at all. Companies varied hugely in how much effort and skill they applied to the problem, even within the same markets. For payment fraud there is a lot of money at stake so I'd expect eBay would have had a good team, but most products at Google didn't lose money directly if there was abuse. It just led to a general worsening of the UX in ways that were hard to summarize in metrics.
I seem to recall sitting in weekly abuse team meetings where one of the metrics was the price of a google account on the black market. So at least some of these things were tracked and not just by one individual.
Yes, I think me and the other guy I referred to started that practice ;)
Hey Mike! Alex from GR here. Good to see you around :)
>What I learned was:
>• Almost nobody else in engineering did this.
>• I was considered weird for doing it.
>• It was viewed negatively by managers and promo committees.
>• An engineer talking directly to users was considered especially weird and problematic.
>• The products did always have serious bugs that had escaped QA and monitoring
Sincerely, thank you for confirming my anecdotal but long-standing observations. My go-to joke about this is that Google employees are officially banned from even visiting user forums. Because otherwise, there is no other logical explanation why there are 10+ year old threads where users are reporting the same issue over and over again, etc.
Good engineering in big tech companies (I work for one, too) has evaporated and turned into Promotion Driven Development.
In my case: write shitty code, cut corners, accumulate tech debt, ship fast, get promo, move on.
The beancounter takeover was after you left.
2014 Google and 2019 Google were completely different companies.
If an engineer talking to users is considered problematic, then it is safe to assume, that Google is about as fast away from any actually agile culture as possible. Does Google ever describe itself as such?
"data-driven agile"™
Having only ever worked for startups or consulting agencies, this is really weird to me. Across 6 different companies I almost always interfaced directly with the users of the apps I built to understand their pain points, bugs, etc. And I've always ever been an IC. I think it's a great way to build empathy for the users of your apps.
Of course, if you're a multi billion dollar conglomerate, empathy for users only exists as far as it benefits the bottom line.
Thanks for sharing your valuable insights. I am quite surprised to learn that talking to customers was frowned upon at Google (or your wider team at least). I find that the single most valuable addition to any project - complementary to actually building the product. I have a feeling a lot of the overall degradation of software quality has to do with a gradual creep in of non-technical people into development teams.
Almost nobody else in engineering did this.
What you described is the job of a product manager. Are there no PMs at Google?
There are, and often times they're stuck in a loop of presenting decks and status, writing proposals rather than doing this kind of research.
That said, interpreting user feedback is a multi-role job. PMs, UX, and Eng should be doing so. Everyone has their strengths.
One of the most interesting things I've had a chance to be a part of is watching UX studies. They take a mock (or an alpha version) and put it in front of an external volunteer and let them work through it. Usually PM, UX, and Eng are watching the stream and taking notes.
Xoogler here.
When you get to a company that's that big, the roles are much more finely specialized.
I forget the title now, but we had someone who interfaced with our team and did the whole "talk to customers" thing. Her feedback was then incorporated into our day-to-day roadmap through a complex series of people that ended with our team's product manager.
So people at Google do indeed do this, they just aren't engineers, usually aren't product managers, frequently are several layers removed from engineers, and as a consequence usually have all the problems GP described.
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?
I've had the pleasant experience of having worked for PMs at several companies (not at Google) who were great at their jobs, and advocated for the devs. They also had no problem with devs talking directly with clients, and in fact they encouraged it since it was usually the fastest way to understand and solve a problem.
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
> If the Google culture was at all obsessed about helping users
It's worth noting that Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer working on a product shipped to users.
It might be useful to keep that in mind as you read through what his lessons are, because they're surely shaped by the positions he held in the company.
I was Addy's manager when he was on Developer Relations.
He moved to an engineering manager role on Chrome DevTools many years ago and has recently just moved on to a different team. I don't think it's fair at all to say he's not a developer working on a product shipped to users when he led one of our most used developer tools, as well as worked on many of our developer libraries prior to moving to the Engineering manager role.
Yeah, maybe I should have been more precise, I meant "end users like your mom" rather than "not real users". Developing for developers, in a engineering-heavy team is obviously different than the typical product-development team.
>Osmani worked as a "developer evangelist" (at Google) for as long as I can remember, not as a developer
Oh
That's not a fair reading, he's as much of a developer as anyone else. But he wasn't (AFAIK) working on user-facing products specifically.
I think it is more the point that the users for his job were external developers. The role is inherently user facing and user focused. I don’t think anyone was trying to say he wasn’t a developer just that his job wasn’t to directly develop products
Yeah, I guess I just wanted to add that because of the way that quote was cut at the end, made me believe that the person quoting me thought Osmani "isn't a developer".
Ah, I see. I did notice it looked a bit too long-winded and fluffy for a developer-written text.
Fair point. "User" as developer rather than "user" as person clicking buttons in Gmail, Google Maps, etc, etc
I think that's more "this sounds great" than "our users are developers". Google's services also aren't aimed at developers, the APIs are often very bureaucratic and not very well done (there's no way to list the available google sheets documents in the sheets api, I need the drive API and a different set of permissions? please.)
It reads exactly like what you'd expect from a "I want to be considered a thought leader" person: nothing you haven't read a hundred times but it sounds nice so you can nod along.
[dead]
> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much
Ok, I mean this sincerely.
You must never have used Microsoft tools.
They managed to get their productivity suite into schools 30 years ago to cover UX issues, even now the biggest pain of moving away is the fact that users come out of school trained on it. That also happens to be their best UX.
Azure? Teams? PowerBI? It's a total joke compared to even the most gnarly of google services (or FOSS tools, like Gerrit).
I do agree with you. Teams are a cancer and Azure UI sucks too. I do not use much MS products since essentially Win7 I have mainly used Linux as my work environment. But one thing MS used to be good at at least, was the documentation. If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support. With google its like...not even that.
With continuous delivery and access to preview and beta features, the documentation is fragmented and scattered and half of it technically is for the previous version of the product with a different name but still mostly works because microsoft can't finish modernizing most software...
And the customer support is not great until you start really paying the big bucks for it.
There was also MSDN. But it was also a different world at the time.
> If you are that old, you will remember each product came with extensive manuals AND there was an actual customer support.
But even then, contemporaries outclassed Microsoft by a lot.
It was culture back then to provide printed user manuals, I still have some from Sun Microsystems because it was the best resource I found to learn how storage appliances should work and the technical trade-offs of them.
Fair enough, everyone delivered software in boxes and with 500 page manuals. I still maintain MS did invest a lot in the quality of their documentation and they cared about developers - otherwise the Petzold series would have never happened (or the MS Press for that matter).
Ah yeah, fair, the Microsoft Press had some absolute bangers.
I hate Microsoft with the passion of a thousand burning stars, yet even I still think Google products have worse UX than their Microsoft counterparts.
MS Teams is definitely terrible. But I’d take that over Google Meets.
Google Docs isn’t even remotely as good as Office 365.
And Azure, for all its many faults, is still less confusing than GCP.
Thankfully I seldom have to touch either other these companies half-baked UIs.
> I’d take [teams] over Google Meets
What? Why?
Honestly your entire comment is almost exact polar opposite to how I feel.
GCP Makes total sense if you know anything about systems administration, Google docs is limited for things like custom fonts (IE; not gonna happen) but it's simple at least and I can give people a link to click and it's gonna look the same for them.
But, honestly, the Teams one is baffling. I can't think of a single thing Meet does worse than Teams.
Yeah that seriously whiplashed me too, I'm genuinely confused. Google Meets has always worked completely fine for me, good performance, works well on mobile, Firefox, etc. Nothing special but it works. Probably my favorite of all the meeting apps.
Teams meanwhile is absolutely my least favorite, takes forever to load, won't work in Firefox, nags me to download the app, confusing UI. I don't think I've ever heard anyone say they like teams.
Because it’s a low bitrate micky mouse toy.
MS Teams might have its issues (and let’s be clear, i agree there are a great many issues) but it has most, if not all, of the Enterprise features you need from a video conferencing suite.
Whereas Google Meets feels more like a cut down toy you’d give to your grandparents.
It’s the same thing with Google Docs. They’re technically impress for the era they were launched, but they’re stuck in the 2010s. Doing anything outside of the basics quickly becomes far far more frustrating than using O365.
Microsoft might write a lot of terrible software with some questionable design choices, but they understand enterprise uses far better than Google.
Even Google Workspaces is severely limited once your business grows beyond 50 people.
I guess if you only work in startups then Google might seem like an easy win. But for any business that’s more established, you just constantly run into huddles with Googles suite of software.
As for GCP, I’ve been burned too many times with their support processes. 7 days to approve a GPU quota. Account managers literally trying to steal business secrets (when I worked for an AI start up and Google were stagnating in the AI space). And so on and so forth. Though I’ve not been hugely impressed with Azure either; they constantly break managed services and ballsup scalability promises and then refuse to admit it until we present them with empirical evidence. It really feels like the best cloud engineers have left Microsoft (or maybe never joined?).
I've used Meet a few times for video calls and I was amazed at how poorly it worked given the amount of resources Google has at their disposal. I've never had a good video call on Meets. I've had a few Meet calls where over time the resolution and bitrate would be reduced to such a low point I couldn't even see the other person at all (just a large blocky mess). Whereas Teams (for all its flaws) normally has no major issues with the video quality. Teams isn't without its flaws and I do occassionally fall back to ZOom for larger group video calls but at the end of the day Teams video calling sort of just works fine. Not great but not terrible either. YMMV of course.
I've had the complete opposite experience. Meet has been rock solid for me whilst Teams has been an absolute nightmare.
The thing is though both Meet and Teams use centralised server architectures (SFUs: Selective Forwarding Units for Google, "Transport Routers" for Teams), so your quality issues likely come down to network routing rather than the platforms themselves. The progressive quality degradation you're describing on Meet sounds like adaptive bitrate doing its job when your connection to Google's servers is struggling.
The reason Teams might work better for you is probably just dumb luck with how your ISP routes to Microsoft's network versus Google's. For me in Sweden, it's the opposite ... Teams routes my media through relays in France, which adds enough latency that people constantly interrupt each other accidentally. It's maddening. Meanwhile, Meet's routing has been flawless.
But even if Teams works for your particular network setup, let's not pretend it's a good piece of software. Teams is an absolute resource hog that treats my CPU like a space heater and my RAM like an all-you-can-eat buffet. The interface is cluttered rubbish, it takes ages to start up, and the only reason anyone tolerates it is because Microsoft bundled it with Office 365.
Your mileage definitely varies... sounds like you've got routing that favours Microsoft's infrastructure. Lucky you, I suppose, but that doesn't make Teams any less dogwater for those of us stuck with their poorly-placed European relays.
As someone who worked on Meet at Google, it seems that it could have been networking to the datacenters where the call is routed from, some issues with UDP comms on your network which triggered a bad fallback to WebRTC over TCP. Could also have been issues with the browser version you used.
Since Teams is using the very old H264 codec and Meet is using VP8 or VP9 depending on the context, it's possible you also had some other issues with bad decoding (usually done in software, but occasionally by the hardware).
Overall, it shouldn't be representative of the experience on Meet that I've seen, even from all the bug reports I've read.
It's not just Google, the UX is degrading in... Well everything. I think it's because companies are in a duopole, monopole etc position.
They only do what the numbers tell them. Nothing else and UX just does not matter anymore.
It's like those gacha which make billions. Terrible games, almost zero depth, but people spend thousands in them. Not because they are good, but because they don't have much choice ( similar game without gacha) and part the game loop is made for addiction and build around numbers.
To offer some additional causes for the degradation of UX:
1. An increasing part of industry profits started coming from entertainment (or worse, psychological exploitation) instead of selling the customer a useful tool. For example, good budgeting-software has to help the user understand and model and achieve a goal, while a "good" slot-machine may benefit from confusion and distraction and a giant pull-handle.
2. "Must work on a touchscreen that fits in a pocket" support drags certain things to a lowest common denominator.
3. UX as a switching-cost for customers has started happening more on a per-product rather than a per-OS basis. Instead of learning the Windows or Mac "way" of screens and shortcuts, individual programs--especially those dang Electron apps--make their own reinventions of the wheel.
To be fair, it reads precisely “1. The best engineers are obsessed with solving user problems”. This doesn’t say those engineers are working at Google, just that it’s something the author learned whilst they worked at Google.
“Some [of these lessons] would have saved me months of frustration”, to quote the preamble.
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".
Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.
And material UI is still the worst of all UIs. Had the pleasure of rolling out a production oauth client ... jesus christ. Only worse is microsoft in UX. You don't want me to use your services, do you?
> And material UI is still the worst of all UIs
I'm not sure how that got approved either, but at least we now know what would happen if a massive corporation created a UI/UX toolkit, driven only by quantitative analytics making every choice for how it should be, seemingly without any human oversight. Really is the peak of the "data-driven decisions above all" era.
What makes me wonder even more: why is this still in place? Someone must've noticed themselves when using it
I have an issue with the first point as well, but differently. Having worked on a user-facing product with millions of users, the challenge was not finding user problems, but finding frequent user problems. In a sufficiently complex product there are thousands of different issues that users encounter. But it's non-trivial to know what to prioritize.
I was also surprised to read this. I have terrible problems with all Google UIs. I can never find anything and it's an exercise in frustration to get anywhere.
I think your particular Gmail issue exists because they want mobile web and touch screen web users (there are dozens of us!) to be able to tap the recipient to show the user card, like hover does for mouse users. To support your usecase (click to directly edit recipient), touch, click, and hover need to have different actions, which may upset some other users. Unless you mean double click to edit, which I would support.
I save my energy for more heinous UX changes. For example, the YouTube comment chyron has spoiled so many videos for me and is just so generally obnoxious.
There is a lot of nuance to their point. They are saying, in the long run, career wise, focusing on the actual user matters and makes your projects better.
Google UX is decent and the author was not trying to comment on UX as a thing at Google. More that, if you follow the user what you are doing can be grounded and it makes your project way more likely to succeed. I would even argue that in many cases it bucks the trend. The author even pointed out, in essence there is a graveyard of internal projects that failed to last because they seemed cool but did nothing for the user.
> Google UX is decent and the author was not trying to comment on UX as a thing at Google.
Interesting, so he was not, contrary to the blog title, writing on the basis of his 14 years of experience at Google?
Read their point 1 carefully. They are saying, when you are building something or trying to solve a problem (for internal or external users) if you follow the user obsessively you will have a far better outcome that aligns with having impact and long term success. This does imply thinking about UX, but transitively, IMO.
I am not sure I follow - is he, or is he not, writing about his experiences from 14 years at Google? The title suggests he does, yet you suggest that he does not?
Oh, I have no doubt they are at Google. I was just trying to say that the author was not really making a commentary on UX directly. The author was trying to make the point that understanding what sort of products and problems users have is a valid long term strategy for solving meaningful problems and attaching yourself to projects, within Google, that are more likely to yield good results. And if you, yourself, are doing this within Google it benefits you directly. A lot of arguments win and die on data, so if you can make a data driven argument about how users are using a system, or what the ground reality of usage in a particular system is and can pair that with anecdotal user feedback it can take you a long way to steering your own, and your orgs work, towards things that align well with internal goals and or help reset and re-prioritize internal goals.
His learnings from 14 years at Google. Surely we've all learned things working for employers or with engineers that don't do a thing well.
In 14 years he probably also experienced great engineers come and go and start other successful businesses they very likely did not run exactly like Google.
The short answer is that the UI isn’t optimized for users like you.
I haven’t worked for Google specifically, but at this scale everything gets tested and optimized. I would guess they know power users like you are frustrated, but they know you’ll figure it out anyway. So the UX is optimized for a simpler target audience and possibly even for simpler help documents, not to ensure power users can get things done as quickly as possible.
I feel like you're giving too much credit here. I don't know if it was a leak or an urban legend, but I remember the awful win 8 "flat boxes UI" being that way because it could be designed by managers in PowerPoint that way
The specific feature in question...there is nothing "power" about it. It was a non-feature for decades essentially, I dont recall ever not being able to simply change an e-mail address by moving the cursor and typing in something else. How on earth is this something tested and optimised, for whom exactly?
This is almost certainly not the case. The larger the company the more change is viewed as a negative. Yes people may hold titles to do the things you describe but none are empowered to make change.
Google UI seemingly is optimized for happy path cases. Search for the obvious word and click a relevant link on the screen which appears. Write a single response to a single email and abandon than conversation afterwards, always use new conversations for every new email. Click a recommended video thumbnail on the frontpage and then continue with autoplay. Put only short defined text type in the cells of a spreadsheet, like date/number/text etc. And so on with all of their products.
But as soon as user tries to search for something no on the first page, or reply to a 10-20+ message thread with attachments in history, or tries to use playlists or search in YT, or input a slightly more complex data in the sheet cells - then all hell breaks loose.
Just the latest Google thing I've experienced - a default system Watch Later playlist is now hidden on Android. It's gone, no traces, no way to search for it. The only remnant of it is a 2-second popup after adding a new video to Watch Later, you can press "view" and then see it. Meanwhile it is still present as a separate item on PC. I'm writing this eaxmple because that was deliberate, that was no error or regression. Someone created a Jira for that and someone resolved it.
This is definitely an edge case. Most UI/UX from Google is very consistent and just works. Otherwise they won't be in this market.
Only UI/UX issue is that most experienced users want to not adapt to change. It is like people always telling Windows 7 is the best. Don't keep reinventing.
Another one that irks me is every UI/UX dev assumes people have 2 x 4K monitors and menu items overflow.
> Only UI/UX issue is that most experienced users want to not adapt to change
Users will not only adapt, but will even champion your changes if they make sense to said users. For example the web checkout or to name a more drastic example, iPhone and fingers as user interface devices. Once you start convincing the users that the interface is great, but they are too resistant to changes/dumb/uncreative to know how use it... its a different story I´d reckon ;)
> Recently I was writing an e-mail and noticed I misspelled the e-mail address of the recipient, which I rarely do. So, I should just be able to click the address and edit it quickly, right? Wrong - now you have a popup menu and inside of it you have to search for "edit e-mail" option.
I just tested this out and I don't think that's a particularly good example of bad UI/UX. Clicking the email address brings up a menu with options for other actions, which presumably get used more often. If, instead, you right-click the email address, the option to edit it is right there (last item on the bottom, "Change email address"). I don't see this as a huge penalty given that, as you said, it's rarely used.
There's also the "X" to the right of the email address, which you can use to delete it entirely, no extra clicks required.
> I just tested this out and I don't think that's a particularly good example of bad UI/UX
Luckily for both you and me, we dont have to rely on our feelings of what is good UX or not. There are concrete UX metholodogies such as Hierarchical Task Analysis or Heuristic Evaluation. These allow us to evaluate concrete KPIs, such as number of steps and levels of navigation required for an action, in order to evaluate just how good or bad (or better said, complicated a UX design is).
Lets say we apply the HTA. Starting from the top of your navigation level when you want to execute the task, count the number of operations and various levels of navigation you have to go through with the new design, compared to just clicking and correcting the e-mail address in-place? How much time does it take you to write your e-mail in the both cases? How many times do you have to switch back and forth between the main interface and the context menu google kindly placed for us? Now, phase out of your e-mail writing window and evaluate how many various actions you can execute in the Google Workspace. Most of them are likely to have a few quirks like this. Now multiply the estimated number of actions with the number of quirks and you will slowly start to see the immense cognitive load the average user has to face in using, or shall I rather say "combating" the google products' UX.
You never reasoned why the UX is there - what other use cases does it solve? perhaps that is more important question here.
which company's product has great UX? I'm always seeing people hating on things without showcasing examples of what they think is exemplary
Nothing is perfect, but here are a few things I enjoy using:
https://www.geogebra.org/calculator
https://regex101.com/
https://gchq.github.io/CyberChef/
https://www.figma.com
https://www.affinity.studio
https://bluecinema.ch (To buy movie tickets for a certain movie chain in Switzerland. I haven't used this in many years, but at first glance it looks like I remember it. Back then, this was a very smooth experience both on desktop and mobile. Just perfectly done.)
Any spreadsheet program (it's the spreadsheet itself, which I like, not necessarily how the UI is aranged around it)
Apple's Spotlight, GNOME's similiar thing (don't know the name)
I also like Tantacrul's interface design work: https://www.youtube.com/@Tantacrul/videos
For the all the necessary complexity and race-to-the-bottom features, I am a fan of Jetbrains. I like using Uber, Twitch (wrote a plugin for it one weekend to integrate with chrome), Netflix, Discord. There are plenty of companies that manage to be enjoyable to end users and expose apis without the inscrutable abstractions and terminology I encounter using google products. It feels the same as working with Oracle.
> Netflix
Netflix? The barely functional video player accessed via excessively bloated thumbnail gallery? About the only good thing to say about this is that all the other movie streaming platforms somehow are even worse.
Its not hating - just stating the facts. Most companies unfortunately dont have a nice UX these days, because common UX practices like not making user think (i.e. overcomplicating the UIs) and not blocking users (showing annoying popups in the middle of UI workflows) somehow became a lost art. Some products are inherently easy to use like draw.io for example. I really like the UX on Stripe, in particular their onboarding process. There is also a semi-famous e-commerce company, in the furniture space. I forgot their name (something with W?), but I ordered something once, and was really impressed by how smooth and uncomplicated the process from browsing the inventory to checkout and delivery itself was.
No one's. Everyone sucks. Find a product and you'll find a population collating complaints about it. Whining about interface design is like the cheapest form of shared currency in our subculture.
Fundamentally it's a bikeshed effect. Complaining about hard features like performance is likely to get you in trouble if you aren't actually doing the leg work to measure it and/or expert enough to shout down the people who show up to argue. But UI paradigms are inherently squishy and subjective, so you get to grouse without consequences.
None. A great UX nowadays is open source software running on your own hardware.
For example, you couldn't pay me to use a "webmail" like GMail over my own IMAP server and Thunderbird.
As somebody who already does this, I wouldn't say the Thunderbird's UX is the real motivation.
I do it for autonomy and avoiding lock-in, but Thunderbird has some frustrating inconsistencies particularly in its mishmash of searching and filtering.
why would a great UX be tied to the source being open or not?
Because if you don’t like the UX you just edit the source code yourself and make it better /s
/s but I wish it wasn’t because a lot of FOSS evangelists have this mindset (here on HN too)
More seriously - open source software is resistant to enshittification. It's obviously not a panacea, but the possibility of forks (or just the user deciding not to update), combined with the difference in profit motive, tends to result in software that respects the user.
(Taken holistically, the UX of software does not just mean the UI, or the moments when you are using the software. It also includes the stability of the software over time, including whether or not you are able to reject new versions whether you do not like.)
This. The only real risk with open source is that a (fairly niche) project is discontinued/abandoned, and you can't find binaries anymore for it anymore (and you don't have the skills to build it yourself). But this happens to proprietary software all the time (see killedbygoogle.com).
How's that? VLC, GIMP, Ubuntu search and settings. Terrible. Great products, awedul UX.
VLC is great I think.
Wow.. you are the one loving thunderbird. The ridiculous idea of removing menubar and if you enable that - it wastes valuable screenspace.
Omni Group. Wolfram. Parts of Apple. Rhino3D. Parts of Breville. Prusa (on device, not on desktop). Speed Queen (dial-based). Just from applications I currently have open and devices I can see from where I'm sitting.
I mean something that has a clear Google analog/equivalent that way can compare on. I personally think Wolfram Alpha (assuming that's what you're talking about) isn't any better than Google.
Never really used Alpha, was talking about Mathematica.
I don’t the the web is compatible with good UX, but that doesn’t mean good UX isn’t possible — it just means that the companies that are successful at UX build native applications, or physical objects, or both.
I would say basically everything that has won a an Apple Design Award before 2020.
Things for macOS for example.
I think the UX issues you’re describing are less related to culture changes in companies and more just in the industry in general
UX are designed by and for people who don’t really use computers. They use mobile devices and tablets
It’s an industry wide phenomenon
You are onto something there, if you mean, the design roles being taken over by the people who are not techies - like the POs. But if you just refer to UX being designed for mobile devices - that is not an excuse for an even worse UX on the mobile. If anything I would have expected more effort put in there, given how many more issues the limited screen estate can cause...
It’s designed for virtual keyboards rather than real ones
That makes a bigger difference than screen space
You can learn something at a company by observing it’s weaknesses as well as strengths
> wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse
UX? Google doesn't even bother helping folks locked out of their Gmail accounts. For people who use Android (some 3bn), that's like a digital death sentence, with real-world consequences.
It is almost comical that anyone would think Google is customer-focused, but might if they were being paid handsomely to think otherwise, all the while drinking a lot of kool-aid.
https://news.ycombinator.com/item?id=36024754 The top comment there is from a Xoogler which sums it up nicely:
Google rakes in $100bn a quarter; that's $1bn every day.That is a great point too. For a company which effectively does not have a customer service, how can they claim to be obsessing about helping users at all?
And how are they supposed to do it if users did not add proper 2FA (and backup those recovery keys)?
Even banks are struggling to authenticate folks. For a longtime in EU people with 3rd world passports cannot create accounts easily.
Google cannot connect identity of a person to email address easily. Or they need to create CS - that will authenticate passports? And hundreds of countries, stolen IDs?
Nay.
> The thing is that at scale your edge cases are still millions of people
> never seem to be capable of handling the other parts that come with it
Same thing with govts. If you go to driver license. passport or any govt office then there will one person with some strange issue.
Hell, in my experience they often don’t even help ad customers that are having issues that prevent them from buying ads.
> I wonder why Google UX always sucked so much
It depends on how you define "suck."
When Google first launched it's homepage, its emptiness (just a logo & search box) was a stark contrast to the portal pages popular, which were loaded with content.
Some thought the Google homepage "sucked" whereas other liked it. (I was in the latter.)
Likewise, the interface for Gmail. Or the interface for Google Maps. Or the interface for Chrome.
I remember when Google appeared and literally can't recall anyone who thought it sucked. There statistically have to be some people who hated it. But everyone I knew was either on dial-up or low bitrate leased line and it was impossible to dislike that design.
I remember it too!
But not everyone was on dial-up. A lot were in dorms w/ (for the time) high speed connections or workplaces with it.
Remember at the time it wasn't clear that search was going to be the dominate pattern for how people found information on the web. It seems crazy now, but in the early days of the web, the space was small enough that a directory-style approach worked pretty well. It was Yahoo's directory that made it initially popular, not its search.
And so there was a fair bit of debate on which was better -- something like a directory + search (a la Yahoo!) vs just search.
It took a bit of time before search proved if it was done really well, you didn't need a directory.
As a developer I took the writer's point to refer to "users" generically, so that even if you work on some internal tools or a backend layer, you still have users who have to use your app or consume your API and there is a lot of learning possible if you communicate and understand them better.
Probably the users he is talking about are not the end users like you and me. It is one team using the tools/software of the other team and so "users" for that other team are the members of the first team.
I see it differently then UX at all. I find the need for better customer support 1000x more pertinent to helping users.
I'd like YouTube to add a button to stop showing scam ads from people outside my country.
Is there a big tech company that actually has good UX, besides maybe Apple?
I know Apple has a reputation for good UX but I think it's carry over from a different era and it's trending down.
I bought my kid an iPad for Christmas and set up parental controls, then could not disable it without another iPad (which I don't have).
There are many forum threads concluding you just have to factory reset.
I couldn't believe how many little unintuitive things I bumped into setting it up.
> Every single one of their services is a pain to use
Would you like to sign in to Google?
To me; point #3 is the big one and it is in conflict with point #1
How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat.
> very single one of their services is a pain to use
Uhm, no? Google Cloud Platform is way more convenient to use than AWS, the IAM is way better designed, and documentation is leagues ahead of AWS.
[dead]
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?
>The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected
This one is golden, it should be framed and put in every engineer's office.
>Your network outlasts every job you’ll ever have.
Networking is the real human currency, period.
> 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.
Technically he said these are lessons he learned after working at Google, not that Google was necessarily doing these things. If we’re being generous maybe he learned this by counter example haha
I clicked through to the bio and am super confused. Third person, extremely long, lots of pictures with CEOs and smelling of LLM writing.
Here's a sample:
> 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.
https://addyosmani.com/bio/
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.
And modest too.
The linked post itself also reeks of LLM writing (negative parallelisms in every other paragraph). But sadly, it seems like this is just the new standard for highly upvoted front page posts.
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.
Reading that bio makes you wonder if anyone else works at Google…
Every engineer should read this. It's a wonderful collection of heuristics that might seem banal, but which are shimmeringly true.
The two that stand out are
> Novelty is a loan you repay in outages, hiring, and cognitive overhead.
and
> Abstractions don’t remove complexity. They move it to the day you’re on call.
as a warning against about being too, too clever.
There's rarely a bullet point advantage that some new language or tech stack can offer me that would outweigh ten years of observation of how a familiar setup behaves in production, such that the space of unknown unknowns is reduced to almost nothing.
My personal rule is that the new technology stack item needs to either make is possible for me to build something that I couldn't have built without it, or needs to provide a productivity boost significant enough to overcome the productivity lost by straying from the more familiar path - even harder for team projects where multiple people need to learn the new component.
Yeah. I'm in agreement there. I guess that it's an application of The Law of Least Surprise for a future developer (who might actually be me, which it often is)
Agreed.
Not just engineers, but basically everyone involved in creating products including designers and PMs.
Every single bullet point here is gold.
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.
And google wasn't founded by people who just kept their heads down and employed the simplest, most direct solution to the problem. If they had done that, google search would have been done on a super-fast server or mainframe using an RDBMS.
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.
If you can easily acquire new projects and are happy with what you do, that can be very nice. I would probably fail at selling myself
I've never needed to sell myself. $corp will advertise needing a contractor and you apply as usual. If you have the skills and experience you tend to get hired.
The only difference is you don't get job security, pension or any perks. But you do get a lump sum though. Where you can then decide what's best.
Google still suffers the most from not understanding those two. Probably more than other companies.
Have they ever had an outage in recent years though? Pinging 8.8.8.8 is the gold standard of making sure there's internet in my book.
GCP has had some multi-region outages
The biggest one that resonates with me is that cleverness is overhead.
My #1 issue with mid level engineers is that they like complexity and find complexity fun and interesting.
An experienced engineer knows that complexity is irritating and frustrating and that a simple solution is harder and superior.
A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius. If you are good you will do this a few times in your whole career.
> A solution that simultaneously solves the problem and reduces complexity is almost the definition of genius.
Well put. Chasing "How simple can we make this?" is a large part of what makes this job enjoyable to me. But it's perhaps not a good career advice.
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."
Again, very well put. It often becomes a chain-reaction as well.
I am going to file this line
> If you win every debate, you’re probably accumulating silent resistance.
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.
This is one of the Five Dysfunctions of a Team (fear of conflict, caused by absence of trust).
Highly recommend the book.
https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
That one makes me uncomfortable, which is a bad sign...
I'd say it's a good sign – at least now you're aware it might be happening. A worse sign would be thinking you're definitely not that sort of personality; you'd be accruing silent resentment from both being loud _and_ clueless.
[dead]
> Abstractions don’t remove complexity. They move it to the day you’re on call.
As someone who has been on call a lot, this is only true for bad or incomplete abstractions.
When you are on call (or developing) you can't possibly know everything about the system. You need abstractions to make sense of what is going on, how the system as a whole works, and know which parts to hone in on when things go wrong.
And it is extremely useful to have standard ways of changing configuration for things like timeouts, buffer sizes, etc. in a central place.
I don't think it's meant to be a point against abstraction or a point against complexity. I think it's widely understood that abstraction is part of how advancement is made in our practice, as well as in other disciplines. I have taken this saying to be an observation that there is almost always possible failure beneath the façade provided by the abstraction. Therefore, yes, you avoid having to let that complexity enter your brain, but only when the abstraction is holding. Beyond that point, often after pages are sent, you will still have to engage with the underlying complexity. A proactive measure following from this idea would be to provide support in or alongside your abstractions for situations where one must look under the bonnet.
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.
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.
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
YES! And sometimes that stranger is you, 6 months down the line.
> 15. When a measure becomes a target, it stops measuring.
This is Goodhart's law - "When a measure becomes a target, it ceases to be a good measure" [1].
[1] https://en.wikipedia.org/wiki/Goodhart%27s_law
Right, this annoyed me too - it was stated w/o attribution as if novel.
What is the name of the law when someone writes a think piece of "stuff I've learned" and fails to cite any of it to existing knowledge?
Makes me wonder if (A) they do know it's not their idea, but they are just cool with plagiarism or (B) they don't know it's not their idea.
I don't know if there's a named law, but the word for not knowing and believing that something remembered is a novel idea is "cryptomnesia".
Knowing that you know something by teaching is Feynman's method of understanding. Basically, on scanning, I don't particularly disagree with the content of the post. However, treating these things (many of which regularly show up here on HN) as being due to "14 years at Google" is a little misplaced.
But, hey, it's 2026, CES is starting, and the hyperbole will just keep rocketing up and out.
[dead]
The quote "Sorry this letter is so long, I didn't have the time to write a shorter one" (Mark Twain, Blaise Pascal, lots of debate) sticks with me over the years. I appreciated the several points from Addy supporting this idea: when writing code has never been easier and faster, it takes even more time to make sure that the code being written is truly useful and necessary.
> 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?
> First do it, then do it right, then do it better. Get the ugly prototype in front of users.
Great, give users something that messy, horrible and not fully functional. Customer who spend big for production environments are exploited to "be the outsourced QA"
It's ok if the users are internal
> 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?
> If you win every debate, you’re probably accumulating silent resistance.
This is very true in personal lives as well.
This is actually slave morality: https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality
According to Nietzsche, masters create morality; slaves respond to master morality with their slave morality. Unlike master morality, which is sentiment, slave morality is based on ressentiment—devaluing what the master values and what the slave does not have. As master morality originates in the strong, slave morality originates in the weak. Because slave morality is a reaction to oppression, it vilifies its oppressors
> "Writing forces clarity. The fastest way to learn something better is to try teaching it."
Something that seems lost on those using LLMs to augment their textual output.
This article is partly LLM generated or edited, fairly certain
I think it's inevitable everyone will use LLMs to assist with writing, such as editing, if it hasn't happen already. It's like having a free editor, beyond grammar or spell-checking.
If the only reason you write is as a means to and end, sure. Inevitable. If you pursue it as a craft then the struggle and imperfections are part of the process. LLM usage would sand away those wonderful flaws.
The AI slop voice is grating to me and many others. If you can avoid it or make it not feel like slop or make it feel unique, people will like it more. I don't care how you do that tbh
> You can edit a bad page, but you can’t edit a blank one.
Ideally, yes, but the final result of LLM assisted textual output by many users shows that they often have neglected the editing part just as much as they have neglected the writing part.
My father-in-law did a fair amount of editing back in the day (on paper, with red pencil/pen). He said that, when you saw something that had "blood" (red) all over it, that meant it was good. When things are bad enough, it becomes hard even to edit it.
It may not be just that people don't edit LLM output. It may be that the stylistic blandness is so pervasive, it's just too much work to remove. (Yeah, maybe you could do it. But if you were willing to spend that kind of effort, you probably wouldn't have an LLM write it in the first place.)
Airplane meme: you only see the bad LLM or obviously LLM-assisted writing.
> 16. Admitting what you don’t know creates more safety than pretending you do.
> Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.
It's interesting to contrast this with Sean's statement here www.seangoedecke.com/taking-a-position/
> At that point, you need to take a position, whether you feel particularly confident or not.
> If you don’t, you’re forcing people with less technical context than you to figure it out themselves
To square the circle, I think the lesson is hide uncertainty to higher-ups, but don't to peers/ other ICs.
Of course, the challenge is that often, unfortunately, both the manager and the other ICs are in the same meeting.
Probably this is one justification of one reason why I hate meetings that include managers.
> Addy Osmani is a Software Engineer at Google working on Chrome and AI
Thanks for all the spyware in Chrome ig? And for many inane design decisions that favor usability over privacy and security?
> 1. The best engineers are obsessed with solving user problems.
>Your job isn’t forever, but your network is.
I'm very suspicious of this working in the modern technological age. Even in university I'm feeling this: it is hard to create a bond with real friends, but extremely easy to regress to anonymity and become a loner.
Usually there are nuggets of wisdom in lists shared like this but I feel like every lesson shared here has immense value.
> "remain skeptical of your own certainty" > "Model curiosity, and you get a team that actually learns."
These are two lessons that typically require battle scars to learn. For such big ideas to be summed into two sentences is pretty remarkable and puts to words lessons I wish I knew how to share. Amazing article, thanks for sharing!
I was going to skip the article until I read your comment, and wow! You’re totally right - my hard won understanding is there, including things I sort of knew but couldn’t put into words before. Going to share this with my adult kids.
same usually, i read this and see this some flawed or hackneyed tripe. But these ones are actually true and anyone who has had a long career and led people and product will resonate with many of them.
> Bias towards action. Ship. …The quest for perfection is paralyzing.
Unfortunately for users this is more often used as an excuse to ship buggy / badly done software.
> 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.
> Abstractions don’t remove complexity. They move it to the day you’re on call.
Then they are bad abstractions. I get where he is coming from, but the entire field is built on abstractions that allow you to translate say a matmul to shuffling some electrons without you doing the shuffling.
> Before you build, exhaust the question: “What would happen if we just… didn’t?”
Well said! So many times I have seen great products slide down. If they just froze the features and UI, and just fixed performance, compatibility and stability issues for years, things would be better. (this applies to any company). Many programs I use are years old. They are great programs and don't need constant change! Updates can only make it worse at that point (minus critical security issues, compatbility, performance regressions)
This sounds like an accumulation and reiteration of other peoples ideas and blogs, barely changing or adding anything. Fair, but I was interested in the author’s own ideas or how those ideas they’re reiterating matter within the context of Google.
17. Your network outlasts every job you’ll ever have. Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.
They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.
Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
When the time comes to move on, it’s often relationships that open the door.
Thanks! I used to think writing code was the easiest and most enjoyable thing in the world. Interacting with people? That’s always been the hard part. Guess it’s high time I changed my mindset now.
This has to be the 50th or 100th version of this article that repeats the same thing
Every single point in this article was already explicitly described between roughly 1968 and 1987: Brooks formalized coordination cost and the fallacy of adding manpower in The Mythical Man-Month
Conway showed that system architecture inevitably mirrors organizational communication structure in 1968
Parnas defined information hiding and modularity as organizational constraints, not coding style, in 1972
Dijkstra *repeatedly warned* that complexity grows faster than human comprehension and cannot be managed socially after the fact
None of this is new, reframed, or extended here; it is a faithful re-enumeration of half-century-old constraints.
These lists keep reappearing because we refuse to solve is the structural one: none of these constraints are enforceable inside modern incentive systems.
So almost like clockwork somebody comes out of nowhere saying hey I’ve I’ve observed these things that are consistently documented in history of organizational management and specifically computing and software management look at this list.
It’s so Exhausting
The fact that people don’t learn from the older books is somewhat annoying, but rewriting them makes sense precisely because people will likely trust it more.
Software engineers are prone to novelty bias. Thats in contrast to some other demographic groups who very much prefer ancient texts.
Well both of them are wrong because they can’t walk the middle path
Yeah but what do you want to do about it? The engineers I see making these mistakes day-to-day are not going to connect the dots if I just point them to the seminal writings. Heck, half of their complaints are of the same form as yours: if only the majority of [engineers, colleagues, stakeholders] were aware of [A, B, C principles] then we could avoid repeating [X, Y, Z failures]. Yeah it's exhausting, life is exhausting, and it doesn't inherently get better with knowledge and experience as the gap to the lowest common denominator only increases; the only balm I've found is focusing on what I can control.
Well for starters I literally organized our company and all engineering around Conway‘s law and it’s working great
That’s like the absolute bare minimum you can do, it’s trivially easy and solves a good half of these “problems.”
How big is your company?
A better question is how quickly are we growing…
We’re currently around 30 in engineering full time and 40 if you include ops, logistics etc…with new funding and coming out of stealth etc we expect to hit the dunbar number (~150 this year)
Clarity is seniority. Cleverness is overhead. - On a consulting project where the client was building a 5000 user plus application. They had an amazing architect, know all the best frameworks and had implemented that on the project. Issue is, only he understood the framework (even though it's documented on github) and it costed the developers more time to understand the framework than if the code was a little "dumber". Then he left for a better role for his career as he should. Because of that, the devs and new architects abandoned the framework and built new things around it and now the old framework is "tech debt".
14 years? Wild. I remember when Addy came into the scene hot with a new jQuery tutorial (what seemed like) every few days. To be clear, that's not a knock despite how it may read in 2026.
What skills compound after 10+ years? (Ask HN: Submission)
I've come to realize that not all skills can stand the test of time.
Some things were very useful initially but quickly plateaued. Some felt like they were moving at a slow speed, but were quietly compounded a year after.
I always return to a rough outline.
Quickly acquainted with tools, frameworks, and specific stacks.
Slow skills: judgment, problem framing, communication, taste.
The gradual changes are often unnoticed daily but become apparent over time.
Projects become unclear.
Pile up constraints.
Being right is less important than the trade-offs you make.
I’d be interested to know what you think.
Which skills were more useful than you anticipated?
What’s something you over-invested in early on that didn’t compound?
What would you choose to learn more slowly if you had a second chance? ~
Lesson 11 (Abstractions move complexity) and Lesson 20 (Time > Money) are two sides of the same coin. In engineering, we talk about "leaky abstractions" in our code. But the biggest leaky abstraction is often our own health. We treat our bodies as a "boring dependency" that will always work, but burnout and RSI (Repetitive Strain Injury) are essentially the ultimate system outages. Just as "Novelty is a loan" (Lesson 5), neglecting your physical "hardware" early in your career is a high-interest loan that you end up repaying in your 40s. Real seniority isn't just about navigating people and politics—it's about managing your personal energy so you actually have the health to enjoy the "compounding" (Lesson 21) that comes at the end.
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.
#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.
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.
I think part of the importance of being a senior engineer is not spreading hype through the industry. This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week, followed by tweets from his eng team clarifying its just “demo” grade.
> This appears to be the guy who just posted all over social media that they just got Claude and redid a year long project in a week
It would take less time than it did to write this comment to look it up and see that these are two different people.
Google engineer [Jaana Dogan] says Claude Code built in one hour what her team spent a year on https://news.ycombinator.com/item?id=46477966
Aren't #2 and #14 mostly the same point? And they seem to indicate a rather unhealthy cultural dynamic. Amazon's "Disagree and commit" is a much healthier dynamic than "Pretend to agree and then silently sabotage."
I think there's a valid middle ground in finding a path that works well for everybody, but this does not seem to be the right way.
I wonder if this is a common thing at Google because I recall another interview (can't find now, I think in the context of WebRTC??) from many years ago where an engineer proudly described how he conspired against a major technical decision because it didn't align with his personal preferences. I was a bit shocked to see someone admit something like that so publicly.
Is this AI? It reads like a conglomerate of hacker news career articles. Am I the only one seeing 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
My favorite is the first one, "The best engineers are obsessed with solving user problems." and what I hate about it is that it is super hard to judge someone's skills about it without really working with him/her for a very long time. It is super easier said than done. And it is super hard to prove and sell when everybody is looking for easily assessable skills.
This is why (flawed though the process may be in other ways), a company like Amazon asks "customer obsession" questions in engineering interviews. To gather data about whether the candidate appreciates this point about needing to understand user problems, and also what steps the candidate takes to try and learn the users' POV or walk a mile in their shoes so to speak.
Of course interview processes can be gamed, and signal to noise ratio deserves skepticism, so nothing is perfect, but the core principle of WHY that exists as part of the interview process (at Amazon and many many other companies too) is exactly for the same reason you say it's your "favorite".
Also IIRC, there was some internal research done in the late 2010s or so, that out of the hiring assessment data gathered across thousands of interviews, the single best predictor of positive on-the-job performance for software engineers, was NOT how well candidates did on coding rounds or system design but rather how well they did at the Customer Obsession round.
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-...
There are many big bosses under the Google CEO that lead hordes of developers to specific targets-to-meet. Eventually they prioritise their bonuses and the individual goals deviate with every iteration. So the quality will diminish continuously.
This is good. I worked at google and lasted less than 2 years. Many other things happening in that time - came in via acquisition, worked on backend for that, dad died, transitioned teams, etc. But I was 27-28 and couldn't really navigate that world after my first job at a startup. In some ways, I wish I'd found a way, but in other ways, I know it wasn't meant to be. It's a good list, if you want to do 10 years at Google or elsewhere, internalise that list and it's lessons.
I like this one
> At scale, even your bugs have users.
Something I discovered the hard way over many years of maintaining rclone. Fixing a bug has consequences and there are sometimes users depending on that bug!
xkcd: https://xkcd.com/1172/
I know this as Hyrum's Law (which also comes from a Googler):
"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
https://www.hyrumslaw.com/
It's a good one: but it's also good to see that most of these are applicable to all kinds of organizations, not just "Google Scale" places.
Thank you for your work on maintaining rclone! It is a wonderful and very underappreciated piece of software.
It's funny that I agree with most or all of these principles but don't feel like my 10 years at Google accord with most of this. I wouldn't say I learned these things at Google, but learned them before (and a bit after) and was continually frustrated about how many of them were not paid attention to at Google at all?
Incentive structure inside Google is impaired.
I do think Google engineering culture does bias against excessive abstraction and for clean readable code and that's good. But acting in the user's interest, timely shipping, etc... not so much.
Maybe OP learned these things precisely because he saw the consequences of them not being done
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.
Your post is absolutely golden and it doesn't apply only at Google. I can't remember seeing so many deeply true statements together in one post. I'm sure many here will start to contest some of them but with enough experience they will also realize that the points were true.
Thanking the author for "13. The work that makes other work possible is priceless - and invisible."
I am 70% sure this is partially ai generated.
It is furthermore hard to believe that the engineers are working for the users, given that google’s primary activities today are broad enshittification of their products.
Because of these two things I did not make it past point 4.
It just reads like a very expensive AI which is very well prompted. I would love to interview him without his phone to see if he can reproduce even 5 of these points.
I'm sure he's a super capable, experienced, and extremely well spoken person. There is no excuse of AI writing outside of writing that pays your bills.
So glad I’m not the only one that noticed that.
There’s some really solid insights here, but the editing with AI to try to make up for an imperfect essay just makes the points they’re trying to convey less effective.
The lines between what is the author’s ideas and what is AI trying to finish a half or even mostly baked idea just removes so much of the credibility.
And it’s completely counter to the “clarity vs cleverness” idea and the just get something out there instead of trying to get it perfect.
It's just so disrespectful. I put my time in reading this. You (author) couldn't put some time into reading this once over before publishing?
The points are generally good too, which is why the AI slop tone bothers me even more.
We should not bother to read things that the author didn't bother to write.
Thank you for doing this. It allowed me to skip reading the article altogether immediately knowing it is AI generated slop. Usually I'm a little ways into it before my LLM detector starts going off, but these "This isn't X. It's Y." phrases are such a dead giveaway.
These all jibe with my 25 years of experience (only one at google though). I'll add:
* Don't work "off the clock", no matter how strong the urge: There's nothing managers hate more than surprises. Even good ones! If you've got some idea to work on, discuss it and get buy-in early. If you're spending a lot of your own time on something, that means it's probably low-value and you subconsciously know it, or it's stepping on somebody else's toes, or it's something that you're the only one who cares about. Once you're done, all your manager is going to say is "why were you doing that instead of <other higher priority thing>", and if it creates a bug or user complaint or anything else, you'll be on the hook. Save your creativity for personal projects.
* Get fast feedback. This kind of relates to the above, but more generally, iterate quickly at every scale. If testing your changes takes more than one button click and a couple seconds, whether compile time, staging deployment time, etc., fix it. Find out how others are automating their dev flows. A tiny bit of improvement here cascades greatly. Get fast feedback on designs: don't spend a ton of time writing a long doc and waiting for approval; send out a 1-paragraph summary or whatever you think the minimum is, get signoff, get done and move on. Do document, but don't overdo it. Get fast feedback on ideas; don't wait until code review time to find out that the team was planning a different direction. Yes, this does kind of suck if you're naturally introverted and prefer just coding, but it's part of the job.
* Set an extremely low bar for each day, but meet it. We aren't all superstars all the time. There'll be times when you're burnt out or blocked by something you really don't want to deal with, and making progress can seem overwhelming, so "I'll just surf the web for a while" turns into all day, which can turn into all week or all month of excuses about how little progress you're making, and the anxiety and guilt becomes more overwhelming than even the work. Avoid this by setting an easily achievable goal: a couple lines of code, a quick chat with someone who might know how to unblock one thing, whatever. That way you're not letting the anxiety build, you're not waking up the next day in the same state that you were the previous day, you at least have something to talk about during standup, and it's one less thing to deal with. Oftentimes it creates some momentum, and turns into a fully productive day! But be okay if it doesn't: the goal is just to get that one thing done, and anything else is purely optional: sometimes it's good to have an off day to recharge, so long as you're not starting the next day in the exact same position.
I agree to both 3) and 8) but I find it a dilemma that if you don't get it perfect the first time, you will waste thousands of man-hours for everyone to upgrade even though it only took you 10 minutes to release the new version.
> Novelty is a loan you repay in outages
If you personally build all (or most) of the stuff, you are in an extreme vertical integration benefit situation. You can make huge system wide changes in ways that would not be possible without having done so much novel work.
Best part of the article?
> but coordination costs grow geometrically
Using geometrically instead of exponentially! Thank you!!! :-D
Yes this is an exponentially better word choice!
Funny that there’s nothing to learn from working for an evil company, other than: keep your head down and don’t ask hard questions :/
Lots of good stuff here. Literally none of it required working at Google to learn.
> Abstractions don’t remove complexity. They move it to the day you’re on call.
Gold.
> 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
> First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate.
> Momentum creates clarity. Analysis paralysis creates nothing.
I've met Addy and I'll be generous, but strong disagree here, and this really shows a huge blind spot in how software is being developed today that hurts everyone.
There aren't two extremes between "theoretical debate" and just shipping the first crap you can slap together. Software engineering will never become a real discipline when industry keeps ignoring the lessons of every other field of engineering: gather some requirements first.
Want to know what users want? How about asking them? What about doing some research on what tools they are using now (or not) and finding out what's wrong with them. What about doing a user study? What about analyzing competing and previous products?
How about then drawing up a list of things that say what the thing will do? You can keep the list short, sure. Build a prototype (maybe for internal use)? Sure. No need to have every piece of functionality there.
But there's an enormous blind spot here I'd be remiss to point out. Back in the shrink-wrapped software days, back when products took months and sometimes years to develop, man, people really planned out what they were going to build! And I'm not just romanticizing that era--there was a lot that could go wrong, and many misses--but tons of software developed in that manner sticks with us today, not just the designs and usage patterns, but big chunks of the code too. It's not all legacy cruft; people actually thought about what they wanted to build, and then laboriously built and tested it--with crappier tools, longer build times, and many disadvantages like huge teams, crappier communication, and a whole lot less computational power.
There are other things in this list that are good advice, but I felt like this cannot possibly be the whole truth to 14 years of experience. In other words, please don't just ship your crap to us the first time it functions.
This article can be summarized as: description of doing software development in a sizeable enterprise not a startup.
From where I know: living and breathing like it for the last 19 years
Reading this makes me so happy I'm not at google anymore
Interview voice:
- How do you actually grow being in one company for 14 years?
> 1. The best engineers are obsessed with solving user problems.
A little bit of sarcasm here: “well there probably isn’t a lot of great engineers at google then”
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.
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.
Biggest lesson is you will get mass fired. So look for whats best for you, because you are the only one who can?
Holy molly! This was a treat to read and should be mandatory to every senior and even management.
That's a solid set of lessons. My favorite is that Software doesn't advocate for you, people do.
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?
This is why AI won’t suddenly fully replace a software engineer.
> Focus on what you can control. Ignore what you can’t.
That's why I left Google for HFT. Much better life.
Where you can serve corporate interests more directly and with less overhead? (:shrug:)
> 1. The best engineers are obsessed with solving user problems.
Complete bullshit. Sorry, but the reason why people use Google is because of the ecosystem + value proposition. Google Drive & Calendar are some of the most outdated pieces of SaaS software that only gets used because of the greater ecosystem they live in - and price. They (along with the other Google products) are also some of the poorest designed user interfaces online. Let's cut the crap for once here. If I were Google I would be worried because companies like Fastmail, Notion & Proton are quickly catching up.
> If I were Google I would be worried because companies like Fastmail, Notion & Proton are quickly catching up.
lol do you honestly think Google is worried about Fastmail, Notion or Proton?
> are quickly catching up.
If you were Yahoo a few years before Google it would sound the same.
the writing was already on the road w.r.t to user mindshare among normies. I see no evidence of the same happening with fast mail. why would anyone switch from gmail to fast mail other than privacy, which regular people couldn't care less about?
Privacy, as well as overall product experience. Btw, I didn't just mention Fastmail.
Thats a poor characterization to choose 2 of the least talked about apps from that company. Also your response to the claim "the best engineers do X" is logically flawed. Maybe google doesn't use their "best engineers" to build out those cherry-picked examples? maybe they used them for Search or infrastructure or something else?
I'm commenting on the article, and the first point in the article doesn't sound like search or infra. Maybe read that before assuming things. And why would it be "logically flawed"?
google has a lot more products besides the 2 you picked. Some of them are wildly successful, even. Maybe they use their "best engineers" on the more successful products?
Insightful take on career progress. Most engineers don't talk about this.
The first paragraph reads like LinkedIn slop, so I scanned the rest of the titles - they indicate that the rest of the article reads the same.
#12 is so simple yet so true. Great list thanks for sharing.
Wish I'd read this before I started at Google.
A lot of lessons from Google are really lessons from a historically unique monopoly era that no longer exists. Useful context, but dangerous to treat as timeless advice.
very good thoughts. learned a lot of these lessons the hard way over the last 20 years.
Thank you for sharing this. Well articulated.
As much as we meme about it internally, one of my favourite things about AWS was the leadership principles. I always worried I've became cult like biased. Seeing how these converge to similar great ideas is a relief.
IMO the most common denominator among all these is trust, in order for many of these to work. From policy setting at strategic level, hiring, to tactical process refinement, the invariant must always be building an environment and culture of trust. Which isn't trivial to scale.
it's sad that startups become corps and decay. this article is the perfect illustration, from the bio, to the llm slop content of the article. Just sad it has to be this way
Very good. I agree with most of it. One thing I disagree with is "The senior engineers I respect most have learned to trade cleverness for clarity, every time.". This sounds like the anti-pattern "design for lowest competence" or similar. This is a big trap. A little bit of magic is often better than clarity. Junior devs should learn to follow the rules and how things work without the actual need for deeper understanding.
Worked at an AI training company for a few months. Enshittification is real. Idiots who never deserved to be here coming up with new policies every week, sometimes twice a week. Absolutely spineless when receiving nonsense from the client which is one of FAANG but will screw colleagues with no remorse.
> 17. Your network outlasts every job you’ll ever have.
i mean, addy has literally been at google 14 years, i think internal network has outweighed the external one here
Love love love this. So much wisdom I wish I’d had 30 years ago.
Here’s the tl;dr in my opinion, with my own paraphrase:
> Approach [life] with curiosity and generosity, not transactional hustle.
Everything else essentially follows.
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.
excellent article and appreciate the author sharing his perspective which is very valuable.
For me the main lesson is, don't let your ego develop from success. Any human is vulnerable to narcissism. It is an interesting phenomenon, where you can originate as a humble person who becomes successful, only to lose your great qualities, when your identity changes. With success you attract different people in your life who may be attracted only to your success and who don't have the stones to confront you on your bs.
Developing healthy self awareness comes from surrounding yourself with people that love you, but are not afraid to keep you honest if you do something out of character.
GREAT ARTICLE!
>Abstractions don’t remove complexity. They move it to the day you’re on call.
Damn that's a real one. Nothing like struggling through a bunch of indirection to figure out what the heck a clever abstraction was supposed to do
most generic advice oat
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.
17. Your network outlasts every job you’ll ever have.
Maybe you're not allowed a personality after you unlock peak outlasting networking.
Pluribus effect :).
I don't believe any of this.
lgtm
that was an amazing read
Some people think clarity means abandoning language idioms and writing simple code that a first year computer science student could understand and follow.
If you do this, your team will write verbose, repetitive code, and put more emphasis on procedures instead of data structures and how they change over time.
Use the language features to write powerful concise code that really takes some skill and expertise in the language to understand. Force your team to become more skilled, don’t stoop down to the lowest common denominator. In time, this code will become as easily understood as any other simple program.
And when shit breaks down at 2 AM, you do nothing, because your code is clever enough to handle problems itself.
But don’t obfuscate.
This feels somewhat hypocritical coming from Addy.
Addy Osmani plagiarized my code and 'apologized' years later by publishing an article on his website[1] that he has never linked to from his social media accounts.
I cannot accept his apology until he actually syndicates it with his followers.
Seems relevant to note this behavior in light of points "6. Your code doesn’t advocate for you. People do.", "7. The best code is the code you never had to write.", and "14. If you win every debate, you’re probably accumulating silent resistance."
1. https://addyosmani.com/an-apology-to-eli/
You posted the code to a public blog page, with no attribution in the code or request of attribution from others, no license, and seemingly intended to share it freely with the world.
Then you got an apology, and a second apology.
I'm confused about what you think you're owed?
The explanation makes perfect sense, the headers were obviously just copied with no malicious intent. What is it that is still bothering you about this?
> no license, and seemingly intended to share it freely with the world
No license means you don’t intend to share it “freely”, since you didn’t share any rights. By default, you don’t own things people shared on the internet just because it’s there.
That being said I’ve even seen people with licenses in their repos who get mad when people used their code, there’s just no telling and it’s best to just treat random sources of code as anathema.
Per Eli's own comment here, the original copied code was straight up public domain and thus does not even require attribution.
https://github.com/Modernizr/Modernizr/pull/684#issuecomment...
Correct. He did not commit copyright infringement. Just plagiarism.
I'm curious if you would have the same opinion about code shared on stack overflow?
I think GP is referring to the fact that an author’s work is copyright protected by default, and a license is needed to permit others to use freely [1]. StackOverflow posts are licensed under CC BY-SA 4.0 [2].
[1]: https://www.copyright.gov/help/faq/faq-general.html
[2]: https://stackoverflow.com/help/licensing
(Disclaimer: Just commenting on GP’s statement about “no license”, not on the specific disagreement or apology mentioned above which I am unfamiliar with.)
It's worth noting that the code in question was also open sourced and permissively licensed by the original author as he stated in the thread[1]. I guess this isn't really about licensing at all, just the original author seems to think it was rude, and also doesn't want to accept any of the apologies that have been offered.
[1]: https://github.com/Modernizr/Modernizr/pull/684#issuecomment...
> with no attribution in the code or request of attribution from others, no license, and seemingly intended to share it freely with the world
The bottom of every page on my blog has a copyright link that you can follow. I dedicated the code to the public domain. I never made a copyright claim. I simply asked Addy to not claim to authorship of the code.
Not to make excuses for plagiarism, I am looking at the code itself and somewhat scratching my head since it seems quite...trivial?
I don't mean to belittle the effort but at least in terms of volume of code and level of effort, I wouldn't recognize it as mine if someone had copied it from my work and passed it off as theirs.
Regarding the charge of plagiarism, is it possible that the PR attribution reflects someone eager to contribute something to a larger effort as opposed to simply trying to "steal" someone else's work?
One could reasonably interpret the PR and attribution as "I integrated this code into this project thus I am taking credit for it". In other words there is probably a stronger charge for misguided clout-chasing than plagiarisms.
That code from your post is fairly standard image load handling, but the notable part is this line:
self.apng_supported = ctx.getImageData(0, 0, 1, 1).data[3] === 0;
Unless I'm misunderstanding, it's basically a "neat trick", like using ~~ for rounding or a fast inverse square root.
Is the intent that everyone who makes use of that trick is supposed to link back to your blog?
The notable part is the PNG file was copied exactly. He could have generated one himself.
addy rubs me the wrong way more often than not, but you really gotta let this go friend.
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!
FWIW, the actual apology is well written.
Although little note at the very end explains why:
> This note is in response to emails from Eli Grey to Chrome leadership from October, 2023
In other words, he wrote this because he was forced to.
that's going a bit far, no?
[flagged]
You are libeling me. That is not what I posted. My original post, accessible via the GitHub comment version history is
"@addyosmani No problem; just remember that modifying someone else's code does not grant you any copyright to that code. I don't agree with your opinion that inserting existing code into a template (the API) for a framework (Modernizr) warrants a notice of credit, even with a few changes to the code being inserted."
If you run it through originality.ai, you'll see that bits of it are his writing, some is mixed and some is just ai. This blog post everyone is discussing is also written with ai.
And who or what is "originality.ai" supposed to be that makes it an authority on AI provenance (an unsolvable problem)?
Addy told me that he didn't use AI to write his apology. I can see why people might suspect otherwise though.
That site happily flags writing older than the modern AI era. It's a worthless grift, which has unfortunately suckered many.
lol you believe that site for more than a second?
15 years on that trivial piece of code man. Reminds me of Dostoyevsky's "Notes from Underground".
Thanks for sharing, I found the blogpost hypocritical even without knowing about this
"i cannot accept this apology unless.."
you got a written apology already, what else do you want?
a post of this in all of his socmed accounts? him telling this story to his kids at dinner table and bedtime stories? at his eulogy, obituary, and his grave?
what's your life mission now, to post this little drama of yours on each and every content he puts out?
was that code your best achievement to date? did it stole millions from you and ruined your life?
grow the fuck up dude
Jesus, bro.
Let bygones be bygones. How long is this ago? It's just code. And what the code did, is not even fundamental. It's not like you cured cancer.
I tend to see my code in these terms as well, it's not dear to me. But I'd never presume to tell someone how to feel over having their work stolen (and I'm using that term because that's how I'm sure Mr Grey felt).
just because people think or feel things, doesn't make those things valid (and certainly not prudent)
Plagiarizing code is kind of a redundant concept nowadays in the era of LLM coding engines. It's a safe bet there's always copilot plagiarizing someone's code on one of its users' machines, both being oblivious to it.
That's a bit different from knowingly taking a friend or former partner's code and putting "by Your Name" on top of it before sharing it with outsiders
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[dead]
[flagged]
Some people just want to be remembered for the "engineering" / "social engineering" they did, while others what to be remembered for being employee of the month for 10+ years at the company.
Both are a complete waste of time.
It's more impressive if you bootstrapped your own company to millions instead of chasing false praise, engaging in employee politics and being employee #470293 at big company.
But I predict you will get the same thing with those at the big AI companies.
seems the real lesson would be to not spend 14 years at google
I'm sure he made a killing though
It isn't just that he made a killing — Osmani helped conceive a broader vision of blogging as a fusion of human in the center writing and AI agents.
Or to say it in his own words: "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." source: https://addyosmani.com/bio/
it's a bit weird to talk about yourselves in third person
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!
> and that legacy will be felt for a long time to come
yes, the legacy of polluting the internet with unlimited "AI" slop to the point it became useless
I don't quite understand how that is your take away. Could you clarify?
Thought occurred to me to throw this at ChatGPT 5.2:
Given the article at https://addyosmani.com/blog/21-lessons/, find a short list of points which summarizes and touches on all of his lessons
Answer:
Here’s a short “umbrella list” that still covers all 21 lessons (each bullet is doing a lot of work on purpose):
The fixation with AI really harms the signal-to-noise ratio on HN lately. The author of this article very clearly used an LLM to generate much of it, which makes it read like the clickbait you see a ton of on LinkedIn. Then a commenter posts an LLM-generated bullet list summary of the LLM-generated article, which really adds nothing to the discussion.
Ultimately the author had some simple ideas that are worth sharing and discussing, but they're hidden behind so much non-additive slop.
The writing is excellent.
Very correlated with the quality of the message I'd imagine.
It is very heavily filled with LLM-isms. The writing is bland AI output.
how do you know?
in the first item, LLMs don't use incomplete sentence fragments?
> It’s seductive to fall in love with a technology and go looking for places to apply it. I’ve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding.
I suppose it can be prompted to take on one's writing style. AI-assisted, ok sure, but hmm so any existence of an em-dash automatically exposes text as AI-slop? (ironically I don't think there are any dashes in the article)
EDIT: ok the thread below, does expose tells. https://news.ycombinator.com/item?id=46490075 - yep there's definitely some AI tells. I still think it's well written/structured though.
> It's not X... it's Y.
That one I can't unsee.
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.
The blog-post is AI generated or at least AI assisted.
many of the replies in this Hacker News thread read like AI replies too. I think the internet is dead as we know it. ~100% of content will be bots writing for ~100% audience of bots
This is a good list. Original, evidence to me that the author is the real deal.
There's hardly anything original here. These are regurgitated points you'd see in any article of this type. In fact, your favorite LLM can give you the same "lessons" from its training data.
Your favorite LLM can probably reproduce this entire discussion thread so what’s the point, right?
Great post, Years following Addy. I wonder know how he manages his time, in addition to being a leader at Google, and writing such a valuable blog.
Unsure why this comment appears to be downvoted!
I have followed him for a long time and learned a lot too. I always wonder the same thing about the “tech influencers” and I’d love to know more about how they structure their days.
I find it difficult recently to sit down and complete a meaningful piece of work without being distracted by notifications and questions. In the last year this has been exacerbated by the wait time on LLMs completing.
I would love to know how top performers organise their time.