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

Whether or not one is good is for other people to decide by evaluating one's deeds.

+1 on this. I personally had a similar issue where I'd start a project then go off on some huge overengineered diversion.

You Ain't Gonna Need It. Let that be your mantra. And always promise yourself that you'll refactor (and actually do it!)

I feel like this leads down a dangerous path of no signal-to-noise ratio and destroys your hope of finding relevant TODOs. Better to, as part of revisiting them, rewrite the comment to explain the de facto behaviour for yourself (and others) in future. If you're not going to do them, anyhow.

I started my career in a small software company that wrote Mac software (in the System 6.5, System 7 days). We had no dedicated support staff, so support calls were either handled by the sales staff or development. Talking directly to customers, hearing where they were having trouble, and learning what they wanted to do, was probably the single most valuable experience in my career. My first thought with any work became "How can I completely eliminate the possibility that I will end up having to support this?"

Of course, this backfired spectacularly a few years later at a different company, when a customer stopped paying a lucrative support contract because the software always "just works". I have decidedly mixed feelings about that!

I like this post because it captures some way in which my perspective has changed over time. Engineering was something I saw as a way to perhaps "cheat" at product problems because if I made a good enough/fast enough/automated enough/generic enough solution, I would be able to iterate on it really fast and so somehow come out ahead of people who went directly towards the simple solution. This mentality was clearly inspired by years of homework being a task that would never go away and that I desperately wanted to get out of my life as fast as possible in the way that consumer products advertise their elimination of household tasks - ergo my goal as a student was to wish I could automate away all aspects of my studies. I would look for any kind of secret trick or forgotten technique that would get me closer to that goal at minimum effort. All the while I would build very little that was finished and get lost in maximizing my use of silver-bullet abstraction.

I've eventually come around to flipping this idea on its head, though. If I design not just some kind of product or solution, but a whole process, starting basically with how I want to run my life and then drilling into specific details from there, the technical knowledge stands on more even ground with other forms of knowledge, and with seeing life itself in a more precious sense.

With that mindset, good scheduling of every day as an end in itself grows vastly more important, and abstraction-for-its-own-sake falls away: All programming problems start by assuming they are solved first with "code that looks like breadboard wiring" [0] and then working up the abstraction ladder from there. Automating the technical parts of the solution won't guarantee that it's right in any other way, but it will ease the pain of changing the specification. Acknowledging that the problem is messy, that breadboard coding is messy, and that I won't know how to solve everything immediately and cannot depend on a silver bullet, all constitute crucial first steps.

Now I always look for really basic groundwork to be laid out early on - typically, transforming the breadboard code into something that uses a new data structure, or generating the code flow from a stack or a list or a tree - and that no shortcut is possible without compromising the ability of a potential future abstraction - that it just takes a lot of layers to get where I want to go. Breadboard code is assumed to be ideal until demonstrated otherwise, while "x in y lines" hype is to be avoided under the assumption that the solution is brittle and over-modeled towards the demo code. I cannot assume that my valuable production code will need x or work in y lines. I don't abstain from adding dependencies, but I will preference towards copy-paste-own when I find a reason to reuse code.

[0] http://www.instructables.com/id/How-to-Build-an-8-Bit-Comput...