4 ms·

This is a great article, I can relate. I specialise in replacing large parts of codebases with code that does the same thing from a business point of view but t

This is a great article, I can relate. I specialise in replacing large parts of codebases with code that does the same thing from a business point of view but that makes future changes cheaper to make. One thing I thing that is worth mentioning is the political aspect of this sort of work. The people in power need to be comfortable with the fact that you will be introducing risk without immediate reward. That is a tough sell to someone who is used to putting out fires and writing root cause analysis reports to management. Sometimes this can’t be done and you have to hide your refactor in real business change work. This is not fun because it usually makes it look like you’re a slow dev. In addition, most developers are fiercely defensive of their code and you need to be aware of that when you chose to replace it. A trick I find useful is publicly declaring, in your team meeting, how useful you found x members tests in covering your refactor. Or their comments or documentation or domain knowledge. When you are picking their brains for implementation specifics try to sympathise with them when you see a bit of hacky or confusing code. Say “I’ve had to do something like that before because of xyz”. It will save face and you will get more out of the developer. Never criticise, they will know what they have done wrong without you telling them. Just, be nice. If you are looking for devs that can do this sort of work effectively then get them to read code in an interview and explain what it does to you. They can even offer suggestions and you get to see how they deliver criticism. Not complex algorithmic code but simple vast swaths of business junk.

sgtnoodle 6y ago
That's basically been my job the last five years. As soon as I joined the company (a scrappy startup of 30 people), I started refactoring large portions of mission critical code prioritized mostly by how terrified other coworkers were of touching it. In the beginning, folk were rather skeptical, but now that the company has grown by an order of magnitude, my earlier work has apparently become a topic of folklore in other parts of the company. As it usually goes, I spend most of my time these days mentoring and in meetings, but I still try to find time to refactor more fragile bits of code before they fall over completely. I encourage my team to tackle technical debt head on rather than work around it whenever possible. Far too often, folk spend more time avoiding solving a problem by patching around it, and it's usually because they're too afraid to dive in and change code that's hard to understand and therefore scary. For whatever reason, I've always had a can-do attitude when it comes to that type of work. You're paying me to get the job done, so give me an impact driver and the biggest hammer you've got. If I break something, it usually means it wasn't built strong enough to begin with. I've broken a lot of stuff over the years...
- zealsham 6y ago
  Is this Jeff Dean ?.
  - sgtnoodle 6y ago
    Lol, maybe the crappier Arduino version. My name is Jeff though.
- plif 6y ago
  > If I break something, it usually means it wasn't built strong enough to begin with. I've broken a lot of stuff over the years... Based on my experience, this statement scares me :) Not to pass any judgment on your impact or abilities, however the types of devs that have been the most challenging for me to work with are those with this attitude that aren't quite as good as they think they are. It can be incredibly toxic to the rest of the dev team and generally bad for business. You need to have a very strong handle of both the business side an tech side to do this type of work effectively. Meaning: no matter how much technical debt there may be, some stuff cannot afford to be broken. Judging risk there is quite challenging as you need a holistic view. I would strongly caution people from diving in and making sweeping changes if they don't have this. The other internal flag that went off is refactors that improve parts of the codebase in isolation while leaving a less cohesive / congruent codebase a whole. This is often worse in the long run than just patching it and actually can make changes harder. Disclaimer: I am in mostly a management role now so you can take the above with an appropriately sized grain of salt.
  - sgtnoodle 6y ago
    Certainly you want a refactoring effort to improve reliability and maintainability rather than harm them. I am a strong proponent of writing an "architecture document" before touching code to do anything but patch a straight forward bug, and soliciting feedback on it long before code review. This is precisely what develops that holistic view you mention. One of the first things I tackled in this codebase was to introduce abstractions to enable unit testing of code that was previously considered not unit testable. As the team has grown, we've developed processes to ensure that everyone explicitly considers risks and how to mitigate them whenever they make a code change. I also agree with you that it's best to be pragmatic when it comes to developing software for a business. Code that's ugly but works is perfectly fine. When it no longer works one day, patching it to keep the lights on is the right course of action. When the same ugly code breaks over and over, though, it's time to solve the root of the problem. Sometimes there's inherent risk in doing that, and things break; it's necessary to do it for the long term good, though. I try to write code that doesn't need to be touched again, but is pleasant enough to dive back into should you inevitably need to extend or debug it. I also try to reuse existing code and improve it as needed rather than create what I call "parallel codebases". I try to mentor my coworkers to do the same. If achieved, then it's a huge productivity multiplier. I think I'm pretty easy to work with. I am confident in my abilities as a software engineer, but I'm also relatively modest. I try to respect work that was done before me and carry the good parts forward if it ends up needing refactoring. I prefer to let less experienced coworkers tackle problems similar to problems I've solved in the past while providing mentorship, so that they can learn similar lessons. I've avoided management because I know I'm bad at it, but I try to support management however best I can. I also throw the occasional team homemade pizza party when there aren't pandemics. Notably, I also tend to be able to work with the stereotypical difficult-to-work-with devs that you mention. My coworkers generally seem to say nice things about me to my face and behind my back, and upper management seems to reflect their appreciation financially. Honestly my biggest interpersonal problem at work right now is that newer employees seem to hesitate reaching out to me for fear of wasting my time. Therefore I try to make it known that I spend as much time staring at the wall as possible during work hours.
