Today at work I wanted to create a temporary list of some files that I needed to manipulate, aligned according to certain API criteria. It was quite a few files, so I wanted a support system for recording progress (a todo-list, kind of).
I solved this task like so:
find . -type f | awk '{ print "[ ] " $1 }' > list.txt
But I could just as well have left out awk, created the list and started
Vim and pressed ctrl+V - G - I - [] - ESC and solved the same
task just as quickly. This solution would most likely have been faster
since I would not have to think (I am quite familiar with Vim, only
superficially familiar with awk).
This is an experience a programmer encounters every day. And usually, our task is not as trivial as creating a list of files and prefixing [] before each list item.
Firstly, not every experience here is the same. Yes, we can choose between
using reduce and iterative code, solving the very same
problem. But sometimes this choice is not trivial. If you would use
reduce of ES5 in production, we would think twice if we used
it to deal with large amounts of data. We would also consider things like
readability. And perhaps have other concerns. Then we would make a choice
based on some standard.
But sometimes what we choose is just a matter of taste. This is true when we program, but also true when we do editing and/or make use of some scripting to solve a simple task.
Should we care? No, and yes. If our solution without a doubt is only about taste it doesn't matter, no. But on the other hand, we can make our work more intriguing and also learn more by doing it in a way we are not very familiar with.
To take pleasure and pride in such details is our craft. A sort of craftsmanship. We could write [] and copy-paste this line for each of every line, like a machine. If it had been the list I made, we would do this for 150 lines and we could only make use of this procedure one line at a time. It would be tiresome, like working in a 19th-century industry. This is why we use hacker tools, be it Vim, some Unix tool, or whatever.
There are always many ways to solve the same task within your environment. I could also have solved the task like this,
find . -type f | sed 's/^/\[\] /' > list.txtOr in many other ways stretching from far-fetched to elegant. But most of them would be better than manually creating a list.