7 ms·

I spent a few years as a full time contractor and kind of had a chuckle at this. I worked on a truly awful mess of a codebase. It was the kind of codebase thro

I spent a few years as a full time contractor and kind of had a chuckle at this. I worked on a truly awful mess of a codebase. It was the kind of codebase through which many devs had passed, and many generations of best practices. One part was straight JavaScript. Another had some jquery. Another had backbone.js - the perpetrators were all former full time employees. The product had never launched. I generally worked 8 hours and signed off promptly to work on my own projects. I did quality work. I viewed myself as a hired gun who was paid to do a job. In the end I was at the company longer than any of their actual full time employees (who left because they didn't like working on the crappy code or were stressed because of company politics) and was the only developer left to take the product to launch. Employees and employers often think that contractors are vampires, and many are, but you'll find the good ones are practically immune to whatever skeletons you've got in the closet and will get the job done.

ENTP 9y ago
We share a similar mindset. I actually get a kick working through crappy code as I find reverse-engineering quite exciting, in a kind of "order from chaos" way. Take something crap, make it better, learn something and get paid for it. Ideal!
- ryan-allen 9y ago
  As someone who usually writes the crap stuff that other people get to live with, now I'm on the other end and having to make this "order from chaos". It's one of the most difficult things I've ever done. I just hope I can figure out how to enjoy it, eventually. At this stage the only thing that keeps me going is I'm too proud to feel ineffective and to fail at this, ugh!
  - ENTP 9y ago
    Chin up! Here are some tips: * Reframe the task as a game. A crime to solve if you like. * See it as a series of black boxes that you keep subdividing (You are working top-down right?) * Keep a [cork|black|white]board like they do in the movies with all the suspects and details of the case, with the string linking them (Do this digitally if you like) * It's more important to know the I/O of the boxes/components than how they work, at least initially * Be transparent with your employer about the difficulty. They know it's a mess - that's why you're there. Good luck!
  - jrumbut 9y ago
    Nothing teaches you how your technology of choice really works like taking apart a massive horrendous codebase. You'll be at the next level of expertise soon!
- collyw 9y ago
  I often get more satisfaction from removing code (and keeping / improving the functionality) than I do from writing new code.
zeta0134 9y ago
In rewriting projects, I often find that as I rewrite them, I can knock out requested features along the way. I've taken this approach when fixing up some of my old personal codebases. It's a two birds one stone approach; it takes me just as long to fix code in the old framework as it does to rewrite the code in the new framework without the buggy behavior, so where possible I do that. We had a similar practice in the restaurant world before I found work as a programmer, and we called it "clean as you go." I think it's quite appropriate. The bug reports will always be there, the feature requests mountainous, and yet the messes don't clean themselves. There must be balance. Do what needs to be done, but make a point to improve your codebase with every new change. Prefer consistency over new hotness, and ease of maintenance over unreadable micro-optimizations. Be a positive force in your codebase, and future developers, especially including yourself, will appreciate your efforts.
- richdougherty 9y ago
  I agree with "clean as you go", but I'm very cautious. Rewrites are scary and risky in legacy code. Usually I'll add a few unit tests to increase coverage and de-risk the change I just made.
  - MaulingMonkey 9y ago
    Leaving code as is can also be scary and risky. Being asked to overhaul an existing system on day 1 is scary though. I tend to hold off on rewrites until I can picture the new system - complete with a solid understanding of exactly how it will fix the problems of the old one. And yes, with good tests.
    - zeta0134 9y ago
      Aye, I agree completely. When approaching a given rewrite, I'm very hesitant to go through with it unless I have a strong understanding of all the files I'm about to have to touch to fix the resulting compiler errors. Ideally this should be straightforward, but the tight coupling often observed in poorly maintained codebases can cause the most innocent of small changes to spiral out into the template metaprogramming circle of death. Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.
maxxxxx 9y ago
Maybe I am weird but I like doing stuff like that. I am more of an optimizer than from-scratch-creator so I like having a starting point. Then you just refactor your way through the system while adding new stuff and fixing bugs. I also like debugging and profiling :-(.
- ENTP 9y ago
  Nothing wrong with that! There are more of out there than we think :-)
  - retreatguru 9y ago
    Can i hire you both?!? Seriously, are there many people that relish refactoring? I'd like to meet them. How to find them?
    - collyw 9y ago
      If you have any Django / Python based stuff that needs refactored and are willing to hire remote I would be up for it.
    - jrumbut 9y ago
      Plenty of us out here!
    - maxxxxx 9y ago
      Seems you can find them here :-)
    - BurningFrog 9y ago
      I've been thinking about marketing myself as "Code Janitor", actually :)
    - deleted 9y ago
      [deleted]
    - jpindar 9y ago
      Here! I spent a lot of my early career porting legacy code from one language/platform to another and I liked that well enough. Now I spend more time refining my own code than is really necessary, just because I enjoy it.
pjmlp 9y ago
Yep, the daily work cycle at enterprise consulting.
peteretep 9y ago
The elephant in the room here — and this is no judgement — is that the contractor isn't worrying about creating more technical debt or something that will fall down in a year's time. It's YAGNI taken to an extreme. As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward. I've also been at - more than once - given managerial control of a large codebase driven exclusively by the need to deliver deliver deliver and had to explain to the company why development has become so much slower since they started.
- jdmichal 9y ago
  > As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward. It's one thing to have the domain expertise to accurately anticipate future asks and preemptively prepare for them. But I've seen very few cases of that, compared to projects that were design pattern lasagna. Layer upon layer of abstraction to solve imaginary problems that were never real nor will ever become real. And all those abstractions cost the same as those which actually solve problems. My approach is always to solve the problems you actually have, and no more. This includes abstractions for unit tests; that's an actual problem. (You are putting all those external dependencies behind interfaces for mocking, right?)

