I have a set of guidelines for myself to keep me from going off into a never-never land of getting nothing done, because I love new gadgets, new software, new tools, etc. They aren't rules, because sometimes the right way to solve a problem is to use something new, but they do help me avoid a lot of pointless wheel-spinning.
Some of those guidelines:
Editing text is a solved problem, emacs or vim, pick one and get back to work. I picked vim 20 years ago, and have mostly stuck with it. I can imagine someone else might have other editor options in the list of things that solve the editing text problem. I go outside of this guideline when poking at Android development, because all of the current docs and tutorials assume I'm using Android Studio and the friction is so much lower when using those tools. At other times I've used other tools. jEdit, Eclipse, OpenOffice, when they were the right tool. But, I always come back to vim for editing text, and it's always what I try first before trying to find the optimal tool...only if vim makes something hard do I branch out.
Linux distributions aren't all that different. Pick one, and get back to work. I picked Fedora 20 years ago (when it was called Red Hat Linux), and have stuck with it. CentOS/RHEL/Scientific Linux goes on my servers, because it's just like Fedora, except stable and reasonably secure for up to a decade after release. Other options are reasonable, but there is no reason for me to switch. I have to know the server-side of every distro my software supports (and FreeBSD), but I don't need to know the desktop minutiae of every distro, so I ignore it completely.
Avoid relying on proprietary tools, particularly those that require a lot of learning to use. This one is more subtle. Maybe the best tool for the job is a proprietary piece of software or a web service...but, it's difficult to have faith that it will be around in five or ten years. So, if there is a slightly worse Open Source option, I will choose that option, because I am less likely to have to learn it again or re-develop my ancillary tools to work with it. I happily pay for good software...but, I don't happily pay (in time or money) for a forced upgrade/migration cycle.
There are lots of others that are less relevant for this context; experience can make some kinds of decisions quicker to make. Though, I guess it can also put blinders on making it harder to see new and better ways to do things. It's probably worth revisiting these decisions every five or ten years to be sure the landscape hasn't changed dramatically.
Some of those guidelines:
Editing text is a solved problem, emacs or vim, pick one and get back to work. I picked vim 20 years ago, and have mostly stuck with it. I can imagine someone else might have other editor options in the list of things that solve the editing text problem. I go outside of this guideline when poking at Android development, because all of the current docs and tutorials assume I'm using Android Studio and the friction is so much lower when using those tools. At other times I've used other tools. jEdit, Eclipse, OpenOffice, when they were the right tool. But, I always come back to vim for editing text, and it's always what I try first before trying to find the optimal tool...only if vim makes something hard do I branch out.
Linux distributions aren't all that different. Pick one, and get back to work. I picked Fedora 20 years ago (when it was called Red Hat Linux), and have stuck with it. CentOS/RHEL/Scientific Linux goes on my servers, because it's just like Fedora, except stable and reasonably secure for up to a decade after release. Other options are reasonable, but there is no reason for me to switch. I have to know the server-side of every distro my software supports (and FreeBSD), but I don't need to know the desktop minutiae of every distro, so I ignore it completely.
Avoid relying on proprietary tools, particularly those that require a lot of learning to use. This one is more subtle. Maybe the best tool for the job is a proprietary piece of software or a web service...but, it's difficult to have faith that it will be around in five or ten years. So, if there is a slightly worse Open Source option, I will choose that option, because I am less likely to have to learn it again or re-develop my ancillary tools to work with it. I happily pay for good software...but, I don't happily pay (in time or money) for a forced upgrade/migration cycle.
There are lots of others that are less relevant for this context; experience can make some kinds of decisions quicker to make. Though, I guess it can also put blinders on making it harder to see new and better ways to do things. It's probably worth revisiting these decisions every five or ten years to be sure the landscape hasn't changed dramatically.