3 ms·

Yeah but programmers are generally not bound to a codebase for life. A friend of mine who works at Google says that he generally works on projects in the "do it

Yeah but programmers are generally not bound to a codebase for life. A friend of mine who works at Google says that he generally works on projects in the "do it new and figure out what it needs to do" phase, while there's other engineers at Google who are very good at the maintenance phase and "keeping stuff running and adding slowly to it". I think that's a very nice way of wording it, but I'd definitely want to see myself in the former group, not the latter.

jacquesm 14y ago
> Yeah but programmers are generally not bound to a codebase for life. If you're young I can see how you might have that impression. But I know quite a few programmers personally that have been working on the same codebase for more than a decade, and even a couple that have been working on the same codebase for 3 decades. The web is still young enough that most people that came into programming through building websites have no idea how long most code bases are alive. There is a neat little proverb here: programs are like children, you can start one in an evening but you'll end up supporting it for the rest of your life.
- kami8845 14y ago
  Not arguing against the fact that old codebases exist and that people have to take care of them. However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase.
  - jacquesm 14y ago
    > Not arguing against the fact that old codebases exist and that people have to take care of them. ok > However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. Ok, so we will disagree on that then. I think that both jobs, new stuff and maintaining old stuff are equally rewarding and are essential skills. If all you can do is make new shiny MVPs you'll never run a business. > If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase. You won't be given the choice, unless you keep running away from your creations.
  - breck 14y ago
    The neat thing about old codebases, is that even if the code is messy, the problem it solves can be very interesting. "Legacy codebase" is another word for "important codebase". When you're coding, you solve the most important problems first. Thus, in some sense, the older the code base, the more important the problem it solves.
    - ams6110 14y ago
      And sometimes the code is actually quite good (not saying that's the case in LibreOffice, I have no idea).
      - breck 14y ago
        Agreed. I often stumble across some project written in the 80's and think, "wow, that's so much clearer than my code". We have a lot more tools than programmers did back then, but tools are incapable of long term thinking.
      - chris_wot 14y ago
        From what I can tell, the UNO code is very good. But there is indeed massive technical debt in the codebase.
  - davesims 14y ago
    Heh -- stick around, kid. :) Those shiny new greenfield codebases, so full of promise, perfect architectures and unfettered extensibility, can turn into slow-moving, spaghetti-code Leviathans in a matter of weeks. It's not just the decades-old, massive LOC codbases that provoke this dichotomy: chances are very good that the code you're working on right now, that gorgeous, sleek, sexy code -- will be staring at you with its cold, incomprehensible dead eyes within the year, asking you how, how did it come to this, how did you neglect me so, and why do you hate me now? OK, or maybe not. But it can happen, and it does, all the time, in really good shops with very experienced coders using all the right techniques and best intentions. I know. Dear God, I know. Of course anyone would rather bootstrap new code and feel the thrill of new object models, shiny, hip new libraries breezing through their editors. But until you've experienced both sides of the equation, the long-term consequences of technical debt growing through a codebase like some kind of...virus...you'll not know how important the second-order effects of refactoring, TDD, and truly clean code really are.

jacquesm 14y ago

> Yeah but programmers are generally not bound to a codebase for life. If you're young I can see how you might have that impression. But I know quite a few programmers personally that have been working on the same codebase for more than a decade, and even a couple that have been working on the same codebase for 3 decades. The web is still young enough that most people that came into programming through building websites have no idea how long most code bases are alive. There is a neat little proverb here: programs are like children, you can start one in an evening but you'll end up supporting it for the rest of your life.

kami8845 14y ago
Not arguing against the fact that old codebases exist and that people have to take care of them. However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase.
- jacquesm 14y ago
  > Not arguing against the fact that old codebases exist and that people have to take care of them. ok > However I don't agree with glorifying old codebases or putting them as "equal" to working on new stuff. Ok, so we will disagree on that then. I think that both jobs, new stuff and maintaining old stuff are equally rewarding and are essential skills. If all you can do is make new shiny MVPs you'll never run a business. > If you're happy doing that, then fine, no one's going to stop you from doing it, but I do think that in general, given the choice, almost anyone would pick building something anew over working on a legacy codebase. You won't be given the choice, unless you keep running away from your creations.
- breck 14y ago
  The neat thing about old codebases, is that even if the code is messy, the problem it solves can be very interesting. "Legacy codebase" is another word for "important codebase". When you're coding, you solve the most important problems first. Thus, in some sense, the older the code base, the more important the problem it solves.
  - ams6110 14y ago
    And sometimes the code is actually quite good (not saying that's the case in LibreOffice, I have no idea).
    - breck 14y ago
      Agreed. I often stumble across some project written in the 80's and think, "wow, that's so much clearer than my code". We have a lot more tools than programmers did back then, but tools are incapable of long term thinking.
    - chris_wot 14y ago
      From what I can tell, the UNO code is very good. But there is indeed massive technical debt in the codebase.
- davesims 14y ago
  Heh -- stick around, kid. :) Those shiny new greenfield codebases, so full of promise, perfect architectures and unfettered extensibility, can turn into slow-moving, spaghetti-code Leviathans in a matter of weeks. It's not just the decades-old, massive LOC codbases that provoke this dichotomy: chances are very good that the code you're working on right now, that gorgeous, sleek, sexy code -- will be staring at you with its cold, incomprehensible dead eyes within the year, asking you how, how did it come to this, how did you neglect me so, and why do you hate me now? OK, or maybe not. But it can happen, and it does, all the time, in really good shops with very experienced coders using all the right techniques and best intentions. I know. Dear God, I know. Of course anyone would rather bootstrap new code and feel the thrill of new object models, shiny, hip new libraries breezing through their editors. But until you've experienced both sides of the equation, the long-term consequences of technical debt growing through a codebase like some kind of...virus...you'll not know how important the second-order effects of refactoring, TDD, and truly clean code really are.