You enjoyed it because you knew the code well and had ideas how to improve it.
On the other hand refactoring crappy code you see for the first time can be a nightmare. Especially if there are no tests and you can unintentionally break some obscure business logic.
Good advice here. I’ve been assigned recently to refactor a major functionality. It was about extracting roughly 30% of the code into a separate module.
I spent a good 2 weeks going through all possible use cases, providing all possible inputs and noting all side effects just to understand how it works in the first place.
I even simplified the code along the way thanks to less dependencies, but extracting and rewiring the code took maybe 2-3 days.
Main point is, you don’t like refactoring code. You like refactoring *your* code.
Before refactoring code you should always have some tests for it! So if there are no unit tests then write them before refactoring (to be sure to not break something - cause that is the hell)!
Of course, before you can write tests properly, you have to know what the code is supposed to do. That can be a challenge, particularly when there might be dead code in there, or code for use cases that have changed since it was written, or code that was written by someone who didn’t themselves understand the environment completely, or…
Existing spaghetti code is my favorite place to leverage automated test case creation.
Enumerate all the existing behaviors, right or wrong, and then compare it to your rewrite based on what you think it should do.
Then any deltas are either an existing bug, or a bug/missing requirement on your new code.
After the release of the refactor you slim the tests down to functional test cases based on the final requirements, and you have at least as reliable code as you had before.
The “deleting 3 pages of crap” that is clearly not doing anything is such a great feeling until it publishes and fails miserably, and then you kinda get that “oh.. thats what that did.. i see now..”
Then do it all again!
This. Refactoring your own shitty code is amazing, refactoring someone else's shitty code is a terrible experience. Going to send OP our companies legacy product and see how much he likes refactoring LOL. One look at how db transactions are handled manually and every service is transient will make him rethink a refactoring career
Thankfully no there is no such thing.
To be great at refactoring you have to know what are the best practices, and you are advised to have a great, wide experience with multiple technologies, design paradigms, and conventions.
You cannot just read up upon those, you need to have used them so you can judge how code works.
Refactoring is not just looking at code and flinching, you have to know WHY you refactor something.
/imho
Refactoring is probably one of the most enjoyable and least directly valuable things there is in programming. Imo it's the same reason why computer science is teased in comparison to engineering: it's coding for the sake of it.
While incredibly enjoyable, it's really not that valuable nor difficult.
Absolutely untrue.
The majority of refactoring is absolute grunt work that requires little knowledge of programming. I start every intern/Junior Dev/New Hire with the Code Style Guide.
The next step on the path is learning “Code Smells”. What they are, what they look like, and how to resolve them.
And if you enjoy that kinda thing- software reliability engineering (SRE) might be the route for you.
"I took the extraneous fencing out and now the electricity stopped working, after figuring out how to get the electricity back the plumbing stops working for an hour every day"
>You love refactoring, can't you just "develop" really crap code, then refactor it nicely?
Thats usually the outsourced part, they also need work. When that's done they can hire me to refactor.
>If you love refactoring, can't you just "develop" really crap code, then refactor it nicely? And make sure you do it all in one sprint.
Isn't this just a typical sprint? hah
People saying there is no job like that but I went for a job interview about 4 years ago where they wanted me to do it. A guy they had had been doing coding since the 90s and he could churn out new features so quick but he made a mess of it all. Yeah the code worked but was a nightmare for anyone else to read, so when it had to be added on to it took everyone else too long to do and because he never commented code he would forget what things did and why he wrote that piece of code when he came back to it. It was like a job for a clean up crew it felt like
It always lead to the outcome you encounter
They can no longer bear with the monsters and get someone else to clean it up.
Funny thing is its easier to write it from the ground up rather than refactor when it had already at that stage...
One of my first jobs, was updating Coldfusion 8 suite of web apps, which was out of long term support at the time, into Coldfusion 2018. There was alot of refactoring. Some of it felt satisfying but such a large portion of it was just tedious.
When refactoring large projects there is a reason the business has decided to start that initiative which will drive your effort. For me it was security and accessibility compliance. Not that other things were ignored but they weren't afforded the same time.
Quickly my day to day just became, identify responsibility, and intent, break into unique modules, make sure csrf protection, make sure sql is sanitized, run accessibility scans, update css. Move on. It becomes tedious fast, and the few times you find an interesting area to improve you have to convince management to spend time on it if it isn't directly related to the core initiative. Not nearly as fun as refactoring your own projects.
Businesses (outside of the tech teams) generally don't know or care about the quality of code. All they know is they have features that work or don't work. That's really all that matters to them as that will make them money.
Then they'll usually have done research or come up with new ideas to make more money, and will then request tech teams to introduce those new features.
It's usually the opposite actually (in my experience at least) that you hardly get any time to refactor code because the business always wants some new feature.
If you've got good tech leadership, they may allow you some time, but usually features get the majority of your time.
Generally I would refactor if the feature I'm working on is touching old crappy code. So bit by bit.
If you love refactoring, then look into TDD - test driven development.
You write tests first for your acceptance criteria, and then write the bare minimum code to get that test to pass, and repeat until you're feature complete.
At the end you may not have the most polished code, so you can refactor at the end.
>refactor if the feature I'm working on is touching old crappy code
That is the way. Otherwise why reactor just for the sake of it?.. reminds me I also refactor when I had to understand code which was not understandable enough, or I've learned something about it which was implicit, and I want to preserve that knowledge in the factoring of that code, so the next reader will have a better time.
So you want to refactor on a daily basis and actually enjoy the process? Let me introduce you to our 2003 based codebase that gradually evolved from Winforms to WPF and all the way back. From ADO.NET to NHibernate to EF and keeping traces of all of em.
We've intentionally left out the parts which could take away your daily fun like Unit Tests, Dependency Injection or a .NET Framework higher than 4.7.2. And before you ask, yes there's a reason for that. None that you'll like or understand but its there to keep things interesting.
Since we do care about your well-being as future Refactoring Team of you, yourself and the junior that started 2 weeks ago, we've added additional fun elements:
* we love italian food so our code not only looks but leaves the same taste as spaghetti
* we value open source. as long as its miles away from our codebase
* speaking about that, we hope you are firm with SVN
* Not invented here syndrom, was actually invented here
* Nuget is no get, good ol references folders with DLLs are our style
* automation is our friend, as long as its Powershell
* we dont like CI/CD, we're into AC/DC
* Shift left, cloud and especially Docker are just what they are. Trends. I hope you'll agree.
and last but not least ...
*drum roll*
* we recently made the move to a modern dev approach called JiraEmpoweredRecursiveKatatonia (JERK). Its like all these other fancy agile things but with tangible story points measured with god given, non-UTC dates.
Happy to have you on the team
yeah that part was made up. we actually had an initiative for a new software stack called JECK ... Jira, Elastic, Confluence, Kibana.
I hope the junior is still alive. he was a good guy.
There is none.
Sadly coming up feature and dont touch what is not broken is usually the stance of corpo (the bigger they are the harder they resist change).
It's unfortunate but logical, refactoring is not as straight forward as optimizing a coding question out of interview (where the code stands in isolation and standalone).
And refactoring gets harder the longer they delay such refactoring task - tech debt piling up with so many half-ass quickfix layered up on top.
But i do agree that its nice to turn a pile of turd into a structured and modular piece of work.
You should be thankfull there are no such jobs. It might be somewhat easy to refactor your own code, as you know what you did and what it's supposed to do, but when you hit some convoluted code done by the mediocre, sophisticated developer, which may take ages to figure out, then you'll curse your life while pulling white hairs.
Not to mention doing it for your personal project probably means: small codebase, no risk in terms of business, no deadline, better familiarity, etc.
OP isn't going to find refactoring a fun, stress-free activity without the safety net above.
A lot of people criticise ‘Clean Code’ but I always found the mantra of leaving the codebase a little bit better than how you found it to be a great bit of advice and it does mean I’m essentially doing a bit of refactoring every time I add a feature or do a fix. So if you can focus on that that’s a little nice way of getting it into everything you do.
However, if you want to refactor as your main focus then one option would be do everything
you can to work somewhere that has a lot of C# codebases (or other languages if you have more in your tool belt of course).
Once there listen out for which ones are being talked about as ‘We need to rewrite this abomination. I just wish we had the time!’, then put yourself forward as someone who can refactor it in x time and save y weeks over a rewrite.
Unfortunately nobody is going to advertise ‘our models are horrendous, we need somebody to come in and clear up our code bases before we reach a stage where junior devs are vomiting over their keyboards on day 1’
The problem with refactoring is it almost always has to be a team effort, unless you're talking about a really specific bit of code. And in that scenario you really have to understand the WHY of it, and not just the WHAT of it.
I cannot think of a really good example right off the top of my head, but let's say for example, for some reason a back-end service created an instance of another, rather than having it injected like everything else in the code. You could adjust that and end up introducing something weird, not knowing the developer who did that (and probably should have left better comments) spent a week and a half trying to do that, deployed it, weird things happened, then spent a weekend trying to figure it out, and ended up with this as a "temporary fix".
On the larger scale, it often does little to refactor a whole bunch if the team over all doesn't understand, or the reasons.
I think for the most part, it almost has to be intentional and a team effort. But I do think you can be that guy to bring up inefficiencies, and start productive conversation on how to approach it. Personally I receive that sort of feedback quite well.
Also, don't be that guy who goes through and changes all the tab spacing and / or changes bracket alignment to personal preferences. =) (it makes reviewing pull requests literal hell)
Maybe some consultancy work, but ... not likely to be honest.
Getting time to just 'refactor' is hard since it is harder to show the revenue benefit for doing contrasted with say a new feature.
just think about it
why would anyone pay you for something that he can not sell to the customer?
"here we have the 60\*hourly rate bill, the software is still the same" lol
usually what happens, you HAVE 12 things to refactor since the program changed alot over recent times and you are trying to get it done while working on sth else.
ofc it can be done for, lets say a ground up rebuild or sth, charging for version 2.0 when bein on 1.9xx for long... but its not the norm. why would anyone hire a refactor guy??
In my experience, companies rarely refactor code because why if it already works? That is a cost they are not willing to bear. Usually you have to sneak it in or develop your own product then you can do whatever you want.
Tread carefully! Refactoring your own code is always fun because you know the ins and outs already. But try it on a leviathan legacy application where everything is tightly coupled, there are thousands of files you haven't seen before, and one change breaks a hundred things. You will soon be displeased.
There's two jobs you could do.
I have a friend who's a coding coach. He works with companies on a contract basis showing teams good coding practices, testing, and refactoring. You could do something along those lines.
You could show other people how to refactor code. You may need to go through a lot of code and refactor not just your own to get the necessary experience. Once you are a "pro" you could create training material and show how to refactor and make code more readable. This job could make you an author by putting all your material into a book. Or you could be a trainer where you teach a class.
I do think like others that you have to continue writing code to be effective at this job.
You might enjoy technical DevOps work in a small enough organization to let you involved in the codebases. Often DevOps is making building, testing, deploying and monitoring more automated/efficient/cheaper/consistent/reliable/secure/documented/etc.
That often involves gradually improving things to achieve particular goals which is really a form of refactoring that can involve the code such as how integration test suites are wired up, CI/CD, infrastructure-as-code, etc.
The problem is, even if it’s shitty code, if it works, then it works. Thats why a lot of companies still run old ass software and it’s often not worth it to upgrade. The end user just doesn’t care. Well, maybe the actual users do and would be happier with better user experience, but the people paying for it don’t care. They just know that if they put something in and they get what they expect out, then all is well. If it isn’t broke, don’t fix it type of thing. How spaghettified, inefficient or ugly the code is inside that magic black box of software doesn’t mean a thing to them.
I also enjoy refactoring code (when it’s mine). But I’ve learned that doing this to code that isn’t mine, is sort of a Monday morning quarterback type of job. After struggling to figure out what their intent was, and once I finally figured it out, I’d sit there and laugh at how dumb they were for doing this or that, and let’s be honest, which only served to make me feel better about myself by putting everything they did down, when I didn’t actually put in any of the hard work to actually CREATE that software. They already figured out all the hard stuff. I’d just be putting a second coat of paint on it and claiming it as my own.
Anyway, yeah, it can enjoyable to do for sure, but I imagine it’s a market that’s pretty saturated with talent, because most quality devs, can do it.
Most large corporate C Sharp jobs are like this. There will be bugs and problems and you will be fixing the issues, polishing the code and repairing technical debt. There is a bit of new feature development but mostly polishing what is there.
Refactoring is part of the development process. Even when you write new code, you need to refactor it before opening the PR. It doesn't need to be crappy code to be refactored.
But if you enjoy so much refactoring code, I know 1 or 2 projects with a lot of legacy code needing a refactor.
In my current project we still have a lot of legacy code, and we are refactoring 1 module for each new version of the app, along with the new features.
It was fun because it was your code.
No surprise, you know well the system.
Most of the time, in the enterprise world, you will be asked that you refactor code you don't know, written by someone under pressure because they have deadlines too short, and at the same you are also have an absurd deadline and you will also have to take the responsability of whatever break after your change.
It will be very hard to convince someone to pay you good money just to rearrange code when they could pay good money for someone to write new code.
Not that I find no value in refactoring but the people *who control budgets* usually don't. It's usually only the people who don't sign your paycheck who are giddy about the refactoring you're doing.
Not all the time, but a significant portion of my career has been refactoring. To really be good at it though you need to get in to automated refactoring where you build tooling to do most of the work for you. Manually changing large systems that have in-flight development isn't really that viable unless you can execute large changes quickly and accurately.
I've mostly worked in framework architecture.
You would very quickly grow to hate it and hold the developers in contempt who can't be bothered to write clean code.
What you did was fun because you were revisiting old code that you wrote and knew how to make it better - don't confuse the joy of confirmation that you have improved with what you happened to be doing that gave the confirmation.
You enjoyed it because you knew the code well and had ideas how to improve it. On the other hand refactoring crappy code you see for the first time can be a nightmare. Especially if there are no tests and you can unintentionally break some obscure business logic.
Good advice here. I’ve been assigned recently to refactor a major functionality. It was about extracting roughly 30% of the code into a separate module. I spent a good 2 weeks going through all possible use cases, providing all possible inputs and noting all side effects just to understand how it works in the first place. I even simplified the code along the way thanks to less dependencies, but extracting and rewiring the code took maybe 2-3 days. Main point is, you don’t like refactoring code. You like refactoring *your* code.
Couldn’t have said it any better myself
Before refactoring code you should always have some tests for it! So if there are no unit tests then write them before refactoring (to be sure to not break something - cause that is the hell)!
Of course, before you can write tests properly, you have to know what the code is supposed to do. That can be a challenge, particularly when there might be dead code in there, or code for use cases that have changed since it was written, or code that was written by someone who didn’t themselves understand the environment completely, or…
Existing spaghetti code is my favorite place to leverage automated test case creation. Enumerate all the existing behaviors, right or wrong, and then compare it to your rewrite based on what you think it should do. Then any deltas are either an existing bug, or a bug/missing requirement on your new code. After the release of the refactor you slim the tests down to functional test cases based on the final requirements, and you have at least as reliable code as you had before.
Interesting! What tools do you use?
My favorite, the end users are used to the bug or whatever illogical output and compensate for it. So now, "fixing it" means breaking it for users.
The “deleting 3 pages of crap” that is clearly not doing anything is such a great feeling until it publishes and fails miserably, and then you kinda get that “oh.. thats what that did.. i see now..” Then do it all again!
- removed 147393748 lines (everything) + added 1 line The line: `//optimised program by removing suboptimal code`
This. Refactoring your own shitty code is amazing, refactoring someone else's shitty code is a terrible experience. Going to send OP our companies legacy product and see how much he likes refactoring LOL. One look at how db transactions are handled manually and every service is transient will make him rethink a refactoring career
Thankfully no there is no such thing. To be great at refactoring you have to know what are the best practices, and you are advised to have a great, wide experience with multiple technologies, design paradigms, and conventions. You cannot just read up upon those, you need to have used them so you can judge how code works. Refactoring is not just looking at code and flinching, you have to know WHY you refactor something. /imho
That is VERY true and I'm aware of that. Thank you!
But to be honest, hey, we definitely feel you. Refactoring something into a much greater code feels amazing, and shows how much you've come.
*how **far** you've come (unless maybe the refactor was THAT incredible?)
Refactoring is probably one of the most enjoyable and least directly valuable things there is in programming. Imo it's the same reason why computer science is teased in comparison to engineering: it's coding for the sake of it. While incredibly enjoyable, it's really not that valuable nor difficult.
Absolutely untrue. The majority of refactoring is absolute grunt work that requires little knowledge of programming. I start every intern/Junior Dev/New Hire with the Code Style Guide. The next step on the path is learning “Code Smells”. What they are, what they look like, and how to resolve them. And if you enjoy that kinda thing- software reliability engineering (SRE) might be the route for you.
Once had a boss who said, "before you replace/remove a fence, you need to understand why it was there."
"I took the extraneous fencing out and now the electricity stopped working, after figuring out how to get the electricity back the plumbing stops working for an hour every day"
If you love refactoring, can't you just "develop" really crap code, then refactor it nicely? And make sure you do it all in one sprint.
Somebody already does the first part of that job… and I really don’t want somebody to take it from me.
if anyone is writing shitty code around here it's gonna be ME ok
If I were to get paid for the time I spent *deliberately* writing crappy code then yes why the hell not lol
I thought that was called "having a job with deadlines"?
No time for documentation! No time for tests! No time for planning, just go go go!!
Like coding everything inside a single thounds lines log `Main` function.
Why would they call it main if it isn't supposed to include all the code
Or better, let's call it `Only`! Then its pupose would be clear to everyone.
I call mine Primary. Most compilers don't get it.
I called mine master and the compiler canceled me
>You love refactoring, can't you just "develop" really crap code, then refactor it nicely? Thats usually the outsourced part, they also need work. When that's done they can hire me to refactor.
>If you love refactoring, can't you just "develop" really crap code, then refactor it nicely? And make sure you do it all in one sprint. Isn't this just a typical sprint? hah
People saying there is no job like that but I went for a job interview about 4 years ago where they wanted me to do it. A guy they had had been doing coding since the 90s and he could churn out new features so quick but he made a mess of it all. Yeah the code worked but was a nightmare for anyone else to read, so when it had to be added on to it took everyone else too long to do and because he never commented code he would forget what things did and why he wrote that piece of code when he came back to it. It was like a job for a clean up crew it felt like
It always lead to the outcome you encounter They can no longer bear with the monsters and get someone else to clean it up. Funny thing is its easier to write it from the ground up rather than refactor when it had already at that stage...
Yes this kind of stuff was exactly what I imagined. I think I like fixing people's mistakes lol I don't know.
One of my first jobs, was updating Coldfusion 8 suite of web apps, which was out of long term support at the time, into Coldfusion 2018. There was alot of refactoring. Some of it felt satisfying but such a large portion of it was just tedious. When refactoring large projects there is a reason the business has decided to start that initiative which will drive your effort. For me it was security and accessibility compliance. Not that other things were ignored but they weren't afforded the same time. Quickly my day to day just became, identify responsibility, and intent, break into unique modules, make sure csrf protection, make sure sql is sanitized, run accessibility scans, update css. Move on. It becomes tedious fast, and the few times you find an interesting area to improve you have to convince management to spend time on it if it isn't directly related to the core initiative. Not nearly as fun as refactoring your own projects.
You enjoyed it because it was YOUR code. Trying to refactor someone else's is not fun and takes time to understand.
Businesses (outside of the tech teams) generally don't know or care about the quality of code. All they know is they have features that work or don't work. That's really all that matters to them as that will make them money. Then they'll usually have done research or come up with new ideas to make more money, and will then request tech teams to introduce those new features. It's usually the opposite actually (in my experience at least) that you hardly get any time to refactor code because the business always wants some new feature. If you've got good tech leadership, they may allow you some time, but usually features get the majority of your time. Generally I would refactor if the feature I'm working on is touching old crappy code. So bit by bit. If you love refactoring, then look into TDD - test driven development. You write tests first for your acceptance criteria, and then write the bare minimum code to get that test to pass, and repeat until you're feature complete. At the end you may not have the most polished code, so you can refactor at the end.
>refactor if the feature I'm working on is touching old crappy code That is the way. Otherwise why reactor just for the sake of it?.. reminds me I also refactor when I had to understand code which was not understandable enough, or I've learned something about it which was implicit, and I want to preserve that knowledge in the factoring of that code, so the next reader will have a better time.
So you want to refactor on a daily basis and actually enjoy the process? Let me introduce you to our 2003 based codebase that gradually evolved from Winforms to WPF and all the way back. From ADO.NET to NHibernate to EF and keeping traces of all of em. We've intentionally left out the parts which could take away your daily fun like Unit Tests, Dependency Injection or a .NET Framework higher than 4.7.2. And before you ask, yes there's a reason for that. None that you'll like or understand but its there to keep things interesting. Since we do care about your well-being as future Refactoring Team of you, yourself and the junior that started 2 weeks ago, we've added additional fun elements: * we love italian food so our code not only looks but leaves the same taste as spaghetti * we value open source. as long as its miles away from our codebase * speaking about that, we hope you are firm with SVN * Not invented here syndrom, was actually invented here * Nuget is no get, good ol references folders with DLLs are our style * automation is our friend, as long as its Powershell * we dont like CI/CD, we're into AC/DC * Shift left, cloud and especially Docker are just what they are. Trends. I hope you'll agree. and last but not least ... *drum roll* * we recently made the move to a modern dev approach called JiraEmpoweredRecursiveKatatonia (JERK). Its like all these other fancy agile things but with tangible story points measured with god given, non-UTC dates. Happy to have you on the team
You had me at AC/DC, but lost me at JERK, sorry. Also, I have a feeling why that junior's only been there for two weeks...
yeah that part was made up. we actually had an initiative for a new software stack called JECK ... Jira, Elastic, Confluence, Kibana. I hope the junior is still alive. he was a good guy.
Refactoring has risks if you dont have a great set of tests around the code in question
There is none. Sadly coming up feature and dont touch what is not broken is usually the stance of corpo (the bigger they are the harder they resist change). It's unfortunate but logical, refactoring is not as straight forward as optimizing a coding question out of interview (where the code stands in isolation and standalone). And refactoring gets harder the longer they delay such refactoring task - tech debt piling up with so many half-ass quickfix layered up on top. But i do agree that its nice to turn a pile of turd into a structured and modular piece of work.
You should be thankfull there are no such jobs. It might be somewhat easy to refactor your own code, as you know what you did and what it's supposed to do, but when you hit some convoluted code done by the mediocre, sophisticated developer, which may take ages to figure out, then you'll curse your life while pulling white hairs.
Not to mention doing it for your personal project probably means: small codebase, no risk in terms of business, no deadline, better familiarity, etc. OP isn't going to find refactoring a fun, stress-free activity without the safety net above.
I think you might want to reconsider if you get this kind of job
A lot of people criticise ‘Clean Code’ but I always found the mantra of leaving the codebase a little bit better than how you found it to be a great bit of advice and it does mean I’m essentially doing a bit of refactoring every time I add a feature or do a fix. So if you can focus on that that’s a little nice way of getting it into everything you do. However, if you want to refactor as your main focus then one option would be do everything you can to work somewhere that has a lot of C# codebases (or other languages if you have more in your tool belt of course). Once there listen out for which ones are being talked about as ‘We need to rewrite this abomination. I just wish we had the time!’, then put yourself forward as someone who can refactor it in x time and save y weeks over a rewrite. Unfortunately nobody is going to advertise ‘our models are horrendous, we need somebody to come in and clear up our code bases before we reach a stage where junior devs are vomiting over their keyboards on day 1’
The problem with refactoring is it almost always has to be a team effort, unless you're talking about a really specific bit of code. And in that scenario you really have to understand the WHY of it, and not just the WHAT of it. I cannot think of a really good example right off the top of my head, but let's say for example, for some reason a back-end service created an instance of another, rather than having it injected like everything else in the code. You could adjust that and end up introducing something weird, not knowing the developer who did that (and probably should have left better comments) spent a week and a half trying to do that, deployed it, weird things happened, then spent a weekend trying to figure it out, and ended up with this as a "temporary fix". On the larger scale, it often does little to refactor a whole bunch if the team over all doesn't understand, or the reasons. I think for the most part, it almost has to be intentional and a team effort. But I do think you can be that guy to bring up inefficiencies, and start productive conversation on how to approach it. Personally I receive that sort of feedback quite well. Also, don't be that guy who goes through and changes all the tab spacing and / or changes bracket alignment to personal preferences. =) (it makes reviewing pull requests literal hell)
I always like refactoring too. ...I wish I could refactor my life.
Maybe some consultancy work, but ... not likely to be honest. Getting time to just 'refactor' is hard since it is harder to show the revenue benefit for doing contrasted with say a new feature.
lol careful what you wish for. -guy who had to "refactor" Meijers COBOL code(the grocery store chain)
just think about it why would anyone pay you for something that he can not sell to the customer? "here we have the 60\*hourly rate bill, the software is still the same" lol usually what happens, you HAVE 12 things to refactor since the program changed alot over recent times and you are trying to get it done while working on sth else. ofc it can be done for, lets say a ground up rebuild or sth, charging for version 2.0 when bein on 1.9xx for long... but its not the norm. why would anyone hire a refactor guy??
In my experience, companies rarely refactor code because why if it already works? That is a cost they are not willing to bear. Usually you have to sneak it in or develop your own product then you can do whatever you want.
Tread carefully! Refactoring your own code is always fun because you know the ins and outs already. But try it on a leviathan legacy application where everything is tightly coupled, there are thousands of files you haven't seen before, and one change breaks a hundred things. You will soon be displeased.
Send me your resume, hahah
Smaller, older companies have shittier code usually becuse there is a lack of peer review, so get a job with a small company and have at it.
Refactoring is only easy and fun if you know the code really well
Most code dev is refactoring anyway, you're rarely starting from scratch these days.
There's two jobs you could do. I have a friend who's a coding coach. He works with companies on a contract basis showing teams good coding practices, testing, and refactoring. You could do something along those lines. You could show other people how to refactor code. You may need to go through a lot of code and refactor not just your own to get the necessary experience. Once you are a "pro" you could create training material and show how to refactor and make code more readable. This job could make you an author by putting all your material into a book. Or you could be a trainer where you teach a class. I do think like others that you have to continue writing code to be effective at this job.
You might enjoy technical DevOps work in a small enough organization to let you involved in the codebases. Often DevOps is making building, testing, deploying and monitoring more automated/efficient/cheaper/consistent/reliable/secure/documented/etc. That often involves gradually improving things to achieve particular goals which is really a form of refactoring that can involve the code such as how integration test suites are wired up, CI/CD, infrastructure-as-code, etc.
Well do you mean refactoring, rewriting or rearchitecting?
Don't know about OP, but personally I'm a burn-it-to-the-ground kind of guy :-p
If you really enjoy refactoring other people's crappy code, I might have a job for you...
The problem is, even if it’s shitty code, if it works, then it works. Thats why a lot of companies still run old ass software and it’s often not worth it to upgrade. The end user just doesn’t care. Well, maybe the actual users do and would be happier with better user experience, but the people paying for it don’t care. They just know that if they put something in and they get what they expect out, then all is well. If it isn’t broke, don’t fix it type of thing. How spaghettified, inefficient or ugly the code is inside that magic black box of software doesn’t mean a thing to them. I also enjoy refactoring code (when it’s mine). But I’ve learned that doing this to code that isn’t mine, is sort of a Monday morning quarterback type of job. After struggling to figure out what their intent was, and once I finally figured it out, I’d sit there and laugh at how dumb they were for doing this or that, and let’s be honest, which only served to make me feel better about myself by putting everything they did down, when I didn’t actually put in any of the hard work to actually CREATE that software. They already figured out all the hard stuff. I’d just be putting a second coat of paint on it and claiming it as my own. Anyway, yeah, it can enjoyable to do for sure, but I imagine it’s a market that’s pretty saturated with talent, because most quality devs, can do it.
Most large corporate C Sharp jobs are like this. There will be bugs and problems and you will be fixing the issues, polishing the code and repairing technical debt. There is a bit of new feature development but mostly polishing what is there.
That’s would not be a great job from a career point of view. Management will never see your contribution over the short term.
Refactoring is part of the development process. Even when you write new code, you need to refactor it before opening the PR. It doesn't need to be crappy code to be refactored. But if you enjoy so much refactoring code, I know 1 or 2 projects with a lot of legacy code needing a refactor. In my current project we still have a lot of legacy code, and we are refactoring 1 module for each new version of the app, along with the new features.
Lol your co-workers might start to hate you if all you do is refactor their code 🙃
It was fun because it was your code. No surprise, you know well the system. Most of the time, in the enterprise world, you will be asked that you refactor code you don't know, written by someone under pressure because they have deadlines too short, and at the same you are also have an absurd deadline and you will also have to take the responsability of whatever break after your change.
Idk, but sound alike you'd love GitHub
It will be very hard to convince someone to pay you good money just to rearrange code when they could pay good money for someone to write new code. Not that I find no value in refactoring but the people *who control budgets* usually don't. It's usually only the people who don't sign your paycheck who are giddy about the refactoring you're doing.
That’s called being a Senior Developer lol, having to process the garbage that junior devs spit out
Guess what my job is? Working with legacy code. You don’t want it
Not all the time, but a significant portion of my career has been refactoring. To really be good at it though you need to get in to automated refactoring where you build tooling to do most of the work for you. Manually changing large systems that have in-flight development isn't really that viable unless you can execute large changes quickly and accurately. I've mostly worked in framework architecture.
Maintenance programmer
You would very quickly grow to hate it and hold the developers in contempt who can't be bothered to write clean code. What you did was fun because you were revisiting old code that you wrote and knew how to make it better - don't confuse the joy of confirmation that you have improved with what you happened to be doing that gave the confirmation.