5 ms·

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

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?
sumtechguy 6y ago
Worst case Fred spends 2 years doing that chases off all of the customers as he is not adding features and the whole division is laid off. At least they had a nice severance package.... In my exp re-factor happens when you add a new feature and it does not fit into the existing framework. Sort of a arch version of the rule of 3.
thinkharderdev 6y ago
That doesn't seem like a fair characterization. The distinction between "refactoring" and "implementing a feature" is not always very clear. If a new feature violates some assumption of a dependent API, do you hack around it or refactor the dependent API to take change the underlying assumption. The refactor may not be strictly necessary to get the feature to work, but an experience developer may understand that the hack, quick solution will cause other more serious issues later and choose to do more work up front to head it off. Should that be a new ticket or a separate task? Maybe. We have to make judgements calls all the time on stuff like that and I don't think it is really possible to micromanage development of a complex application that way.
WJW 6y ago
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 6y ago
  "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 6y ago
    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.
- mcv 6y ago
  I make tickets for my refactorings. Solving tech debt is also important. You're spot on, though. I'm currently in a position where I refactor a lot. This is in a team that started with just me cobbling together a prototype, later with two other freelancers. We'd regularly completely reorganise our entire stack, because we were still figuring stuff out. Now it's a team with 7 developers, an actual PO, a separate scrum master and a designer, and I still love to refactor stuff while everybody else is building features. Another freelancer that's still left is our infra guru and he keeps tinkering with that instead of building features, but it's definitely helping the team.
netsectoday 6y ago
Fred understands that it's unsustainable to always deliver features. Fred has been doing this for years. Fred knows the ropes. Fred has morals and stopped producing garbage code because he knows how painful it is for the whole team. Fred intelligently does it as part of the requested workflow because he knows it'll be heavily scrutinized by non-technical staff. Fred knows that deadlines are made up and don't mean anything, and should probably find a new job because he's not valued within his organization. Be Fred. Get fired.
- watwut 6y ago
  Based on that strawman story, all other developers despise Fred. So maybe his refactorings are not that great? And if they are great, where is tech lead or other developers in all that that should protect Fred?
  - cosmiccatnap 6y ago
    Wooshed over you I see...Fred will get a better job and everyone at the company understands Fred because they are all Fred at heart but they like where they live and they can't afford to spend the time job hunting or moving cities with another kid on the way. Fred doesn't have kids, Fred has projects and ideas and the only people who don't understand why Fred is doing what he's doing are managers who can't understand why they are paying him for a week with no features even though there is a very very good chance he has cut down future development time considerably. Be Fred, quit your crappy job until you find one that can use your talents instead of calling you dead weight for exercising a grain of innovation in an otherwise destitute business grind.
- hhas01 6y ago
  Refactoring is what you do to existing, rough production code as a prelude to developing new features on top of it, so that the new code is built on a solid foundation and the whole lot doesn’t degenerate into a big ball of mud. Therefore, if refactoring is all that Fred does, he’s not adding value, he’s an OCD hack and/or make-work bluffer who’s masturbating the code for his own gratification. Sack his worthless disruptive ass and move forward already.
