
That coworker who never stops refactoring - mcrittenden
https://critter.blog/2020/08/11/that-coworker-who-never-stops-refactoring/
======
renewiltord
I don't want a teammate like this. I want to work in a team where we all do
this _sometimes_. Fortunately, I have that team. I think if I hired people and
then determined how I could use them best I've already failed vs. if I see
where I could use help the most and then hired the guy who can do that the
best.

Every engineer I know who I respected for this behaviour also delivered
boatloads of functionality independent from "improving dev productivity 25%"
which kinda makes sense since if you go around refactoring everything you
kinda know the whole thing. Also, how do you even know if you've improved dev
productivity 25% if you haven't even improved your own functionality-
delivering at any rate (which you'd only know if you attempted to deliver
functionality)?

In fact, every engineer I know who I respected to deliver boatloads of
functionality also had this behaviour.

All of the guys who thought they were this guy but didn't deliver boatloads of
functionality were just some wheel spinners who weren't really useful. I'll
probably never work with them again if I do my hiring right.

~~~
dcow
The problem with "we all do this _sometimes_ " is that no team ever gets to
75% of their backlog. And no manager is able to justify spending the extra few
days to automate something correctly or "get it right" because there's always
pressing product work to do. I've found it to be much more practical that the
team lean into each other's strengths than to fool themselves into thinking
you'll ever see "infrastructure automation and fix flaky tests" as the mantra
for a few sprints.

I guess a well oiled team could rotate positions around but then you tend to
lose a coherent vision of what "right" is in any given domain because you
don't have domain experts anymore since everyone has to be an omni-tool.

~~~
bkor
> And no manager is able to justify spending the extra few days to automate
> something correctly or "get it right" because there's always pressing
> product work to do.

As-if the business side of things has any idea of how long something will
take. Refactoring or doing some infrastructure work can just be tagged
together with some other bits.

For the business side of things it's more important to know when things will
be ready and knowing that timeline.

Further, a manager can explain that e.g. "the car needs maintenance". Business
isn't against such things, but if the manager cannot switch from IT-speak to
business language then it might seems that the business side won't get it..
but maybe it was the explanation that was lacking.

Especially in sprints I noticed that it's understandable to everyone that not
everything is finished in one sprint. Though if it happens to often, maybe
just promise less.

~~~
dcow
I know. I believe these things should be possible in theory. I rarely see them
in practice. I attribute this to a unilateral lack of discipline.

------
gfodor
This advice applies generally - leaning into the interests of your team acts
as a multiplier. I haven't seen it done often, and sometimes it's explicitly
frowned upon, but I often advocate for team interests to influence roadmap
prioritization.

"But the customers' needs should prioritize the roadmap!"

Yes, they should, but it should be balanced. Better to have 10x the output, a
happy team, and hit a broad surface area of customer value, than a slow,
clock-punching team who comes into work being told what to work on by dictum
based upon the most high customer demands. A sign you're doing this right is
if there is some slight tension between engineers working on what they like,
and what management feels is the important thing to be doing. You want that
tension, and need to manage it from falling too far to one side or the other.

It often turns out if you have a balance here, you'll see innovation happen as
a side effect. Team interests of a smart team often are somewhat far afield
and lead to bursts of creativity, and can lead to new forms of thinking that
lead to new features. Ensuring the team groks the customers' needs, and their
demands, as well as giving them opportunities to pursue their passions, allows
them to connect the two together when inspiration hits. Often times to
innovate you need to do more than just listen to your customer, you also need
someone with an orthogonal interest, knowledge, or talent stack to cross-
connect things into something greater than the sum of its parts. Empowering
the builders on your team to explore things is a good way to harvest some of
this 'innovation space.'

~~~
fiddlerwoaroof
I also think that customers often don’t know their needs, if that makes sense:
the team can often see ways to streamline a product that never occur to the
customer because the current behavior “anchors” their ideas (although, the
reverse is often true too)

------
simonw
A big risk here is that it's very easy for refactoring you make a codebase
worse.

Someone spots the same functionality in two places, applies DRY, then two
weeks later a new requirement means they need to work slightly differently
from each other and that change has to be unwound again.

I've seen plenty of helpful refactors that broke code in subtle ways (if your
tests aren't robust enough this can happen really easily).

I've seen projects take literally months longer because the team hit caught up
in "refactoring" code written by previous engineers - not because it needed
it, but because the new engineers preferred to write their own code than dig
in and understand what was written before them.

~~~
vvanders
Yup, instead of DRY I'm a big fan of WET, Write Everything Twice.

Third time? Maybe consider a refactor at that point.

~~~
weego
I learned this from the smartest dev manager I've ever had in the second or
third week at the job, it really tore down a lot of the notions I'd formed as
a self taught developer.

We were looking at a pull I'd created and he asked 'are these things really
the same or is it just a coincidence because the features aren't mature enough
yet?'. And yes I'd conflated two things with entirely different intents by
over-abstracting.

~~~
k_sze
The book "Pragmatic Programmer" talks about this in chapter 2, topic 9.

The kind of duplication you want to avoid is _knowledge_ duplication. If two
pieces of code literally do the same thing but for different reasons/purposes,
it may not be a good idea to deduplicate them.

~~~
lkschubert8
Yeah I think DRY has been bastardized to mean dont repeat code when it
actually means encode business logic in one place.

~~~
mcv
I mind duplicated code a lot less than duplicated data. If two things have to
match, but they're using two different configurations, then there's going to
be a mismatch some day. I'd rather create the second config out of the first
one. If front- and backend need to know something, have the front-end get its
config from the backend, instead of hard-coding it in two places.

------
jll29
This post talks about a team role that has been called the "librarian". Some
of the software engineering literature proposed that a team of three can be
most productive as a pair supported by a librarian that writes useful library
functions.

