llm/3a862c31-848e-4e32-be93-99402d2b43b6/topic-7-00699bf9-a38f-4fcc-81a1-ac930c83610d-input.json
You are a comment summarizer. Given a topic and a list of comments tagged with that topic, write a single paragraph summarizing the key points and perspectives expressed in the comments.
TOPIC: User-Focused Engineering Culture
COMMENTS:
1. > 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 a
2. 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.
3. 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.
4. 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.
5. I always strongly suggest sample code to people designing new APIs. Can be a very revealing exercise.
6. > 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".
7. 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.
8. 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.
9. 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.
10. > 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.
11. 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.
12. 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.
13. I often chuckle when (our) animations may have more complex math that consume more resources than the awaited logic/call that they gate.
14. 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
15. 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.
16. 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.
17. 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.
18. You need to be a product-minded engineer.
19. I have never seen a pure ticket based / zero ownership approach ever work.
20. 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.
21. 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).
22. 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.
23. 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
24. >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.
25. 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 e
26. If it’s impossible to understand users problems then something has gone horribly wrong.
27. > 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".
28. 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.
29. Ignoring the users is the correct solution. Defining company culture through software loading is ridiculous.
30. 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.
31. 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.
32. 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 tr
33. > But how does one make judgment a repeatable process?
Principles can help scale decision-making.
34. 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.
35. > 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.
36. 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.
37. 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.
38. 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.
39. 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.
40. 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 d
41. 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.
42. 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.
43. 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.
44. 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!
45. 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.
46. 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.
47. Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop. That's just an excuse.
48. 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.
49. 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.
50. 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.
51. 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".
52. > "solving the right problem wrong" vs "solving the wrong problem right".
That's a really useful framing!
53. 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.
54. existing is better than not existing and those who move fast and ship crappy software first will win. learn the lesson :)
55. 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.
56. 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!"
57. Same. Mine is: existence is the most important feature.
58. 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.
59. 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.
60. 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.
61. 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.
62. > 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
63. 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.
64. 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
65. 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.
66. 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 ano
67. 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.
68. > 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.
69. 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?
70. >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.
71. 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.
72. > 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.
73. 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.
74. 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.
75. > 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.
76. 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.
77. Fair point. "User" as developer rather than "user" as person clicking buttons in Gmail, Google Maps, etc, etc
78. 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.
79. 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.
80. 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".
81. 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.
82. 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.
83. 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.
84. 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.
85. 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.
86. You can learn something at a company by observing it’s weaknesses as well as strengths
87. 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.
88. 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.
89. I see it differently then UX at all. I find the need for better customer support 1000x more pertinent to helping users.
90. To me; point #3 is the big one and it is in conflict with point #1
91. How so? Those two together is literally agile; not as I've seen it done, but as it's intended. Learn, iterate, repeat.
92. 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?
93. > 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.
94. Agreed.
Not just engineers, but basically everyone involved in creating products including designers and PMs.
Every single bullet point here is gold.
95. > 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"
96. > 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)
97. > 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.
98. #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.
99. > 1. The best engineers are obsessed with solving user problems.
100. 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.
101. > 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
102. > 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.
103. 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?
104. 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"?
105. 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?
106. > 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”
107. 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.
108. 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.
Write a concise, engaging paragraph (3-5 sentences) that captures the main ideas, notable perspectives, and overall sentiment of these comments regarding the topic. Focus on the most interesting and representative viewpoints. Do not use bullet points or lists - write flowing prose.
User-Focused Engineering Culture
108