18 ms·

That coworker who never stops refactoring

• tyingq 6y ago
  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 6y ago
    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.
• dmitryminkovsky 6y ago
  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.
• staysaasy 6y ago
  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 6y ago
    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.
• secondcoming 6y ago
  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.
  • Kednicma 6y ago
    Fred's employer needs labor. Fred is doing labor which the employer doesn't know it should value. The employer needs to learn about the cost of maintaining code over time; everyone would love to be in a position to produce features and customer value all day and never have to maintain what they've built. The employer could structure their teams and sprints so that refactoring and other maintenance tasks are built-in, but instead let it become invisible work which cuts into labor. Don't be Fred's employer. Set up teams which build tools, maintain developer infrastructure, work across the company to improve code quality standards, and ease the burden of deploying services at scale. I've been at three different employers on the equivalent of a tools team. It's a pleasure to have fellow developers as my customers, and I understand that my role is integral to not just success, but comfort and peace of mind.
    • secondcoming 6y ago
      It's not really about the employer, it's Fred. Fred is treating his assigned work as though it was titled 'Implement Feature X (and also anything else you'd like to do)'. That's just bad discipline. There's a time and a place for refactoring. If Feature X cannot actually be done without refactoring then mark that ticket as blocked, and start work on a new ticket that will unblock it.
  • CraigJPerry 6y ago
    Fred’s possibly a “DevOps Engineer” or maybe a “Tech Lead”. It’s conceivable he understands the software delivery game better than the “just ship it” brigade who don’t really care beyond what the jira ticket says. I wonder if Fred accurately estimates his work to include all the quality, longevity and cost reduction work he does but just gets shouted down as pessimistic during their iteration planning?
• simonw 6y ago
  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 6y ago
    Yup, instead of DRY I'm a big fan of WET, Write Everything Twice. Third time? Maybe consider a refactor at that point.
    • weego 6y ago
      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.
      • landryraccoon 6y ago
        Wow, you just blew my mind. "Don't Repeat Yourself" could just be premature optimization and overfitting on a tiny data set.
        • gsej 6y ago
          Absolutely. This has been discussed here quite a bit (e.g. https://news.ycombinator.com/item?id=120614530 https://news.ycombinator.com/item?id=120614530). In real life it's often visible when you have methods that take one or more flags to tell them how to behave. Fixing involves duplicating the method - one copy for calls where the flag is true, one for where it is false. Then simplifying, then repeating. The code that falls out at the end is often dramatically simpler than what was there before. It makes me wonder about some of these programming aphorisms - they only seem to work if you are already experienced enough to know to take them with a pinch of salt.
• waiwai933 6y ago
  The whole category of responsibilities listed (automated tests excepted) is what tech leads effectively do where I work... is this not normal?
  • nullspace 6y ago
    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 6y ago
      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 6y ago
        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!
• yummypaint 6y ago
  https://www.youtube.com/watch?v=dQdsFpvTKU4 https://www.youtube.com/watch?v=dQdsFpvTKU4
• thunderbong 6y ago
  Rule of Three https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... https://blog.codinghorror.com/rule-of-three/ https://blog.codinghorror.com/rule-of-three/
• praveenperera 6y ago
  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?
• Wandfarbe 6y ago
  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.
  • fiddlerwoaroof 6y ago
    I agree, the teams that cause the biggest messes are, in my experience, the ones that passively receive requirements from POs, without thinking about the conceptual integrity of their domain. However, complaints about stories taking “too long” sometimes are complaints that people are trying to do a better job on a story than specified.
  • codingdave 6y ago
    100% Agree - I am the PO on my product. I was the original coder, I know this code better than any of the newer devs. And yet they bring so many great ideas to the table that make the product far better than what I wrote up in a story. They make the code better, they ask great questions, they propose changes to designs and features... and we then end up with a much stronger product. The stakeholders love the results we are coming up with, and I'm thrilled with where the product is going, and the devs enjoy contributing at multiple levels and having some autonomy.
  • thdc 6y ago
    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 6y ago
      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.
• neandrake 6y ago
  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.
• codenesium 6y ago
  There is pointless refactoring but Fred sounds like a senior developer cleaning up messes to me.
• thinkingkong 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        Guess how much that person likes getting assigned to write tests after 6 months to years?
• cle 6y ago
  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.
• zabil 6y ago
  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.
• adamsvystun 6y ago
  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.
• k__ 6y ago
  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.
• dave_aiello 6y ago
  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.
• fudged71 6y ago
  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 6y ago
    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).
• gfodor 6y ago
  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 6y ago
    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)
• bsaul 6y ago
  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).
• rconti 6y ago
  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.
• ysavir 6y ago
  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.
• mannykannot 6y ago
  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 6y ago
    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 6y ago
      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.
• jeherr 6y ago
  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 6y ago
    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.
  • AnthonBerg 6y ago
    It's also that the cognitive systems variant usually called ADHD is highly flexible, broadly scoped, continously introspective, sensitive towards inefficiency, and can intuitively pattern-match across different contexts. This means that the "ADHD" mind is just better at seeing what needs to be improved in processes and tooling.
• tarkin2 6y ago
  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 6y ago
    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.
• watwut 6y ago
  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".
• juliendc 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        That explains it perfectly...thank you.
• dgreensp 6y ago
  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.
• BurningFrog 6y ago
  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.
• chojeen 6y ago
  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.
• dummydata 6y ago
  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.
• gregkerzhner 6y ago
  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.
• DanielBMarkham 6y ago
  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 6y ago
    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?
