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

111–120 of 319 posts

Re: Software Engineering at Google (2017)

#111

Post by scarface74 »

webmaven wrote: post #76
scarface74 wrote: post #41

Earlier quoted context omitted.

My experience is that the difference in raises between an employee that got an “Exceeds Expectations” and one that “Meets Expectations” isn’t significant enough to be worth wasting the time worrying about it. The best way to make more money is to change jobs. Google may be different.

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

Probably,

But working at regular non SV companies, I’ve learned just to focus on doing as well as possible while still having a sane work life balance, keeping on top of industry trends and job hopping when my salary and the market were out of whack.

Google pays such above market salaries, the strategy would be different.

Re: Software Engineering at Google (2017)

#112

Post by fouronnes3 »

skj wrote: post #89
weinzierl wrote: post #65

Earlier quoted context omitted.

That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.

It's not like we (I am a Googler) email patch files around. Everything is integrated into the system. You create a CL (change list), it automatically gets a number. People can review it, test it, or fork it (make a new CL using your CL as a starting point) as much as they want, all from that CL number.

So basically it's a branch?

Re: Software Engineering at Google (2017)

#113

Post by sytelus »

duncan-donuts wrote: post #104
sytelus wrote: post #91

Earlier quoted context omitted.

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

One thing I think that is important to point out is the, “working beautifully” part. I agree that rewriting stuff just because is a waste of time and money. There are plenty of solutions out there that may solve a problem and may be working fine, but have now hit their scaling ceiling and people become frustrated. Rewriting stuff is a part of software, but should almost always be done incrementally. I also don’t thin…

The only reason given was exactly what was quoted by parent. Also refactoring different than rewriting.

Re: Software Engineering at Google (2017)

#114

Post by casual_slacker »

sytelus wrote: post #91
Radim wrote: post #5

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

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

I know this is a battle as old as time, but the other extreme does exist: a system so complex that it directly attributes to attrition and decay, but too business-critical to get rid of. Yes, it's a "serious issue", and yes, it's common at many overgrown startups.

Re: Software Engineering at Google (2017)

#115

Post by withhighprod »

thetechlead wrote: post #66
elmozyz wrote: post #64

Earlier quoted context omitted.

> Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage. Being a startup does not excuse this kind of cavalier attitude

When you face life-or-death scenarios everyday as a startup founder. Not a single startup was killed by software bugs or design faults. Never. Many other things do.

Well if you brew an engineering culture like this, it’s no good. When you get 10+ engineers, Code reviews and most best practices are needed.

And honestly for a good startup you’ll need a few senior engineers who won’t like the way of roll the fk out.

Re: Software Engineering at Google (2017)

#116

Post by sytelus »

casual_slacker wrote: post #114
sytelus wrote: post #91

Earlier quoted context omitted.

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

I know this is a battle as old as time, but the other extreme does exist: a system so complex that it directly attributes to attrition and decay, but too business-critical to get rid of. Yes, it's a "serious issue", and yes, it's common at many overgrown startups.

There are always good technical reasons to rewrite things but the reason quoted by the parent i.e. devs not “feeling” ownership and won’t work on code wholeheartedly unless it’s their code - those reasons are evil.

Re: Software Engineering at Google (2017)

#117

Post by ThaJay »

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…

- build an interface to the code to be changed

- make all code that uses said code use the interface instead

- build the feature switch into the interface

Re: Software Engineering at Google (2017)

#118

Post by z0r »

lugg wrote: post #9
yakshaving_jgt wrote: post #8

Earlier quoted context omitted.

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.

Writing code is hard, so there's nothing wrong with reading it being hard too. (I'm only half kidding).

Re: Software Engineering at Google (2017)

#119

Post by aaaaaaaaaab »

matwood wrote: post #106
aaaaaaaaaab wrote: post #43

Earlier quoted context omitted.

Ah yes! It's not enough if you're great at your job, or even if you do other people's jobs... Instead you have to have this checklist of your quarterly goals, on which you can go through with your engineering manager on biweekly 1-on-1 meetings! And of course you should make a nice spreadsheet and a confluence page documenting your progress, since we're data driven :) Did you fix a major fuckup in some legacy compone…

> Did you fix a major fuckup in some legacy component? What if that legacy component was no longer in use? Is there some bigger picture in play? I've been at bad companies before, so I understand being cynical. But, having people just do whatever they feel like also does not work. From the outside it looks like Google has quite a bit of this, so they are clearly trying to get people on some path. The messaging app si…

>What if that legacy component was no longer in use? Is there some bigger picture in play?

Said legacy component was (and is) making a substantial chunk of the companies revenue.

Re: Software Engineering at Google (2017)

#120

Post by le-mark »

Macha wrote: post #36
MeteorMarc wrote: post #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?

On an individual level, this feels like a box-ticking exercise at the company I work at. Project goals are hard to set out a year in advance as a developer as there's a good chance that within 6 months the direction is changed yet again from product. Personal career development goals are not really considered. When it gets tied into career progression, you end up with not very productive goals (but easily measurable!…

When it gets tied into career progression,

I've come to the conclusion it's folly to pursue any one companies career progression maze. Because you get corralled into all sorts of sillyness like this; vying for projects with your peers, acrimonious code reviews, chasing silly metrics, etc. I find it's much more effective in time, money and title (and work life balance, and mental health) to simply switch jobs for the higher title.

In other words don't fall for the "work your ass off for a possible future bump in pay and title" game many companies play.

Post reply on HN