8 ms·

I've been on both sides of this issue in the span of my career. I've joined companies with absolutely horrific code, and I've hired people who thought my code w

I've been on both sides of this issue in the span of my career. I've joined companies with absolutely horrific code, and I've hired people who thought my code was shit. My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. Your job at first is simply to understand the code and demonstrate that you are able make improvements to it without breaking everything. Doing so will win you the trust and respect of your teammates, whereas if you come right out of the gate trying to rewrite everything there is a very good chance you will make yourself look like an ass by spending a lot of time and energy introducing bugs into a previously-stable area of the code. Once you have a decent understanding of how and why the code is the way it is, and the trust of your teammates, then you can invest effort into fixing the highest-priority issues with the code. Being able to read and work effectively in legacy code is an essential skill for any software engineer. For now you should just try to focus on fixing bugs and implementing new features, and take pleasure in the fact that you are improving the project and developing a handful of hard and soft professional skills. That being said - there should be a limit to how much bullshit you put up with. If after six months to a year you still find that you hate the job, and a better opportunity comes along, then go ahead and take it.

oaiey 8y ago
> Being able to read and work effectively in legacy code is an essential skill for any software engineer. This is key advise. It makes the difference between a person who enjoys the art of coding and a professional who get paid for work. Basically you have to first proof why the invest of rewriting brings any financial benefit. Till then, be professional and maintain it.
- some_account 8y ago
  Just to offer a different opinion here: I think happiness at work is the most important thing for me personally, and I have no patience for legacy codebases that look like shit. I mean, you are offering good advice for a person that wants to fit in as his highest priority, no doubt about that. But there are people (like me) who don't enjoy working deep down in complicated shitty code to the degree that I don't even want to be a programmer in such environments. There are ways to mitigate this. Join companies that care about clean code and micro services. Work in the cloud. Avoid enterprise. Those advices can be hugely important for someone who just hates those kind of gigs where you feel like you don't want to be there even.
  - Xylakant 8y ago
    I consider the ability to work with legacy codebases an essential skill. If you can’t do that, you’ll be changing jobs like other people change underwear. Any codebase that sees real usage will accumulate cruft, odd behavior and legacy code over time. Dealing with that and assessing what’s worth refactoring and what’s best cut or even just left as it is to reach a business goal is the skill that differentiates a seasoned engineer from a code monkey. That shitty legacy code is often what brings in the money to sustain the company, otherwise it would have been turned off long ago. Microservices don’t help much in that regard: each micro service can look squeaky clean from a code perspective and the whole system can still behave in shitty, unpredictable ways. (Been there, seen that) It’s also not about fitting in: taking on a shitty codebase and transforming it into something better is an outstanding skill and requires constant communication with all stakeholders, especially when you want to cut legacy stuff. It’s certainly not something for people that prefer a quiet corner.
    - mrhappyunhappy 8y ago
      Are you saying you don’t change underwear often? ;)
      - Xylakant 8y ago
        Not every few hours and I’ve seen people quit a job between starting late on the first day and an early lunch break. So literally faster than I usually change my underwear.
        Ultimatt 8y ago
        These people should have asked to see a sample of what they were going to have to work on.
        Xylakant 8y ago
        They didn’t even have a look at the code. Their task would have been to write and maintain end-user documentation and they left before they even had computer and stuff set up. Just never came back from lunch. Said they’d not feel up to the task. I was just a student at that time, so I can’t really say if that was a hiring fuckup or just an odd person. Certainly one of the weirder things to witness in my career.
