4 ms·

Does anyone else have an absolute dread of FIXING / REPAIRING something? And a solution for this dread? Sometimes I'm at a point where I would put my hand in a

by nnq 8y ago

Does anyone else have an absolute dread of FIXING / REPAIRING something? And a solution for this dread? Sometimes I'm at a point where I would put my hand in a running blender together with a live kitten or something painful and horrible like that, just to get NOT to have to FIX something that needs fixing and instead to START something new or to completely replace or refactor something or to buy something new and set it up in the place of the thing needing fixing... anything, just not repairing, not debugging, not fixing or not optimizing one more little half/broken thing. The only thing I similarly dread is "going the last mile" from 80% to 100% and finishing any project/task, but for this at least I have a big bag of tricks that works most of the time. But fixing / repairing instead of replacing something or starting with something completely new... This is HELL for me. Even visually, a blank piece of paper or a blank screen pumps me up with energy. But when I see something already half-working / half-written but know that there are some serious bugs/defects that I need to hunt down and repair somewhere in that. It sometimes fills me with so much dread that my subconscious makes me "forget" that that task exists, or forget what its components are so I end up miss-estimating by factors of up to 100x (with obviously horrific consequences for everyone's budget and sanity).

philbarr 8y ago
Besides having decent source control habits so you know you can go back if you mess up, I usually have a "playground" project that is pretty similar to the app I'm working on. I can do what I like in there, experiment, break things, doesn't matter. That way if I have a problem I can't seem to even get started with in my main app, I go in my playground app and start there instead. It's like my cosy developer "safe zone".
Klathmon 8y ago
I've had very similar feelings before, and in my experience that fear of "fixing" is telling me something, that i'm not in a good position to be fixing whatever it is. You mention that "refactoring" doesn't give you the same dread? Could it be because you know the problem better if you are tackling a refactoring but you don't when you are bugfixing? I've found that that dread wasn't from bugfixing, but was from a lack of confidence about the part of the codebase i'm working on. Personally, I've found good results with tricking my brain into thinking i'm "refactoring" while really "bugfixing". Schedule the time to review the codebase that i'll be bugfixing, talk to the author if possible (and it's not you). If I want to indulge myself I'll sometimes "mock refactor" it, I'll open a new tab in my editor and almost pseudocode rewrite the component or module that needs fixing/debugging. Then once I feel I understand it enough, I can actually dive in and fix the bugs in the original code. And by that time i'm familiar enough with that section that i'm not fearing every letter typed as I know what will happen, I understand the intent behind the code. I also struggle with the fear of "wasting time" a lot with this kind of stuff. I have this incorrect feeling that if I was able to develop these 300 lines of code in 6 hours, that I can't possibly devote 6 more hours to fixing a few lines. But the reality is that often the small 1-2 line bugfixes are the largest timesinks of all, and that I can't be afraid to schedule those 6 hours to look into that bug. Once I get over that hump that I'm somehow "cheating" the system by allocating so much time to what ends up being so little change, I feel a LOT better about actually doing it.
dredmorbius 8y ago
Can of worms scenario. When something is in a degraded or broken state, it's just that: broken or degraded, but for unspecified reasons. Once you start messing with it, you're likely to discover numerous unpleasant truths. These are small revelations or griefs: The damage is worse than you thought. There is other damage, previously unrealised. You lack the tools, equipment, or parts to diagnose, repair, or replace broken equipment. You're in over your depth. Others around you don't respect or trust in your skills. You need to dedicate space over time to the repair, contested with other uses or people. If a repair is in a domain I have experience, skill, tools, trust (or full independence), then it's little problem. Large or novel projects, or social interference (co-workers, management, vendors, clients, household members, neighbours, politicians) make the prospect far less appealing.

by nnq 8y ago

philbarr 8y ago

Besides having decent source control habits so you know you can go back if you mess up, I usually have a "playground" project that is pretty similar to the app I'm working on. I can do what I like in there, experiment, break things, doesn't matter. That way if I have a problem I can't seem to even get started with in my main app, I go in my playground app and start there instead. It's like my cosy developer "safe zone".

Klathmon 8y ago

I've had very similar feelings before, and in my experience that fear of "fixing" is telling me something, that i'm not in a good position to be fixing whatever it is. You mention that "refactoring" doesn't give you the same dread? Could it be because you know the problem better if you are tackling a refactoring but you don't when you are bugfixing? I've found that that dread wasn't from bugfixing, but was from a lack of confidence about the part of the codebase i'm working on. Personally, I've found good results with tricking my brain into thinking i'm "refactoring" while really "bugfixing". Schedule the time to review the codebase that i'll be bugfixing, talk to the author if possible (and it's not you). If I want to indulge myself I'll sometimes "mock refactor" it, I'll open a new tab in my editor and almost pseudocode rewrite the component or module that needs fixing/debugging. Then once I feel I understand it enough, I can actually dive in and fix the bugs in the original code. And by that time i'm familiar enough with that section that i'm not fearing every letter typed as I know what will happen, I understand the intent behind the code. I also struggle with the fear of "wasting time" a lot with this kind of stuff. I have this incorrect feeling that if I was able to develop these 300 lines of code in 6 hours, that I can't possibly devote 6 more hours to fixing a few lines. But the reality is that often the small 1-2 line bugfixes are the largest timesinks of all, and that I can't be afraid to schedule those 6 hours to look into that bug. Once I get over that hump that I'm somehow "cheating" the system by allocating so much time to what ends up being so little change, I feel a LOT better about actually doing it.

dredmorbius 8y ago

Can of worms scenario. When something is in a degraded or broken state, it's just that: broken or degraded, but for unspecified reasons. Once you start messing with it, you're likely to discover numerous unpleasant truths. These are small revelations or griefs: The damage is worse than you thought. There is other damage, previously unrealised. You lack the tools, equipment, or parts to diagnose, repair, or replace broken equipment. You're in over your depth. Others around you don't respect or trust in your skills. You need to dedicate space over time to the repair, contested with other uses or people. If a repair is in a domain I have experience, skill, tools, trust (or full independence), then it's little problem. Large or novel projects, or social interference (co-workers, management, vendors, clients, household members, neighbours, politicians) make the prospect far less appealing.