4 ms·

Do you really think the team that made, say, Google Talk, were the ones who wanted to kill it and push everyone to a different product? I don't know who made ei

Do you really think the team that made, say, Google Talk, were the ones who wanted to kill it and push everyone to a different product? I don't know who made either one, but I would be shocked if the decision maker that pulled the plug had anything to do with the creation of the product. I, personally, don't like to kill my babies. Clawing back bonuses for something out of the control of the engineers seems like a dystopian nightmare, and any company that tried it would, hopefully, die a fiery death after an exodus of talent to more reasonable employers.

humanrebar 8y ago
> I, personally, don't like to kill my babies. I do. Software isn't my progeny or legacy. It is the tools in my workshop. If I can use one tool to do the work of five, I'll gladly downsize to declutter and simply my life. Finding self-worth in the longevity of tools is an emotional anti-pattern.
- deong 8y ago
  I think you're taking him a bit too literally. In these examples, you're not looking at simplifying anything. You're not getting rid of unneeded code. You're getting rid of debugged and stable code in favor of writing something new from scratch because fuck all knows why.
  - humanrebar 8y ago
    In this case, worst case, it's multiple groups of engineers all advocating for their pet projects. They can all be wrong and concerned about personal sunk costs instead of having some perspective and humility and working together to the extent it makes sense. I gather maybe the Google advancement structure discourages doing nothing and generally being stable when it makes sense, in which case there could be plenty of improvement to be had all around.
    - deong 8y ago
      Oddly enough, I assume the Google advancement structure values anything but stability. You launch products to get promoted. Maintaining them is for fools and losers. Granted, I have no inside information. That just fits the externally observable information and the tiny amount of corporate politics that occasionally makes its way public.
- SwellJoe 8y ago
  So, what part of Google's chat strategy fits your description of "downsize to declutter and simplify"? Google has had something like...seven(?) chat and chat-like projects, and each new iteration of "let's kill the most popular chat product we have" seems to result in several new chat-like things, most of which fail and many of which are weirdly complicated and/or confusingly branded/messaged.
  - humanrebar 8y ago
    I was agreeing with your point. It seems pretty obvious that the end goal is something simpler for both the engineer and the end user. The defensiveness of some engineers to protect their particular contributions is a net negative.
    - rhizome 8y ago
      It seems pretty obvious that the end goal is something simpler for both the engineer and the end user. I don't mean to be short, but...based on what evidence?
rhizome 8y ago
Do you really think the team that made, say, Google Talk, were the ones who wanted to kill it and push everyone to a different product? Man, for all the lore and blogging that operates around working at Google, the skills of people who get hired, plus the first-hand accounts of what it takes to move up the ladder there, I'd think they'd be able to release things by people who make their products less killable. Ah, but reality rarely meets the legend. This is my point: what if what gets released by Google is just bad software engineering? Maybe SOLID-deficient. If products are killed because they don't have the features contained in subsequent iterations of the concepts, how come the products were not extensible, or capable of being grafted onto something else? I seem to remember reading about this kind of thing being a big part of software engineering.
- super-serial 8y ago
  I think the acronym Google always misses out on is KISS (Keep it Simple Stupid) because no one there is "stupid." If you only hire geniuses, no one wants to write documentation or do things the boring/easy way that would create more maintainable software. Instead everyone there has to use the latest framework or best practices, then re-engineer things to prove they deserve their top-performer salary. I think the first Google Hangouts was written in Angular 1? Code rot from frameworks like that will ensure the product will die in 5 years at a company like Google. Everyone at Google is a "top-performer" so they want to use the latest development tools and shiny things and no one wants to upgrade/maintain 5 year old code written in an old framework. I think a lot of other companies get around this by hiring less than top performers. Those types of coders will maintain legacy systems because they don't have as much pride. So I think it's mainly a problem that Google has a culture of tech elitism, instead of a culture that focuses on user satisfaction.
  - jeltz 8y ago
    I think you are correct but I want to add that most of the top programmers I have met have had zero issues with doing maintainance work. Just look at many of the big names in open source if you need some examples. I think Google's culture is to blame, but this culture is ptobably created much due to only hiring top performers, rather than other companies who have to do with a mix of skill levels.