sriku 8y ago
One way to deal with it is to understand why the mess in the first place. You may find reasons to forgive the mess. If you're looking at a startup that had to try a lot of things perhaps (and when the team was junior) hitting on the workable idea later, maybe they just did what they had to do. The forgivance may also give you the incentive to improve it. A good measure is whether the shitty code does something worthwhile and interesting. Might get you to a point of empathy. Edit: "you" = OP
miry 8y ago
I came to this also. In first months of work is learning process: practices, workflows and processes. Then you should introduce changes via retrospectives. The same solution for outsource companies, that joined to old project. There are no time for such thing as debates which eggs are better. It should be introduce smoothly.
topmonk 8y ago
I agree here, but keep copious notes. I've found mind mapping software, like freemind is good for this. It will help keep you sane. Without that, IMO trying to internalize large amounts of badly written code can negatively affect your brain's ability to come up with good, well written code. All those bad ideas and patterns become the first things that pop into your mind when you try and solve problems. “When you stare into the void, the void stares back into you” sort of thing...
- Hates_ 8y ago
  Do you have any example of how you use mind mapping. I've tried a few times to use it but have yet to find a good way to layout my notes/thoughts in a map.
  - topmonk 8y ago
    I don't have any hard and fast rules, but if it is a big complicated project I don't usually try and come up with a single coherent diagram of my thoughts. Instead, I start out with a node for the date, and a child node for a subject, and child node of that with a sentence or two concerning a topic I'm working on. If there are more details to it, problems, questions, etc. they become sub-nodes of that, and so on. I don't usually change the details of nodes that I already worked on, but rather write what has changed in a new node with the same name but under a later date node. I find that it becomes a mess if I try and keep every node updated to what I currently think about it, because too much information builds up to efficiently do so. Also, a lot of what I write only make sense in the context of what I wrote on other subjects during the same time period, so if I change one, I end up having to rewrite more and more, which eventually becomes a big mess. The main benefit is that I can go through my notes quickly, skipping minutia of topics I'm not interested in simply by not reading the details of a node. I used to use a text file, and that was a very big problem, because not only would the amount of text that I'd have to go through became daunting. Also, I sometimes found it hard to interpret what I wrote, which means I wouldn't know if it applied to the problem I was working on or not. However, in contrast to the above, I do try and make a definitive structure if it's a small topic or a quick idea for a new project or something simple like vacation plans. BTW, it also works very well for taking notes for a class or self-study.
LandR 8y ago
>> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers. SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. So get through your probation period then you can maybe start making noises.
- zorked 8y ago
  > SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. It's very easy to criticize, often not easy to understand the situation where the bad code was written. Maybe the hastily-written code was the thing that saved a company from bankruptcy and was written by dedicated engineers, and bringing your friend to fix it was the plan all along, and what they needed was someone to fix the code and not decry everybody as stupid. [I'm not saying this is what actually happened to your friend. I don't know your friend :)]
  - Aaargh20318 8y ago
    > It's very easy to criticize, often not easy to understand the situation where the bad code was written. A lot of people seem to think that criticism of the code is the same as criticism of the person who wrote the code. They are not the same thing. Root knows I've written plenty of crappy code over the years for very valid reasons. You are not your code, saying the code sucks doesn't mean I think you suck.
    - deleted 8y ago
      [deleted]
    - laughingpine 8y ago
      > You are not your code, saying the code sucks doesn't mean I think you suck. Some people take _any_ criticism of their code personally regardless of how constructive you are being. I have had a person completely blow up at me for simply asking (literally a question - a valid question) "why did you choose to use a BindingList instead of a List?" Maybe it was how I phrased it? People are tough to get sometimes.
cooervo 8y ago
excellent advice.
eyezick 8y ago
To add on to this, you can still improve the code quality while building on it by adding tests as you go, so you can have some solace and also sanity when testing your own code.
jfroma 8y ago
Excellent advice, I agree 100% with this. Also I want to add that allocating time for a refactoring or fixing legacy code is hard to justify most of the time. Instead I try to follow the "boy scout rule": On every bug fix or new feature you work on "Leave Things BETTER than you found them". An small change like properly naming a class or a variable, or just writing a readme file explaining something will help you and your team in the future. https://medium.com/@biratkirat/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385 https://medium.com/@biratkirat/step-8-the-boy-scout-rule-rob...
- albumdropped 8y ago
  +1