ENTP 9y ago

We share a similar mindset. I actually get a kick working through crappy code as I find reverse-engineering quite exciting, in a kind of "order from chaos" way. Take something crap, make it better, learn something and get paid for it. Ideal!

ryan-allen 9y ago
As someone who usually writes the crap stuff that other people get to live with, now I'm on the other end and having to make this "order from chaos". It's one of the most difficult things I've ever done. I just hope I can figure out how to enjoy it, eventually. At this stage the only thing that keeps me going is I'm too proud to feel ineffective and to fail at this, ugh!
- ENTP 9y ago
  Chin up! Here are some tips: * Reframe the task as a game. A crime to solve if you like. * See it as a series of black boxes that you keep subdividing (You are working top-down right?) * Keep a [cork|black|white]board like they do in the movies with all the suspects and details of the case, with the string linking them (Do this digitally if you like) * It's more important to know the I/O of the boxes/components than how they work, at least initially * Be transparent with your employer about the difficulty. They know it's a mess - that's why you're there. Good luck!
- jrumbut 9y ago
  Nothing teaches you how your technology of choice really works like taking apart a massive horrendous codebase. You'll be at the next level of expertise soon!
collyw 9y ago
I often get more satisfaction from removing code (and keeping / improving the functionality) than I do from writing new code.

zeta0134 9y ago

In rewriting projects, I often find that as I rewrite them, I can knock out requested features along the way. I've taken this approach when fixing up some of my old personal codebases. It's a two birds one stone approach; it takes me just as long to fix code in the old framework as it does to rewrite the code in the new framework without the buggy behavior, so where possible I do that. We had a similar practice in the restaurant world before I found work as a programmer, and we called it "clean as you go." I think it's quite appropriate. The bug reports will always be there, the feature requests mountainous, and yet the messes don't clean themselves. There must be balance. Do what needs to be done, but make a point to improve your codebase with every new change. Prefer consistency over new hotness, and ease of maintenance over unreadable micro-optimizations. Be a positive force in your codebase, and future developers, especially including yourself, will appreciate your efforts.

richdougherty 9y ago
I agree with "clean as you go", but I'm very cautious. Rewrites are scary and risky in legacy code. Usually I'll add a few unit tests to increase coverage and de-risk the change I just made.
- MaulingMonkey 9y ago
  Leaving code as is can also be scary and risky. Being asked to overhaul an existing system on day 1 is scary though. I tend to hold off on rewrites until I can picture the new system - complete with a solid understanding of exactly how it will fix the problems of the old one. And yes, with good tests.
  - zeta0134 9y ago
    Aye, I agree completely. When approaching a given rewrite, I'm very hesitant to go through with it unless I have a strong understanding of all the files I'm about to have to touch to fix the resulting compiler errors. Ideally this should be straightforward, but the tight coupling often observed in poorly maintained codebases can cause the most innocent of small changes to spiral out into the template metaprogramming circle of death. Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.

maxxxxx 9y ago

Maybe I am weird but I like doing stuff like that. I am more of an optimizer than from-scratch-creator so I like having a starting point. Then you just refactor your way through the system while adding new stuff and fixing bugs. I also like debugging and profiling :-(.

ENTP 9y ago
Nothing wrong with that! There are more of out there than we think :-)
- retreatguru 9y ago
  Can i hire you both?!? Seriously, are there many people that relish refactoring? I'd like to meet them. How to find them?
  - collyw 9y ago
    If you have any Django / Python based stuff that needs refactored and are willing to hire remote I would be up for it.
  - jrumbut 9y ago
    Plenty of us out here!
  - maxxxxx 9y ago
    Seems you can find them here :-)
  - BurningFrog 9y ago
    I've been thinking about marketing myself as "Code Janitor", actually :)
  - deleted 9y ago
    [deleted]
  - jpindar 9y ago
    Here! I spent a lot of my early career porting legacy code from one language/platform to another and I liked that well enough. Now I spend more time refining my own code than is really necessary, just because I enjoy it.

pjmlp 9y ago

Yep, the daily work cycle at enterprise consulting.

peteretep 9y ago

The elephant in the room here — and this is no judgement — is that the contractor isn't worrying about creating more technical debt or something that will fall down in a year's time. It's YAGNI taken to an extreme. As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward. I've also been at - more than once - given managerial control of a large codebase driven exclusively by the need to deliver deliver deliver and had to explain to the company why development has become so much slower since they started.

jdmichal 9y ago
> As easy it is as a contractor (as I can attest) to make fun of previous implementation spacemen who came before you, they often had the laudable goal of creating something that would be easier and cheaper to work with moving forward. It's one thing to have the domain expertise to accurately anticipate future asks and preemptively prepare for them. But I've seen very few cases of that, compared to projects that were design pattern lasagna. Layer upon layer of abstraction to solve imaginary problems that were never real nor will ever become real. And all those abstractions cost the same as those which actually solve problems. My approach is always to solve the problems you actually have, and no more. This includes abstractions for unit tests; that's an actual problem. (You are putting all those external dependencies behind interfaces for mocking, right?)