6 ms·

I can easily imagine taking pride in maintaining a well-written project doing amazing things. I believe most people unhappy with maintaining someone else's work

I can easily imagine taking pride in maintaining a well-written project doing amazing things. I believe most people unhappy with maintaining someone else's work are dealing with neither, and are furthermore discouraged from doing anything to make it better. Just complete the tickets as quickly as possible, and keep your head low.

dozzie 11y ago
Yes, but you wouldn't know in advance that this codebase you're going to be assigned to is well-written, or that it does amazing things (unless you're in its target users group or know the target industry already). If somebody offered you a job to merely maintain an old, gigantic codebase, I don't think your first thought would be "wow, I'm going to learn so much from this!", and there probably wouldn't be any way you could assess the codebase quality before accepting the offer so you could end up thinking that eventually. This is how things that you want and that could help you grow can be vastly different.
- philipov 11y ago
  I mean, if you're a novice, it should be your first thought. If it isn't, I consider that a failure of education. Jumping into writing something from scratch when you're not part of the target user group or know the target industry already is a great way to produce horrible code that you (or someone else) will hate to maintain. This is why it's so important to grill your interviewers about the reality of working at the company, although I'll admit that I learned which questions to ask from bad experience. Asking those questions also happens to serve as excellent signalling to your technical interviewers, much more effective than being able to solve some silly logic puzzle. And to be perfectly fair, you do learn so much from working on poorly written projects that are a horror to maintain. Failure teaches you which mistakes to avoid next time.
  - jetcata 11y ago
    I'd love to hear which questions you ask in interviews to get this information out of the interviewers!
    - philipov 11y ago
      Ask them the questions you'd want to know answers to if you were hiring them, to determine their own merits. Insist on talking with the people you'll actually be working with. You want to know their opinions on programming paradigms, and design patterns. Ask about operational details like version control, code review, and releases. Ask about the history of the code base, who wrote it, where are they now. Ask how documentation is created. There are so many things you can ask. Good code is surrounded by good processes. Ask about the processes that lead to good code. This not only susses out what the situation is on the ground, but also demonstrates your own quality.
  - distracted828 11y ago
    > failure teaches you which mistakes to avoid next time As a recent grad who has been fired from two jobs, I would be afraid to join a poorly written project because I would worry that I would fail and then be fired. Learning how to be successful is pretty important and teaches you things you cannot learn from lurching from failure to failure.
    - jschwartzi 11y ago
      Even the jobs with poorly-written codebases teach you a lot. Only they're teaching you through experience what is or isn't maintainable.
      - distracted828 11y ago
        Sure, but at a certain point, you need to learn a method to writing a maintainable codebase. Otherwise you never become capable of building a successful project.
    - deleted 11y ago
      [deleted]
    - stuxnet79 11y ago
      How did you fail?
  - JSeymourATL 11y ago
    > I learned which questions to ask from bad experience. Would you mind sharing your best, most probing questions-- the one's that proved most useful cutting through corporate posturing and BS?
ArkyBeagle 11y ago
Maintenance isn't that significantly different from development from scratch. The differences are only in how it's paid for and how you evaluate risks. Development from scratch means much more ... "sales" overhead. Meetings and (ultimately) disposable documentation.

dozzie 11y ago

Yes, but you wouldn't know in advance that this codebase you're going to be assigned to is well-written, or that it does amazing things (unless you're in its target users group or know the target industry already). If somebody offered you a job to merely maintain an old, gigantic codebase, I don't think your first thought would be "wow, I'm going to learn so much from this!", and there probably wouldn't be any way you could assess the codebase quality before accepting the offer so you could end up thinking that eventually. This is how things that you want and that could help you grow can be vastly different.

philipov 11y ago
I mean, if you're a novice, it should be your first thought. If it isn't, I consider that a failure of education. Jumping into writing something from scratch when you're not part of the target user group or know the target industry already is a great way to produce horrible code that you (or someone else) will hate to maintain. This is why it's so important to grill your interviewers about the reality of working at the company, although I'll admit that I learned which questions to ask from bad experience. Asking those questions also happens to serve as excellent signalling to your technical interviewers, much more effective than being able to solve some silly logic puzzle. And to be perfectly fair, you do learn so much from working on poorly written projects that are a horror to maintain. Failure teaches you which mistakes to avoid next time.
- jetcata 11y ago
  I'd love to hear which questions you ask in interviews to get this information out of the interviewers!
  - philipov 11y ago
    Ask them the questions you'd want to know answers to if you were hiring them, to determine their own merits. Insist on talking with the people you'll actually be working with. You want to know their opinions on programming paradigms, and design patterns. Ask about operational details like version control, code review, and releases. Ask about the history of the code base, who wrote it, where are they now. Ask how documentation is created. There are so many things you can ask. Good code is surrounded by good processes. Ask about the processes that lead to good code. This not only susses out what the situation is on the ground, but also demonstrates your own quality.
- distracted828 11y ago
  > failure teaches you which mistakes to avoid next time As a recent grad who has been fired from two jobs, I would be afraid to join a poorly written project because I would worry that I would fail and then be fired. Learning how to be successful is pretty important and teaches you things you cannot learn from lurching from failure to failure.
  - jschwartzi 11y ago
    Even the jobs with poorly-written codebases teach you a lot. Only they're teaching you through experience what is or isn't maintainable.
    - distracted828 11y ago
      Sure, but at a certain point, you need to learn a method to writing a maintainable codebase. Otherwise you never become capable of building a successful project.
  - deleted 11y ago
    [deleted]
  - stuxnet79 11y ago
    How did you fail?
- JSeymourATL 11y ago
  > I learned which questions to ask from bad experience. Would you mind sharing your best, most probing questions-- the one's that proved most useful cutting through corporate posturing and BS?

ArkyBeagle 11y ago

Maintenance isn't that significantly different from development from scratch. The differences are only in how it's paid for and how you evaluate risks. Development from scratch means much more ... "sales" overhead. Meetings and (ultimately) disposable documentation.