vatotemking 8y ago
> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. Even if I didnt do anything, the code keeps breaking!
TheGrumpyBrit 8y ago
In the meantime, use an issue tracker to keep a handle on all the stuff you actually need to do to bring this code up to speed. If a test needs creating, add an issue for it. I'd personally not keep this in a tracker that your manager uses to track metrics, but keep it separate and build it up. If it's really a rewrite job, you'll end up with a lot of entries in there of varying size and complexity. You can start moving those issues across to whatever issue tracker your boss does keep an eye on as you get to them. That way, you're not just walking in, announcing that the entire lot is garbage, and wasting time rewriting it all (which is what the business will think you're doing if the current implementation is at least vaguely functional), but you're gaining familiarity with the code and compiling a decent sized todo list that you can present at the appropriate time, as well as a list of fairly quick wins that you can get done when you have some downtime.
curun1r 8y ago
That 6 months is also a great opportunity to establish a test suite. It's dangerous to tell management that the code is bad. It's not dangerous to say that it needs tests, since that's an industry best practice and there are objectively no tests, and that you believe that a certain amount of your time needs to be devoted to paying back some of that testing debt. Then, when 6 months rolls around, you either have the confidence to do a major refactor/rewrite or leave and give the person who comes after you the test suite necessary to do the next step. Plus, to my mind, there's no better way to start understanding a new codebase than to start with tests, either writing them or reading the existing suite.
sandos 8y ago
I would add to this by adding tests gradually during this time. If there is no understanding from management that this is needed, do it guerilla style and do it anyway, maybe at a smaller scale. In my mind, unit tests is not what you want to start with with a messy legacy codebase. It takes a huge amount of effort testing lots of already working code. Add unit tests for any new code, but try and implement tests for the entire system, functional/integration tests are also easier to argue for in terms for direct benefit for the customer. Unit tests are more for the developer and is harder to argue for. Adding tests makes it easier to confidently refactor the code later on.
- afx 8y ago
  Any practical suggestions on how to bootstrap testing (unit and/or UI) for an existing project that has never seen any? Or any recommended resources I could read up on?
  - epicide 8y ago
    Particular resources and guides are gonna depend heavily on language/frameworks/etc. Start with areas that are the most valuable to the business. Not only does this more easily show the (business) value of testing, but it helps keep you from introducing a very visible and very bad looking regression. Anything dealing with money (especially billing) is probably a good indicator. Be warned, here be dragons. That being said, don't verify your testing setup with business critical tests. Verify your setup (to yourself and other devs) with the quickest thing you can accomplish. The business critical ones are your (team's) short term goal. Pick out the X most important logic paths (e.g. customer checkout or some subsection of that). Work on regression testing that over the next few months. Make sure your tests are both automated and actually get run. The latter is more important than the former. Ideally, your tests will prevent a nasty bug from going in and will immediately prove the business value of your testing efforts. This will establish the trust you need to continue testing and refactoring.
  - _drFaust 8y ago
    Hmm.. it's definitely tough to begin on a codebase with 0% coverage. The first step is to stop the bleeding so begin adding unit tests for any new code you write and be sure to factor this effort in with your sprint estimations. In parallel work top down with high level integration tests written against feature flows. E.g., As a user when I select this then I expect this. This doesn't mean you need to actually use BDD gherkin library for your test runner but at least frame the context of these in that regard since you don't care about the minute details of the underlying code, just the experience of the user story. And lastly, don't just write tests to write tests, try to understand what is important to cover against because there is nothing worse than maintaining barely useful tests wired up to legacy data fixtures.

oaiey 8y ago

> Being able to read and work effectively in legacy code is an essential skill for any software engineer. This is key advise. It makes the difference between a person who enjoys the art of coding and a professional who get paid for work. Basically you have to first proof why the invest of rewriting brings any financial benefit. Till then, be professional and maintain it.

some_account 8y ago
Just to offer a different opinion here: I think happiness at work is the most important thing for me personally, and I have no patience for legacy codebases that look like shit. I mean, you are offering good advice for a person that wants to fit in as his highest priority, no doubt about that. But there are people (like me) who don't enjoy working deep down in complicated shitty code to the degree that I don't even want to be a programmer in such environments. There are ways to mitigate this. Join companies that care about clean code and micro services. Work in the cloud. Avoid enterprise. Those advices can be hugely important for someone who just hates those kind of gigs where you feel like you don't want to be there even.
- Xylakant 8y ago
  I consider the ability to work with legacy codebases an essential skill. If you can’t do that, you’ll be changing jobs like other people change underwear. Any codebase that sees real usage will accumulate cruft, odd behavior and legacy code over time. Dealing with that and assessing what’s worth refactoring and what’s best cut or even just left as it is to reach a business goal is the skill that differentiates a seasoned engineer from a code monkey. That shitty legacy code is often what brings in the money to sustain the company, otherwise it would have been turned off long ago. Microservices don’t help much in that regard: each micro service can look squeaky clean from a code perspective and the whole system can still behave in shitty, unpredictable ways. (Been there, seen that) It’s also not about fitting in: taking on a shitty codebase and transforming it into something better is an outstanding skill and requires constant communication with all stakeholders, especially when you want to cut legacy stuff. It’s certainly not something for people that prefer a quiet corner.
  - mrhappyunhappy 8y ago
    Are you saying you don’t change underwear often? ;)
    - Xylakant 8y ago
      Not every few hours and I’ve seen people quit a job between starting late on the first day and an early lunch break. So literally faster than I usually change my underwear.
      - Ultimatt 8y ago
        These people should have asked to see a sample of what they were going to have to work on.
        Xylakant 8y ago
        They didn’t even have a look at the code. Their task would have been to write and maintain end-user documentation and they left before they even had computer and stuff set up. Just never came back from lunch. Said they’d not feel up to the task. I was just a student at that time, so I can’t really say if that was a hiring fuckup or just an odd person. Certainly one of the weirder things to witness in my career.

