Hacker News Reader

Comment by orblivion | Hacker News Reader

The strangest thing is that I love refactoring, and I sort of assume that it's another one of those things that programmers love to do, but managers keep pushing us to limit our time and move on to things that are visible to customers. But now I'm wondering if that's not the case. Or maybe it's just the sort of programmer who loves abstractions and is cast as a "perfectionist".

I'm currently getting my footing now as a contractor. If this is actually something that most programmers don't like to do, is there an angle for me to pitch myself as "The guy who will clean up your code base"?

View on HN

> I'm currently getting my footing now as a contractor. If this is actually something that most programmers don't like to do, is there an angle for me to pitch myself as "The guy who will clean up your code base"?

Absolutely not. Do not go there. If you love the process of software engineering, the art of refactoring, building good abstractions, etc., then you need to have your own code; your own garden to tend. You cannot just parachute into an ailing codebase to "clean it up"; you need to build the mental theory behind it first, which means deeply understanding the problem being solved. If you are able to do this, you may make lots of changes which genuinely improve the code, and you will be hated for it. Because when you leave, nobody is going to understand why you made all those changes, and they're going to think you're some enterprisey architecture astronaut who just made everything more complicated, even if they're wrong. You've just disconnected their mental models from the codebase and then jumped ship, leaving them with something they can no longer maintain. Now instead of bad mental models matching bad code, then have bad mental models completely divorced of this new "good" code. They're worse off. You cannot just "clean up" a codebase -- keeping a clean codebase takes a long time, a lot of background knowledge, and a lot of care.

The best thing you could do would be to improve their own mental models, and guide them in improving their own codebases. But this is a completely different skillset, and I don't know how much money there is there. It requires them to accept your help, which is a big ask.

I have to disagree with other responses. I think you could make a career of this for the same reason management consultants can.

You could swoop in and "fix" some stuff and then leave the in-house team not understanding what you've done. That sounds profitable. You might even get called back to fix things a second time.

As with management consulting, I think it would at the system level tend to do more harm than good, even if you do good work and get paid well for it. I agree strongly with feoren that the code needs to reflect the in-house developers' mental models of the domain or everything will fall apart. If you fix things and then give them a bunch of processes and coding standards to follow, they will not do well and you will be thought of as some clueless architecture astronaut by them. But profitably.

This is totally me. I love refactoring, simplifying and adjusting code to be easier to modify. I almost always refactor before adding features, since I can adjust the code to make my modifications easier to do.

The guy who will clean up your code base isn't a viable role because then the team that works on the code day to day will have to re-learn where everything is. It can work when a company is acquiring new code to refactor during integration, since the refactor catches bugs and makes engineers become familiar with it, but that would be done by people staying with the code base as well.

Probably the closest things to that are test writer, technical documenter and build engineer.

Yeah I don't think being on a team of people doing regular cleanups would really work well. I'm thinking more like "Oh, yeah we've had that code hanging around for a while. We don't really want to touch it because it's kind of a mess and we forgot how it works, but we have to make changes now and again. If someone could clean it up we'd be a lot more efficient".

This would likely not even be a software company as such.

> is there an angle for me to pitch myself as "The guy who will clean up your code base"?

You sort of answer your own question unfortunately.

> managers keep pushing us to limit our time and move on to things that are visible to customers.

So if a manager only values things visible to a customer, why would they hire an expensive consultant work on things that aren't valuable to them?

They don't stop it they just limit it. It's very difficult for them to know the right amount but unless they're totally ignorant they know it's not zero. If the code is a mess it may become apparent to them that they need to increase that threshold for a spurt.

I love refactoring too. It kind of feels like what I imagine editing writing feels like. You've got the rough draft, but also so many lessons learned and can see the big picture now. Much easier to go back and write something cleaner after the fact. I kind of treat all of my code this way.

Contractors are generally paid to solve a problem, and you'll be hard pressed to find an employer that believes tchnical.debt is worth paying boat loads of money for. If this is your angle of interest, I'd look into "legacy modernization", which works in a lot of the same ways as code refactoring with the big difference that you generally also need to shift programming languages and computing platforms . I did a gig 10 years ago and learned enough Cobol to be competent but most of the work was learning the business domain, format shift code, refactor over and over.

I mean yeah that's close enough and something that's crossed my mind as well. I didn't know it had a pithy title like that, I'll look into it. Glad I asked a stupid question and got a smart answer, thank you.

Reply on news.ycombinator.com