10 ms·

Mea culpa: How developers fix their own simple bugs differently from other devs

124 points by zdw 5y ago

nineteen999 5y ago
Interesting. So many times I have patched something in order to get it working and wondered whether the developer would have come up with the same fix, or if they would have done it differently.
rembicilious 5y ago
When my own code presents a bug I tend to chase it back to it’s “philosophical roots”. I tried to work out edge cases from the beginning; to handle invalid data; to swat the bugs before they appeared. A bug reared it’s little insectoid head. Now I’m wading my way through every piece of code that remotely affects the issue and making damn sure that my perfect vision is realised. On the other hand, fixing a bug in someone else’s code doesn’t have all these personal implications. If I fix the bug without causing regressions I’m a hero! After all, it’s not personal to me.
- cwingrav 5y ago
  Agreed, and that is the heart of it. - Someone fixing their own code fixes the codebase. Someone fixing someone else's code, generally only knows enough to make a fix at a single point, to fix an observed bug. I think the abstract is just making statistical observations and hopefully in time will develop and test hypothesis that could create a theory. Anyway, they can use my hypothesis above and give it a whirl.
gfody 5y ago
my bug: find the absolute root cause and fix it, ideally by changing a single character their bug: I'll need to rewrite most of this, what the hell were they thinking?
- peanutz454 5y ago
  From the article: We also found that bug-fixing commits by authors tended to be larger in size and scope, and address multiple issues, whereas bug-fixing commits by other developers tended to be smaller and more focused on the bug itself.
  - ziml77 5y ago
    This makes sense. If I'm fixing a bug in code I'm not super sure about, I want the change to be as focused as possible because even if it looks like it should be made into a bigger change, I don't know what the knock-on effects will be. There's also a matter of not being sure if the desire to rewrite a large chunk just comes down to personal preference.
    - andai 5y ago
      Yeah, in my case at least "what the hell were they thinking" comes down not to them having solved the problem incorrectly, but a difference in the shapes of our minds.
cjfd 5y ago
This is the/a main reason why frequent changes in who maintains/develops a program is bad for the quality of the software.
DubiousPusher 5y ago
> when they fix other people's bugs, their commits are smaller and more tightly focused. While this may be true of junior engineers or people working on a project that they don't actually put into production, I feel it can't be true of most people working a devops roll on a production system. I only worked several years in devops on a small production system with a few hundred users but I learned very quickly to respect others' work and the thought they had put into their areas and to be very wary of "fixing" anything more than the described bug. Honestly, not exaggerating, it makes my stomach churn a bit. Regressions are very real and if you don't have decent test coverage with actual integration or functional tests, you are writing regressions and you just don't know it.
- Jorengarenar 5y ago
  In the first paragraph you say you disagree, but the second one just reconfirms the article?
  - toxik 5y ago
    GP may be saying that senior devs tend to s---t all over people's code. I've certainly seen it happen. But I think that's more of a personality trait (well, lack of empathy) than anything else.
    - drran 5y ago
      When I will see the problem, I will fix the problem. What the problem with that? Do I need to create a ticket and assign it to Junior with a book long description and proposed solution?
      - cowsandmilk 5y ago
        Depends on priorities and how much you are working to help junior devs create better code in the future. Sometimes, teaching other developers why something is a bug is the best thing for your team long term.
