Any suggestions on how I can speed up my workflow in Elixir?

[StefanHoutzager]

Good question. A couple of giants have thought about this. For them TDD (recommended by others in this thread) is not the way. Leslie Lamport:

Today, programming is generally equated with coding. It’s hard to convince students who want to write code that they should learn to think mathematically, above the code level, about what they’re doing.

Bulletin of EATCS

Architects draw detailed plans before a brick is laid or a nail is hammered. But few programmers write even a rough sketch of what their programs will do before they start coding. We can learn from architects. […]
Programmers spend a lot of time thinking about how to code, and many coding methods have been proposed: test-driven development, agile programming, and so on. But if the only sorting algorithm a programmer knows is bubble sort, no such method will produce code that sorts in O ( n log n ) time. Nor will it turn an overly complex conception of how a program should work into simple, easy to maintain code. We need to understand our programming task at a higher level before we start writing code. […]
Writing formal specs also teaches you to write better informal ones, which helps you think better. The ability to use tools to find design errors is what usually leads engineers to start writing formal specifications. It is only afterward that they realize it helps them to think better, which makes their designs better.

We need to understand our programming task at a higher level before we start writing code.

There are two things I specify about programs: what they do and how they do it. Often, the hard part of writing a piece of code is figuring out what it should do. Once we understand that, coding is easy. Sometimes, the task to be performed requires a nontrivial algorithm. We should design the algorithm and ensure it is correct before coding it. A specification of the algorithm describes how the code works.

Etc, see Untimely meditations about software engineering for the full text.

Donald Knuth wrote about “Literate programming”:

According to Knuth,[5][6] literate programming provides higher-quality programs, since it forces programmers to explicitly state the thoughts behind the program, making poorly thought-out design decisions more obvious. Knuth also claims that literate programming provides a first-rate documentation system, which is not an add-on, but is grown naturally in the process of exposition of one’s thoughts during a program’s creation.[7] The resulting documentation allows the author to restart his own thought processes at any later time, and allows other programmers to understand the construction of the program more easily.

Literate programming

Knuth only rarely uses unit tests:

the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

Here explicit about extreme programming (TDD etc):

Still, I hate to duck your questions even though I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term “extreme programming” sounds like exactly the wrong way to go…with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.

Interview with Donald Knuth | Interview with Donald Knuth | InformIT

Others / related:

Writing documentation improves the design of your code. Talking through your API and design decisions on paper allows you to think about them in a more formalized way.

A beginner’s guide to writing documentation

The Ultimate Guide to Code Documentation for Development Teams