Live data from Hacker News

Lessons from 14 years at Google

addyosmani.com

451–460 of 732 posts

Re: Lessons from 14 years at Google

#451
post #10

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…

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

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?

Re: Lessons from 14 years at Google

#452
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…

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

Re: Lessons from 14 years at Google

#453

Earlier quoted context omitted.

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

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.

Re: Lessons from 14 years at Google

#454
post #30

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…

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.

Re: Lessons from 14 years at Google

#455

Earlier quoted context omitted.

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

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.

[dead]

Re: Lessons from 14 years at Google

#456

Earlier quoted context omitted.

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.

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.

Re: Lessons from 14 years at Google

#457

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.

Re: Lessons from 14 years at Google

#458

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.

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

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.

Re: Lessons from 14 years at Google

#459

Earlier quoted context omitted.

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.

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