renewiltord 5y ago
Hmm, this agrees with how I have behaved. I have deeper knowledge of the bug in my code so I can make more fundamental changes. With code I'm unfamiliar with I am less certain if I'm bringing down Chesterton's fence. I wonder if there is also a social aspect to this of 'politeness' in not stepping on others' work. I wonder if there are ways around that. EDIT: Though, interestingly, reading some of the comments with people misunderstanding the title, it looks like the article is right. If it had said the opposite, I might well have rationalized it the other way.
im3w1l 5y ago
> This is why I find empirical studies so valuable: in many cases "X" and "not X" are equally easy to rationalize, so we need evidence to help us decide which to believe. I agree with the author here, but I also see some cause for alarm. When we could see it going either way, maybe it really could. As in, the result was a coincidence. Or maybe not exactly a coincidence, but caused by some very specific details. This investigation was on java code, but will the same hold for haskell code? Closed source code? Will it be true 20 years from now? Maybe... but I also wouldn't take the answer for granted. And, most insidious of all, maybe we as a community will look at this and decide it's a problem to be solved, and succeed in solving it.
stinos 5y ago
We also found that bug-fixing commits by authors tended to be larger in size and scope, and address multiple issues Too bad I cannot see examples of what this actually entails - for us one commit which fixes several issues is a complete no-go: that should be separate commits. So now I wonder whether the paper really means single commits which address multiple things, or groups of commits?
- dsego 5y ago
  No need to be overly pedantic (I know this is HN but still). In this context a bug-fixing commit could mean patch, diff, revision, PR etc.
  - stinos 5y ago
    I wasn't really trying to be pedantic, Im genuinely curious about what gets meant here. E.g. as you say, do they mean PR or literally one single commit? And in the latter case, is this something localized to the projects they sampled or is this a more general practice?
- withinboredom 5y ago
  I think that largely depends on the team and the code. I've worked in legacy code bases where fixing a bug can cause other bugs to show up. A single PR must address multiple issues to keep the software working.
  - bonoboTP 5y ago
    A PR can have multiple commits.
    - Milner08 5y ago
      Sure but if the thing you're fixing requires fixing other parts how do you get to 'one commit fixes one thing'. Its simply not possible sometimes. Unless you hack in half baked fixed for the sake of a 'commit to fix X' then have to change that in the next commit to fix Y, etc. That's just a time wasting exercise.
Swalden123 5y ago
I find when bug fixing, I find more bugs that I can't stand and have to fix and accidentally make my commits too large.
barrkel 5y ago
The less you know about code, the more local your changes. In fact this is how the architecture of a software system degrades: lots of local changes sort of make it "melt". Global invariants become temporally or spatially local invariants, code and data flow which had a single purpose acquire multiple purposes, names become semantically overloaded, and so on.
- OliverM 5y ago
  Do you know of any external, authoritative studies demonstrating this? I know it's true from long experience of seeing it happen repeatedly, but I'd like to point at something that can justify a 'refactoring sprint' or something like that to try tackling the impact of this pattern. The other justification is that clean refactored codebases are quicker to change, but it's a difficult sell.
  - adamkl 5y ago
    Maybe not exactly what you’re looking for, but this is a classic paper on the topic: http://laputan.org/mud/ http://laputan.org/mud/
- codeflo 5y ago
  Very true. Some things I also noticed: Changes tend to be made higher up in the stack, ultimately the UI, because that has a lower risk of breaking something else. This gets very messy very fast. Bugs in shared code tend to be worked around rather than fixed because other code might depend on those bugs — which quickly becomes a self-fulfilling prophecy. Some functions/methods seem to be natural magnets for these overly local changes, and as a result, can wildly grow in size over time. I once analyzed how a 50-line function had grown to 5000 lines over a few years in a series of individually justifiable changes. All of this is a downwards spiral that’s very hard to stop once it has started. “Refactoring sprints” and other heroic efforts sadly seem to have little impact in such an environment if they don’t also radically address the engineering practices that lead to the situation.
  - hobs 5y ago
