Software Engineering at Google (2017)
1–10 of 319 posts
Re: Software Engineering at Google (2017)
#2"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals"
This seems attractive for other large organizations. Any positive or negative experiences from readers?
Re: Software Engineering at Google (2017)
#3"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?
Most large companies operate this way. Its great as long as the powers that be actually action these assessments and validate confirm the assessment with other members of the team.
Re: Software Engineering at Google (2017)
#4"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?
We do this at a smaller scale (~1500 employees) with success. It enables everyone to work towards a goal and to discuss with their superior any issues that get in the way, as well as every success story along the way. Both are very important parts of the journey.
Re: Software Engineering at Google (2017)
#5Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership":
"In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."
Re: Software Engineering at Google (2017)
#6Previous discussion: https://news.ycombinator.com/item?id=13619378
Re: Software Engineering at Google (2017)
#7This all looks nice and perfect, but what's the catch ?
Re: Software Engineering at Google (2017)
#8Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."
Thanks for highlighting this. To me it seems an important idea that contradicts conventional wisdom, similar in the way that most people over-encourage DRY, blind to the fact it increases coupling.
Re: Software Engineering at Google (2017)
#9Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."
Thanks for highlighting this. To me it seems an important idea that contradicts conventional wisdom, similar in the way that most people over-encourage DRY, blind to the fact it increases coupling.
I frequently find myself drastically refactoring code to understand it. I don't commit those changes because it's not worth the effort to justify the cleanup to people who treat these rules as gospel.
Apparently me spending half a day reading code is no big deal but cleaning it up is a waste of time.
Shrug.
Re: Software Engineering at Google (2017)
#10This all looks nice and perfect, but what's the catch ?
That at the end of the day, this is all controlled and used by human beings, who are notoriously known for sometimes being mean and selfish?
Examples: the 80/20% project work that is described is a really good idea IMHO, however if somebody choses to work 50/50 in a period, becuase that person is "almost finished and longing to present it", then it might turn into a problem for the team leader and the employee.
Software sometimes fails, even highly sophisticated build automation.
Rewriting software may introduce a sense of ownership to employees, but it may also lower the quality of the code that is being rewritten - worst case to the extend that the code needs another rewriting to even function as intended.
...but why let yourself get blocked by the negatives, instead of being inspired by the positive?