I have been in teams where we carried out projects, and each project's
codebase re-invented a lot of functionality (e.g. converting HTML to plain
text, tokenising an English sentence). Of course I proposed a librarian role,
which as the article contends is suitable for particular personalities.

In a group of, say, ten or more people there is a room for that kind of
specialisation (librarian, sysadmin, statistician, ...).

~~~
8note
When you say librarian, I think of a team member who knows the code base and
reasons why the code base is the way it is.

Maybe historian is a better name though

~~~
PaulStatezny
> knows the...reasons why the code vase is the way it is

I try to document (in code) a lot of that "why", so that the answer doesn't
need to be passed around as tribal knowledge.

If you need a person around to be able to explain the project architecture,
it's probably a sign that you need more/better documentation.

Just my 2 cents.

~~~
piva00
I do the same, any kind of minimally unexpected code gets its explanation as a
comment if the code can't be clear about the why. I like to leave a comment
with what is happening, the background for it and any kind of gotchas I'm
aware at the time.

This has saved countless man-hours for my teams, including myself when
refactoring part of the codebase a year or so later, having a nicely written
rationale behind some weird-looking code gives me not only peace of mind but a
lot of trust in the rest of the team.

------
Wandfarbe
I'm not a big fan of people just doing what the ticket states.

Quality doesn't start when a customer comes up with a simple fix/enhancement.
Quality comes from people with experience who knows exactly what needs to be
done even if it is not stated in a Ticket.

\- Security \- Maintainability \- Usability \- Clarity \- Performance

You are the expert, NOT your PO. Your PO tells you what he/she needs, you tell
them what you HAVE to do.

And personally, i have never heard anyone complaining that someone else did a
better job on a ticket than the ticket stated.

~~~
thdc
Is this not the norm?

I haven't been working for long, but the product manager at my job just tells
us the features and the we're free to build it however we decide to.

~~~
Wandfarbe
Highly depends on the skill level and experience of your overall team.

There are plenty of people writing code in small companies who just never seen
or heard it or never experienced the advantage of doing it good/better.

They get a task to do and thats what they gonna do.

There are also Teams in the wild where people get pushed to over a longer time
of period because people gave up on them but you don't wanna be the bad guy
firing them and there is still an it expert shortage and you might find
something new for them to do, you know, people where you are wondering how
they earn a paycheck.

And i have seen plenty of experts who just don't have the experience to see
certain issues.

Good example are things like: Mandatory Code review (for shared ownership, for
quality), taking metrics serious (yes messure what you do), proper CI/CD (no
do not skip breaking unit tests...) etc.

I believe, one of my most critical skill for companies is making sure those
things are in place or become good. It feels weird to be honest, that those
things are so critical and still are not lived as you would assume, or at
least i do.

------
thinkingkong
Ugh. I hate posts like this. Refactoring, speed improvements, documentation,
testing, etc arent roles. They arent buckets. They arent seats you fill.
Theyre part of every engineers job. The issue is we keep dividing issues into
“product work” and “unproductive” work. If this person is fascinated with
refactoring thats amazing. If theyre obsessed with speed, equally so. But
there needs to be constraints on when to start optimizing and when to stop.
The when to stop part is the one where people fail the most. Simultaneously,
we should all be dedicating time on a regular basis to these types of
activities. Like min 25% of our weeks for most companies. Instead we hide
these improvements in features and complain when coworkers are “slow”.

~~~
bradstewart
I don't think the author is suggesting you go out and hire a "refactor
person", a "new feature person", a "documentation person", etc. Rather,
assigning the body of required work to each developer based on her interests.

If you have one new feature ticket and one refactoring ticket, don't give the
new feature ticket to the developer known for refactoring too often.

> But there needs to be constraints on when to start optimizing and when to
> stop.

Now that is very true. But feels like a separate issue to me.

~~~
thinkingkong
Actually I think assigning work specifically to people ends up solidifying
responsibilities. Its like the person who doesnt mind writing tests. Guess who
ends up writing nothing but tests? Guess how many tests the rest of the team
writes?

~~~
Rapzid
Guess how much that person likes getting assigned to write tests after 6
months to years?

------
dmalvarado
My god, this describes me to a T, and every one of those bullet points sounds
like a fantastic way to spend time working. It was only when I caused a
production issue due to a refactor that I gave up on trying to making a
behemoth codebase better for everyone who has to work in it, and that’s when
work got sad and boring.

I will take this to my team.

~~~
ctheb
We can’t be afraid to change code. If your code change caused a production
issue, what’s stopping someone else from causing a similar issue even if they
aren’t refactoring?

I have worked on teams where people don’t know what the code does and the test
coverage is spotty. It’s a minefield and only a matter of time before
something breaks. It sounds like your refactoring work was a much needed step
in the right direction.

There needs to be sufficient testing and monitoring in place to catch problems
earlier than production, so that people are not afraid to change code.

Would you be willing to share more details about the specific problem you ran
into?

------
DanielBMarkham
I think the thing a lot of devs don't know is that there's a limit to
refactoring. At some point, you're done.

It's like a mountain. The team is dropped half-way up the mountain. The dev
that refactors all of the time continues to head up the mountain. It can be
slow work. It's a tough climb. Most of the time, devs on the team don't know
any better, so they just do the work in front of them, slowly sliding down the
mountain. Eventually, they look at the mountain and say "There's no way
anybody could conquer that! We're lucky just to get our work done without too
many bugs!"

Meanwhile, the refactoring dev reaches the top and slides down the other side.
That dev starts looking for bigger mountains. The rest of the team he left
behind sink into despair and cynicism.

Eventually, when organizations grow large enough, most everybody lives at the
bottom of the first mountain. Devs who leave and try to summit are ridiculed
at best, shunned at worst. They're hated if they only go halfway and then
fail.

