4 ms·

I say this a lot, but if you are this irritated by Rails, then you ought to see the 20+ year old legacy C/C++ some of us get to work with ;)

angrygoat 6y ago
I'll see your legacy C/C++ and raise you legacy Fortran 77 :)
- wwright 6y ago
  We needn't fill the young Rubyist's head with nightmares that deep, friend :)
cmrdporcupine 6y ago
This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.
- gen220 6y ago
  This is, IMO, one of the most underrated aspects of the monorepo, that has such a valuable impact over time. It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.
  - randall 6y ago
    Ya, fb feels the same way fwiw. I'm very sold on the benefits of monorepos now.
  - lifeisstillgood 6y ago
    For sanity, sustainability and fairness I would rather that read It only takes a handful of extremely passionate engineers > It only takes a handful of paid engineers, full time assigned to the task
    - gen220 6y ago
      Anecdotally (I don't work at Google, and this might not apply there because it's such a large company): At the monorepo companies I've worked at, of the 2% passionate I mentioned, maybe half have naturally gravitated towards working FT on the infra teams, the other half make very occasional but astronomical contributions, while working full-time on an actual product. What I mean to say is that with a monorepo, you leave the door open to essentially passion-driven contributions made by the other half of that 2%. In non-monorepo environments, the barrier to uniform adoption is too high for someone that isn't full-time assigned to the task to justify. Some people are genuinely passionate about this stuff, and want to take on the task of migrating the entire code base, because it's a fun challenge and it'll improve their day-to-day work every day for the remainder of their employment. They're very rare, but they do exist, and with a monorepo those people are better-equipped to drag the company forward.
      - lifeisstillgood 6y ago
        I don't get this - changing the code is not the problem - this is a political / marketing issue. I have some news - passion is not enough, and there are more than 2% of people working on things they are passionate about - it only 2% get lucky. I can think of a few instances in my recent career at large monorepo company where I have built something on the scale of "passionate, could improve our working lives" One died because ... well I gave up, two are used locally by my team and those I could persuade, whilst other solutions built by others for the same fix have gone on to be blessed officially, (ie replaced by grassroots competition) and one was replaced by a fully mandated and funded project that spotted the need and just steamrollered over all the local fixes. One is still outstanding and I think well worth pushing still. But I don't dream of the big win where suddenly the Board says "why, without your glasses Miss Moneypenny you look ravishing". I get paid, I work, and I try and make the world a bit better where I can. I am passionate about it. But i don't write blog posts about how passionate I am. Maybe I should :-)
- mmargerum 6y ago
  I've got a large codebase i've been maintaining since 1999 that i've continued to evolve and is still in use today . I've been able to steadily improve it without breaking much. IDK maybe its being > 50 but I can appreciate less "dynamic" environments. I do we dev in vue with a go back end but I know the vue part is going to be a rewrite in 5 years. Who wants to keep doing that shit? not this 52 year old guy.
  - cmrdporcupine 6y ago
    Modern refactoring and static analysis tools really make it far easier to keep old code bases up to date. As a hobby thing I'm taking an almost 30 year code base written in C and reworking it into C++17. I've become somehow somewhat adept at this transformation over the years :-)
- pjmlp 6y ago
  Yeah, the problem is that the large majority of the world isn't Google, software isn't their main business, and their codebases are maintained by a continuous rotation of external contractors that are paid by the tickets that they get to implement.
  - cmrdporcupine 6y ago
    Yep, and don't get me wrong. Stray out of the monorepo and into the wilds of various git hosted code bases at Google and you'll find code rotting in the fields, maintained to a far lower standard (IMHO).
rubber_duck 6y ago
I started on C++ back in VS6 days and I wrote tons of it when I was in to game dev and graphics programming - but I would not want to work on those systems and kinds of problems when I can get paid the same to work on higher level stuff - the tooling quality and slow iteration cycle when I'm really stuck on something leads to a lot of stress - I just want low stress dev environment where I focus on solving problems I'm being paid to solve - not problems created by the tools and then having to explain stakeholders why something seemingly simple takes 3x of the estimate. I like environments where I'm confident in my estimates - C# proved to be good in this regard simply because the tooling is there even when I hit a wall and it has a relatively consistent uniformity that makes it easier to navigate unknown territory.
- bigredhdl 6y ago
  I agree. My team is just more productive in C#, so we just stay there as much as possible. As you say, the ability to work on just solving the actual problem is very under valued.
- cmrdporcupine 6y ago
  Funny, after 10 years of Java and other high level languages I was very happy to go work on C++ at a lower level and have been pushing myself lower down the stack as I go. C++ these days is a far more pleasant beast than the VS6 days, the tooling is pretty good and the language can be tamed into a pretty elegant beast with the right coding standards and discipline.

