Yes. But. The trick is knowing other tools in sufficient depth to know when Excel is an anti-pattern. Which is hard, b/c it's so flexible that it gets adapte

Yes. But. The trick is knowing other tools in sufficient depth to know when Excel is an anti-pattern. Which is hard, b/c it's so flexible that it gets adapted to a lot of stuff it really shouldn't be. A big chunk of Corporate America uses Excel the way our foreprogrammers used Perl or Bash, adapting it to all manner of tasks because it's what they know. I admire their resourcefulness (and scorn their IT environment for limiting their access to better tools) but that handiness leads them into solutions that are fragile, unmaintainable, uncheckable and unscaleable. The step from Excel to broader, more flexible tools is the move away from graphically delineated relationships to logically stated relationships. It's a very hard step, and one most people won't make unless they force themselves through a period of clumsiness while they orient themselves to a new approach. Exercises like the OP are a great way to do just that: "I'm going to force myself in this direction by setting some simple but arbitrary obstacle that will build capabilities I can use elsewhere." Doing so on tasks that are well understood may help even more -- "I know how I would do this in Excel, how do I do it in Python?" -- because your knowledge of the problem frees you to learn the new things about this new sort of solution. The OP isn't saying the CLI is the right tool for everything, he's saying this is a way to build the understanding that lets you move to it freely when it is the right.