I am of the opinion that most big-organization developers don't actually know
how to code. Sure, they know how to type in programs. Hopefully they know
enough to test what they're writing. But a real understanding of what
programming is? No. Until you've been over a few mountains you don't know what
you don't know. Sadly these are many times the folks that get promoted.

~~~
jklm
I like this analogy.

But to extend it, consider this. The refactoring dev can’t help but climb
every single mountain they see. The product focused dev decides instead they
want to climb Everest.

You drop them both in a mountain range in the US. The refactoring dev starts
climbing. The product focused dev decides to hop a plane and fly directly to
Everest.

Taking a step back from the analogy, not everything is worth refactoring. How
much will that code change over time? And what’s the opportunity cost of doing
the refactor?

------
vp8989
This article is based on a very commonly used but flawed premise that all
product-driven work actually delivers value to the business and that tech-
driven work doesn't.

This is only really true in the real world for a subset of brand new startups,
where none of the low hanging fruit product ideas have been built yet but the
"idea" for the business is very good. Tech-driven work doesn't pay off here
because of scale. It's not worth working on perf when your total server bills
is in the hundreds or thousands of $. It's not worth working on dev exp when
you have < 10 developers. You don't need to refactor yet as it's greenfield
code anyway and it's easy enough to glob stuff on to support business ideas
... for now.

If you are working on a sufficiently mature product, there is a fairly high
chance that the product-driven feature you are about to spend months on will
fail to gain any traction and be totally scrapped. Anyone who has 5+ years
experience has probably experienced this multiple times, this happens all the
time even at "good companies".

This is because all the obvious low-hanging fruit ideas were already built
years ago (which is why the business even has any money to employ YOU as a
software engineer).

In more established companies you are less likely to deliver value to users
but more likely to deliver value to the business by executing on "tech-driven"
initiatives. This is because of scale:

\- If you work on perf, cutting 10% of server costs is a big deal when you run
thousands of them vs. tens of them \- If you work on developer efficiency,
improving that for hundreds or thousands of developers is a big deal \- If you
refactor to support future changes, preventing forced "big bang" rewrites of
large established systems you will save the business millions of $ in salary

------
juliendc
A very respected developer in my previous company once told me: "make the
change easy, then make the easy change". I guess everybody has already heard
it because it's kind of a famous quote but it has really changed the way I
develop since then. Every times there is something I need to implement and I
feel like the codebase "resists" it, I think about this quote. I then take the
necessary time to make this change easy first.

Found a link to a tweet, which looks like the original source (not sure
though):
[https://twitter.com/KentBeck/status/250733358307500032](https://twitter.com/KentBeck/status/250733358307500032)

~~~
tyingq
Is there a good example of this? It rolls off the tongue well, but I'm not
really clear on what it means in practice.

~~~
zem
i was once working on some game code that had developed organically, so there
was a weird mix of various sprite operations being done in either the world or
the sprite's coordinate system. someone wanted to add sprite transformations
like mirroring (basically the ability for a sprite to turn into its reflection
sprite along one of its axes) and scaling, but there were several places where
there would need to be checks for e.g. "if sprite.x_mirrored" and "if
sprite.y_mirrored" when dealing with other transformations like off-centre
rotations, and no one was eager to sit and go through them all.

so i took some time and consolidated all the sprite geometry code into a
bounding box object, and then had every sprite own a bounding box, and have
the rest of the code interact with the bounding box where possible. that
suddenly made a bunch of other things easier to do, because they came down to
"how will this affect the bounding box" and they could be done in a single
place.

~~~
tyingq
That explains it perfectly...thank you.

------
secondcoming
Fred was employed to do a job. Fred isn't doing it. Fred needs to learn the
ropes; everyone would love to be in a position to work on whatever they want
at the expense of everyone else. Fred could raise tickets to allow him time to
do the refactoring but he sneakily does it as part of other work which puts
his colleagues in a position where they have to accept his work because it's
late.

Don't be Fred. Freds get fired.

~~~
WJW
In my experience, Freds are often a holdover from an earlier time in the
companies' life when autonomy was not only desirable but required. Some years
pass, a few managers get hired between the CTO and Fred and sooner or later
the manager needs Fred to fall in line because he makes the manager look bad.

Eventually the "make a ticket for everything" scrum crowd wins out and it's
now Fred's fault for refactoring without a ticket. Fred long ago learned that
refactoring tickets always mysteriously sink to the bottom of the backlog, so
he doesn't make them anymore.

TBH, the Freds I encountered are not really in any danger of getting fired.
Because they were the only ones touching all parts of the codebase with their
refactorings, they were pretty much walking bus factors.

~~~
thinkharderdev
"Fred long ago learned that refactoring tickets always mysteriously sink to
the bottom of the backlog, so he doesn't make them anymore."

Exactly this. Maybe Fred understands that if he creates a ticket to do a
required refactor then it will never get prioritized and when things blow up
in production 2 months from now it's his phone that's going to ring in the
middle of the night.

~~~
schwartzworld
Fred knows the codebase so well he has a list of functionality he wants to
rewrite. He patiently waits until a ticket comes up in the backlog that
touches that code.

------
staysaasy
IMO being able to cut through work that you don't love is a tremendous skill,
especially for software engineers. Many of the most successful engineers I've
worked with had a really valuable trait where they were 100% effective on
projects that they loved while also 90% effective on ones that they hated.
This really helped them stand out when the standard ratio was closer to 100% /
20%.

~~~
Frost1x
For me the difference is often that I'm willing to put in what is essentially
unpaid overtime for tasks I love, because I enjoy it and want to see that
route succeed (a bit of selection bias here).

Its not that I'm less productive writing your CRUD application with set of 6
different popular obscure libraries of the week, it's just that when I reach a
point where I've spent 40-45 hours doing that, I'm going to report back that
it needs more time, because it does. I'm less likely to report back something
I love needs more time, because I'm already giving it more time.

So often that efficiency difference you see is me consuming tech debt or cost
in the form of personal time. It has little to do with the fact I struggle
because I think the work is silly or meaningless and more to do with the fact
that I'm not giving 110% if I feel it's meaningless, but you will get 100%.
Not slacking on the boring tasks, just giving additional effort on the
interesting tasks.

------
bcrosby95
You need to put Fred on stuff that other developers have some buy in for. If
you have zero automation, putting Fred on that is a bad idea. If you have zero
tests, don't put Fred on that either.

Because the minute Fred leaves, all that work will rot then be discarded. It's
better to have Fred work on something that will be maintained beyond his
employment.

~~~
PaulStatezny
I don't understand; why would tests and automation be discarded just because
Fred leaves?

~~~
dack
Most code needs ongoing maintenance - if folks aren't writing tests to begin
with, then they probably aren't going to update them as functionality changes
over time if Fred isn't around. And automation might be great for the current
situation, but eventually need some improvements that nobody is willing to do.
Eventually the tool seems less useful and people stop using it.

------
rconti
I don't see why this perspective on someone doing things differently is so
surprising in an era where we're pushing the advantages of diversity. Everyone
comes at things from a different perspective and has different strengths.

I remember having a coworker ask me for advice on a storage array he was
working on. He was banging on the UI, checking out all kinds of irrelevant
paths, seemingly exploring all possible ways of accomplishing the task at
hand, even the ones that were very unlikely to be correct. I was kind of
frustrated that he was spending time exploring unimportant elements as I could
clearly see it was one of just two or three options. I tried to brush aside
some of the exploratory actions and he said "oh, I know that probably won't
work, I just wanted to take a look.."

I didn't have the patience or attention span to wait for this ridiculously
slow interface, so I wandered away after giving my best advice.

A couple months later, whose experience did we always rely on when trying to
figure out a novel problem? That's when it clicked for me. I won't necessarily
have more patience myself with the exploration steps, but I certainly
appreciate those who do.

------
fudged71
Our CTO cofounder was a "technical genius" asshole who did 3 entire rewrites
of our stack before a single user touched the product. He would come back from
a weekend and say "I stayed up and refactored everything to make it faster".
Of course this left our other developer completely in the dark and it broke a
lot of shit in the process.

We ultimately fired him and got another cofounder up to speed into that role.
It was the most frustrating red flag that we should have caught earlier and
put a stop to.

~~~
disgruntledphd2
If you don't have test coverage, you can't refactor (or at least it's a
terrible idea).

The first step in refactoring is writing a test (probably component level at
first) such that you can make sure you don't break anything.

Seriously, this is all covered in Fowler's book on refactoring (which is
incredibly worth a read).

