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 prod

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-Computer/ http://www.instructables.com/id/How-to-Build-an-8-Bit-Comput...