I really like the breakdown sequence of "Automation in real life" because it nearly perfectly describes the process I go through to evaluate if something is wor

I really like the breakdown sequence of "Automation in real life" because it nearly perfectly describes the process I go through to evaluate if something is worth trying to build. Introducing the "would someone pay for this" is a key step because it tells me if it's worth pursuing even if I didn't need it myself. The answer is almost always no. Further, the majority of these small automations increasingly look like they are feature improvements on existing products. This example is also perfect because it was a feature within Powerpoint that would probably take the Microsoft Office team a day to prototype [1] and a few months to build into the next update with backward compatibility etc... So to me the value at the outset isn't in the code, which is fairly trivial, but the value is in knowing what to code and how to integrate the new automation. Here's where this breaks down though...you can't evaluate what you should be building and how it would be built, if you have no idea how to build something. So it is important to learn to code, if only to understand how hard it is to do different things. That holds true for everything though, from making a meal to fixing a carburetor or doing braids. You need experience doing things before you can know how to estimate whether they are worth doing in a new context. [1]Something like... #Compute centroid of rectangle: >self = (coord[0]+(coord[2]/2), coord[1]+(coord[3]/2)) #Compute centroid of background rectangle >other = same formula >#Align >def add(self, other): self.x = self.x + other.x self.y = self.y + other.y