That’s obvious fake! Everybody in our brotherhood knows that knowledge can be gathered no matter if the object is sleeping or not! 
Eiji
2
AstonJ
As has been mentioned by others, the eco-system has expanded vastly over the last few years, so perhaps focus on the areas that interest you the most? 
In addition to the below, don’t forget we also have https://elixir-radar.com which is run by Plataformatec’s co-creator @hugobarauna and the Thinking Elixir podcast run by @brainlid and co 
(in fact check out all of the blogs and posts in our #learning-resources:blogs-podcasts section!)
Also, if you’re a member on the forum you should also be getting our digest emails - these are great because they often highlight what’s hot not just in threads, but also posts (it’s not uncommon to see a post by José, Chris, Robert and others feature in them!) If you’re on X then our account there tweets all public threads, and adds hashtags relating to the various frameworks/tools.
6
mindok
My intent was more generic. DDD and its ubiquitous language gets you some of the way there and allows you to discuss features with the business, but there are a lot of non-functional factors that also need translating into business-speak. For example, the ability to discuss technical trade-off criteria in terms that business people understand. “Yes, you can have sub-millisecond response time, but we’re going to have to build a nuclear power station to run all the GPUs needed to get you the answer that fast, and that may not fit with our current budget or project timelines. What, really, is the impact on the business if users have a 500ms response time?”
I think it is more about understanding what drives a business, what motivates individuals within a business (and what concerns them) and then consciously moving the discussions about features, tradeoffs etc into their frame of reference rather than just discussing concepts related to features in a common language.
Where you focus your learning efforts depends on how you see your career evolving. I have personally found it easier to develop my communication skills to bridge business and technology than to keep up with the bleeding edge of technology.
2
sodapopcan
Oh right DDD. I would say that in general it’s good to study DDD, especially when it comes to Phoenix/Elixir. While they aren’t meant to be a 1-to-1 mapping, Phoenix Contexts are based on DDD’s Bounded Context and understanding those is a huge help in understanding how to use Phoenix Contexts better. A good “DDD brain” is also a huge asset in avoiding compile time dependency heck.
0
dimitarvp
I hope you will forgive me the generalization, but your entire follow-up post reeks of you not getting the general message and still focusing on the tech details and on your fear of missing out.
In your particular situation I’d say that if you really want to know what a distributed cache is, you should find a tutorial that lets you build a small app on 3 nodes and a singular cache server and then test it. (You’ll likely need docker-compose or k8s for this so it all fits on your dev machine.)
doing = reading * 100
…that’s all there is to it. Nothing beats practice. Reading only gets you so far, and after that point you are just blocking your brain with non-actionable shallow knowledge and reducing your overall creativity. Don’t do that.
Whether Redis or ETS or various other solutions [stepping on them] are the best option is 99% irrelevant. You need to evaluate tradeoffs on the spot when you are paid to do so, and even if you get it wrong you wouldn’t deploy an under-performing cache anyway so who cares if you get it wrong the first time? Also it has to be said that you won’t be working on e.g. real-time robotic surgery systems so no lives will be lost due to a mistake.
In the past you have mentioned your academic background (after I hinted at you having such a demeanor) and it really shows in this thread. Don’t get paralyzed by “I don’t know everything!”. Well, duh, nobody does. Chill.
We are all winging it. We are not a mythical group whose every single member is miles ahead of you and you’re the only one who doesn’t know stuff. Let go of that insecurity. Allow it to just leave your brain. Don’t hold on to it, don’t believe its lies.
As mentioned above: make peace with the fact that you’ll have to improvise and enlist all your previous experience in general problem-solving… or if you really cannot do that then programming is not for you. This is not a plumbing course; you will never be at 100% “I know everything” level (and I am pretty sure that even plumbers can never learn everything and still have to improvise every now and then).
0
Fl4m3Ph03n1x
I think you make a good point here. Do you have any you’d personally recommend, tucked away in your favorite’s?
This is where my experience differs. Most of the time, due to reasons within the companies I work with, deploying sub-optimal solutions that add to the tech debt is often common. This is done either because business wants “feature X for yesterday”, because legal reasons create hard deadlines, or simply because the company does not want to invest time and resources.
This fact forms the basis of my experience. Yes, I can deploy sub optimal solutions that are a cancer to maintain in order to make business or product happy. They’ll get their feature out to market in time. But then me and my team are stuck dealing with a radioactive stack. And the promises of “we’ll fix it later” rarely materialize.
In this reality, you only ever have 1 chance to really make life for you and your team easier. The first deploy.
As for the rest of your response I don’t really have a proper answer. All I can say is that you seem to have a pretty good grasp of my person, just by reading my posts and reasoning.
And while I still remain strong on some of my opinions, at the very least your post gave me plenty of material for self reflection. I thank you for that.
1
dimitarvp
I had, some years ago, then I forgot. Sorry.
I agree 100% but we can’t override the shot-callers. I still can do my best but I will not pursue the perfect solution from the get go because that means I must always work much more than 8h a day, which is not acceptable even if I was paid extra.
If they want low-quality work then they’ll get low-quality work. If they ask why are deliveries slow, I give it to them straight: “you wanted tasks X, Y and Z in one day and not a week, this comes with the problem that further iteration slows down – if you give us more time budget, velocity on average will increase”.
Do they usually listen? No. Have I been fired for being too honest? Yes. Do I care? Not one bit. I’d do it again.
This is where this mythical improvisation I keep mentioning comes into play. More experience, better improvisation. IMO you have plenty of experience already and are quite diligent. You should give yourself more credit. And you should care less about your employer; they are not your life.
We cannot override immutable physics laws. Don’t beat yourself over it. Again, if they want crappy work done then they’ll get crappy work done. Not your problem.
4
jarrodm
Thinking Elixir podcast
Thinking Elixir podcast. It’s been ‘enough’ for me to get a sense of what’s new in the landscape.
“Two roads diverged in a yellow wood.” All decisions have opportunity cost, but as with the Robert Frost poem, whichever path you take, you ought to own it. My advice would be to build something that scratches your own itch, and that will inform which technologies you invest in. Another piece of advice: FOMO is overrated, boring and productive should be the first option, unless you can strongly argue the benefit/cost of taking on a new approach (e.g., Liveview over deadview)
5
sabit990928
You guys already mentioned a lot, at some stage discussion found a different direction.
Let me repeat once again what others said:
- I signed up for elixir forum’s email summary. I might select few topics or could totally ignore everything
- I signed up for elixir radar weekly newsletter. Usually pick some posts if interested. Could check open position requirements and business domain
- from time to time I listen thinking elixir podcast. They gather list of news in every episode and have all the relevant links
Except for that, here’s few things that might be interesting:
- I read changelog with updates of the current tools, libraries which we use in the company
- from time to time I generate empty phoenix/liveview project. Check main differences and current standards
- in one of our previous companies we had weekly retro on friday and tried to raise such a question: “What’s new in elixir?” and you could share if there anything on your end with colleagues in a small talk manner
- I use Dash as a centralized documentation manager for interested elixir and other libraries
- could be a little irrelevant, but I try to document my journey and findings in this telegram channel Telegram: View @sr_it_blog
- solve some exercism tasks if I’m little bored from main job tasks
- always have some programming book to read. I’m slow, but at least have some books to make a quick search depend on domain
Also want to genuinely thank this discussion participators as I made several notes for myself and saved few of your links for the future 
3
