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. Elixir Conf 2014 - Elixir Elevate by Greg Vaughn - YouTube

Some project ideas:

• Build the Game of Life without using any processes. Try to minimize the cells processed in each new generation.
• Build any moderate sized project while pairing 100% of the time. Trade driving so it’s 50/50.
• Build a chat application using only what ships with Elixir (and Erlang). The app should be able to “Host” or “Join” an IP that’s currently hosting. Make sure I can receive messages while I’m typing one.

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.

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.

The first thing I tried to write in Elixir was an auction application for my fantasy football league. I built it such that it could support multiple auctions going on in different leagues concurrently. That felt like an intermediate introduction to Elixir and especially OTP. Since then I have worked on a charting library and a little toy Phoenix app that demonstrates that library.

From all of that, the advice I would give for a learning project order would be:

• Pure functional library
• Project that uses OTP (if it needs a database, just use ETS)
• Project that uses Ecto
• Project that uses Phoenix (these last two could be reversed. My Phoenix project doesn’t use a database and that has made it much simpler)

I think not starting with Phoenix made Phoenix much easier to understand at an intermediate (as opposed to “I know who to write a CRUD app with it”) level once I got to it.