I'm a good engineer but I suck at building stuff

I agree with this philosophy as well. If is a project or program that will be worked on more as time progresses, typically it refactors itself after the programmer has a better grasp of the big picture. Often the bigger picture can only be grasped after there is some momentum with the project. I'd say this works 90% of the time, where the other 10% needs more upfront design and research done before any real work is started.

I find this is a problem when I lack control over what I am building, so I focus on the act of building it which is in my control.

No. It has to be clean, correct, and come with full unit test coverage the first time. You have until the next sprint to implement it. Your workspace is a Macintosh at a long desk where you'll be working shoulder to shoulder with other devs working on other projects. If you can't manage even that, you're just not a good fit for our company; we expected more of an engineer of your experience level.

Based on a true story.

Learning the programming art is like learning any other art. You first learn the rules (and even more importantly the REASON behind the rules). You then build the discipline of applying the rules. And finally through experience you learn where some of the rules just don't apply.

The usual progression is something like:

1. Build your first major project as senior engineer. You make something that works, but is brittle and soon becomes difficult to work with.

2. Build your second major project. This time, you adhere to ALL established best practices. The end product is difficult to configure because you've gone too far in flexibility, and a major pain to maintain because the codebase is 3x larger than it needed to be, and filled to the brim with boilerplate code. You also resist changes that threaten the precious architecture. Everything's perfectly isolated and testable, though!

3. Build your third major project with the minimum needed to get it to work for your client, keeping a few of the best practices to keep it mostly flexible enough for changing requirements. It will eventually grow in unhealthy ways as requirements shift beyond fundamental architectural assumptions, but you already knew this going in.

4. Make the mistake of doing a "2.0" rewrite of your major project. Vow never to do it again.

I'm naturally a perfectionist, so I fall into this trap often, though I've gotten better over time. I rely on a few simple tricks (ugh, the buzzfeed headline practically writes itself):

1. If I'm stuck and can't decide which path to take, it's usually because I don't have enough data to tell which path is better. The fastest way to get that data is to pick one path arbitrarily and start walking down it. Pretty soon, it will be become obvious if it's the wrong path.

2. One of my favorite things about code is that it's infinitely malleable. Especially thanks to the magic of Git, I can undo any change. Nothing is permanent which means no decision is carved in stone. Deciding isn't deciding what to do forever, it's deciding what to do for now.

3. Sometimes I get stuck trying to do a depth-first traversal of the fractal tree of all possible implications of the program. Going depth-first down every single edge case and rathole is not an efficient way to get something up and running.

You really want to go breadth-first or best-first instead. To do that, you need to leave markers in your code of which branches remain to be explored. Those are TODO comments. So instead of falling into a rathole and not making progress on the thing that's at the forefront of my mind right now, I just leave a TODO, "Figure out what to do here if the ___ doesn't ___."

TODOs are great because they help my current velocity by not getting sidetracked and my future velocity by giving me something to pick up on when I finish something else. I pretty frequently search my code for TODO and grab one that sounds fun.