------
spacemanmatt
I am on a small team that factors/refactors heavily. Some thing I have noticed
about the practice over the almost three years since I started this particular
job:

1\. Adding small features is extremely predictable, in terms of delivery time
estimates we give to management. 2\. Our bug count is very low, and when we
solve a bug it is often small, pervasive, and resolved in exactly one piece of
code. 3\. The more we factor, the better we get at it, and the easier it is to
add new factors rather than new globs that need factoring.

I don't see the promise of "agile" work out every time but factored code
delivers like this every time for me.

------
dmitryminkovsky
I am that guy and every day is a struggle to manage that inclination!

I really appreciate the author’s attempt here to get into the psyche
(developer experience vs user experience) and to find a constructive
resolution.

I’m not sure I agree with the conclusion though because I think often the
issue is a matter of lacking experience (which takes time) and discipline
(which takes practice). Though I’m sure many cases are just as the author
described.

------
gbuk2013
Ha - I’m this guy at work except I’m a couple of times more productive than
everyone else because I know the codebases back to front and our team is
several times more productive than other teams because the code is neat and
tidy after continuous refactoring for years. We added 2 engineers to the team
and they were both shipping features after a week of training because the code
is neat and tidy. Having close to 100% test coverage makes refactoring easier,
although sometimes new bugs do happen. ;)

~~~
cmckn
Refactoring always requires a deeeep muscle-memory of the codebase, getting to
that point at a job is a great feeling. Sometimes (always?) making things
pretty pays off, too! :)

~~~
gbuk2013
It depends on how the code is structured. Our apps use a micro kernel / plugin
architecture of loosely coupled modules so most of the time it is sufficient
to know only a few modules to be able to refactor. Fundamental changes require
a lot more knowledge - this is true - but they are not common.

In my experience so far it is the structuring for maintainability that really
shows the skill of the programmer - writing the logic itself is the easy part.

------
watwut
If the Fred is providing value to other developers, why are other team members
despising him to the point of calling him names often?What this shows is a
strawman situation that is meant to make the point, but is actually showing
dysfunctional team.

It does not show enough details for us to know whether Freds refactorings are
needed or making codebase worst. It is sort of Rorschach test where we are
supposed to pick a side and then fight among ourselves about following two
questions:

Question 1: "is the refactoring you never seen on the codebase you have no
idea about by a guy that is despised by his team" good or bad?

Question 2: "A guys is disliked by his team. Is he right and team is wrong or
other way round?"

The only correct answer is "who the hell knows but damm start managing that
damm team".

------
cle
I often understand code based by refactoring things. And then I throw it all
away. I use it as a way to play with the codebase and understand the rationale
behind its design and organization.

Sometimes other people do that too, they just need some guidance that it’s
okay to do that and then throw it away. The important artifact you’ve created
is a deep understanding of the codebase.

------
aaanotherhnfolk
I've been on a team like this before with heavily separated feature and
refactor pods and it doesn't really work.

The feature pods outpace the refactor pods. Feature pods can use a bad pattern
50 times in the time it takes refactor pods to fix 10 of them. Not every fix
can be scripted. Some bad patterns restrict the ability for the codebase to
stay up to date on dependencies, etc. Lots of reasons not to accumulate this
stuff faster than you can strip it off.

