As time goes by and Elixir grows (and my life gets more chaotic) I am having increasing difficulty keeping up to date with the Elixir ecosystem.
Often time I discover new tools, but what used to take me a couple of hours to grasp now takes likely several weeks due to the complexity. New frameworks are starting to pop up and Elixir is venturing into AI (it has been for a while now) and in a day with so many hours, I am starting to find it very difficult to keep up to date with everything.
To add to my existential dread, there are also other communities doing a very good job of spreading Elixir, like podcasts, Devtalk and even SO has seen increased Elixir activity (since last time I checked).
To even add more to this, I am also trying to expand my knowledge horizontally by reading books on transversal topics such as DDD on my own free time (which is also increasingly limited).
Discussion
So I would like to inquiry the community on some topics:
how do you keep up to date with everything?
do you pick and choose what to invest in? what algorithm do you use to discard new events?
what routine of “keep up to date” do you have?
do you “learn on the job” or do you complement with something extra?
how do you keep yourself motivated to keep pushing/learning?
And, check above source every week. In some spare moments, I occasionally browse forums, trying to discover something new.
Don’t become an information addict. The things I need to know will always reach me through some channel.
Both.
I like thinking and creating, and find satisfaction in them. Dopamine drives me forward.
If I feel tired and lack passion, take a break. Don’t let myself burn out. The most important thing is to live happily and healthily.
When I get upset by the so-called civilized life of the world, I look up at the sky and tell myself: “When an eagle soars in the sky, it enjoys all the freedom and glory.”
This i exactly my issue. Elixir community has a lot of things, and I want to keep my knowledge sharp around the community because I perceive this as being a fundamental trait not just of my employment status, but also of my work pro-efficiency.
Why would a company hire me, of all people, if some folk next door knows how to user more tools than I do?
This is the driving force of dread. I am always one step away from being out-competed. My solution to that is to be more knowledgeable than everyone else, which does come at an increasingly high cost.
Do you often find yourself learning things that add little value to your job security / position? If so, do you care? How do you justify that to yourself?
Do you channel this motivation into side projects? What is the output and how to your expose it?
The substantive part of what you need to learn is the domain or problem that the tools apply to. Tools change, but problems are a lot more stable. (Maybe there’s more depth, though, so actually understanding things can take more time.) If you learn linear algebra, you can use or read about nx, numpy, R, matlab, and they’ll all make sense since they’re saying the same stuff. If you learn about graphics, you can pick up different graphics and video libraries in different ecosystems, and go backwards to learn the language that they’re a part of. (Or suggest substantive improvements where something is missing or needs work compared to some other ecosystem.)
Elixir community become indeed very big, but you could always find that stuff you really want to use are not yet done, are in development (like no stable 1.0.0 release) or prepared for other use cases (like scenic which is primarily dedicated to embedded systems). Yeah, this community is still too small. Come on and chat with me - I’m lonely here - wait what?
Following 4 dev forums (elixir, erlang, devtalk and rust), subscribing dozens of RSS channels and reading thousands of documentation pages.
Looking for inspiration. One time I give a try “this” and the other time something else. I’m discarding RSS news manually. I’m just reading/listening//watching if I’m interested in title or in mood for something.
Wait, consume, repeat
The main tech stack you are gonna be using in next job is likely a requirement to know and understand before applying, so this does not makes a sense for me. That’s said people learn all the time - bit by bit. I found many times that I would solve same problems from past differently, but I’m not blaming myself as I remember what I felt when choosing something and I have a rule to live without real regrets.
I’m doing what I like. If I’m not touching dev-related stuff for some time then I quickly become really bored. That’s not only a way for a well-paid job, but also hobby. From time to time I’m writing a scraper to automate something or CSS style when I think that some page could look better for my use cases. When I describe it this way it looks like I’m addicted to it.
Devs secret: 5 minutes on toilet fixes all problems.
Unlike how it was many years ago now most job offers are terrible. You are supposed to be a so-called “Platform Engineer”, so in short you would do exactly everything and they would pay you a “standard” backend salary. You can ignore such offers without any worry. Nobody is expert in everything. You would be surprised when you find what “obvious things” you and other people have no idea about.
If you find a job that matches a profile then just apply. Be honest saying what you can and listen carefully to what the other side needs. If both sides are satisfied that’s called a deal. I would repeat my stories as much as people need. One time I was rejected, because I had no idea about hockey rules - that’s something you can learn easily. A good reaction is "Sorry that my parents were not Canada's citizens, lol" (of course in polite words) and bad reaction is "Ehh, I should learn x th sport rule as maybe this way I would have that job …".
If you have food and money savings you don’t need to talk with lazy monkeys. When they would become hungry come back with a banana and a smile of same size.
Work as a business - just met requirements with a declared quality and cost. As said the most important tech stack are usually required at recruitment process (of course it could be a junior role with paid learning and that’s completely different).
The common rule is:
cheap, fast and good - choose 2 of them
If they want you asap and pay small money then propose half-time work or just don’t care. It’s for sure cruel, but it works like that everywhere and in all directions. If you want something good asap then you have to pay well and so on … Think like that … how much are you willing to pay someone that want’s job asap without any knowledge or experience? How would you compare such salary to the senior or expert one?
For me it depends. One time I share a dev_joy and other time I help others. As wrote already if you want to create something then do that for things that you would use as well. People are lazy, so you are gonna be easily motivated to work hard to make a life easier.
There is just too much everywhere. There will eventually come up an occasion where you find it because you need it.
There is no algorithm. I use what I think I need, and I prefer what I have used in the past.
I can’t learn without using. Those contrived examples everywhere don’t help me, as they usually don’t cover edge cases (which I have the tendency to always hit with full speed).
As I usually learn by using at a project, finishing the project is also what keeps me learning.
It’s very often not about what you know and that you have to know everything, it’s about cultivating the mindset of being a problem solver and not being afraid of new and unknown problems because the only guarantee in programming is that you absolutely will stumble upon those and will have to learn the solutions as you go.
That’s one of the top reasons why we are paid a lot. If I were to become a car mechanic I can bet a hefty sum that I can learn 99% of every potential repair edge case in 2 years of interning at a popular and busy place.
Programming will never give you that; you have to keep your eyes open as you solve problems and finding the common threads among them. That’s why formal computer science education is actually important.
Be at ease. You can still explore – I still do even after 22 years of programming – but you have to be curious and not going full throttle and burning yourself out because that’s going to hit you VERY HARD at one point; you’ll hate the job and you’ll even start hating programming as a hobby. From then on it’s game over for you if you can’t take a 2-3 years of vacation and go on a literal and metaphorical self-discovery journey which, you guessed it, most people cannot financially afford.
Same. Some years ago I found myself wanting to spend more time with my wife… and she was literally 2m away from me almost every day and at almost every hour, and I was still not spending enough time with her. Then I said “frak that” and started aggressively cutting time on the computer that I am not being paid for (or having fun with). It was extremely difficult and I lapsed back and forth many times but nowadays I am mostly with a purpose when I am on the computer, be it a paid job or actually investing in my own infrastructure at home – or just working on a hobby project. (Or chatting with people I enjoy communicating with.)
I started being very strict about time-boxing computer activities. If I find myself just poking in the forum (this or another) for more than 1h, I just step away from the computer.
Really nice summary @derek-zhou! And the answer depends on whether the hiring manager is a corporate empire-builder, or a lean and mean startup founder! And so what and how you learn (and do) depends on who you want as a boss.
To echo what others have said, the ability to frame problems in a language common to technologists and business folk, identify potential solutions (taking into account trade-offs related to stability, cost, maintainability etc) and implement pragmatic solutions never goes out of fashion. Technology details are fast-moving. Critical thinking and good judgement are evergreen. Focus on the latter, particularly as you grow older, have less time and become more cynical.
One more thing… Even though the bleeding edge of Elixir is moving rapidly with Nx, LiveBook, etc etc, we are blessed with an incredibly stable and capable core, from the first days of Erlang, that is well suited to solving a huge range of problems. I think that’s why there are so many grey-hairs here - we’re fed up with learning new things all the time to solve the same class of problem.
What you are competing on is not who knows more tools, but who creates more business value (profits - costs).
IMO, one competitive developer should:
abstract the business, make it run stably and create real business value. (increase profits)
at the same time, ensure development and maintenance at a lower cost. (reduce costs)
Do you often find yourself learning things that add little value to your job security / position? Yes.
If so, do you care? I don’t care. Because my current job is just a temporary point in my life. I shouldn’t plan my future life solely around it. Otherwise, when I lose my job, I’ll lose my anchor in life.
How do you justify that to yourself? Plan for a greater goal, such as becoming an solo entrepreneur, and learn what is necessary to achieve it.
I try to think my job is just a transition before achieving my goal. Of course, I still need to give my best effort to work, but if others are not satisfied with my work, that’s their problem. If they are dissatisfied enough to want to fire me, fine, pay me my severance and I’ll leave immediately.
Do you channel this motivation into side projects? Yes
What is the output and how to your expose it? My Elixir related outputs are located at cozy-elixir. I just mentioned it on my personal website and GitHub page. I think promoting it everywhere can be annoying.
Additionally, I can share with you what my life has been like after overcoming information anxiety:
try to create real small business projects for solving my own problems, and it might be helpful to others. It prevent myself to fall into the tutorial trap (Everything I do remains at the demo stage.)
learn computer science. I am a self-taught developer, so my knowledge is somewhat lacking in these areas. And I have gradually grown averse to chasing trends, I just want to solve problems well enough. I find it very helpful to learn about things that haven’t changed much since their inception. (Computer science is the essence, while tools are just the appearance.)
These two activities occupy a lot of my spare time, leaving little room for anything else to distract me.
TBH, I would reject an offer myself, if it comes to “how many tools do you know”-like questions. I can solve problems, that’s why. If there is no tool to solve it on hand, I would do kinda research, and if it does not bring up anything satisfactory, I’ll create the tool myself. That’s it.
Even more, I can barely name three so-called “patterns,” let alone “tools,” and people knowing the name for each and every pattern in the universe, very rare were able to …ahem… apply any of it to the real world problems.
Why you get hired over someone else, does not really depend on your skills alone, there is this thing called “company culture”, which might be an explicitly stated and lived thing, or just some thing that evolved implicitely.
So you have to be a fit for that culture, and that culture has to be a fit for you. I don’t give a **** for getting 20 or 30% more when I already realize during the process that the culture is not one of my taste.
And of course, it always depends on whoever holds the interview… There is something involved we call “Nasenfaktor” in Germany, which basically describes the massive influence of the first impression usually based on how you look or what you wear.
For me, if the only concern was getting hired, I’d do JS/TS, Java, or PHP. But my concern is having some fun learning and coding.
I used to think a few years ago, too, that keeping up with tooling from elixir ecosystem (and not only) is important and should be a focus.
These days as I shift more to trying to break free from these glorified factory worker jobs, I understand that tooling is just a small part of the problem and understanding how to solve the problem correctly amounts to actual drastic improvements in efficiency.
In some cases it is very true that finding the correct technology to solve the problem can make it much more manageable and this is where the community comes in. Almost all of us solve problems in different domains and are acquainted with the tools and their state. For example I worked mainly with small companies that always needed web interfaces, and the release of liveview couldn’t be more perfect.
Now I not only know how to use liveview effectively, but I can consult others whether it would make sense for them to adopt it or go with another technology and this IMO is where the true value lies. Knowing who to reach to ask for advice is the key thing that is much better than trying to process all of that information on your own.
These days the only technology news I read is from lwn.net and elixirforum (even though the forum is more of a place I value for conversations like this than hard technical specifics) and occasional random sources from time to time for my personal interest in technology. I think that following feeds and other similar things is the easiest way to kill your productivity and focus, and waste your time.
Thank you all for the wonderful replies!
I cant possibly refer to all of them, so I have picked some that lead me to more questions.
I believe both of these are related.
I believe that the more tools you know, the easier it is for you to add business value because the chances of using the right tool for the job increase.
I will give an example:
Use Redis with a cluster of Elixir apps to serve as a global caching mechanism
Use Elixir ecosystem with cachex (and perhaps nebulex, although not required) to achieve a distributed global caching mechanism
Both options aim at achieving the same: a global caching mechanism.
Option 1, requires you to understand elixir, redis, and the edge cases of how redis behaves under heavy load and failure. It also requires you to know how to use redis as a persistent storage system.
Option 2 relies solely on Elixir’s knowledge. You do need to learn how to use cachex, and that may not be trivial.
At the end of the day, option 2 requires less tools to achieve the same result. But I, don’t know how to use cachex, only redis. Should I invest my next weeks learning option 2, or stick with what I already know?
I believe the person going for option 2 would have an advantage on me as they would potentially be able to achieve the same end goal with less tooling. As a result, ironically, learning more tooling is required in order to use less tooling.
Let me know if I am missing something.
So, my recent dive into a more transversal topic, DDD is something you see a more worth while investment, right?
I do struggle with this. Usually my job is a fundamental part of my life, an anchor if you will. Perhaps this is why our vision is so different.
I usually lean on the side of “I will adapt as best as I can to whatever culture the company has”. Sometimes it works, other times it leaves you damaged and broken beyond recovery.
At the end of the day, and because I have a family to keep, 30% increase in compensation does mean a considerable change for my family.
By reading more I am starting to see a pattern in here where people are not really worried about being replaced or about job security. It feels like some members here have a very different mind set from what I experience.
It looks like you deal with my anxiety in a different way, becoming a generalist problem solver.
The problem I have with this approach is that every time a new problem arises (and in this area we are blessed with never ending problems to solve), you need to learn everything from scratch, using the new tools and systems. This is fine when you are younger and have more energy/time, but as the clock keeps on ticking, the resources to always go from 0 to hero become less and less.
I believe it is because we have a problem that we seek solutions, and then look for available tools, instead of matching tools to problems.
Take your example, for instance:
“Oh, the db query is very slow” - the problem
“We have no time to improve the performance of query, so we add a cache for the query result” - a possible solution
“Are there any existing tools available? ” - try to discover available tools.
First, people will think of Redis. Then, Let’s search “Elixir Redis”. We’ll find whatyouhide/redis. If you or your team are satisfied with this tool, you can use it directly. After all, using fancy technology won’t increase your business value.
But, if you or your team heard that Elixir and Erlang are powerful, so perhaps you may think that you don’t need to use Redis. Let’s search “Elixir cache”. We’ll find whitfin/cachex.
You can see, all of this doesn’t require us to follow trends or keep up with news. Instead, we start from the problem and look for possible solutions through through multiple channels:
search engine
forums
friends
…
This is not a simple decision. You need to consider:
your or your team’s preferences
the current state of your infrastructure
your personal enthusiasm (For me, I wanna simpler stack, so I might choose to learn cachex)
…
You can think of it this way: “I need to solve a problem, and I want to solve it elegantly with as few tools as possible. First, I need to do some research to understand what solutions others are using and what their pros and cons are. And, then, choose the one that best matches my problem and has the lowest cost.”
Did you notice the main difference? Everything starts from the problem, not from the tools.
If you still feel the need to master or learn more tools, you can settle for just knowing more tools, instead of wasting time on learning technologies you might never use.
What is the meaning of knowing more tools? You only need to know a one-sentence description of every tool, and create a map for yourself:
* cache
- cachex - an extremely fast in-memory key/value store with support for many useful features, without using Redis
- ...
* params validation
- ecto changset - ...
- params - parameter structure validation and casting with Ecto.Schema.
You don’t have to master it or learn it, just know what it is. That’s enough. When you really need it, it’s not too late to learn.
As @dimitarvp said, this is what we signed up for. There’s no real getting around it, but it can be mitigated, and I’ve been doing so my whole career. I’ve used the same text editor for well over a decade, the same OS, and generally the same tech. One of the top reasons I landed on Elixir is due to its stability and its “it’s possible we’ll never see a 2.0” mindset. I also rejected the utility of things like Angular and React for business applications and have largely managed to avoid them (except for about 2.5 years).
Of course, you can still be fine being stubborn and sticking with literally the same tech and never adapting, though you will probably eventually have to become a manager. I knew a guy who was a terrible programmer in terms of code quality though had really good product sense and made apps people wanted to use. He only knew AS3 and refused to learn anything else. He now has a high up position at a large cinema company as they still had the need for AS3 in 2015 when they hired him.
This is really it.
The point is that it’s how people feel about you in the interview. Well, it is about how you feel about each other, but it depends on who is being pickier. As someone who has done a lot of interviewing, if the candidate shows they have basic programming skills then my decision is going to be based off of their willingness to learn and adapt and how I feel they will fit in at the company. I actually wish companies were allowed to be more upfront about this—for me it would sting much less to learn I didn’t get a job because they didn’t like me as a person rather than that they thought I was a bad programmer
