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

Software Engineering at Google (2017)

arxiv.org

Post reply on HN
Print view View original

271–280 of 319 posts

Re: Software Engineering at Google (2017)

#271

Post by lugg »

quietbritishjim wrote: post #73
lugg wrote: post #9

Earlier quoted context omitted.

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.

I think the objections to rewriting code are sometimes justified, rather than just blindly following rules. As you said, refactoring code helps you understand it. This means that you can end up feeling like your code is objectively clearer than before you started, but sometimes it's just an illusion caused by the fact that you just (re)wrote it. If there are other people in the company that already understand that fu…

You're talking about rewrites. I'm talking about cleaning up messes left by lazy people long ago, so long ago that most of the juniors are scared to clean it up despite it being impossible to understand without a days reading.

You can say it disrupts others understanding of shitty old code, frankly I don't care. Code is not immutable and maintaining status quo helps nobody except the old guard stay relevant.

Re: Software Engineering at Google (2017)

#272

Post by lugg »

chucksmash wrote: post #131
lugg wrote: post #9

Earlier quoted context omitted.

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.

Working Effectively with Legacy Code recommends just this idea. They call it scratch refactoring. Refactor without a lot of forethought to see how the system works, then just throw away your changes but keep your newfound understanding.

This is effectively "it." But I do like to branch off the more useful refactors into their own commits.

Re: Software Engineering at Google (2017)

#273

Post by dilyevsky »

sigsergv wrote: post #257
dilyevsky wrote: post #251

Earlier quoted context omitted.

Google havent been using p4 since around 2013

Piper interface and workflow is heavily influenced by perforce.

Except it’s now highly scalable that is taking care of branching performance. Nothing technically making it difficult to branch afaik. In fact rapid (grape) used it pretty heavily to track rollouts if I remember correctly.

Re: Software Engineering at Google (2017)

#274

Post by [deleted] »

steelframe wrote: post #192
webmaven wrote: post #76

Earlier quoted context omitted.

Well, if you exceed expectations, doesn't that mean you didn't set your goals high enough?

At Google you are expected to exceed expectations. But seriously, you are evaluated against the role description (software eng? product mgmt?) and your level. If you exceed expectations consistently over several review cycles, you are encouraged to apply for a promotion. The goal is to get you promoted into a role and level where you can consistently meet expectations.

[deleted]

Re: Software Engineering at Google (2017)

#275

Post by sjg007 »

steelframe wrote: post #192
webmaven wrote: post #76

Earlier quoted context omitted.

Well, if you exceed expectations, doesn't that mean you didn't set your goals high enough?

At Google you are expected to exceed expectations. But seriously, you are evaluated against the role description (software eng? product mgmt?) and your level. If you exceed expectations consistently over several review cycles, you are encouraged to apply for a promotion. The goal is to get you promoted into a role and level where you can consistently meet expectations.

Ahh the Peter Principle. https://en.wikipedia.org/wiki/Peter_principle

Re: Software Engineering at Google (2017)

#276

Post by sjg007 »

taivokasper wrote: post #61
Izmaki wrote: post #26

Earlier quoted context omitted.

It's not easy to list goals from the top of my head as it's not my strong side, and especially not if they have to be measurable (which good goals should be, rather than your boss evaluating whether or not you did something), but here goes: Goals could be "Pick up language X in order to help development on project Y" or "Get formally introduced to all R&D team leaders, and get introduced to their roadmaps" or "Facili…

Thank you. I asked because in the previous company I worked for we had difficulties setting measurable goals for devs and ended up tracking only product goals.

Product can be highly variable (or uncertain) so dev goals would focus on skills necessary to achieve said product. Ideally these skills a general and transferrable.

Have you ever read a white paper? You see how they manage to say that the product will solve every problem you have and nothing specific at all? Same idea.

Re: Software Engineering at Google (2017)

#277

Post by sjg007 »

thetechlead wrote: post #75
hknd wrote: post #60

Earlier quoted context omitted.

How does it make sense to compare the processes of a company with >100k people touching code and products with more than 1B qps, to a startup with This comparison makes absolutely no sense.

Because there are people who think things work at Google must work magically for their company. There are many patterns that seem perfect in theory but fail miserably in the real world. Always think different and take nothing for granted.

"good enough for Google" == "nobody got fired for buying IBM"

Re: Software Engineering at Google (2017)

#278

Post by lucasmullens »

cpeterso wrote: post #254

I'm curious to learn more about Google's approach to project planning and management, beyond OKRs for personal or team goals. Do all teams use the same standard process or are teams allowed to do their own thing? What tools and cadence do they use to track project milestones and progress? With Google's monorepo and a centralized bug tracker, they could make some nice project dashboards.

Each team does their own thing. There's some project management tools that are popular, but no Google-wide standard.

Re: Software Engineering at Google (2017)

#279

Post by quietbritishjim »

lugg wrote: post #271
quietbritishjim wrote: post #73

Earlier quoted context omitted.

I think the objections to rewriting code are sometimes justified, rather than just blindly following rules. As you said, refactoring code helps you understand it. This means that you can end up feeling like your code is objectively clearer than before you started, but sometimes it's just an illusion caused by the fact that you just (re)wrote it. If there are other people in the company that already understand that fu…

You're talking about rewrites. I'm talking about cleaning up messes left by lazy people long ago, so long ago that most of the juniors are scared to clean it up despite it being impossible to understand without a days reading. You can say it disrupts others understanding of shitty old code, frankly I don't care. Code is not immutable and maintaining status quo helps nobody except the old guard stay relevant.

I said:

> Of course, sometimes rewrites/refactors really are an improvement

If that's what you were talking about in the first place, fair enough and my apologies.

Re: Software Engineering at Google (2017)

#280

Post by Cedricgc »

weinzierl wrote: post #25
jsty wrote: post #17

Earlier quoted context omitted.

You could also gate experimental code behind feature flags which aren't set in prod

I agree that feature flags can be a solution sometimes. The presentation and the paper I linked to in my question discusses this, but they also mention large-scale refactorings and this is where I don't see how feature flags can help. For example: How do they untangle a wad of code that is large enough that it takes longer than a few days and more than a single developer to get the code back into a state that is acce…

https://trunkbaseddevelopment.com/branch-by-abstraction/
Post reply on HN