It also impacted team cohesion, as refactor pods started to resent the poor
quality of feature pods' deliverables. Since refactorers are peers, it got
weird when they exerted refactor pressure on feature devs who got wedged
between their peers and their managers.

Ultimately I think this article is a little too black and white. The "just do
the ticket" dev is as undesirable a teammate as the "refactors to excess" dev.
It's better if devs are a little of both and the team culture helps everyone
keep a healthy balance.

------
mcv
A story about me! I mean, I'm not Fred, but I am. I always try to leave the
code a little bit nicer than I found it, and that means if I find warts on
code that I need to change, I'm going to fix those warts.

I love the project I'm currently on, and that's probably because for the first
time since I've gotten good at this, I actually get the freedom to do it.

Would it be better to just build those features quick and dirty? Maybe.
Certainly for the first few weeks or months. And then the code starts turning
into a mess, and somebody needs to clean it up, and apparently that's what I
love.

------
toomanybeersies
The alternative is usually that if Fred isn't allowed do these improvements,
they never get done, then you end up with 5 year out of date dependencies, a
useless test suite, and a mountain of technical debt.

------
jeherr
Fred sounds like he _may_ have ADHD. I'm Fred and I have ADHD. Now I'm not an
expert so it's not necessarily true. ADHD comes in a spectrum of severity, and
plenty of ADHD symptoms are just things normal people have trouble with too.

That said people with ADHD tend to have trouble with delayed gratification.
Helping your coworkers has immediate benefits when they are grateful for your
help, even though long-term it may make things worse. We also tend to have a
lot of social anxiety and care a lot what other people think about us
(rejection sensitive dysphoria). For these reasons, I believe people with ADHD
have learned to be very helpful to those immediately around us, even to a
fault.

Fred still has to get his work done though. Have some empathy for him because
you don't know what he may be dealing with compared to you, but it's not an
excuse.

~~~
toomanybeersies
I also have ADHD and my experience is similar. It's generally much more
enjoyable to bash out a bunch of small bugfixes and refactors then to slog
away at a feature for a week.

I've managed to strike a deal with my manager that I get to spend 25% of my
time working on reducing tech debt and other smaller fixes, and the rest on
primary product development.

------
tyingq
My guess is that Fred isn't going to be giddy about being taken off the main
codebase.

The idea that he might be good at the plumbing doesn't mean he wants to do it.

There's also the danger that you end up with endless churn in your plumbing,
testing, etc, tools instead.

I get the gist of the article, but sometimes you have to face the hard reality
that there's a bad match between a team's needs and a team member's desires.

~~~
jrott
Yeah this lines up pretty well with my experience. Usually when I see someone
endlessly refactoring something it's because they have an idea they're really
into.

You end up with everything having dependency injection or one service that has
been churned on 15 times. I haven't seen it yet where it's general plumbing
fixes.

------
adamsvystun
The leap from this:

> That coworker who never stops refactoring

to this:

> Fred is more interested in providing value to other developers than to
> users.

is not so clear to me, while the article assumes it to be self-evident.

I personally like refactoring even though I work on the codebase alone. I do
it because refactoring allows me to ship features faster (in aggregate), and
allows me to create a better overall experience for users. I care only about
the end result for the users, and this necessitates that I keep the code clean
and succinct.

------
chojeen
At a startup, there's a good chance Fred's time would be better spent knocking
out feature work (you only have so much runway, after all). But at a mature
tech company, assuming he's good at his job, Fred is likely providing a ton of
value by

\- Keeping his coworkers sane (barely functional codebases that are difficult
to work with have a way of killing morale) \- Having an intimate knowledge of
the code base that can inform future feature work \- Paying down tech debt
that's generally uninteresting to more feature-oriented coworkers

Having a whole team of Freds is probably not a good idea, but having one in a
senior engineer or tech lead role is really useful.

------
BurningFrog
Refactoring is the design phase in an agile process.

The old way, inspired by bridge building, I guess, was to first thing out a
great design for your software, and then implement it.

This turns out to not work because, unlike bridges, software is always
changing and needs new features.

So in agile, you just write the simplest thing that can possibly work to solve
your next task. _Then_ , when things work, you refactor the code to have a
good design.

Designing something _after_ it's built is a mind bending concept, but it's
made possible by what we make being just text in files, not set in stone.

------
tarkin2
I’ve suffered from never-refactored codebases. And made people suffer from my
refactoring.

My company once decided to use dependency injection, everywhere, everywhere,
and for anything. The code became a needlessly orchestrated nightmare.

Now any refactor to make my code solve a generic rather than specific problem
— and I’m making the codebase bigger in code and number of files — gives me
pause for thought.

The more abstract something is, the further away from specifics it is, and
sooner or later specifics change, and those changes break your happy
abstraction.

~~~
gnusty_gnurc
I think it's important to make the difference between generic and
intentionally designed.

Just using an "abstraction" doesn't mean that your code is abstract, it may
just not be a tangle of functions that were stringed together on the fly.

At least for me, there's a clear point where I've coded something and find
myself getting overwhelmed when making changes or trying to bridge the final
gap to completion. That's when I step back and try to make sense of it and
refactor.

------
ipsocannibal
If you follow the advice of this article your refactoring wizard becomes the
operations silo. Code quality on the team goes down overall because operations
silo Guy can't review all CR's himself and if he tries to the rest of the
teams velocity suffers. Don't worry operations silo Guy will clean it up later
anyway which doesn't happen because more code is written by the other
developers than operations silo Guy can refactor. Other developers on the team
will put off refactoring and automation work because that's now operations
silo Guy's domain. They grow rusty in those skills. You also lose the ability
to include operations silo Guy in swarming on features as he hasn't been
keeping up with the product's development because he's always refactoring some
old integ test or run script.

