I don't typically write "lifehack" posts, but this question has come up repeatedly over the last few weeks:
How did you find time to learn Elixir? Must be nice to not work or have a family :p
I'm also very married and a father of two, and I'm happily working full time (more than full time really) with Pluralsight. But I also had ample time to dive into Elixir and I thought I would share how I did it.
And I'll just come out with it right here: A series of little wins. I set myself up to win tiny little tasks which then led to more tiny Little Wins and the next thing I knew, I was thinking in Elixir. A series of Little Wins, I can't write that enough. More on this below.
This post will be a combination of "lifehack" stuff as well as tangible steps I took over the course of two weeks to become reasonably proficient in the language. Apply to whatever language you like. Elixir is the 7th programming language I've learned (and no I'm not counting HTML and CSS):
These are in no particular order and we could argue whether SQL is really a programming language but I've programmed systems using PLPGSQL so I say it is :p.
Give Yourself Permission
Make the decision, don't waffle. Don't say stupid shit to yourself, including:
- It's a fad
- I'm too old/young/fat
- There's no job market for it
- Something will come along and replace it later
I could go on, but you get the idea. These are downers and only serve to derail inspiration and make you sound toxic. Don't be toxic.
It's a Fad (or: "I'm an Asshole")
People have said this to me about every single language I learned save for Pascal (because it was the 80s) and SQL (because it's a workhorse language that's been around forever). Everything is a fad in a long enough time scale and when you say these words aloud you sound like a complete asshole. You might be right, the language you're referring to might go away in a few years - you still sound like a toxic asshole so let be aware of how your words impact others - mostly yourself.
Assholes don't do anything but sit on the sidelines and call people names. Let them. You hitch your wagon to whatever star you like and be a better you. We're in an industry that is ever-changing, ever-moving. You need to move with it or you need to move aside.
There's No Job Market/Use Case/What Can I Do With It?
You're opening a door here, not solving a problem. Even if nothing amounts from it you've stretched your brain some, exercised your ability to solve a problem and that is always a win. You simply cannot go wrong by trying to learn something.
When you do learn it you might find yourself creating something fun or solving a problem in a more elegant way that you can bring back to your day job. I did just this when I learned Ruby - my brain exploded with ideas and I created Subsonic and a number of other projects inspired by the language.
Decide. Just... Decide. Now let's...
Before I get into the nitty gritty details I need you to focus on the importance of execution. You can't go into this with the decision made and say "ho hum when I get the time... maybe this weekend". Nope. You must execute and it can literally be 10 minutes a day at lunch or 2 hours at night where you code instead of fucking off on Xbox.
What's coming next is how to set yourself up to win little tasks - building one win on top of another, creating a "cadence" the builds under you. But you won't do any of it unless you commit. I put "Elixir Time" on my calendar every day and treat as an appointment I need to keep, which underserves it because it's so much more.
This is time I'm investing in myself, in my career. Time that I will not question, I'll just execute.
Here are some simple steps to move beyond dreaming about it and actually doing it. They might sound silly, but each one is a demonstration of your commitment and, in a way, a Little Win:
- Follow the movers and shakers on Twitter
- Sign up for the weekly newsletter
- Install Slack and subscribe to the language team
- Read and Post questions on Stack Overflow
- Write some blog posts (if you're into that kind of thing) about your explorations. This requires you to be fearless (see above).
And now, let's write some code.
My Series of Little Wins
I suck as a programmer so it's important for me to not give into my incompetence and lack of confidence. I Decided to learn elixir I gave myself time to Execute - now the question became what, exactly, will I do?.
Having a goal is nice, but it can also be destructive if you set it when you have no idea what's going on. So skip the goal, let's Execute and have a good time!
Task 1: Creating a New Project
How much easier could it be? With C#/.NET it's File > New Project and you pick your flavor of project. With Ruby it can be a single file all the way up to a nicely structured set of directories. It's a little wild west in there, but it's doable. With Node it's
npm init my_project.
With Elixir it's spelled out with a quick Google search:
mix new my_project ➜ Projects mix new my_project * creating README.md * creating .gitignore * creating mix.exs * creating config * creating config/config.exs * creating lib * creating lib/my_project.ex * creating test * creating test/test_helper.exs * creating test/my_project_test.exs Your mix project was created successfully. You can use mix to compile it, test it, and more: cd my_project mix test Run `mix help` for more commands.
That took 3 or 4 minutes of reading, 3 seconds to do. At this point we have a lot we can do, but the first thing to notice is the last line - where to find help. That says something about the project. We have a
/test directory and a config setup. Nice!
We just learned a lot and executed a little win. We can now stop here and go play Xbox.
Task 2: Writing a Test
We've created an initial project, now how do I write a test? This is where things can get kind of nuts because we haven't even dabbled in the language yet! Let's not get too out of control on this one - we need a small win so make this easy.
test directory so having a look inside we see two files:
test_helper.exs. This tells us something:
- The file extensions for Elixir are
.exsas seen in our project setup. Something to write down later as a Little Win.
my_project_test.exsfile is likely a throw away, which is great because we can hack it up
- The concept of Test Helpers is there for us. Nice!
Looking inside the test file we see this:
➜ my_project cat test/my_project_test.exs defmodule MyProjectTest do use ExUnit.Case test "the truth" do assert 1 + 1 == 2 end end
It's a somewhat familiar syntax and I can apply rules from other languages to it. The constructs are clean and feel very Ruby-ish to me. I like that (I like Ruby) and from here I think I can write a test of my own:
defmodule MyProjectTest do use ExUnit.Case test "the truth" do assert 1 + 1 == 2 end test "my name" do assert "Rob" == "rob" end end
Kind of a dumb test, but I want to watch it fail (hopefully). If it doesn't, I just learned something rather huge. Now I just need to figure out how to run a test.
I remember when I created the project it said "Run 'mix help' for more commands". Let's start there - if mix created the project for us, it will probably run the tests too:
➜ my_project mix help mix # Run the default task (current: mix run) mix app.start # Start all registered apps mix archive # List all archives mix archive.build # Archive this project into a .ez file mix archive.install # Install an archive locally mix archive.uninstall # Uninstall archives mix clean # Delete generated application files mix cmd # Executes the given command mix compile # Compile source files mix deps # List dependencies and their status mix deps.clean # Remove the given dependencies' files mix deps.compile # Compile dependencies mix deps.get # Get all out of date dependencies mix deps.unlock # Unlock the given dependencies mix deps.update # Update the given dependencies mix do # Executes the tasks separated by comma mix escript.build # Builds an escript for the project mix help # Print help information for tasks mix hex # Prints Hex help information mix hex.build # Builds a new package version locally mix hex.config # Reads or updates Hex config mix hex.docs # Publishes docs for package mix hex.info # Prints Hex information mix hex.key # Hex API key tasks mix hex.outdated # Shows outdated Hex deps for the current project mix hex.owner # Hex package ownership tasks mix hex.publish # Publishes a new package version mix hex.registry # Hex registry tasks mix hex.search # Searches for package names mix hex.user # Hex user tasks mix loadconfig # Loads and persists the given configuration mix local # List local tasks mix local.hex # Install hex locally mix local.rebar # Install rebar locally mix new # Create a new Elixir project mix phoenix.new # Create a new Phoenix v1.0.0 application mix run # Run the given file or expression mix test # Run a project's tests iex -S mix # Start IEx and run the default task
Good grief. There's a lot in here - stuff I should actively ignore right now because I'll short-circuit, become overloaded and give right into my insecurities that I talked about above (I can't do this, it's too big, it's a fad*).
Right there at the bottom is what I need -
mix test # Run a project's tests. Boom.
➜ my_project mix test Compiled lib/my_project.ex Generated my_project app 1) test my name (MyProjectTest) test/my_project_test.exs:7 Assertion with == failed code: "Rob" == "rob" lhs: "Rob" rhs: "rob" stacktrace: test/my_project_test.exs:8 . Finished in 0.02 seconds (0.02s on load, 0.00s on tests) 2 tests, 1 failures
Radical! I learned so, so much with this Little Win:
- Elixir is a compiled language
- Testing a project also compiles it
- Case sensitivity is built-in for strings (hooray!)
- The assertion failed in an informative way.
lhsmeans "left hand side",
rhsis "right hand side" and I can see what failed and how.
With these two wins I can now move on feeling pretty damn happy.
Strings, Dates, Numbers - Getting a Footing
This part might seem obvious, and indeed it is. It also requires a book or some type of learning resource besides Google. For this kind of thing I tend to go directly to Pragmatic Programmers. Do a search on Elixir and find a great set of books. But there's one that stands out and it's amazing: Dave Thomas's Programming Elixir. This book is simply wonderful and I can't recommend it enough.
Usually when I read programming books I like to read them in the order in which makes sense - for me it's learning the basic types, then the operators, data structures and so on. Here I found Dave's lead in to be so fun to read - I recommend it highly.
Elixir is a functional language so this book starts with that, which it should. For me, functions are made from primitive elements like strings, numbers, dates etc. so I like to know how those work. I read how those work, play around in my little project and write some more tests to see these things work.
Specifically strings - that's just me. I find that if a language has any warts it will be in how it handles strings, mutability, regex, and so on.
This is where you and I will branch off. I get my footing by understanding basic types - you might need to learn data structures and method calls. Either way slice it up so you can learn a little at a time. For me, it was:
- Concatenating a String
- Using basic Regex to run replacements and matches
- String syntactic sugar
With dates I found out (rather quickly) that the date/time story in Elixir is a bit limited and if you need to work with these things you'll be installing a package called Timex. I also found out that you can access stuff from Erlang directly (which a lot of people do). I bookmarked this as a thing to come back to (which I still haven't done).
Data Structures and Databases
My first set of experiments and Little Wins took about a week, and the more I built up my wins, the harder it became to get focused. I fight this constantly - I just want to jump to the finish line and build stuff. It takes a lot of effort to stop myself and stay focused.
I felt pretty good about the basics and how projects went together - now it was time to work with basic lists and data structures.
And this is where my brain exploded. Elixir is a functional language and there are aspects to it that are completely foreign to me (which is no surprise really). I tried as hard as I could to control the firehose of concepts coming at me... but eventually I just gave up and let it wash over me and I read the book all the way through.
Knowing I would pick it up again and read it quite a few times over.
At this point I stared at the mess of concepts on the floor and decided to pick one and dive into it. So I did - setting myself up for Little Wins here and there with each "higher" concept beyond the basics. Specifically:
- Using Recursion to iterate over a list and perform an operation
- Using List Comprehensions in a meaningful way
- Using the Pipe operator
The problem I typically have with this kind of thing is that it's all so demo-y. I need to grasp something real! So I did, and I modified my list:
- Successfully Query PostgreSQL
- Using Recursion to iterate over a list and perform an operation
- Using List Comprehensions in a meaningful way
- Using the Pipe operator
From there I was able to roll lists of data that meant something to me, using the the types and tests that I began to understand from before... the wins were piling up...
An Ongoing Thing: Finding the Idioms
Here's a neat thing about Elixir - there are some voluntary idioms that people use (like the callback structures in Node) to make life easy. Here are a few:
- Required function parameters come first and are listed out. Optional parameters are passed using a Keyword List
- Function results typically have a tuple structure that indicates what happened - like
- Pattern Matching allows you to control the flow of your application in a very elegant way
- Writing smaller, more concise functions and piping them together makes programming a lot of fun
There are more idioms - and right now this is where I'm at. Call it "Level 5" if you will - and this is where the work begins. From here the Little Wins shift from learning to building, which is exactly what I've started to do.
I feel pretty good about the way things are going.
Are you feeling anxious about this post? Do you want to tell me how you wish you had time or that that sounds fun but I need to make money? I'll ask you why you work in a young, vibrant industry and expect things to stay the same for you.
Be an innovator. Make positive changes. You can do it - just give yourself the time and go for the Little Wins.