jstimpfle 5y ago
I'm always a bit embarassed when I look at my commit history, for personal projects but also for projects at work. The simple commit that just fixes a bug or adds a feature in a few lines is very rare. It's often that a bug could be fixed on a single line, but this "actual" issue is drowned in a sea of read and green in the commit diff. Normally I cannot resist the urge to improve something. Sometimes it's a structural improvement. Often it's only cosmetic changes or moving stuff around that might make things clearer or not, I'm not always sure. At least my mind is working on the problem. When I look at commits from some other devs that often do these localized fixes, it almost always seems like the codebase deteriotes a little bit on a global scale for example because some knowledge is duplicated from some other location 500 lines away. I think I lean on the side of focusing on the end product (the tip of the development branch) at the cost of having not the most beautiful history ever. I'm also aware that my style of developing makes it hard to develop in large teams / a product with many release lines. For my small projects that have very little collaboration, my approach seems to work, though. Maybe there's only two ways to have a nice history: Have a shitty end product, or be a domain expert. The latter seems unrealistic to me, because working on something you already know how to do is not very satisfying.
- simonpantzare 5y ago
  When reviewing, I appreciate when commits with fixes/additions are separated from structural/cosmetical changes.
  - mytailorisrich 5y ago
    In fact, a commit should have a single purpose, otherwise it creates dependencies and, for instance, you cannot revert a feature without also reverting a bug fix and it makes cherry-picking a nightmare.
    - brigandish 5y ago
      I agree, but I've also been told off for making many, small commits. I don't know why the complainers don't squash them together if that's the way they feel and leave the moaning out of it.
theshadowknows 5y ago
My bug fixes almost always start out with “why the F did I do that?????” And then a long series of “oh…” before I finally get to the “ah hah!” Which is a moment I still enjoy after all these years. But fixing someone else’s code I’m more like “ok…I need to find the bread crumbs so I don’t get lost in this forest and end up messing something up…let me test this seemingly simple…ok yeah that broke stuff better roll it back.”
- michaelgrafl 5y ago
  Lucky you if you manage to break stuff in a way that's immediately observable!
  - spaetzleesser 5y ago
    Very true. I have many stories where a bug got “fixed” only to find out that there were unexpected consequences later on.
  - theshadowknows 5y ago
    Oh Im sure I’ve broke things that just haven’t been observed yet!
glangdale 5y ago
One of my direct reports once fixed one of my "simple bugs" with the astonishingly direct commit message: "Const, motherfucker. Do you speak it??!?" (which, I hasten to add, would have been unthinkable if it had been a bit of peer-to-peer banter, much less senior-to-junior, but as a way of winding up your boss, it was a absolute masterwork)
- lagadu 5y ago
  Can't really go wrong with a Pulp Fiction reference either!
- darkerside 5y ago
  He was probably talking to the code and not you. You're right he should be tactful, but as a manager, please don't take it personally. It's kind of your job not to.
  - glangdale 5y ago
    Nah, he was talking to me. We had that kind of a relationship where this stuff was always going to be considered funny, not offensive. We did tone it down a lot when other people were around because this kind of banter can be misinterpreted by third parties ("oh my god, what terrible things is he going to say to me if they speak like that to each other").
- tialaramex 5y ago
  Const should be default. Kate Gregory has a C++ talk where she discusses being brought in to clean up code and she's like OK step one, mark everything const. Of course some of it isn't const, but the compiler will point out every place where this made no sense, so next you can remove the consts that the compiler is unhappy about until you get a const-correct program.
  - glangdale 5y ago
    Yeah, pretty much agree. The problem of being lazy about constness is that when you finally get your act together and think about it, you'll wind up having these huge "viral" chains of const-fixes to do. The code will be better for it, but you'll wind up changing long chains of things to be const.
