Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

Post reply on HN
Print view View original

321–330 of 732 posts

Re: Lessons from 14 years at Google

#321

Post by titzer »

> 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.

Re: Lessons from 14 years at Google

#322

Post by abustamam »

mike_hearn wrote: post #139
hansmayer wrote: post #93

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 everythi…

> 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,…

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.

Re: Lessons from 14 years at Google

#323

Post by [deleted] »

Sephr wrote: post #287

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 cod…

[deleted]

Re: Lessons from 14 years at Google

#324

Post by crystal_revenge »

firefoxd wrote: post #5

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.

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!"

Re: Lessons from 14 years at Google

#325

Post by blibble »

croemer wrote: post #306
mgrat wrote: post #194

Earlier quoted context omitted.

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/

> 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

Re: Lessons from 14 years at Google

#326

Post by etamponi »

> 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?

Re: Lessons from 14 years at Google

#327

Post by fooker »

mike_hearn wrote: post #139
hansmayer wrote: post #93

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 everythi…

> 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,…

The beancounter takeover was after you left.

2014 Google and 2019 Google were completely different companies.

Re: Lessons from 14 years at Google

#328

Post by lovich »

stefan_ wrote: post #197
p1esk wrote: post #168

Earlier quoted context omitted.

Almost nobody else in engineering did this. What you described is the job of a product manager. Are there no PMs at Google?

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?

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

Re: Lessons from 14 years at Google

#329

Post by d0gbread »

hansmayer wrote: post #286
bitexploder wrote: post #265

Earlier quoted context omitted.

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?

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.

Re: Lessons from 14 years at Google

#330

Post by d0gbread »

seanmcdirmid wrote: post #257
hansmayer wrote: post #93

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 everythi…

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.

Post reply on HN