Software Engineering Insights from 10 Years at Google
addyosmani.com
Software Engineering Insights from 10 Years at Google
1–10 of 151 posts
Re: Software Engineering Insights from 10 Years at Google
#2My 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 doc to verify that all the relevant constraints are being addressed.
It might suck to spend 4hr writing a doc and 1hr*(N engineers) reviewing it but getting everyone aligned, and writing down why you did something and what was considered but ignored, is one of the super powers people have. At larger companies this process, when done informally, can be done in under a day and save months of headaches down the line. Especially so when the reviewer leaves comments like "can we break X up into milestone A, B, and C instead of rolling our a single piece".
Re: Software Engineering Insights from 10 Years at Google
#3Re: Software Engineering Insights from 10 Years at Google
#4(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…
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.
Re: Software Engineering Insights from 10 Years at Google
#5(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…
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?
Re: Software Engineering Insights from 10 Years at Google
#6The large pull quotes (which I’ll be honest I’m never a fan of) just interrupt me trying to figure out the layout.
So I’m not sure how things are organized.
I’m on my phone now, maybe it’s better on desktop. Reader mode didn’t really change anything so unfortunately that didn’t help.
The article sounds interesting.
Re: Software Engineering Insights from 10 Years at Google
#7I’m sorry but I’m having a hard time following this page. There are at least two sizes of section headers, and I can’t tell if one is a subsection of the other or they communicate some kind of relative importance or what. The large pull quotes (which I’ll be honest I’m never a fan of) just interrupt me trying to figure out the layout. So I’m not sure how things are organized. I’m on my phone now, maybe it’s better on…
Re: Software Engineering Insights from 10 Years at Google
#8It may seem harsh, but the industry should stop elevating this kind of pablum.
Re: Software Engineering Insights from 10 Years at Google
#9Has 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…
Re: Software Engineering Insights from 10 Years at Google
#10Has 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…
As I read through the article, I couldn’t figure out if it was me “hating” on the author or if it really read like a 99 cent store hallmark card.
Glad to see I wasn’t the only one who thought the latter.