gfodor 6y ago
If Fred was spending his days fingerpainting on the walls, you may have a point. I don't like the idea of being a technical leader and frowning upon people doing productive, deep, technical work because it doesn't check a dozen boxes of being on the approved list of things to be working on. The art of management is to take that creative energy, skill, and passion and direct it towards generating value for the organization. Top tier teams happen in part because management flips this bit from zero to one for each team member, through leadership, coaching, decision making, and providing 'air cover.' You go to war with the army you have, and the best leaders turn people who would fail under average leaders into superstars. If this is the person's only flaw, and they're otherwise a great team member, good person, and capable engineer, if they are ultimately fired, that is management's fault, not Fred's.
dgreensp 6y ago
Blaming employees for breakdowns in process and communication and firing them is one way to run a team. This article proposes an alternative to that.
__MatrixMan__ 6y ago
... Unless they're really good at it. I hate to admit it, but I'm a Fred. Extrinsic motivation doesn't work well for me. Yeah, I need to make some money I guess, but I'll make some pretty hefty compromises re: pay and benefits if it means working with an interesting stack or on an interesting problem because intrinsically motivated work is far higher quality for me than extrinsically motivated work. A common pattern in my career is that my work stands out in some way that causes me to get pulled out of the main grind--and put on some fun special project. As long as the value you're providing by being a Fred is greater than the value of the job you were hired to do, I find that they'll find ways to keep you around. I do feel like a Jerk sometimes because I end up getting what feels like a promotion for doing my job poorly, while those doing it well have to stay and keep doing it, but when I buckle down and keep my nose to the grindstone I end up writing shitty code and letting my team down. If Fred is otherwise hard working, there's probably a place for him nearby.
boxed 6y ago
I'm a Fred. Not fired, getting good raises every year. Gets huge support from the team because they see I'm working for them. Don't be in a job that fires Fred. That job is a ticking bomb.
tehjoker 6y ago
Fred was a human performing a craft and applied science with ingenuity, experience, and some autonomy. Then people tried to beat that out of him because they belonged to a hierarchical organization based around various kinds of punishments.
SeriousM 6y ago
Your definition of Fred is someone who's not communicate the problems and tries to fix them during the time he needs to do planned work. I was a real Fred and did exactly that. My work was really valued but I always had the impression that no one really saw my intentions and the importance of this extra work. In the end I burned because of this. Today I'm still a Fred but I learned that transparency is the key to successful communication. If something is odd and needs refactoring that doesn't fit in my current ticket I raise a new ticket with exactly the problem I found (instead leaving a dead Todo in the code). Then I discuss this finding in the next planning and we budget to do it if it's required to be done. Most of the time it helps tremendously to share thongs with my colleagues and welcome up with an even better solutions than I came up in the first place. That's a Fred you want to have in your team.
flavious 6y ago
Fred should learn how to squeeze in his refactorings into other, related tickets. And to learn how to argue about why an user story is more points worth, without explicitly saying the R word.

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?

sumtechguy 6y ago

Worst case Fred spends 2 years doing that chases off all of the customers as he is not adding features and the whole division is laid off. At least they had a nice severance package.... In my exp re-factor happens when you add a new feature and it does not fit into the existing framework. Sort of a arch version of the rule of 3.

thinkharderdev 6y ago

That doesn't seem like a fair characterization. The distinction between "refactoring" and "implementing a feature" is not always very clear. If a new feature violates some assumption of a dependent API, do you hack around it or refactor the dependent API to take change the underlying assumption. The refactor may not be strictly necessary to get the feature to work, but an experience developer may understand that the hack, quick solution will cause other more serious issues later and choose to do more work up front to head it off. Should that be a new ticket or a separate task? Maybe. We have to make judgements calls all the time on stuff like that and I don't think it is really possible to micromanage development of a complex application that way.

WJW 6y ago

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 6y ago
"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 6y ago
  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.
mcv 6y ago
I make tickets for my refactorings. Solving tech debt is also important. You're spot on, though. I'm currently in a position where I refactor a lot. This is in a team that started with just me cobbling together a prototype, later with two other freelancers. We'd regularly completely reorganise our entire stack, because we were still figuring stuff out. Now it's a team with 7 developers, an actual PO, a separate scrum master and a designer, and I still love to refactor stuff while everybody else is building features. Another freelancer that's still left is our infra guru and he keeps tinkering with that instead of building features, but it's definitely helping the team.

netsectoday 6y ago

Fred understands that it's unsustainable to always deliver features. Fred has been doing this for years. Fred knows the ropes. Fred has morals and stopped producing garbage code because he knows how painful it is for the whole team. Fred intelligently does it as part of the requested workflow because he knows it'll be heavily scrutinized by non-technical staff. Fred knows that deadlines are made up and don't mean anything, and should probably find a new job because he's not valued within his organization. Be Fred. Get fired.