cornel_io 6y ago
Yes, absolutely never criticize - as a manager, the #1 thing that makes me start to hate a report is when they complain about other people's work. Most of the time they don't understand why code was written the way it was (Chesterton's fence), and even when they do and are making valid complaints it's just a dick move that doesn't help. Trust me, the lead and manager both know when someone sucks, they don't need to hear more about it. And if you're wrong with your criticisms, you just demonstrate that you suck. Literally lose lose.
- Erlich_Bachman 6y ago
  > Trust me, the lead and manager both know when someone sucks Through which mechanism do you think they know it? If nobody ever tells them that some piece of code is bad, this mechanism doesn't do its job.
hackeredje 6y ago
Given time, every developer will end up in some company, doing projects, having to go trough other vast requirements, documentation, databases, interfaces and codebases to understand these. So I think you refer to persons who do not do projects but who stay i one company for a large time versus people who do projects (and are sometimes called consultants) and in general how they communicate with each other.

sgtnoodle 6y ago

That's basically been my job the last five years. As soon as I joined the company (a scrappy startup of 30 people), I started refactoring large portions of mission critical code prioritized mostly by how terrified other coworkers were of touching it. In the beginning, folk were rather skeptical, but now that the company has grown by an order of magnitude, my earlier work has apparently become a topic of folklore in other parts of the company. As it usually goes, I spend most of my time these days mentoring and in meetings, but I still try to find time to refactor more fragile bits of code before they fall over completely. I encourage my team to tackle technical debt head on rather than work around it whenever possible. Far too often, folk spend more time avoiding solving a problem by patching around it, and it's usually because they're too afraid to dive in and change code that's hard to understand and therefore scary. For whatever reason, I've always had a can-do attitude when it comes to that type of work. You're paying me to get the job done, so give me an impact driver and the biggest hammer you've got. If I break something, it usually means it wasn't built strong enough to begin with. I've broken a lot of stuff over the years...

zealsham 6y ago
Is this Jeff Dean ?.
- sgtnoodle 6y ago
  Lol, maybe the crappier Arduino version. My name is Jeff though.
plif 6y ago
> If I break something, it usually means it wasn't built strong enough to begin with. I've broken a lot of stuff over the years... Based on my experience, this statement scares me :) Not to pass any judgment on your impact or abilities, however the types of devs that have been the most challenging for me to work with are those with this attitude that aren't quite as good as they think they are. It can be incredibly toxic to the rest of the dev team and generally bad for business. You need to have a very strong handle of both the business side an tech side to do this type of work effectively. Meaning: no matter how much technical debt there may be, some stuff cannot afford to be broken. Judging risk there is quite challenging as you need a holistic view. I would strongly caution people from diving in and making sweeping changes if they don't have this. The other internal flag that went off is refactors that improve parts of the codebase in isolation while leaving a less cohesive / congruent codebase a whole. This is often worse in the long run than just patching it and actually can make changes harder. Disclaimer: I am in mostly a management role now so you can take the above with an appropriately sized grain of salt.
- sgtnoodle 6y ago
  Certainly you want a refactoring effort to improve reliability and maintainability rather than harm them. I am a strong proponent of writing an "architecture document" before touching code to do anything but patch a straight forward bug, and soliciting feedback on it long before code review. This is precisely what develops that holistic view you mention. One of the first things I tackled in this codebase was to introduce abstractions to enable unit testing of code that was previously considered not unit testable. As the team has grown, we've developed processes to ensure that everyone explicitly considers risks and how to mitigate them whenever they make a code change. I also agree with you that it's best to be pragmatic when it comes to developing software for a business. Code that's ugly but works is perfectly fine. When it no longer works one day, patching it to keep the lights on is the right course of action. When the same ugly code breaks over and over, though, it's time to solve the root of the problem. Sometimes there's inherent risk in doing that, and things break; it's necessary to do it for the long term good, though. I try to write code that doesn't need to be touched again, but is pleasant enough to dive back into should you inevitably need to extend or debug it. I also try to reuse existing code and improve it as needed rather than create what I call "parallel codebases". I try to mentor my coworkers to do the same. If achieved, then it's a huge productivity multiplier. I think I'm pretty easy to work with. I am confident in my abilities as a software engineer, but I'm also relatively modest. I try to respect work that was done before me and carry the good parts forward if it ends up needing refactoring. I prefer to let less experienced coworkers tackle problems similar to problems I've solved in the past while providing mentorship, so that they can learn similar lessons. I've avoided management because I know I'm bad at it, but I try to support management however best I can. I also throw the occasional team homemade pizza party when there aren't pandemics. Notably, I also tend to be able to work with the stereotypical difficult-to-work-with devs that you mention. My coworkers generally seem to say nice things about me to my face and behind my back, and upper management seems to reflect their appreciation financially. Honestly my biggest interpersonal problem at work right now is that newer employees seem to hesitate reaching out to me for fear of wasting my time. Therefore I try to make it known that I spend as much time staring at the wall as possible during work hours.

cornel_io 6y ago

Yes, absolutely never criticize - as a manager, the #1 thing that makes me start to hate a report is when they complain about other people's work. Most of the time they don't understand why code was written the way it was (Chesterton's fence), and even when they do and are making valid complaints it's just a dick move that doesn't help. Trust me, the lead and manager both know when someone sucks, they don't need to hear more about it. And if you're wrong with your criticisms, you just demonstrate that you suck. Literally lose lose.

Erlich_Bachman 6y ago
> Trust me, the lead and manager both know when someone sucks Through which mechanism do you think they know it? If nobody ever tells them that some piece of code is bad, this mechanism doesn't do its job.

hackeredje 6y ago

Given time, every developer will end up in some company, doing projects, having to go trough other vast requirements, documentation, databases, interfaces and codebases to understand these. So I think you refer to persons who do not do projects but who stay i one company for a large time versus people who do projects (and are sometimes called consultants) and in general how they communicate with each other.