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

651–660 of 732 posts

Re: Lessons from 14 years at Google

#651

Post by diydsp »

rswail wrote: post #595
taklimakan wrote: post #198

Earlier quoted context omitted.

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

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.

Re: Lessons from 14 years at Google

#652

Post by mattacular »

QuadrupleA wrote: post #466
mattacular wrote: post #413

Earlier quoted context omitted.

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)

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.

Re: Lessons from 14 years at Google

#653

Post by red-iron-pine »

eloisant wrote: post #586
fragmede wrote: post #468

Earlier quoted context omitted.

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.

Re: Lessons from 14 years at Google

#654

Post by red-iron-pine »

Panzer04 wrote: post #374
vbezhenar wrote: post #354

Earlier quoted context omitted.

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.

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.

> 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

Re: Lessons from 14 years at Google

#655

Post by sanderjd »

bigcloud1299 wrote: post #133

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

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.

Re: Lessons from 14 years at Google

#656

Post by wbl »

intended wrote: post #617
lazylizard wrote: post #552

Earlier quoted context omitted.

efficiency is the enemy of employment, no?

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

Nursing massively expanded but they didn't want to take it.

Re: Lessons from 14 years at Google

#657

Post by sanderjd »

zdragnar wrote: post #486
spicyusername wrote: post #189

Earlier quoted context omitted.

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

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!

Re: Lessons from 14 years at Google

#659

Post by sanderjd »

dclowd9901 wrote: post #364
bigcloud1299 wrote: post #133

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

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

Re: Lessons from 14 years at Google

#660

Post by gedy »

thisOtterBeGood wrote: post #521
soorya3 wrote: post #337

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

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.
Post reply on HN