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

131–140 of 319 posts

Re: Software Engineering at Google (2017)

#131

Post by chucksmash »

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.

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.

Re: Software Engineering at Google (2017)

#132

Post by PurpleBoxDragon »

sytelus wrote: post #116
casual_slacker wrote: post #114

Earlier quoted context omitted.

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.

Does the developer not work on any systems unless they feel it is theirs, or is it a particular system that causes this phenomena? If it is the latter case, then the dev's reasoning is really a symptom of a deeper problem.

Re: Software Engineering at Google (2017)

#133

Post by sigsergv »

StreamBright wrote: post #37
sigsergv wrote: post #18

Earlier quoted context omitted.

I think they don't branch code because perforce branches are horrible and merging them back to HEAD is extremely painful process for monorep.

Even git or hg branches are horrible. Once you have multiple people working on the same codebase and touching the same files it is pretty horrid to manage. I know several companies not using branches because the merge conflict resolution takes too much time. The PDF explicitly calls out the time consuming part: "Almost all development occurs at the “head” of the repository​, not on branches. This helps identify integ…

Rebased branches in git are nice (for one developer only unfortunately), there are some pain of course but when rebase is performed often (once a day) it consumes not so much of time. The real pain begins when some huge commit is pushed to HEAD but it still manageable.

Anyway, I feel sad that so much efforts were put on really nice VCS concepts and almost no one use them in enterprise development.

Re: Software Engineering at Google (2017)

#134

Post by seanmcdirmid »

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…

Code rots, even the best code rots, because the people and cultural environment that the code was written under change and fade away. Refreshing it occasionally, even if it isn’t improved in a significant way, is one way to deal with that rot.

Even if the product/library/framework never changed much, rewrites would still be necessary to keep it going as new generations of programmers shuffle through. Otherwise we wind up with a Verner Vinge dystopian culture of software archeology.

Re: Software Engineering at Google (2017)

#135

Post by sigsergv »

ashelmire wrote: post #72
StreamBright wrote: post #38

Earlier quoted context omitted.

What do you mean? Branching is not a solved problem once people are editing the same files.

Git is actually pretty good at automatically resolving conflicts within files; unless you edit the same lines, it’s easy. If you do edit the same lines, merging is pretty straightforward. This whole conversation the last day or two on HN has been kind of nuts. Like everybody agrees you shouldn’t put all your code in a single file, right? Why not? It would let everyone see all of the source code in one place! But it w…

Sometimes one-line commit could cause merging conflict that requires hours of communications. Or even days in distributed teams.

Re: Software Engineering at Google (2017)

#136

Post by sethammons »

le-mark wrote: post #120
Macha wrote: post #36

Earlier quoted context omitted.

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…

Or find a good company. I've worked hard and gone from mid level (actually slightly lower) to principal over several years at the same, growing company. My responsibilities have drastically changed over time towards greater impact and my pay is nearly 3x from where I started.

Re: Software Engineering at Google (2017)

#137

Post by seanmcdirmid »

sytelus wrote: post #124
gtirloni wrote: post #110

Earlier quoted context omitted.

It's hard to relate without more information about the specific situation. What is the current programming language used? Is the project mostly legacy (few or no changes in the last few years)? Is the project critical to the company? How many people are working on it today? Are they fully assigned to it or is it a "touch when it breaks" kind of situation? Is the project following modern CI/CD practices? If not, how h…

Yes, there are many legitimate reasons to rewrite like dieng frameworks/languages. However we are discussing here the case where reason proposed for the rewrite is solely to satisfy physiological need of some developers to work on code they can call it their own. A lot of things can be done by refactoring but the devs with these issues often just start new projects of their own that does same thing. In companies like…

Do you mean psychological or really physiological? I get the former, the latter seems dubious at best.

Re: Software Engineering at Google (2017)

#138

Post by [deleted] »

sytelus wrote: post #116
casual_slacker wrote: post #114

Earlier quoted context omitted.

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.

[deleted]

Re: Software Engineering at Google (2017)

#139

Post by sethammons »

weavie wrote: post #33
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?

I had this when I worked at a large enterprise several years ago. If I recall correctly we had to state goals for each of 5 major categories and another set of 5 supplementary categories. The categories were things like - deliver customer value, enhance team work, collaborate well across teams and various other enterprise buzz words, I forget exactly.. As a coder, my goal was pretty much to write good code and avoid…

That's unfortunate (and all too common). Goals should be meaningful to you and the company and be few. Achieving them over time should feel good. And reviews should be an opportunity to show off a bit and learn where you can improve a bit.

Re: Software Engineering at Google (2017)

#140

Post by rpod »

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

Hey, I just wanted to say that I really love your gensim library. I've used it for my Master's thesis a couple of years back and it's been a tremendous help. Thanks so much!
Post reply on HN