Haga 5y ago
There are "simple" bugs only with proper encapsulation. Everything is a wrongful assumed simple bug
lifeisstillgood 5y ago
When I write some code it has a platonic ideal in my mind, and I never achieve that ideal, due to various constraints (time, skill, etc). I may pepper the code with TODOs but it's hard to convey that ideal to others. So when I come back, my code is an unfinished oil painting, and my fixes will try to complete the painting. If I bug fix someone else's code I am not trying to complete the painting - I am at best just doing restoration. It is a long time before Inhave made enough restorations to believe I truly own the painting.
- CRConrad 5y ago
  > If I bug fix someone else's code I am not trying to complete the painting - I am at best just doing restoration. Hmm... "Restoration", eh? https://en.wikipedia.org/wiki/Ecce_Homo_(Mart%C3%ADnez_and_Gim%C3%A9nez) https://en.wikipedia.org/wiki/Ecce_Homo_(Mart%C3%ADnez_and_G... ;-p
  - lifeisstillgood 5y ago
    :-) That did fleetingly cross my mind as I was writing it. And yeah, I suspect I may have done that a couple of times - taking over someone else's codebase is not unlike watching the pilot parachute out of a flying plane with a "it's all yours now". Sometimes you have wings and engines and radio, sometimes the port wing is on upside down but the joystick is jammed starbd so it's all ok. But you really need to know that as the pilot jumps. All in all, I think understanding someone else's codebase is like taking over writing a novel halfway through. It's why we all like a rewrite. (And maybe why film scripts sometimes fell like they were written by committee)
hikarudo 5y ago
See also Peter Naur's "Programming as Theory Building". Essentially,the original authors of a system have a theory (what nowadays we would call a model) in their minds of the system, of its architecture. Something that is difficult to convey by code alone. So when a new batch of programmers start working on that codebase, they don't have any knowledge of this theory, so their fixes and new features are of much worse quality than what the original programmers would have proposed.
- erikerikson 5y ago
  Thank you for mentioning this paper, I've been trying to find it unsuccessfully for too long! Yes, we establish a theory of the problem and a theory of the solution. Coherent updates relate to these both.
- raincom 5y ago
  Just like there is a difference between interface and implementation in OOP languages, here 'theory' is in the heads of the original builders of the software, and the 'implementation' is the code written in particular languages. It is easy to debug and fix when one has that 'theory' in one's head.
xxxtentachyon 5y ago
A less charitable take, and something that came to mind for me faster than what others are presenting (that commits fixing bugs that you caused tend to be larger because you know more about the architecture around the code needing to be fixed), is that including other code changes in your bug fix commit serves as a way of covering your ass. If the reviewer needs to sift through and understand 100 lines of whatever (maybe germane to the fix, maybe not), the few lines that address the issue you caused won’t get as much focus, and therefore the issue (that you caused!) itself won’t stand out in your teammates’ minds.
- vineyardmike 5y ago
  This is exactly what i first thought too! A little embarassed, but when i was new to my team as a jr engr i totally did this intentionally.
zug_zug 5y ago
One of the great challenges in coding is fixing somebody else's code with 100% confidence you didn't break something bigger. Each function may appear to have a contract, but it's sometimes unclear if other code is relying on the apparent (mis) behavior of the code. Obviously any sort of global state (including config files, database), magic, parallelism, async, abstraction layers make this exponentially more complex. The author knows all the things that aren't there, it's easy. The bug-fixer just has to check every single thing or risk being bitten by something spooky (e.g. a database trigger).
- whydid 5y ago
  Tests and compiled languages help reduce risks associated with fixing a bug in a function. The classic fear that "I don't know what else uses this function" is simple enough to solve for a developer who knows how to perform static analysis. However, many don't. Even if they do know how to find all areas where a function is being called, it's easier for the "busy" developer to make a copy of the entire function and just change the part they need.
  - heisenbit 5y ago
    Static analysis of use requires knowing all the calling parties and having access to their code. A lot of systems these days are not static monoliths but dynamic assemblies.
    - cratermoon 5y ago
      Or the code you're working on is part of a library or some other component that's used by other projects, some of which you don't even know about.
- cratermoon 5y ago
  > One of the great challenges in coding is fixing somebody else's code with 100% confidence you didn't break something bigger. That's the entire premise of the techniques in Working Effectively With Legacy Code: how to ensure the code you write changes the behavior that you want to change but doesn't change behavior that shouldn't. Great book.
MattGaiser 5y ago
I remember that in my first job, one of my first tasks was to fix a bug where the dates were off by 1. I knew nothing about the codebase and nothing about professional software development so I just incremented the date in the UI by 1.
- Cyberdogs7 5y ago
  This is so terribly beautiful in providing a great example of exactly what the article is talking about. Even better if your 'fix' passed peer code review.

