By who’s standard?

You’re still learning - and as such you should never stop learning. Developing software isn’t a manufacturing activity - it’s a design activity and the pace is totally different.

• Productive is a massive red herring

What you really need is more practice in “building software” and it’s debatable whether increased tool savviness will give you that.

By all means, always look to automate repetitive tasks but if that requires “learning and adopting yet another tool” think about the potential opportunity cost. Time learning yet another tool is taking time away from improving the skill of “building software”. So before adopting yet another tool: the potential benefit better be worth it.

The flip-side is that failing to commit to adopting a particular tool can be just as harmful - in the past not properly learning Brunch with Phoenix could become a potential time sink - just like adopting Vue.js or React while neglecting webpack can be a mistake.

So choose the tools that you invest time in wisely. And once you commit to one, go just a bit further than you think you need - otherwise you may not be aware of the additional benefits that the tool can give you.

(This is why I tend to prefer small tools that do one thing well (and hopefully integrate well with other orthogonal tools) - usually it doesn’t take that long to harness their full potential. “Batterys-included”/“all-in-one” tools tend to have a steeper learning curve even if you want just a small part of their functionality.)

After some “building software” practice, invest in some Hammock Driven Development - i.e. don’t let tool-use get in the way of (or worse, replace) thinking. Conversely sometimes you need to do stuff to move the thinking along - and possibly even throw away “the stuff you just did”.

Just keep in mind:

• Tests are real code and as such they should adhere to the same quality standards as production code - if you are going to keep them over an extended period of time.
• Don’t let the tests weigh you down. Regardless of the coding investment, delete them when it’s clear they are testing the wrong thing in the wrong place. Deleting tests can be hard; treat them as a byproduct of your knowledge acquisition process. Tests can be used to explore the solution space for a particular problem. You can easily find yourself in a position where the tests will tell you that you misunderstood the problem. The tests have done their job - now delete them and start solving the right problem in the most appropriate manner.

Aside: The IDE Divide
Move Slow and Mend Things by Kevlin Henney

One solution is to start by writing test… It would pay off in the long term.

In your case it would pay off directly because testing manually 20x each actions is kind of avoidable.

Start by writing the exact expected result, and assert around response… after all we have ExUnit

I often use h or i in the console…

eg

iex> h Task.async

def async(fun)                                 

    @spec async((() -> any())) :: t()

Starts a task that must be awaited on.

This function spawns a process that is linked to and monitored by the caller
process. A Task struct is returned containing the relevant information.

Read the Task module documentation for more info on general usage of async/1
and async/3.

See also async/3.


                           def async(mod, fun, args)                            

    @spec async(module(), atom(), [term()]) :: t()

Starts a task that must be awaited on.

A Task struct is returned containing the relevant information. Developers must
eventually call Task.await/2 or Task.yield/2 followed by Task.shutdown/2 on the
returned task.

Read the Task module documentation for more info on general usage of async/1
and async/3.

## Linking

This function spawns a process that is linked to and monitored by the caller
process. The linking part is important because it aborts the task if the parent
process dies. It also guarantees the code before async/await has the same
properties after you add the async call. For example, imagine you have this:

    x = heavy_fun()
    y = some_fun()
    x + y

Now you want to make the heavy_fun() async:

    x = Task.async(&heavy_fun/0)
    y = some_fun()
    Task.await(x) + y

As before, if heavy_fun/0 fails, the whole computation will fail, including the
parent process. If you don't want the task to fail then you must change the
heavy_fun/0 code in the same way you would achieve it if you didn't have the
async call. For example, to either return {:ok, val} | :error results or, in
more extreme cases, by using try/rescue. In other words, an asynchronous task
should be thought of as an extension of a process rather than a mechanism to
isolate it from all errors.

If you don't want to link the caller to the task, then you must use a
supervised task with Task.Supervisor and call Task.Supervisor.async_nolink/2.

In any case, avoid any of the following:

  • Setting :trap_exit to true - trapping exits should be used only in
    special circumstances as it would make your process immune to not only
    exits from the task but from any other processes.
    Moreover, even when trapping exits, calling await will still exit if the
    task has terminated without sending its result back.

  • Unlinking the task process started with async/await. If you unlink the
    processes and the task does not belong to any supervisor, you may leave
    dangling tasks in case the parent dies.

## Message format

The reply sent by the task will be in the format {ref, result}, where ref is
the monitor reference held by the task struct and result is the return value of
the task function.

I also use a lot of tab completion, it gives me the list of module’s functions directly from the console.

Another tip is I start a phoenix server with

$ iex -S mix phx.server

I can update code, recompile from the console and have it reload in my browser (in case of Phoenix) without ever restarting my server.