[eru]

> I want to study data science, maths, devops and find that my desire is driven by fear of becoming outdated and irrelevant. [..] and conquering the anxiety of ever changing rules to the game.

If that is your genuine concern, I'd suggest focussing on timeless topics. Two easy rule of thumbs: (1) if it's been around for a while and still relevant, it's probably going to stay that way (eg compilers/parsers, operating systems). (2) if it's hard and math-y, it has a good chance at staying power, even if new.

In any case, do what adyus said: pick one thing, and ship, ship, ship.

Some inspirational reading: Peter Norvig's "Teach Yourself Programming in Ten Years" (http://norvig.com/21-days.html), Richard Hamming's "You and Your Research" (https://www.cs.virginia.edu/~robins/YouAndYourResearch.html). Or if you are of a more entrepreneurial bend, P.T. Barnum's "The Art of Money Getting" (https://www.gutenberg.org/files/8581/8581-h/8581-h.htm)

Happy to talk in private. My email is in my profile.

(Some snark thrown in for free: forget about OOP design patterns.)

[MarcusP]

Could you elaborate on your snark? Do you think OOP design patterns become outdated quickly? Do you think it's a waste of time for a programmer to study them?

[mdup]

In my case it came in two steps:

1. Learn GoF design patterns. Be amazed by the cleverness.

2. While learning others languages, discover that other approaches remove the need for GoF design patterns at all.

Example: Visitor isn't needed in a language with double dispatch (like Lisp). Chain-of-Responsibility is just foldl. Factory for dependency injection is just a closure or a partial function. And so on.

[eru]

Yes, that's what I was playing at. Other languages have things similar to design patterns, too.

If you are in luck, a language gives you first class support for abstracting new patterns. (Eg in assembly a procedure is just a pattern and convention, most modern languages help you by providing procedures. Same languages are very good at being extended. Lisp is a good example, and so is Haskell. Even Python is great in that respect compared to, say, Pascal.)

I am still trying to figure out what dependency injection really is. It's seems like only the Java guys have a need for it, but they rave about it.

[devdas]

If you have a function which invokes a different object (or more commonly, a different network service), you pass that as a parameter instead of making a call inside the function.

foo() { service = someRemoteService(authn, authz); http://lookingglass.internal.adm.bol.com/?page=TAM+Middlewar... }

is replaced by

foo(service) { do_something_with_service(service) }

It makes replacing service with fake_service_object easier, thus simplifying the test process.

Common use case: If your service was a remote database, you can replace the database handle with a mock object which pretends to be a DB but is actually a simple object returning hardcoded values.

[Sven7]

"Successful" OOP design pattern implementations are generally dependent on the kind of team you are surrounded by, and the people that maintain the code down the road. If you are, or want to be in a position to influence those decisions, OOP is good to have in the toolkit.

But most devs don't want to be in those positions :) Cause it involves a bit more people wrangling than code wrangling.