Becoming an intermediate elixir developer

There’s no easy answer. To gain experience you need to spend time experiencing multiple situations. The experience you gain with side projects that aren’t really “in production” is helpful, but not the same as working for a company that has production systems.

I am encouraged by your elevator example. My first ElixirConf talk about OTP used elevators as the test case. https://www.youtube.com/watch?v=R_8ehmGTVbw

I’m in the same dilemma as you are. Nice question

This is a great talk @gregvaughn! A great showcase of what OTP is capable of.

You are correct here. At the moment any actionable advice is appreciated. With that being said, I able to extract the following advice from your response:

1. Watch more elixir conference video which discuss OTP and understand the reasoning behind the presenter’s idea and code. Furthermore, try to reimplement my own solution for the talk. E.g your elevate talk and the source code.

Indeed there is no easy answer but for me at least Erlang/Elixir’s main value proposition is the OTP (Erlang) and metaprogramming / macros (Elixir).

Invest in those. I am yet to read the “Metaprogramming Elixir” book (I have it) but I only hear good things about it. There are 2-3 really good books about Elixir + OTP in particular as well and I have one of them (I think by written by @JEG2).

It’s important to know your own learning style. Do you prefer the conference talk style, or a tutorial video, or would you prefer to read a book, or do you jump into a coding project and learn what you need as you go? Any of those can work.

One thing that I have consciously done in my career is to gain some understanding of the layer below where I’m actually working. For example, if you’re working in any web framework, you ought to know something about the HTTP protocol. If you’re working with Ecto.Changesets then it’s helpful to have an idea of what data is stored in there. Knowing these things help you gain intuition of what is easy/possible/impossible and help you have a mental model for when things don’t go as expected and you have to debug.

Making architectural decisions is just the how. I always start with why. Why do you have this particular problem that you are tasked to solve?

Why does the business want a new elevator service? Are the current solutions too slow? Is the problem actually optimizing elevator dispatch?

Similarly, understand the business can help choose between sql and nosql. Nosql or document databases are very flexible and works great for nested relations. Is that what the business data look like?

Also, design docs are necessary evil. You may or may not like them, it’s a tool for communication.

Sorry if all that seem too vague. I guess my point is you want to think like an engineer, so you have to understand requirements as well as the limitations.

Meta programming is also something on my list to review as well.

I believe you are referring to this book by @JEG2. I have read that book. It was one of those books that helped me become a mature developer. Helped to think through an application from data to GenServers.

I mainly prefer books and video courses since they tend to be more comprehensive. And recently I am starting to appreciate conference talk as well.

This is a very good point.

Maybe contributing to open source?