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.

Speed shouldn’t be your objective, it comes with time and experience and you will be fast at certain aspects and still slow in others. I check docs countless times a day and while I know some stuff by heart most the time I just know a vague idea of the function I’m looking for or how to do it in another language. So somethings I’m fast at others slow and I’m approaching a decade of experience.

I know many programmers who are very fast but leave an awful mess in their wake. Speed is relative, I might be able to complete a feature in 2 hrs that would take a colleague 4 hrs but he might have made a more robust, extensible solution or considered things that I forgot or considered unimportant at the time. Another programmer might take 30 mins and get something quick and dirty up which will work but will be a mess that needs mopping up sooner or later.

So focus on automating repetitive tasks. If you’re checking a browser a lot and not working in html or css then you should probably be writing tests which will let you focus on the code not switching windows. I only check the browser when I’m making a visual change like color or position and I let tests tell me if the thing is displaying with the correct values when I visit that page or run a given function and I only open iex if I want to experiment with a specific function or check docs directly via command line I rarely write new code directly there.

Testing will probably be your largest leap in speed, so I’d focus on that one first when you learn to avoid context switching to a browser when you don’t have to, that’s a massive speed increase, it’ll save you 10-15 seconds of swapping and clicking around on average. Time yourself next time you switch from terminal editor to browser and refresh and check something how long is it 5 seconds 10, 20, 30? 5 seconds doesn’t seem like much but 5 * 20 is 100 so you’re losing almost 2 minutes every time you fresh the browser 20 times assuming it’s only 5 seconds and I’d bet it isn’t. Finally make sure your editor supports running tests with a simple key binding and get used to pressing it a lot it should be 1 or 2 keystrokes. That saves tons of time because you’ll be running them a lot and 1-2 seconds to click a button or type “mix test” is a lot of time over the span of a day running tests hundreads of times. Little things like that can make massive improvements to your work speed even if everything else remains your current speed.

What @kokolegorille said, if it’s part of a project you’ll need tests anyway and having them saves you using iex and recompiling. I only reach for browser to test relatively big parts of application and mostly develop with mix test