Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

521–530 of 732 posts

Re: Lessons from 14 years at Google

#521

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.

Re: Lessons from 14 years at Google

#522

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.

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…

How do you feel about the whole thing years later?

Re: Lessons from 14 years at Google

#523

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

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…

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?

Re: Lessons from 14 years at Google

#524

Earlier quoted context omitted.

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.

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

Re: Lessons from 14 years at Google

#525

Earlier quoted context omitted.

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.

Re: Lessons from 14 years at Google

#526

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

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

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

Re: Lessons from 14 years at Google

#529
post #334

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

[deleted]

Re: Lessons from 14 years at Google

#530

Earlier quoted context omitted.

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.

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

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

Post reply on HN