[NinetyNine]

That's a pretty interesting situation. I certainly don't think there's any "something" blocking you, I'd guess it's more of a vague feeling of caution that you're clinging to because you can't quite understand it. It's easy to get into these traps when it's something very important (like your job).

There are a few things you can try. You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it. You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this).

Your "sudden change" probably wasn't so sudden, but rather your experience with hitting the limitations of writing shitty code. Now you want to avoid those pitfalls in the future, but your boss doesn't seem to understand.

There's also plenty of places for you to go still, if none of the above works for you.

Edit: Creating a checklist of "the smallest chunk of work" can help you keep moving rather than getting stuck in tweakfinity.

[jtheory]

A few suggestions based on my experience (I have the same problem sometimes...):

- "get it working and keep it working": get the minimal possible functionality working (outputting some result, even if there's utterly no error handling, input is ignored, all of the requisite services are stubs and any actual processing is faked), and make sure you keep it working -- if some refactoring is going to take more than an hour or two, plan it differently. This helps you get really quickly to a proof-of-concept (with TODOs everywhere in the code), and stops you from shredding it to "do it right" because that would break it.

- keep a list of your ideas of how to do it correctly, in a separate file. Yes, for the moment we're dropping the input directly into a SQL query and returning the result directly wrapped in a <pre> tag; for the real product we'll need parametrized queries, a dynamically loading JS table (to research), etc. etc.

- stay offline. Do not download libraries or frameworks, do not research the best way to do X, do not research the problem domain or look for open source projects that do similar things but are huge and will suck up your entire afternoon when you could have just hacked out a completely unreuseable, inflexible, one-time fix for this particular problem in an hour. Research is fun, it's interesting, and it's a way to avoid actually doing what you need to do -- half-assed work. If you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours.

Good luck!

[klibertp]

Great advice, both from you and grandparent. First, I wanted to say that my boss is a programmer himself, much better than I am, and he understands the value of good code very well. But he's also a bussinesperson and knows when the product is much more important than the code - I trust him on this. At least consciously. It's really not his fault at all.

---

> You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it.

I can't. I mean - I do program in my spare time and have side projects, but if anything it worsens the situation: I have more time and no deadline, so I just tinker with the code until I'm satisfied. And I am satisfied, it's not like I don't know what "good enough" means, just that in personal projects that level of "good" is even higher, because I'm the one who sets it.

> You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this)

This is exactly what I'm trying to do - but it's a workaround at best, not a solution to the problem.

> rather your experience with hitting the limitations of writing shitty code

That's true - around that time I was part of a team that developed CRM system in PHP. It was meant to be 3-4 months project but in the end it was a year long nightmare of rewrites and feeling guilty for everything. I never did any postmortem or proper analysis of what went wrong (everything) and maybe that's why my attitude changed. I wonder if it's too late now?

---

> "get it working and keep it working"

This is a way I work most of the time. And refactoring I do and am talking about is always much quicker than an hour - I do it in very small chunks, one function or class at a time, not breaking the code. It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.

> keep a list of your ideas of how to do it correctly, in a separate file

I do this with larger ideas. It's not that. Rather, I can't force myself to drop the input directly in the SQL using string formatting. I know I did it in PHP years ago and it burned me so hard I won't do it again. Willingly, at least.

> stay offline. Do not download libraries or frameworks, do not research the best way to do X... > if you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours

This seems to be exactly what I need to do. It never occurred to me, but when I think about it I see that looking for "better" implementation in libraries eats large chunks of my time. And these implementations aren't even that good... Combined with mastery of tools, I think it can work. Thanks, I get the feeling that there is hope for me :)

[jtheory]

> It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.

Ah ha... one solution, then, may be to force yourself to stop when it's only just barely working, instead of continuing on refactoring. :)