Hacker News Reader

Comment by jen729w | Hacker News Reader

I realised I was guilty of this in 2016 so for 2017 I've made a few simple changes, the primary one being how I write my "project" name in OmniFocus.

For instance, I had "Learn how to use bash properly". Well, what does that mean? When is that finished? It never is. Now, that project is called "Read 'Learning the bash shell'".

Immediately, that's attainable. When I've finished reading the book, perhaps I'll want to do more, perhaps I won't. But at least I know that I'll have completed that project.

View on HN

Yup, that's a big part of the "getting things done" (GTD) mindset. Write down small, actionable tasks that can be completed. Not fluffy goals.

I've started doing the same by making renaming my list titles on Taskcade into actionables instead of a broader goal. Have done wonders for me.

Why do you even set yourself such a goal?

Just learn to use it when you need it, or when you have a task, where you suspect that it might be faster done in bash.

Reading a book on it can give you a better idea of which tasks might be faster done that way, so that when you run into one, you're better equipped to recognize it as such than you might otherwise be.

That is actually very correct.

I remember reading a book about the Shell and bash 15 years ago. It was the only book I read about the topic, but it helped me a great deal to develop an intuition about what it can do.

Didn't prevent me though from getting sometimes lost in crafting complex scripts, where manual work or a java-program would have been faster.

Well, that's sort of the problem with bash scripting - its range of capabilities, combined with its atrocious syntax and various limitations, makes it something of an attractive nuisance, where you end up in a rabbit hole of "how do I do this in bash" while doing it in anything else would be more productive.

Maybe the most important thing to learn about shell scripting is when not to use it. Alas, if the book that teaches that skill has been written, I have yet to run across it.

The shell is a tool, as is a proficiency in C, Python, Java, Golang, etc. The more tools you can successfully wield, the more you can build. Just because you're not super proficient in the shell doesn't mean someone else might be the same, so you shouldn't simply dismiss it. It is simply another tool to use and your "when not to use" question can literally be used with ANY technology.

As an exercise, try replacing bash / shell scripting with SQL or C or Python. This is the fallacy in your argument :)

I don't believe I did "simply dismiss it". But perhaps I was insufficiently clear in saying that bash is relatively unusual in making it tricky to identify the point at which to stop trying to force it through hoops and use something more powerful and easy to work with instead.

[Meta: Why I think you have been downvoted]

> " Just because you're not super proficient [...] As an exercise [...] This is the fallacy in your argument "

This assumption of missing knowledge and handing out of an "exercise" in logical thinking comes across rather patronising. Also I'm not sure where the argument was, that you found a fallacy in.

Thank you for your contribution, nevertheless. I too believe that the decision on whether to use a tool or not, depends on your knowledge about it.

There's also a simple scheduling issue. Learning takes a while, and often the problem you're trying to solve is urgent.

It can also show you the opposite, understanding something better might make you realize it's not as useful as you thought before, or might not be applicable to your needs.

One could see that as a different way of achieving what the parent poster said. You set a smaller goal that you can achieve (learn to do the task you need done right now) instead of the nebulous task of "learn the bash shell". They chose to read a book and gain everything in the book (regardless of whether they'd use it or not) and you chose to get something done.

In defense of their side of things, there will be important things in that book that they might never think to try to learn and that might not come up during internet searches for specific problems.

Both sides have merit, IMO.

I tend to read books after I've tinkered with something for a couple of weeks, to fill in the blanks.

But what I actually wanted to point out is that learning bash doesn't seem to have a giant appeal to OP. If it had, he wouldn't put it off on a todo-list.

If you don't feel like to sit down and learn and entire topic for the fun of it, it's better to do it piece by piece.

I just want to be better at it. I like learning things.

There is some Gestalt psychology involved; realizing that how people perceive the "whole" final product is separate from the individual tasks required to create the product.

When I stress about delivering on larger expectations, I do the GTD task breakdown exercise, and trust that the assembled "whole" will be fine if the "parts" are solid and of high quality.

What would be an OmniFocus substitute for Android/Windows/Linux?

While I was working on Mac I never really liked OmniFocus. Then I used Taskpaper, then taskpaper-vim, then vim-orgmode.

Taskpaper is almost right but orgmode has few additions that I really need. Vim-orgmode works better than original orgmode on emacs for me.

In short try to pick something that can be easily migrated unless you want to be tied in ecosystem. There are ogmode clients for iPhone and Android, haven't checked them because I don't need them.

https://www.taskpaper.com/ https://github.com/davidoc/taskpaper.vim https://github.com/jceb/vim-orgmode

Taskpaper looks like a close alternative. If you are also looking for a web alternative to OmniFocus, the closest thing I've found so far is https://www.taskcade.com

Reply on news.ycombinator.com