------
dgreensp
Yup, I’ve found that even when pretty much every engineer on the team knows
that velocity is slow because necessary refactors have not been done,
refactoring is often not considered real work and real progress. It’s the kind
of thing you’re supposed to do in your spare time, off the roadmap. Also,
people who find refactoring difficult or unpleasant will try to get you to see
things from their point of view! Or they and their teammates have tried so
many times to get the green light from leadership to pay down technical debt
that they have given up.

It’s underappreciated that developers have different strengths and interests
and could be doing different kinds of work rather than being treated as
interchangeable workers, even at a relatively small start-up, in my
experience.

------
codenesium
There is pointless refactoring but Fred sounds like a senior developer
cleaning up messes to me.

------
solinent
I think the biggest value of refactoring is reducing code size, which is
directly correlated with bug count / severity (there are tons of studies
here). Ultimately you're providing a huge value to your clients. If your code
stinks on the inside, it's gonna take a huge effort to make it smell nice on
the outside.

If you stop repeating yourself, you may make less mistakes because there are
simply less chances of it. Good abstractions help.

They also speed up your development speed, accelerating you towards your goal
instead of coasting.

~~~
flavious
Over-abstraction also has a non-negligeable cost.

~~~
solinent
Over-abstraction usually increases entropy, so your code size is bigger.

------
jspaetzel
I draw a parallel between refactoring and code ownership. Once I've worked in
an area of code for a while (several sprints) then I probably know enough to
try refactoring. Longer time working on it == more ability to refactor.

The idea of what is correct (to you and to others) and what needs refactoring
changes over time, even the product changes. Sometimes it can be beneficial to
wait a while and see if you still feel the same way after a few weeks.

------
CGamesPlay
If your team is 5 people, and each one makes the company 4% better every year,
then after a year the company is 3.3x better, and after 5 it's 403x better. If
you team is 5 people, but one of them makes other engineers 4% better each
year, and the rest focus on the company, then after a year the company is 3.2x
larger and after 5 it's 392x better. Wasn't worth it. At six engineers the
balance slightly shifts.

    
    
      Group                1 year   5 years  Gain
      5 product               3.3     403.4
      1 tools, 4 product      3.2     392.8  -2.6%
      6 product               3.5     492.7
      1 tools, 5 product      3.3     501.0  +1.7%
    

Now, obviously the team probably won't stay 5 engineers for 5 years, but my
point is: like everything else, this is a cost-benefit analysis. For small
teams, it turns out it's not worth it to have happy Fred on your team, and you
should let him go work on internal tools for a few dozen engineers where he
can have massive impact there.

------
ysavir
This blog posts describes the conflict as "providing value to other
developers" vs "providing value to users", but that's false dichotomy.
Refactoring isn't about providing value to other developers, it's about
reducing the complexity and investment necessary to make future changes.
That's valuable to the other developers, sure, but it's also valuable to the
business, and also valuable to the users.

While there's certainly something to be said for assigning people
responsibilities that work well with their personal strengths, that won't
compensate for misunderstanding the purpose of refactors, how and when to
apply them, and how to prevent the need for them in the first place. It's
essentially hiding the problem rather than identifying the problem and
introducing a relevant solution.

------
sfink
Codebases follow evolutionary paths. If the code isn't going to be needed for
long, there's no point in refactoring. If it does have a long lifespan, then
every change, every addition, has the potential to increase complexity and
make it harder to adapt. That's ok for a while, but in the longer term
requires a counterbalancing pressure in order to be sustainable.

Whether that pressure is provided by regular developers, or partly or wholly
by dedicated people, depends on the interests and skills of the people on
hand. Carving off a Fred is one successful strategy. So is having core
developers actively maintaining the integrity of the overall system as they
make changes.

You have to pick, or stumble upon, the right strategy for your situation and
staff.

------
waiwai933
The whole category of responsibilities listed (automated tests excepted) is
what tech leads effectively do where I work... is this not normal?

~~~
nullspace
IME, not really. And to be honest, I don't think it's a good idea to delegate
these tasks to a single person on the team.

~~~
waiwai933
I wouldn't say it's delegated necessarily, but we consider a tech lead's goal
to be unblocking the rest of the team, and if there's nothing specific to deal
with at any point (hah!), dealing with these points is often the most obvious
way of unblocking for the future.

Which isn't to say that the rest of the dev team can't do any of these things,
but the tech lead is almost always the most experienced dev, and a lot of the
DevOps type points aren't concrete ticket items, and a ticket which basically
says "Explore [X] to see if it'll help" is (a) potentially too abstract for a
very green dev and (b) the tech lead is probably best positioned to judge
whether there'll be any meaningful help in practice.

~~~
waiwai933
By way of example, I might write a dev ticket along the lines of:

Background/Goal: With a larger userbase, we would like to add a moderator
role. Users with this role would be able to hide posts, but not have any other
elevated privileges.

Suggested Implementation:

* Add Moderator to the UserRole enum

* Split the post hide/deletion privilege into two separate privileges

* Associate the post hide privilege with Moderator and Admin roles

* Associate the post deletion privilege with only the Admin role

But a "improve the deploy process" ticket would probably look more like:

Background/Goal: Deploys currently take fifteen minutes on average, from start
to finish. We would like to cut this down if feasible.

Potential Lines of Inquiry:

* Can we build things in parallel?

* Can we add more CPU/memory to our build environment?

* What would implementing blue/green deploys look like in terms of cost and benefit?

Comparing the two, you can see that the second is a lot more abstract--and
maybe this is just me being bad at ticket writing!

------
dave_aiello
The greatest difficulty I run into as an indy developer is lack of internal
documentation.

I often write something and don't look at it for a long time thereafter; In
the intervening period, I forget some important aspect of how this code works.
Or I inherit a piece of code from another developer, and I have no idea why it
was implemented the way it was.