• toomanybeersies 6y ago
  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.
• nix23 6y ago
  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 6y ago
    Only if he managed to ship fast enough to compete...
    • nix23 6y ago
      Compete in what? NoSql Databases? The latest and greatest feature, witch often is just unstable and badly designed?
• zaro 6y ago
  Yep, that's me. Features are simply something that happens as a byproduct of a refactor.
• mcv 6y ago
  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.
• jll29 6y ago
  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, ...).
  • celim307 6y ago
    We have someone on our team who maintains and develops a repository that is basically ran as a OSS project that directly services our main product. It’s wonderful. With guaranteed longevity and having internal devs as the customer, things like on boarding are a snap. The documentation is comprehensive and there’s a slack channel monitored 24:7 for questions and onboarding.
  • hardwaregeek 6y ago
    Yeah, it's similar to the toolsmith position in the surgical team model that Brooks espouses: https://wiki.c2.com/?SurgicalTeam https://wiki.c2.com/?SurgicalTeam Of course there should probably be a toolsmith at the team level, but also at the org or even company level to avoid the re-inventing problem you mention.
  • dgb23 6y ago
    I really like this term! Because it implies that Fred is not just doing refactoring, optimization and automation work but also writes new code that others use/interact with (hopefully with sufficient documentation). Also because I'm often this kind of Fred, sometimes because it is expected of me, sometimes because I just have a natural urge to do so. However with the caveat that I also complete features and projects as is the nature of my work. In the past I was _too_ Fred-like, but with experience comes pragmatism I guess. KISS and YAGNI are the mantras that keep Fredism at bay. A simple yet effective technique to fight Fredism when inappropriate is to just write things down in plain $Language and keep going with your feature/ticket/task. It also helps in another way: Sometimes the first instinct is not the right one so you avoid premature optimization etc. by sleeping over it, bouncing it off your collaborators/team and so on.
• vemv 6y ago
  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.
• gbuk2013 6y ago
  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 6y ago
    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 6y ago
      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.
• sfink 6y ago
  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.
• jspaetzel 6y ago
  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.
• dmalvarado 6y ago
  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 6y ago
    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?
  • gkrimer 6y ago
    Yep, me too! Please come to Google. This is the only place that I have ever worked that values code quality and testability, rather than just saying it values these and then letting everything fly to meet some arbitrary deadlines. There are downsides to working here as well though. Happy to chat! gkrimer@geeeeeemail.com
• polymonster 6y ago
  Refactoring is life
• renewiltord 6y ago
  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.
  • gtirloni 6y ago
    This attitude sounds awful. Hopefully we never work together in the future.
    • renewiltord 6y ago
      Glad to hear it. I try to be as transparent as possible with my expectations so if we're ever in a situation where we might end up working together, you'll know so you can dodge me. Early compatibility checks are great, imho.
    • ci5er 6y ago
      Wow. Can you tell me what you DO believe (affirmatively), so that I can interview against it in the future?
  • dgb23 6y ago
    I think there is a fitting English saying that kind of sounds like "eat your own pie" or something like that. I can't find it! I agree with your general sentiment. But there are situations and teams where programmers don't tend to have an optimal individual skill-distribution so to speak. Surely there is an opportunity to complement each other to a certain degree.
• jariel 6y ago
  "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.
• solinent 6y ago
  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 6y ago
    Over-abstraction also has a non-negligeable cost.
    • solinent 6y ago
      Over-abstraction usually increases entropy, so your code size is bigger.
• blahbhthrow3748 6y ago
  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.
• seancoleman 6y ago
  I loved the term a colleague used for this: refactorbation.
• zwilliamson 6y ago
  I believe they call this person a “catfish” developer
  • avierax 6y ago
    No they don't... Catfish developers are precisely those who endure doing work that everyone else despises. Fred is just doing what he likes.
• CGamesPlay 6y ago
  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.
• bcrosby95 6y ago
  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 6y ago
    I don't understand; why would tests and automation be discarded just because Fred leaves?
    • dack 6y ago
      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.
    • polygot 6y ago
      I'm not the OP, but I think they mean that the tests will slowly become out of date (if nobody else is updating them.)
    • toast0 6y ago
      Requirement changes, I change the code, test fails, I remove the test, Fred isn't there to speak for the test. Automation fails, I turn it off and run the thing by hand. Fred isn't there to turn the automation back on, or yell at me for running it by hand instead of fixing the automation.
  • dack 6y ago
    Right, if the root cause is a culture issue (which results in not having adequate testing), then having Fred write the missing tests will not solve it.
• spacemanmatt 6y ago
  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.
• Trias11 6y ago
  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.
  • hhh 6y ago
    god bless you soldier
    • Trias11 6y ago
      Thank you. true master carry no sword
  • tristan_ph 6y ago
    someone has to write this in manifesto format
    • tjr225 6y ago
      It also reads like absurd satire- but the line between the two is thin.
• donatj 6y ago
  My advice? Be Fred.
  • MichaelRazum 6y ago
    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.
• spaetzleesser 6y ago
  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.
• ccktlmazeltov 6y ago
  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.
• aaanotherhnfolk 6y ago
  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.
• mullikine 6y ago
  I would like to put this in the personality profile part of my CV
• hnruss 6y ago
  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.
• j_z_reeves 6y ago
  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.
• kapakos 6y ago
  I call the coworker that is described in the article a ‘senior engineer’.
• vp8989 6y ago
  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
• ipsocannibal 6y ago
  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.
• jlucktay 6y ago
  Hi, it's me, I'm Fred