watwut 6y ago
Based on that strawman story, all other developers despise Fred. So maybe his refactorings are not that great? And if they are great, where is tech lead or other developers in all that that should protect Fred?
- cosmiccatnap 6y ago
  Wooshed over you I see...Fred will get a better job and everyone at the company understands Fred because they are all Fred at heart but they like where they live and they can't afford to spend the time job hunting or moving cities with another kid on the way. Fred doesn't have kids, Fred has projects and ideas and the only people who don't understand why Fred is doing what he's doing are managers who can't understand why they are paying him for a week with no features even though there is a very very good chance he has cut down future development time considerably. Be Fred, quit your crappy job until you find one that can use your talents instead of calling you dead weight for exercising a grain of innovation in an otherwise destitute business grind.
hhas01 6y ago
Refactoring is what you do to existing, rough production code as a prelude to developing new features on top of it, so that the new code is built on a solid foundation and the whole lot doesn’t degenerate into a big ball of mud. Therefore, if refactoring is all that Fred does, he’s not adding value, he’s an OCD hack and/or make-work bluffer who’s masturbating the code for his own gratification. Sack his worthless disruptive ass and move forward already.

gfodor 6y ago

If Fred was spending his days fingerpainting on the walls, you may have a point. I don't like the idea of being a technical leader and frowning upon people doing productive, deep, technical work because it doesn't check a dozen boxes of being on the approved list of things to be working on. The art of management is to take that creative energy, skill, and passion and direct it towards generating value for the organization. Top tier teams happen in part because management flips this bit from zero to one for each team member, through leadership, coaching, decision making, and providing 'air cover.' You go to war with the army you have, and the best leaders turn people who would fail under average leaders into superstars. If this is the person's only flaw, and they're otherwise a great team member, good person, and capable engineer, if they are ultimately fired, that is management's fault, not Fred's.

dgreensp 6y ago

Blaming employees for breakdowns in process and communication and firing them is one way to run a team. This article proposes an alternative to that.

__MatrixMan__ 6y ago

... Unless they're really good at it. I hate to admit it, but I'm a Fred. Extrinsic motivation doesn't work well for me. Yeah, I need to make some money I guess, but I'll make some pretty hefty compromises re: pay and benefits if it means working with an interesting stack or on an interesting problem because intrinsically motivated work is far higher quality for me than extrinsically motivated work. A common pattern in my career is that my work stands out in some way that causes me to get pulled out of the main grind--and put on some fun special project. As long as the value you're providing by being a Fred is greater than the value of the job you were hired to do, I find that they'll find ways to keep you around. I do feel like a Jerk sometimes because I end up getting what feels like a promotion for doing my job poorly, while those doing it well have to stay and keep doing it, but when I buckle down and keep my nose to the grindstone I end up writing shitty code and letting my team down. If Fred is otherwise hard working, there's probably a place for him nearby.

boxed 6y ago

I'm a Fred. Not fired, getting good raises every year. Gets huge support from the team because they see I'm working for them. Don't be in a job that fires Fred. That job is a ticking bomb.

tehjoker 6y ago

Fred was a human performing a craft and applied science with ingenuity, experience, and some autonomy. Then people tried to beat that out of him because they belonged to a hierarchical organization based around various kinds of punishments.

SeriousM 6y ago

Your definition of Fred is someone who's not communicate the problems and tries to fix them during the time he needs to do planned work. I was a real Fred and did exactly that. My work was really valued but I always had the impression that no one really saw my intentions and the importance of this extra work. In the end I burned because of this. Today I'm still a Fred but I learned that transparency is the key to successful communication. If something is odd and needs refactoring that doesn't fit in my current ticket I raise a new ticket with exactly the problem I found (instead leaving a dead Todo in the code). Then I discuss this finding in the next planning and we budget to do it if it's required to be done. Most of the time it helps tremendously to share thongs with my colleagues and welcome up with an even better solutions than I came up in the first place. That's a Fred you want to have in your team.

flavious 6y ago

Fred should learn how to squeeze in his refactorings into other, related tickets. And to learn how to argue about why an user story is more points worth, without explicitly saying the R word.