I would love it if developers wrote a line of comment or two per function,
just laying out what's happening and why the code was written that way.

------
gregkerzhner
Having someone responsible for the dev environment and tools sounds great if
your team and organization has scaled enough to allow this.

Having one person be the point person for refactoring, tech debt and code
review on the other hand seems like a bad idea - these should be every
developer's responsibilities. This sounds like a pretty silly team overall -
all the team members write quick, messy code and then one person is on
"cleanup crew" fixing bugs and improving design?

Talk about a way to brew up some tension and misalignment on a team. "Hey
George... I know you are about to open a 2nd pull request to add additional
features to your work, but I just refactored your whole initial
implementation, and now there are 30 merge conflicts..."

We always talk about the bus rule at work - if someone got hit by a bus
tonight, would the team be able to operate tomorrow? If we had "refactor guy"
on our team though, I probably would have to resist not giving them a gentle
nudge forward every time we wait to cross the street together.

------
k__
I remember my first React project in 2015.

A co-worker initialized the project with CoffeeScript and Flummox, then
switched to ES6 and then switched to Redux.

It was a few thousand lines of code, so it was often "Yes we can add that new
feature when I did my refactoring" which often took weeks in which I couldn't
do anything valuable.

Also, the bugs that grew of those re-writes followed us for months.

------
thunderbong
Rule of Three