124 points by zdw 5y ago

Interesting. So many times I have patched something in order to get it working and wondered whether the developer would have come up with the same fix, or if they would have done it differently.

rembicilious 5y ago

When my own code presents a bug I tend to chase it back to it’s “philosophical roots”. I tried to work out edge cases from the beginning; to handle invalid data; to swat the bugs before they appeared. A bug reared it’s little insectoid head. Now I’m wading my way through every piece of code that remotely affects the issue and making damn sure that my perfect vision is realised. On the other hand, fixing a bug in someone else’s code doesn’t have all these personal implications. If I fix the bug without causing regressions I’m a hero! After all, it’s not personal to me.

cwingrav 5y ago
Agreed, and that is the heart of it. - Someone fixing their own code fixes the codebase. Someone fixing someone else's code, generally only knows enough to make a fix at a single point, to fix an observed bug. I think the abstract is just making statistical observations and hopefully in time will develop and test hypothesis that could create a theory. Anyway, they can use my hypothesis above and give it a whirl.

gfody 5y ago

my bug: find the absolute root cause and fix it, ideally by changing a single character their bug: I'll need to rewrite most of this, what the hell were they thinking?

peanutz454 5y ago
From the article: We also found that bug-fixing commits by authors tended to be larger in size and scope, and address multiple issues, whereas bug-fixing commits by other developers tended to be smaller and more focused on the bug itself.
- ziml77 5y ago
  This makes sense. If I'm fixing a bug in code I'm not super sure about, I want the change to be as focused as possible because even if it looks like it should be made into a bigger change, I don't know what the knock-on effects will be. There's also a matter of not being sure if the desire to rewrite a large chunk just comes down to personal preference.
  - andai 5y ago
    Yeah, in my case at least "what the hell were they thinking" comes down not to them having solved the problem incorrectly, but a difference in the shapes of our minds.

cjfd 5y ago

This is the/a main reason why frequent changes in who maintains/develops a program is bad for the quality of the software.

DubiousPusher 5y ago

> when they fix other people's bugs, their commits are smaller and more tightly focused. While this may be true of junior engineers or people working on a project that they don't actually put into production, I feel it can't be true of most people working a devops roll on a production system. I only worked several years in devops on a small production system with a few hundred users but I learned very quickly to respect others' work and the thought they had put into their areas and to be very wary of "fixing" anything more than the described bug. Honestly, not exaggerating, it makes my stomach churn a bit. Regressions are very real and if you don't have decent test coverage with actual integration or functional tests, you are writing regressions and you just don't know it.

Jorengarenar 5y ago
In the first paragraph you say you disagree, but the second one just reconfirms the article?
- toxik 5y ago
  GP may be saying that senior devs tend to s---t all over people's code. I've certainly seen it happen. But I think that's more of a personality trait (well, lack of empathy) than anything else.
  - drran 5y ago
    When I will see the problem, I will fix the problem. What the problem with that? Do I need to create a ticket and assign it to Junior with a book long description and proposed solution?
    - cowsandmilk 5y ago
      Depends on priorities and how much you are working to help junior devs create better code in the future. Sometimes, teaching other developers why something is a bug is the best thing for your team long term.

renewiltord 5y ago

Hmm, this agrees with how I have behaved. I have deeper knowledge of the bug in my code so I can make more fundamental changes. With code I'm unfamiliar with I am less certain if I'm bringing down Chesterton's fence. I wonder if there is also a social aspect to this of 'politeness' in not stepping on others' work. I wonder if there are ways around that. EDIT: Though, interestingly, reading some of the comments with people misunderstanding the title, it looks like the article is right. If it had said the opposite, I might well have rationalized it the other way.

im3w1l 5y ago