humanrebar 8y ago

> I, personally, don't like to kill my babies. I do. Software isn't my progeny or legacy. It is the tools in my workshop. If I can use one tool to do the work of five, I'll gladly downsize to declutter and simply my life. Finding self-worth in the longevity of tools is an emotional anti-pattern.

deong 8y ago
I think you're taking him a bit too literally. In these examples, you're not looking at simplifying anything. You're not getting rid of unneeded code. You're getting rid of debugged and stable code in favor of writing something new from scratch because fuck all knows why.
- humanrebar 8y ago
  In this case, worst case, it's multiple groups of engineers all advocating for their pet projects. They can all be wrong and concerned about personal sunk costs instead of having some perspective and humility and working together to the extent it makes sense. I gather maybe the Google advancement structure discourages doing nothing and generally being stable when it makes sense, in which case there could be plenty of improvement to be had all around.
  - deong 8y ago
    Oddly enough, I assume the Google advancement structure values anything but stability. You launch products to get promoted. Maintaining them is for fools and losers. Granted, I have no inside information. That just fits the externally observable information and the tiny amount of corporate politics that occasionally makes its way public.
SwellJoe 8y ago
So, what part of Google's chat strategy fits your description of "downsize to declutter and simplify"? Google has had something like...seven(?) chat and chat-like projects, and each new iteration of "let's kill the most popular chat product we have" seems to result in several new chat-like things, most of which fail and many of which are weirdly complicated and/or confusingly branded/messaged.
- humanrebar 8y ago
  I was agreeing with your point. It seems pretty obvious that the end goal is something simpler for both the engineer and the end user. The defensiveness of some engineers to protect their particular contributions is a net negative.
  - rhizome 8y ago
    It seems pretty obvious that the end goal is something simpler for both the engineer and the end user. I don't mean to be short, but...based on what evidence?

rhizome 8y ago

Do you really think the team that made, say, Google Talk, were the ones who wanted to kill it and push everyone to a different product? Man, for all the lore and blogging that operates around working at Google, the skills of people who get hired, plus the first-hand accounts of what it takes to move up the ladder there, I'd think they'd be able to release things by people who make their products less killable. Ah, but reality rarely meets the legend. This is my point: what if what gets released by Google is just bad software engineering? Maybe SOLID-deficient. If products are killed because they don't have the features contained in subsequent iterations of the concepts, how come the products were not extensible, or capable of being grafted onto something else? I seem to remember reading about this kind of thing being a big part of software engineering.

super-serial 8y ago
I think the acronym Google always misses out on is KISS (Keep it Simple Stupid) because no one there is "stupid." If you only hire geniuses, no one wants to write documentation or do things the boring/easy way that would create more maintainable software. Instead everyone there has to use the latest framework or best practices, then re-engineer things to prove they deserve their top-performer salary. I think the first Google Hangouts was written in Angular 1? Code rot from frameworks like that will ensure the product will die in 5 years at a company like Google. Everyone at Google is a "top-performer" so they want to use the latest development tools and shiny things and no one wants to upgrade/maintain 5 year old code written in an old framework. I think a lot of other companies get around this by hiring less than top performers. Those types of coders will maintain legacy systems because they don't have as much pride. So I think it's mainly a problem that Google has a culture of tech elitism, instead of a culture that focuses on user satisfaction.
- jeltz 8y ago
  I think you are correct but I want to add that most of the top programmers I have met have had zero issues with doing maintainance work. Just look at many of the big names in open source if you need some examples. I think Google's culture is to blame, but this culture is ptobably created much due to only hiring top performers, rather than other companies who have to do with a mix of skill levels.