[https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...](https://en.wikipedia.org/wiki/Rule_of_three_\(computer_programming\))

[https://blog.codinghorror.com/rule-of-
three/](https://blog.codinghorror.com/rule-of-three/)

------
jariel
"Doesn’t it seem powerful, to have a person on your team completely dedicated
to helping other developers be as productive as they can be? "

Fred may be helping, he may be helping in an inefficient way, he may be doing
'make work', he may be screwing things up.

It depends more on the materiality of the outcome, not the motivation of the
effort.

------
dummydata
I have a Fred on my team. He recently took a few weeks to refactor a large
part of the codebase which consisted of about 200 file changes. The problem
with this approach is that he never discussed his changes with the team,
leaving the discussion until code review time. Some refactoring doesn't quite
need a discussion, but large changes should.

It should go without saying that I think refactoring is super valuable. The
way to go about it is to: 1\. Recognize what in the codebase you see an
opportunity to refactor 2\. Discuss with the team (more experienced developers
can have some useful suggestions) 3\. Write a separate ticket for the changes
(you can prioritize this after your required work)

Obviously, #3 won't work if your group doesn't value refactoring. In that
case, you should bring up the conversation. You'll probably find many/most of
your coworkers will be in agreement.

------
j_z_reeves
I welcome a coworker refactoring a section of the codebase to make it easier
to change in the future. I do not like it when a coworker, new to the project,
assumes that a certain way is incorrect. Like, introducing docker and
additional tooling when no one asked for it. I especially do not like it when
abstractions are unnecessarily forced.

Another perspective, if I am busy building out a feature and I open my source
control to several huge PRs containing trivial changes, I groan. Now, not only
do I have to respond to these PRs in a timely manner, I have to ensure that
the changes are part of a codebase's design roadmap.

Large refactorings should be discussed, agreed upon and expected. Breaking a
several thousand line module into a folder containing separate modules is nice
and a welcome endeavor. I just don't want to see it as part of a feature PR.
Discuss it and create a separate PR.

Also, just because you refactor, doesn't even your refactor is good. You can
refactor in a worse off way as well. Your refactor may make the codebase nicer
now, but could prevent easy changes later. Your refactor may go against best
practices. I have seen this from developers that are on the Dunning–Kruger
spectrum. Once again, refactors should be discussed and agreed upon.

As a side note, this seems like a great interview question to determine
cultural fit. I do not want to work with a "fred" that doesn't communicate
concerns and intentions.

------
mannykannot
I am sympathetic to this viewpoint, but I realized how infeasible it is with
this suggested use of Fred's obsessions: "quick and thorough code review".
People like Fred will never be _quick_ in their review, but boy, will they be
thorough! Everything presented for review will be rejected for being
fundamentally the wrong way to do the job, as explained in great detail.

Similarly, "refactoring and managing tech debt" will become "rewrite from
scratch", and "automating anything that can possibly be automated" and
"streamlining the deploy process" will be inordinately parameterized in order
to cover every possible (and hypothetical) edge case.

~~~
KMag
Not all people like Fred will act as you describe. When I was at Google,
Michael Chastain (I think he is/was a GDB maintainer) did lots of massive
refactorings across the whole Google codebase, and was one of the hand full of
people with ownership rights at the root of the source tree. He really was a
major force multiplier.

~~~
mannykannot
I don't know Michael Chastain, but I know people who fit your description,
and, unlike the generic Fred of the article, they are not slow to deliver
useful software - quite the opposite, in fact.

------
bsaul
on a side note, i've witnessed a big difference between code that was properly
architectured from the beginning, to code that evolved in a purely iterative
fashion, driven by end-user feature tickets.

Architecture design is to me a different beast from simply refactoring,
because it is also meant to anticipate future evolutions, in order to provide
a solid technical layer upon which feature can be iterated.

Unfortunately i don't think a lot of teams knows when is a good time to
seriously think about the time to (re)design / architecture a system. Nor what
is truely meant by "architecture" ( hint: no, it's not just about picking the
latest MVC variation of day).

------
neandrake
I identify with the motivations outlined in this post. One additional thing
I'll add is that refactoring allows me to learn and understand the existing
code base. Being able to move and rewrite code reminds me of playing with
Play-Doh. This practice lets me immerse myself into the code a bit more so I
can grok it more easily. Half the time my refactoring is thrown out or shelved
for ages so there's nothing in the project history to show for it other than
my new-found knowledge.

------
nix23
I like Fred, he cares about doing stuff the right way rather than get work
done, with Fred our Operating-system's would be much better/faster and easier
to maintain.

~~~
solidasparagus
Only if he managed to ship fast enough to compete...

~~~
nix23
Compete in what? NoSql Databases? The latest and greatest feature, witch often
is just unstable and badly designed?

------
vemv
It all boils down to one's personal motivations.

Refactoring and tooling work make sense if that work is oriented towards
increasing productivity and maintainability, using contrasted personal
experience, and skill.

Do you envision being _done_ at some point? Are you getting a actual
productivity boost with your meta-work? Are you solving problems proven to be
actual problems from previous experiences?

If not, it's better to introspect.

------
ccktlmazeltov
Honestly good and secure code is only achieved through multiple refactoring. I
hate people who just jump from features to features and have no intention of
maintaining and on improving a piece of code once it's written. This is how
you get tech debt.

------
zaro
Yep, that's me. Features are simply something that happens as a byproduct of a
refactor.

------
hnruss
If refactoring didn’t introduce regressions, then that would be great to have
someone constantly refactoring to improve the codebase. In my experience
though, it often makes more work for the rest of the team, sometimes for years
afterwards.

------
spaetzleesser
I often refactor code as a way to procrastinate on other tasks I am not sure
about how to approach them. Sometimes it's productive and results in better
code but sometimes it's just shuffling code around without much improvement.

------
zabil
Great read. Especially the point about developers vs users.

Programming langauges and IDE's have an effect too in my opinion. I've found
myself and other team members refactoring much more when using OOP languages.
Design is very subjective.

------
kapakos
I call the coworker that is described in the article a ‘senior engineer’.

------
seancoleman
I loved the term a colleague used for this: refactorbation.

------
yummypaint
[https://www.youtube.com/watch?v=dQdsFpvTKU4](https://www.youtube.com/watch?v=dQdsFpvTKU4)

------
praveenperera
The fear would be Fred runs out of useful refactoring and starts creating work
for himself.

When you're a hammer everything looks like a nail syndrome?

------
mullikine
I would like to put this in the personality profile part of my CV

------
zwilliamson
I believe they call this person a “catfish” developer

~~~
avierax
No they don't... Catfish developers are precisely those who endure doing work
that everyone else despises. Fred is just doing what he likes.

------
polymonster
Refactoring is life

------
jlucktay
Hi, it's me, I'm Fred

------
donatj
My advice? Be Fred.

~~~
MichaelRazum
My advice short: Fire Fred. Long: Depends on your process. Generally you
should have refactoring tasks. So a dev detected bad architecture or some
issue in the ticket. Then do the stuff and make a refactoring task. Or change
the ticket. This way Fred would have enough of work that he loves. Sometimes
he should do also stuff which he hates - its a job.

I said fire because it reminds me of a coworker who was very lazy. He
complained about code (yes it was messy) but he was extremly slow in
delivering. Simple tasks took 5x the time they should take and the refactoring
wasn't that good. I mean 2x the time might be ok if you improve stuff. But no
way a 5x delay. Especially in a large project, if there are some really messy
things, you need to talk with other devs to decide on architecture and so on.
It's no way a one man show.

------
Trias11
Yup. That's me.

I hate shitty band-aid code. I love perfection.

I'm Michelangelo - but that by definition makes me a loner. I love staring at
my code and contemplate on it's beauty just like the result of the code
working.

I'm perfect at one-man projects.

I hate processes, standups, scrums and all that team playing bullshit.

I love customers and bosses who are trusting and freedom giving.

I love beers, steaks, good food and team gatherings - and i love people whom i
am "working" with - but everyone knows i am working on something that is NOT
"let get this shit done quickly and push this out of the door by next friday".
That's not me.

Although I'm the one my boss comes to with "i don't know how but can you do
something about it tomorrow"? I'm good and super sharp focusing and delivering
on my own. If i need help - I'll ask.

I'm all for skunkworks.

I debug my code myself, using techniques i polished myself over the years and
I'll end up with lightbulb that will last 100 yrs. Not the one that cost $3
and requires full replacement after 3.5 weeks of light usage.

I try not to buy stuff made in China. I love stuff made in Europe or Japan.

So, don't push guys like me into your "processes" and "change managements"
wasting pipeline bullshit.

I won't fit.

I speak at conferences. I do evil harmless things. I violate countless stupid
compliance rules. I take risks no one knows about. I don't follow rules, and
pretty much skip reading them when i can.

I do my best to deliver masterpieces. One piece at a time.

Downvote me.

~~~
mnky9800n
This reads like the Morty speech in Rick and Morty when the good parts of
Morty go off and become a stock broker.

I feel like the only thing you are actually good at is working by yourself
because participating in a society seems far too difficult for you.

~~~
amdeiJH
Society, noun: A clique of people using arbitrary compliance tests and
popularity contests like teenagers to create a virtual hierarchy.

People further up the top of the hierarchy take the economic output of the
ever decreasing number of work horses while contributing nothing but talk.

~~~
Joker_vD
This emergent phenomenon is pretty much hard-coded in humans. Vide: the entire
human history. Confer: multiple social experiments of building "the perfect
society".

~~~
nescoiquid
Each animal can be said to posses a survival strategy; ours resides not in
talons, or rapid flight, or keen perception, or camouflage, but in
cooperation. Even the hierarchical structure of our social organization aids
in this.

It is a humble observation, even if it was difficult for me to appreciate for
such a long time.

------
blahbhthrow3748
Personally when people move into the "dev tools" role they often seem to lose
sight of the forest for the trees. They'll argue for an idealized workflow -
everything has to have 80% test coverage, everything has to have tracing,
everyone's editor needs an exact set of plugins. They start out fixing
papercuts they've personally experienced and end up building tooling to solve
problems nobody has.