> This is why I find empirical studies so valuable: in many cases "X" and "not X" are equally easy to rationalize, so we need evidence to help us decide which to believe. I agree with the author here, but I also see some cause for alarm. When we could see it going either way, maybe it really could. As in, the result was a coincidence. Or maybe not exactly a coincidence, but caused by some very specific details. This investigation was on java code, but will the same hold for haskell code? Closed source code? Will it be true 20 years from now? Maybe... but I also wouldn't take the answer for granted. And, most insidious of all, maybe we as a community will look at this and decide it's a problem to be solved, and succeed in solving it.

stinos 5y ago

We also found that bug-fixing commits by authors tended to be larger in size and scope, and address multiple issues Too bad I cannot see examples of what this actually entails - for us one commit which fixes several issues is a complete no-go: that should be separate commits. So now I wonder whether the paper really means single commits which address multiple things, or groups of commits?

dsego 5y ago
No need to be overly pedantic (I know this is HN but still). In this context a bug-fixing commit could mean patch, diff, revision, PR etc.
- stinos 5y ago
  I wasn't really trying to be pedantic, Im genuinely curious about what gets meant here. E.g. as you say, do they mean PR or literally one single commit? And in the latter case, is this something localized to the projects they sampled or is this a more general practice?
withinboredom 5y ago
I think that largely depends on the team and the code. I've worked in legacy code bases where fixing a bug can cause other bugs to show up. A single PR must address multiple issues to keep the software working.
- bonoboTP 5y ago
  A PR can have multiple commits.
  - Milner08 5y ago
    Sure but if the thing you're fixing requires fixing other parts how do you get to 'one commit fixes one thing'. Its simply not possible sometimes. Unless you hack in half baked fixed for the sake of a 'commit to fix X' then have to change that in the next commit to fix Y, etc. That's just a time wasting exercise.

Swalden123 5y ago

I find when bug fixing, I find more bugs that I can't stand and have to fix and accidentally make my commits too large.

barrkel 5y ago

The less you know about code, the more local your changes. In fact this is how the architecture of a software system degrades: lots of local changes sort of make it "melt". Global invariants become temporally or spatially local invariants, code and data flow which had a single purpose acquire multiple purposes, names become semantically overloaded, and so on.

OliverM 5y ago
Do you know of any external, authoritative studies demonstrating this? I know it's true from long experience of seeing it happen repeatedly, but I'd like to point at something that can justify a 'refactoring sprint' or something like that to try tackling the impact of this pattern. The other justification is that clean refactored codebases are quicker to change, but it's a difficult sell.
- adamkl 5y ago
  Maybe not exactly what you’re looking for, but this is a classic paper on the topic: http://laputan.org/mud/ http://laputan.org/mud/
codeflo 5y ago
Very true. Some things I also noticed: Changes tend to be made higher up in the stack, ultimately the UI, because that has a lower risk of breaking something else. This gets very messy very fast. Bugs in shared code tend to be worked around rather than fixed because other code might depend on those bugs — which quickly becomes a self-fulfilling prophecy. Some functions/methods seem to be natural magnets for these overly local changes, and as a result, can wildly grow in size over time. I once analyzed how a 50-line function had grown to 5000 lines over a few years in a series of individually justifiable changes. All of this is a downwards spiral that’s very hard to stop once it has started. “Refactoring sprints” and other heroic efforts sadly seem to have little impact in such an environment if they don’t also radically address the engineering practices that lead to the situation.
- hobs 5y ago

jstimpfle 5y ago

I'm always a bit embarassed when I look at my commit history, for personal projects but also for projects at work. The simple commit that just fixes a bug or adds a feature in a few lines is very rare. It's often that a bug could be fixed on a single line, but this "actual" issue is drowned in a sea of read and green in the commit diff. Normally I cannot resist the urge to improve something. Sometimes it's a structural improvement. Often it's only cosmetic changes or moving stuff around that might make things clearer or not, I'm not always sure. At least my mind is working on the problem. When I look at commits from some other devs that often do these localized fixes, it almost always seems like the codebase deteriotes a little bit on a global scale for example because some knowledge is duplicated from some other location 500 lines away. I think I lean on the side of focusing on the end product (the tip of the development branch) at the cost of having not the most beautiful history ever. I'm also aware that my style of developing makes it hard to develop in large teams / a product with many release lines. For my small projects that have very little collaboration, my approach seems to work, though. Maybe there's only two ways to have a nice history: Have a shitty end product, or be a domain expert. The latter seems unrealistic to me, because working on something you already know how to do is not very satisfying.

