Refactoring code is less stressful if you do this

#shorts #refactoring #code

Next time you refactor code, consider incremental refactoring. It lets you spread the effort of a refactor across the software development team. Instead of creating a user story, github issue, or jira ticket - come up with a plan to enlist all the developers to help. Then build this into each estimate that's part of a user story or whatever you use for work item management.

This is because otherwise, management will be tempted to pull out refactoring. And if you've determined its necessary for the quality of the code, you must prevent them from unintentionally damaging their own software product if you want to be a professional, senior programmer!

[marna_li]

This is actually a thing you learn after a lot of experience: Don't tell the boss about what they don't know and probably will not understand. It might enter as a work task, but it will not be prioritized. But there is a culture aspect to the mindset required. If the team don''t care since they do not deem it worth since the management will say "No". Programmers are after all lazy, and don't want to create a mess.

[Paprik]

I think senior developers, who understand what refactoring is needed, should have enough of a say in project management that they shouldn't need to hide tasks sneakily. Likewise project managers that aren't competent enough to understand this, shouldn't keep forever delaying such tasks. And if this is not how it works in your company than a discussion should take place. Of course it's exactly like you say in the video, an experienced dev should understand the importance of new features too and you should agree on a healthy balance between new content & refactoring, but there really should be no need for hiding secret tasks.

[harshitambasta]

Meanwhile my scrum master Karen: "Guys we are not working on anything that is not on the JIRA board."

[davewx]

Definitely agree. Developers should totally strike the word “refactor” from their vocabulary when dealing with people who aren’t developers. They won’t get it and will assume you’re some egghead off doing unnecessary things just for fun. Of course the reality is often that the refactoring is *required* to deliver other features, but for whatever reason some nontechnical folks still won’t see it that way.

I will add, thought, that it gets a little more complicated from a technical standpoint in that the best way to deal with refactoring is to do it separately from feature work, I.e. thr coding and pull requests for the refactoring should absolutely be done separately from the work that involves behavior changes. It’s very possible that an over-involved PM type might notice that there are multiple PR’s and question why that’s happening, in which case I would still try to avoid framing that work as refactoring.

[floriankopp]

Oh hi, you are back! I found your channel a year or so ago and was sad to see that you hadn't put anything out for years, your videos helped my through some tough times in my own career :)

[go_better]

You propose a much humane approach, more team driven, that I've been using. When I recieve a ticket, I refactor/upgrade related code and sometimes even cover it with the tests. Nobody cares about test scope dependencies and nobody cares about the code review.

And if I go and tell management "could we refactor this?" They'll be like "oh sure let's create a technical debt task and we'll see when we can implement it" (NO, WE WILL BURY THIS REQUEST AND FORGET ABOUT IT right away).

To be fair, I met one of the team leads on one job interview and he told me about how he approaches "code health" or "project health". So lets his team members to speak out loud about areas that could be refactored or libraries that could be used. And after that HE REALLY SPECIFIES time percentage of sprints to make it happen. What a cool guy.

[PasteteDoeniel]

So glad I found this channel today. the few videos I've watched have already been full of amazing advise.

[silver_crone]

This. I've taken on a lot of legacy coded projects that need updating to keep functioning. Incremental changes are crucial. The project has users logging in every day, and still needs to hum along while you tuck in what needs refactoring. It's easier to chuck it all out and start over, but rarely is that something that happens in the wild.

[sourandbitter]

Only problem I see is if the software would need regression testing after a refactor.

[nonfaktor]

agreed. huge refactoring usually don't get integrated aswell because nobody wants to deal with the merge conflicts.

[obaid]

but how are we supposed to commit such changes if every change on a team has to be associated with a ticket D:

[geekstakulus]

I have been using incremental refactoring for the past five years and I advise in favour of it. Management don't really understand the role of refactoring, and incremental refactoring is a great way of bypassing management's barrier.

[sunshinelizard]

@Healthy Software Developer One challenge with this is making sure QA is in on the testing of the areas of code that are modified - you can't ship untested code without deciding to take risks for the company without consensus and risking the loss of trust in the team. It's a difficult conundrum that tortures me a bit. How do you solve this?

[rconr]

Love what you said. This is absolutely great advice. But aren’t we not being transparent with business at that point.

[florinpandele]

I tried doing that and they refused my PRs.

[crystalray]

What you suggest doing is perfectly viable and I am 100% FOR IT. Question is how do I find TIME to do this extra steps? I do not work in agile team of developers. I work as a sole software developer in 20+ people marketing deparment. There used to be 2 of us but my senior dev left because he considered work to be not developmental at all to your skills as developer. Our, ,methodology" is, ,we need this work/feature done as fast as possible".
I talked literally to everyone and everyone would prefer me doing more in-depth work rather than adhoc but when their client needs features he/she needs it NOW. So I have to code then NOW.
I mean I literally can and did convinced my whole team (which was as hard as breaking the concrete with a pen, took me months - fact I was able to speak with business better than 99% in the field and actually convince them solo is really in big part because I watch your videos, THANKS!) but corporations have their ways that are not easily changed.
PS. Yes there was about 11 developers in succession before me having similar situation and they left a ton of unfinished projects so I do not write any new applications just fix what they did if business needs it because I do not want to increase technical debt. And there is no time to remove technical debt while coding anything else.

[NikitaLipkanov]

That's a good thing to do, but it is not a solution for every refactoring situation. Sometimes it's better just to clean things up for 2 weeks and continue to work with a better structure..

[KemalAhmedIsAwesome]

I tried doing that and the devs kept saying in their reviews to stop doing the incremental refactor bundled with the PR and to do it in a separate ticket.

[arielguzman]

See this sort of experience is what I doubt AI can compete with. Maybe eventually but not anytime soon. So juniors focus on building experience.

[markendsley]

Where I work, management wouldn't pull it out lol.