sriku 8y ago

One way to deal with it is to understand why the mess in the first place. You may find reasons to forgive the mess. If you're looking at a startup that had to try a lot of things perhaps (and when the team was junior) hitting on the workable idea later, maybe they just did what they had to do. The forgivance may also give you the incentive to improve it. A good measure is whether the shitty code does something worthwhile and interesting. Might get you to a point of empathy. Edit: "you" = OP

miry 8y ago

I came to this also. In first months of work is learning process: practices, workflows and processes. Then you should introduce changes via retrospectives. The same solution for outsource companies, that joined to old project. There are no time for such thing as debates which eggs are better. It should be introduce smoothly.

topmonk 8y ago

I agree here, but keep copious notes. I've found mind mapping software, like freemind is good for this. It will help keep you sane. Without that, IMO trying to internalize large amounts of badly written code can negatively affect your brain's ability to come up with good, well written code. All those bad ideas and patterns become the first things that pop into your mind when you try and solve problems. “When you stare into the void, the void stares back into you” sort of thing...

Hates_ 8y ago
Do you have any example of how you use mind mapping. I've tried a few times to use it but have yet to find a good way to layout my notes/thoughts in a map.
- topmonk 8y ago
  I don't have any hard and fast rules, but if it is a big complicated project I don't usually try and come up with a single coherent diagram of my thoughts. Instead, I start out with a node for the date, and a child node for a subject, and child node of that with a sentence or two concerning a topic I'm working on. If there are more details to it, problems, questions, etc. they become sub-nodes of that, and so on. I don't usually change the details of nodes that I already worked on, but rather write what has changed in a new node with the same name but under a later date node. I find that it becomes a mess if I try and keep every node updated to what I currently think about it, because too much information builds up to efficiently do so. Also, a lot of what I write only make sense in the context of what I wrote on other subjects during the same time period, so if I change one, I end up having to rewrite more and more, which eventually becomes a big mess. The main benefit is that I can go through my notes quickly, skipping minutia of topics I'm not interested in simply by not reading the details of a node. I used to use a text file, and that was a very big problem, because not only would the amount of text that I'd have to go through became daunting. Also, I sometimes found it hard to interpret what I wrote, which means I wouldn't know if it applied to the problem I was working on or not. However, in contrast to the above, I do try and make a definitive structure if it's a small topic or a quick idea for a new project or something simple like vacation plans. BTW, it also works very well for taking notes for a class or self-study.

LandR 8y ago

>> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers. SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. So get through your probation period then you can maybe start making noises.

zorked 8y ago
> SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. It's very easy to criticize, often not easy to understand the situation where the bad code was written. Maybe the hastily-written code was the thing that saved a company from bankruptcy and was written by dedicated engineers, and bringing your friend to fix it was the plan all along, and what they needed was someone to fix the code and not decry everybody as stupid. [I'm not saying this is what actually happened to your friend. I don't know your friend :)]
- Aaargh20318 8y ago
  > It's very easy to criticize, often not easy to understand the situation where the bad code was written. A lot of people seem to think that criticism of the code is the same as criticism of the person who wrote the code. They are not the same thing. Root knows I've written plenty of crappy code over the years for very valid reasons. You are not your code, saying the code sucks doesn't mean I think you suck.
  - deleted 8y ago
    [deleted]
  - laughingpine 8y ago
    > You are not your code, saying the code sucks doesn't mean I think you suck. Some people take _any_ criticism of their code personally regardless of how constructive you are being. I have had a person completely blow up at me for simply asking (literally a question - a valid question) "why did you choose to use a BindingList instead of a List?" Maybe it was how I phrased it? People are tough to get sometimes.