simonpantzare 5y ago
When reviewing, I appreciate when commits with fixes/additions are separated from structural/cosmetical changes.
- mytailorisrich 5y ago
  In fact, a commit should have a single purpose, otherwise it creates dependencies and, for instance, you cannot revert a feature without also reverting a bug fix and it makes cherry-picking a nightmare.
  - brigandish 5y ago
    I agree, but I've also been told off for making many, small commits. I don't know why the complainers don't squash them together if that's the way they feel and leave the moaning out of it.

theshadowknows 5y ago

My bug fixes almost always start out with “why the F did I do that?????” And then a long series of “oh…” before I finally get to the “ah hah!” Which is a moment I still enjoy after all these years. But fixing someone else’s code I’m more like “ok…I need to find the bread crumbs so I don’t get lost in this forest and end up messing something up…let me test this seemingly simple…ok yeah that broke stuff better roll it back.”

michaelgrafl 5y ago
Lucky you if you manage to break stuff in a way that's immediately observable!
- spaetzleesser 5y ago
  Very true. I have many stories where a bug got “fixed” only to find out that there were unexpected consequences later on.
- theshadowknows 5y ago
  Oh Im sure I’ve broke things that just haven’t been observed yet!

glangdale 5y ago

One of my direct reports once fixed one of my "simple bugs" with the astonishingly direct commit message: "Const, motherfucker. Do you speak it??!?" (which, I hasten to add, would have been unthinkable if it had been a bit of peer-to-peer banter, much less senior-to-junior, but as a way of winding up your boss, it was a absolute masterwork)

lagadu 5y ago
Can't really go wrong with a Pulp Fiction reference either!
darkerside 5y ago
He was probably talking to the code and not you. You're right he should be tactful, but as a manager, please don't take it personally. It's kind of your job not to.
- glangdale 5y ago
  Nah, he was talking to me. We had that kind of a relationship where this stuff was always going to be considered funny, not offensive. We did tone it down a lot when other people were around because this kind of banter can be misinterpreted by third parties ("oh my god, what terrible things is he going to say to me if they speak like that to each other").
tialaramex 5y ago
Const should be default. Kate Gregory has a C++ talk where she discusses being brought in to clean up code and she's like OK step one, mark everything const. Of course some of it isn't const, but the compiler will point out every place where this made no sense, so next you can remove the consts that the compiler is unhappy about until you get a const-correct program.
- glangdale 5y ago
  Yeah, pretty much agree. The problem of being lazy about constness is that when you finally get your act together and think about it, you'll wind up having these huge "viral" chains of const-fixes to do. The code will be better for it, but you'll wind up changing long chains of things to be const.

Haga 5y ago

There are "simple" bugs only with proper encapsulation. Everything is a wrongful assumed simple bug

lifeisstillgood 5y ago

When I write some code it has a platonic ideal in my mind, and I never achieve that ideal, due to various constraints (time, skill, etc). I may pepper the code with TODOs but it's hard to convey that ideal to others. So when I come back, my code is an unfinished oil painting, and my fixes will try to complete the painting. If I bug fix someone else's code I am not trying to complete the painting - I am at best just doing restoration. It is a long time before Inhave made enough restorations to believe I truly own the painting.