angrygoat 6y ago

I'll see your legacy C/C++ and raise you legacy Fortran 77 :)

wwright 6y ago
We needn't fill the young Rubyist's head with nightmares that deep, friend :)

cmrdporcupine 6y ago

This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.

gen220 6y ago
This is, IMO, one of the most underrated aspects of the monorepo, that has such a valuable impact over time. It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.
- randall 6y ago
  Ya, fb feels the same way fwiw. I'm very sold on the benefits of monorepos now.
- lifeisstillgood 6y ago
  For sanity, sustainability and fairness I would rather that read It only takes a handful of extremely passionate engineers > It only takes a handful of paid engineers, full time assigned to the task
  - gen220 6y ago
    Anecdotally (I don't work at Google, and this might not apply there because it's such a large company): At the monorepo companies I've worked at, of the 2% passionate I mentioned, maybe half have naturally gravitated towards working FT on the infra teams, the other half make very occasional but astronomical contributions, while working full-time on an actual product. What I mean to say is that with a monorepo, you leave the door open to essentially passion-driven contributions made by the other half of that 2%. In non-monorepo environments, the barrier to uniform adoption is too high for someone that isn't full-time assigned to the task to justify. Some people are genuinely passionate about this stuff, and want to take on the task of migrating the entire code base, because it's a fun challenge and it'll improve their day-to-day work every day for the remainder of their employment. They're very rare, but they do exist, and with a monorepo those people are better-equipped to drag the company forward.
    - lifeisstillgood 6y ago
      I don't get this - changing the code is not the problem - this is a political / marketing issue. I have some news - passion is not enough, and there are more than 2% of people working on things they are passionate about - it only 2% get lucky. I can think of a few instances in my recent career at large monorepo company where I have built something on the scale of "passionate, could improve our working lives" One died because ... well I gave up, two are used locally by my team and those I could persuade, whilst other solutions built by others for the same fix have gone on to be blessed officially, (ie replaced by grassroots competition) and one was replaced by a fully mandated and funded project that spotted the need and just steamrollered over all the local fixes. One is still outstanding and I think well worth pushing still. But I don't dream of the big win where suddenly the Board says "why, without your glasses Miss Moneypenny you look ravishing". I get paid, I work, and I try and make the world a bit better where I can. I am passionate about it. But i don't write blog posts about how passionate I am. Maybe I should :-)
mmargerum 6y ago
I've got a large codebase i've been maintaining since 1999 that i've continued to evolve and is still in use today . I've been able to steadily improve it without breaking much. IDK maybe its being > 50 but I can appreciate less "dynamic" environments. I do we dev in vue with a go back end but I know the vue part is going to be a rewrite in 5 years. Who wants to keep doing that shit? not this 52 year old guy.
- cmrdporcupine 6y ago
  Modern refactoring and static analysis tools really make it far easier to keep old code bases up to date. As a hobby thing I'm taking an almost 30 year code base written in C and reworking it into C++17. I've become somehow somewhat adept at this transformation over the years :-)
pjmlp 6y ago
Yeah, the problem is that the large majority of the world isn't Google, software isn't their main business, and their codebases are maintained by a continuous rotation of external contractors that are paid by the tickets that they get to implement.
- cmrdporcupine 6y ago
  Yep, and don't get me wrong. Stray out of the monorepo and into the wilds of various git hosted code bases at Google and you'll find code rotting in the fields, maintained to a far lower standard (IMHO).

rubber_duck 6y ago

I started on C++ back in VS6 days and I wrote tons of it when I was in to game dev and graphics programming - but I would not want to work on those systems and kinds of problems when I can get paid the same to work on higher level stuff - the tooling quality and slow iteration cycle when I'm really stuck on something leads to a lot of stress - I just want low stress dev environment where I focus on solving problems I'm being paid to solve - not problems created by the tools and then having to explain stakeholders why something seemingly simple takes 3x of the estimate. I like environments where I'm confident in my estimates - C# proved to be good in this regard simply because the tooling is there even when I hit a wall and it has a relatively consistent uniformity that makes it easier to navigate unknown territory.

bigredhdl 6y ago
I agree. My team is just more productive in C#, so we just stay there as much as possible. As you say, the ability to work on just solving the actual problem is very under valued.
cmrdporcupine 6y ago
Funny, after 10 years of Java and other high level languages I was very happy to go work on C++ at a lower level and have been pushing myself lower down the stack as I go. C++ these days is a far more pleasant beast than the VS6 days, the tooling is pretty good and the language can be tamed into a pretty elegant beast with the right coding standards and discipline.