
When and why to clean up your code: now, later, never - itamarst
https://codewithoutrules.com/2018/11/02/when-clean-up-your-code/
======
d--b
I used to be a full time developer at a company where we only shipped new
features. At some point, I wanted to go remote and part time. I've asked them
if they'd be down if I worked in the shadows refactoring shitty code and
replacing crappy modules. Which is what I'm doing right now.

For them, they pay me a fraction of a developer's price and get a constant
improvement of the codebase.

For me, I work at my own pace, remote and part time. I live in a place where I
don't need much money.

It's awesome.

~~~
pmiller2
That’s really interesting. Compared to what you could get on the open market,
what’s “a fraction” mean? 1/2? 2/3?

It’s kind of hard for me to imagine moving out of the Bay Area, but I’m sure
there are major cities outside California that one could easily live on 1/2 a
software developer’s income.

~~~
d--b
I took 1/4th, but I was working for a very successful finance company in New
York. If you don't count the yearly bonus, I took about 2/3rd.

But the calculation should not be about the fraction, it should be about what
you need. If you make $100/hr and work 5hr/day, that's $110k with 5wk
vacation. I make more than this and I moved to France, so I make a very decent
living compared to the local standards.

------
gitgud
_The Boy Scouts have a rule: “Always leave the campground cleaner than you
found it”._ \- Robert. C. Martin

~~~
e40
To this I would add: _When in Rome, do as the Roman 's do_.

When you are repairing other people's code, don't change it to your style, fix
it in theirs.

~~~
Jtsummers
And this depends on who "owns" it. If you don't have communal ownership of
code, don't make drastic changes without consultation. This is like
rearranging someone's kitchen for them "because it's more efficient". It's
not, because now they don't know their code anymore (I had this happen to me a
few times, I know it needed work but the work done made it harder for me to
make other changes later that the "helper" didn't know was planned).

If you'll be the one owning the code, do what you want. If it's not yours,
check first.

If you do have communal ownership, coordinate and establish style guides,
ideally using tools to establish conformance (rather than eye-balling it, this
also leads to greater consistency).

~~~
gwbas1c
That's why a team should have code reviews; and everyone should keep an eye on
what's changing.

This way if someone decides to rearrange something, the stakeholders can hold
up the review until they're happy.

I've certainly blocked code reviews because of planned changes.

That being said, you only "own" code if you own the business. If you think you
"own" code, you might need to re-evaluate your ego.

------
biesnecker
In my experience the only two real choices are now or never, because later
almost always becomes never under pressure to do new things.

------
informatimago
In my ideal environment, each time I would load a source file in my editor, it
would be reformatted according to my own preferred formatting rules. And upon
writing, it would be saved in some common "standard" format good for git
diffs. This way each programmer can be presented the code in the best way he
can read it, and the tools can work on a standard representation that they can
best deal with.

I will note that some projects such as FreeRDP, already have an autoformat
script that does the "saving" part (unfortunately, not entirely automatically,
since the precommit-hook is not set to run it).

------
ne9xt
it’s kind of frustrating, cracking open old code for a change or bug fix and
seeing some really gross helper function you have to use. the temptation to
take 30 minutes and refactor is too irresistable sometimes.

I do agree with the basic idea of the article though. maintenance/sustaining =
touch the code as little as you can (helps with diffs) greenfield = take the
time to make it right for as long as you can

~~~
jniedrauer
As I gain experience, I find myself more and more just gritting my teeth and
using the nasty function as-is.

The business types don't care. What they care about is having something to
sell.

The engineers who are even capable of understanding what I'm doing don't care
because they've got their own deadlines on a totally unrelated part of the
codebase. They probably won't even work here any more by the time someone has
to touch this code again.

------
steverb
Remember that updating references is usually a global update. Now you have to
test EVERYTHING that used that reference.

I've had so many projects bitten by an overzealous dev who decided to update
the version of a library because newer = better and then we spent the next
three weeks chasing bugs/differences between the versions.

Edit: Curious about the down votes. Would someone who disagrees care to
illuminate me?

~~~
sixstringtheory
Not a downvoter, but when I saw your reply it made me think that you may need
a better process around maintaining dependencies.

At least IMO, best practice is to continually evaluate and adopt updates to
dependencies. I’d rather have a slow trickle of problems associated with
continuous updates, than have a total firefight when you realize you _have to_
upgrade, now, and you have neither solid plans and practice in place to do so,
nor the time because you’re in the middle of yet another feature drop that is
pushing tech debt to the breaking point.

Setting and forgetting dependencies is like saying you have a backup
somewhere, but never actually testing if you can recover from it. That’s the
kind of thing that could turn a routine outage into a crippling emergency.

~~~
steverb
Fair point.