CRConrad 5y ago
> If I bug fix someone else's code I am not trying to complete the painting - I am at best just doing restoration. Hmm... "Restoration", eh? https://en.wikipedia.org/wiki/Ecce_Homo_(Mart%C3%ADnez_and_Gim%C3%A9nez) https://en.wikipedia.org/wiki/Ecce_Homo_(Mart%C3%ADnez_and_G... ;-p
- lifeisstillgood 5y ago
  :-) That did fleetingly cross my mind as I was writing it. And yeah, I suspect I may have done that a couple of times - taking over someone else's codebase is not unlike watching the pilot parachute out of a flying plane with a "it's all yours now". Sometimes you have wings and engines and radio, sometimes the port wing is on upside down but the joystick is jammed starbd so it's all ok. But you really need to know that as the pilot jumps. All in all, I think understanding someone else's codebase is like taking over writing a novel halfway through. It's why we all like a rewrite. (And maybe why film scripts sometimes fell like they were written by committee)

hikarudo 5y ago

See also Peter Naur's "Programming as Theory Building". Essentially,the original authors of a system have a theory (what nowadays we would call a model) in their minds of the system, of its architecture. Something that is difficult to convey by code alone. So when a new batch of programmers start working on that codebase, they don't have any knowledge of this theory, so their fixes and new features are of much worse quality than what the original programmers would have proposed.

erikerikson 5y ago
Thank you for mentioning this paper, I've been trying to find it unsuccessfully for too long! Yes, we establish a theory of the problem and a theory of the solution. Coherent updates relate to these both.
raincom 5y ago
Just like there is a difference between interface and implementation in OOP languages, here 'theory' is in the heads of the original builders of the software, and the 'implementation' is the code written in particular languages. It is easy to debug and fix when one has that 'theory' in one's head.

xxxtentachyon 5y ago

A less charitable take, and something that came to mind for me faster than what others are presenting (that commits fixing bugs that you caused tend to be larger because you know more about the architecture around the code needing to be fixed), is that including other code changes in your bug fix commit serves as a way of covering your ass. If the reviewer needs to sift through and understand 100 lines of whatever (maybe germane to the fix, maybe not), the few lines that address the issue you caused won’t get as much focus, and therefore the issue (that you caused!) itself won’t stand out in your teammates’ minds.

vineyardmike 5y ago
This is exactly what i first thought too! A little embarassed, but when i was new to my team as a jr engr i totally did this intentionally.

zug_zug 5y ago

One of the great challenges in coding is fixing somebody else's code with 100% confidence you didn't break something bigger. Each function may appear to have a contract, but it's sometimes unclear if other code is relying on the apparent (mis) behavior of the code. Obviously any sort of global state (including config files, database), magic, parallelism, async, abstraction layers make this exponentially more complex. The author knows all the things that aren't there, it's easy. The bug-fixer just has to check every single thing or risk being bitten by something spooky (e.g. a database trigger).

whydid 5y ago
Tests and compiled languages help reduce risks associated with fixing a bug in a function. The classic fear that "I don't know what else uses this function" is simple enough to solve for a developer who knows how to perform static analysis. However, many don't. Even if they do know how to find all areas where a function is being called, it's easier for the "busy" developer to make a copy of the entire function and just change the part they need.
- heisenbit 5y ago
  Static analysis of use requires knowing all the calling parties and having access to their code. A lot of systems these days are not static monoliths but dynamic assemblies.
  - cratermoon 5y ago
    Or the code you're working on is part of a library or some other component that's used by other projects, some of which you don't even know about.
cratermoon 5y ago
> One of the great challenges in coding is fixing somebody else's code with 100% confidence you didn't break something bigger. That's the entire premise of the techniques in Working Effectively With Legacy Code: how to ensure the code you write changes the behavior that you want to change but doesn't change behavior that shouldn't. Great book.

MattGaiser 5y ago

I remember that in my first job, one of my first tasks was to fix a bug where the dates were off by 1. I knew nothing about the codebase and nothing about professional software development so I just incremented the date in the UI by 1.

Cyberdogs7 5y ago
This is so terribly beautiful in providing a great example of exactly what the article is talking about. Even better if your 'fix' passed peer code review.