4 ms·
I think the best answer is "the one you're interested in" or maybe if you have a goal then use that? Learning something completely is never simple, everything
by openfuture 8y ago
I think the best answer is "the one you're interested in" or maybe if you have a goal then use that?
Learning something completely is never simple, everything leads to the same thing.
- cutety 8y ago> I think the best answer is "the one you're interested in" or maybe if you have a goal then use that? Ding ding ding, this is the correct answer. Something you have a vested interest in will always be infinitely easier to learn than some random thing someone else (who likely _is_ interested in it) suggests because they said it was easy. For example, while not exactly a “super simple” topic, at work part of my responsibilities include maintaining/developing ETL jobs for copying data from a few data warehouses to local app dbs. I absolutely dread anytime I have to spend any amount of time working on these, I find it boring, the software terrible, the problems tedious. And, I’m certain if I spent a fair amount of time really learning the technologies/patterns/etc, it wouldn’t be nearly as much of a chore. And, given I’m not working with google level terabytes of data, only a few 100 or so gigs, the scope of what I’d have to learn likely isn’t terribly difficult. The problem is though, I have absolutely no interest in doing so, I only work on them because I inherited them, and if I were to need to do the same thing from scratch, I’d likely try something other than “enterprise” ETL frameworks, or more realistically try my damndest to find someone that actually likes doing this kind of thing so then I don’t have to worry about it. Contrasted to about a little over a year ago, I got super interested in CI/CD and containerization technologies. I started having no experience with CI, Docker, and really only having deployed things to heroku. However, I was fairly quickly able to get up to speed with the basics of the technologies, and then a short time after that I became the “Docker & CI” guy at work, I found that I was able to quickly and (hopefully) competently answer almost any question/issue coworkers were encountering. I now spend a fair amount of time configuring CI and containerizing older apps in our portfolio just because I thought it was fun/interesting to do, which provided me with even more opportunities to learn and find gaps in my knowledge. But, to some others, spending any amount of time configuring CI, fighting with a legacy codebase to get it’s test suite to run in a containerized/CI environment , and building security scanning practices likely sounds absolutely dreadful, tedious, or a waste of time. So, whatever you have an actual interest in learning completely will be the easiest, whether that be Machine Learning, full blown functional programming in Haskell, enterprise Java OOP, application architecture, compiler/language development, or even something as deceptively “simple” as building CLI tooling. Anything someone advertises to you as “easiest to learn” is something that person themselves are interested in, which is why to them it was easy, but if you don’t give a shit about it, it likely will be a chore and far from the “easiest”.