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

Software Engineering Insights from 10 Years at Google

addyosmani.com

Post reply on HN
Print view View original

11–20 of 151 posts

Re: Software Engineering Insights from 10 Years at Google

#11

Post by gravypod »

tmpz22 wrote: post #5
gravypod wrote: post #2

(Opinions are my own) My favorites from the list, that I did not see other companies (specifically startups) do at all: > A single large release may be divided into a series of lower-risk well-understood rollouts. > Design documentation should not be an afterthought but an integral part of the software engineering process. > Coordinate reviews for the design doc and compare the design as it evolves with the original…

> It might suck to spend 4hr writing a doc Maybe our releases are too big but our technical specs take much longer to write and even longer to coordinate stakeholders when conflicts do come up. Can people really crank these docs out in 4 hours?

Depends on the size and level of detail. I'm currently on page 25 and week three of a doc. I've also drafted a quick one or two pager with summary, goals, non-goals, and a plan with links to code + libraries + docs.

Re: Software Engineering Insights from 10 Years at Google

#13

Post by ThrowawayR2 »

bern4444 wrote: post #4
gravypod wrote: post #2

(Opinions are my own) My favorites from the list, that I did not see other companies (specifically startups) do at all: > A single large release may be divided into a series of lower-risk well-understood rollouts. > Design documentation should not be an afterthought but an integral part of the software engineering process. > Coordinate reviews for the design doc and compare the design as it evolves with the original…

What's critical is that this remains an informal process. The moment this process becomes codified into a formal doc that requires approvals and reviews across teams, is the moment this ends up becoming a far larger part of the work than it should. Making it a required aspect of the job dramatically slows down the work and makes the doc act as a gatekeeper to technical work.

Unfortunately, once you have 100+ people across multiple teams and disciplines working on the same product release, formal documentation and all the ceremony that goes with it is no longer optional. Things have to be written down to keep that many people all on the same page and focused on the same goals.

Re: Software Engineering Insights from 10 Years at Google

#14

Post by addy_osmani »

Hey folks. Author of this post here. I sincerely apologize, this was accidentally published live prematurely (my fault). It’s got a number of style and structure issues I’ve been working through locally (you are spot on regarding the heading feedback). I have taken it down and will be publishing it in the future once it is actually complete.

Re: Software Engineering Insights from 10 Years at Google

#15

Post by Retric »

Supermancho wrote: post #8

Has someone collected all these self-aggrandizing posts that spew from ex-Googlers and current Googlers? It feels like a pre-requisite for their promotion packets. These all sound about the same and are altogether unhelpful. Note the copious links to terms and inlined quotes rather than an actual study, or any evidence at all...just vague rewording of colloquial expressions commonly traded around. The only use seems…

Look, yes this is another post that seems to be written by an idiot but that’s presumably because their simply a bad at this type of communication. Writing for a mass audience is just really difficult to do well and this is just one of the common failure modes for technical people.

Even if you can’t find value in what was written just take it as a lesson in what not to do.

Re: Software Engineering Insights from 10 Years at Google

#18

Post by magicalist »

Supermancho wrote: post #8

Has someone collected all these self-aggrandizing posts that spew from ex-Googlers and current Googlers? It feels like a pre-requisite for their promotion packets. These all sound about the same and are altogether unhelpful. Note the copious links to terms and inlined quotes rather than an actual study, or any evidence at all...just vague rewording of colloquial expressions commonly traded around. The only use seems…

It's somebody's blog post that's passing by and will be gone tomorrow. I don't think we have to worry about it being overly "elevated".

On the other hand we have a bunch of people spending too much time on hacker news, often with all the insight of someone who spent 5 minutes scanning a wikipedia article. I'd worry a lot more about the long term effects of elevating this self congratulatory content, but where's this content cop then?

> It may seem harsh

Honestly it seems like it's trying too hard. Call it feel good vagueries and move on.

Re: Software Engineering Insights from 10 Years at Google

#19

Post by Plaastix »

addy_osmani wrote: post #16
Plaastix wrote: post #12

Archive link: https://web.archive.org/web/20220518230424/https://addyosman...

Sorry about that. The post will be live again (in complete form) in the next week or two. This was an accidental early deploy :/

Oh sorry to repost this!

Re: Software Engineering Insights from 10 Years at Google

#20

Post by gmiller123456 »

Is there any evidence that Google is actually better at software engineering than other companies? IMHO, it seems they have enough money to deliberately do things inefficiently which would kill a smaller company, but Google can manage to succeed through brute force.

Honestly I think the better example would be from a tiny company that can't afford to do things wrong.

Post reply on HN