This is probably the 1000 post on the subject but from time to time it is fine to repeat the message.
During all my career I’ve been avoiding to be identified with any technology. Instead, I’d love to be identified by the fact that I use technology to solve problems.
This has a couple of implications that I’d love to enumerate
Programming languages will change with time
I prefer not to be called a “Ruby engineer” for example. If I do that, I am losing the opportunity to learn from different contexts. We tend to stand in our echo chamber of our environment. We lose the ability to see different approaches to the same kind of problems in order to better understand the tradeoffs.
This is why I tend to use multiple stacks in multiple pets that are not the same stacks I use in my day to day job.
You can go wide but also deep in some things
This does not mean you have to avoid going deep in some stuff. It makes sense to become an expert in your text editor. It is just that you should not despise the rest.
I’ve been using Emacs for a long time but last year moved to neovim. It forces you to make a mental change that is well worth. I don’t regret any second I spent tweaking my (emacs config)[https://github.com/rafadc/emacs.d/blob/master/settings.org] and it helped me a lot in creating a workflow I am happy with for vim.
There are some things that belong to a common knowledge that is well worth the effort
I am finishing another skim of Designing data intensive applications and its knowledge can be applied to an enormous set of situations. It will not perish when new databases arrive or will not fade out when a new feature appears in PosgreSQL. It can be helpful when you are in a MySQL environment or in a MongoDB project. That knowledge is extremely valuable.
We learn by connecting the dots
This is often overlooked. There is one helpful strategy on learning that consists in associative learning. You learn better by connecting similar concepts together. Knowledge is better anchored if you have many different places where you get the same concept from. For example, if you know how to do concurrency in Go it will be far more easy for you to grasp it in Javascript. But also the other way round it true. You will become better and the concurrency you already knew by knowing what other options are and what tradeoffs other people had.
Also, this way of accessing the same concepts from different angles trains our ability to check to the same problem from different perspectives.
So, my recommendation to all my fellow inhabitants of the tech landscape is to prevent yourself from becoming a Java engineer and instead become a problem solver that specializes in tech to solve problems.
Happy hacking!