Don't group your problems
At some point in the early afternoon, I got a to-do list. I had the project manager in a screen share showing me the problems she was seeing, and in another window a tech lead giving me feedback on a Github pull request. They were all mostly linked to this one component, so with three new items on my list, I thought, hey, I can refactor this and take care of all of them.
By mid-afternoon I was hopelessly mired, with a new template taking a ridiculous number of arguments, and at the same time Not Working At All, and I couldn’t figure out which of the several parts I had in the air was causing the problem.
Instead of bulling through, though, I finally learned something. I stopped, and threw away all the changes I’d made. I looked at just one item on the list, the pull request feedback. It was just changing some IDs on some tags. I changed the IDs and updated the pull request. Simple.
Next item. A status indicator shared between windows wasn’t cleared if one window was closed while in an error state and another one was opened. I had been trying to reset it on window close in my Brand New Super Component, but instead I figured out how I could essentially initialize it on window open without touching the existing component. (In the process I learned a little about how to call controller methods from a route in Ember.js, which was a bonus.)
Now I had two items cleared off the list, and I was free to fix the third in any way that worked. And, yes, I created a new component slightly different from the original one, but now I only had to solve one problem, so my new one was not as ambitious and didn’t require as many complicated changes. And it worked.
We’re gonna make an engineer out of me yet.