cooervo 8y ago

excellent advice.

eyezick 8y ago

To add on to this, you can still improve the code quality while building on it by adding tests as you go, so you can have some solace and also sanity when testing your own code.

jfroma 8y ago

Excellent advice, I agree 100% with this. Also I want to add that allocating time for a refactoring or fixing legacy code is hard to justify most of the time. Instead I try to follow the "boy scout rule": On every bug fix or new feature you work on "Leave Things BETTER than you found them". An small change like properly naming a class or a variable, or just writing a readme file explaining something will help you and your team in the future. https://medium.com/@biratkirat/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385 https://medium.com/@biratkirat/step-8-the-boy-scout-rule-rob...

albumdropped 8y ago
+1

vatotemking 8y ago

> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. Even if I didnt do anything, the code keeps breaking!

TheGrumpyBrit 8y ago

In the meantime, use an issue tracker to keep a handle on all the stuff you actually need to do to bring this code up to speed. If a test needs creating, add an issue for it. I'd personally not keep this in a tracker that your manager uses to track metrics, but keep it separate and build it up. If it's really a rewrite job, you'll end up with a lot of entries in there of varying size and complexity. You can start moving those issues across to whatever issue tracker your boss does keep an eye on as you get to them. That way, you're not just walking in, announcing that the entire lot is garbage, and wasting time rewriting it all (which is what the business will think you're doing if the current implementation is at least vaguely functional), but you're gaining familiarity with the code and compiling a decent sized todo list that you can present at the appropriate time, as well as a list of fairly quick wins that you can get done when you have some downtime.

curun1r 8y ago

That 6 months is also a great opportunity to establish a test suite. It's dangerous to tell management that the code is bad. It's not dangerous to say that it needs tests, since that's an industry best practice and there are objectively no tests, and that you believe that a certain amount of your time needs to be devoted to paying back some of that testing debt. Then, when 6 months rolls around, you either have the confidence to do a major refactor/rewrite or leave and give the person who comes after you the test suite necessary to do the next step. Plus, to my mind, there's no better way to start understanding a new codebase than to start with tests, either writing them or reading the existing suite.

sandos 8y ago

I would add to this by adding tests gradually during this time. If there is no understanding from management that this is needed, do it guerilla style and do it anyway, maybe at a smaller scale. In my mind, unit tests is not what you want to start with with a messy legacy codebase. It takes a huge amount of effort testing lots of already working code. Add unit tests for any new code, but try and implement tests for the entire system, functional/integration tests are also easier to argue for in terms for direct benefit for the customer. Unit tests are more for the developer and is harder to argue for. Adding tests makes it easier to confidently refactor the code later on.

afx 8y ago
Any practical suggestions on how to bootstrap testing (unit and/or UI) for an existing project that has never seen any? Or any recommended resources I could read up on?
- epicide 8y ago
  Particular resources and guides are gonna depend heavily on language/frameworks/etc. Start with areas that are the most valuable to the business. Not only does this more easily show the (business) value of testing, but it helps keep you from introducing a very visible and very bad looking regression. Anything dealing with money (especially billing) is probably a good indicator. Be warned, here be dragons. That being said, don't verify your testing setup with business critical tests. Verify your setup (to yourself and other devs) with the quickest thing you can accomplish. The business critical ones are your (team's) short term goal. Pick out the X most important logic paths (e.g. customer checkout or some subsection of that). Work on regression testing that over the next few months. Make sure your tests are both automated and actually get run. The latter is more important than the former. Ideally, your tests will prevent a nasty bug from going in and will immediately prove the business value of your testing efforts. This will establish the trust you need to continue testing and refactoring.
- _drFaust 8y ago
  Hmm.. it's definitely tough to begin on a codebase with 0% coverage. The first step is to stop the bleeding so begin adding unit tests for any new code you write and be sure to factor this effort in with your sprint estimations. In parallel work top down with high level integration tests written against feature flows. E.g., As a user when I select this then I expect this. This doesn't mean you need to actually use BDD gherkin library for your test runner but at least frame the context of these in that regard since you don't care about the minute details of the underlying code, just the experience of the user story. And lastly, don't just write tests to write tests, try to understand what is important to cover against because there is nothing worse than maintaining barely useful tests wired up to legacy data fixtures.