DEV Community: Edney Pitta

My anti-procrastination list

Edney Pitta — Mon, 04 Jun 2018 16:52:32 +0000

Originally published on my blog.

I'm a procrastinator. I wanted to write a well-researched-long-form article about what I'm doing to fight it but, well, I started to procrastinate on that.

What follows is a list of 3 actions with some background information that have been helping me to stop procrastinating lately. Probably they won't work for you exactly as they are stated here (they might not even work for me at some point anymore), so my advice is to try and adjust them to your needs.

1) Don't overload your working memory

We have two memory systems: our working memory handles what we are immediately and consciously processing in our minds, as opposed to the long-term memory, which is responsible for storing larger chunks of information. The key fact about our working memory is that it can only hold about 4 chunks of information simultaneously, and acknowledging this had a big impact on how I work.

As you go through the day, you load your mind with all sorts of stuff: the comments you're getting on your recent Facebook post, that e-mail you still have to answer, a couple pieces of code you saw that need some refactoring, etc. To remember all these things you start to accumulate them on your working memory, which may cause you to feel overwhelmed and not knowing where to start.

This is by far the biggest reason for me to procrastinate. Preventing this alone helped me a lot, so I always keep this in mind: I cannot overload my working memory. I have to protect it, keep it focused only on the task at hand if possible. Here's a list of what I did to achieve this:

Set up an agenda. Whatever comes that I'll need to do later, I just put a scheduled reminder on my Google Agenda.
Related to the previous point, I started to use post-its while I'm coding. It helps me to break my tasks in smaller pieces and, if something unexpected arises, I just write it down and continue to do what I was doing. This has an incredible effect because I know I can safely focus on the current task and review all other things later, so they don't have to be on my working memory.
Avoid social media during the workday, specially in the morning. I used to wake up and catch up on stuff posted last night while in bed or commuting. By the time I sat down to work, my mind was already full of information and it was way more difficult to concentrate on work. Avoiding that makes me feel like my mind is empty, free to focus.

2) Break bad habits

We are driven by habits, so it's important that we recognize which ones are harming our productivity or making us procrastinate.

As I mentioned, I had a habit of checking up social media and news sites while in bed in the morning. In fact, I had a problem with social media in general: once checked, I kept coming back to them, scrolling for minutes just to realize that none of that was interesting. I was kind of addicted to the notifications and new messages' little hits of dopamine. To beat that, I followed a so given advice: increase barrier to entry.

There are many ways you can do this. What worked best for me was turning my phone into a dumb phone: I uninstalled all social media apps, blocked WhatsApp and Slack notifications and even disabled my browser. This made it impossible for me to quick check social media on my phone and waste time on them.

I had to go even further however. I still had this problem in the browser, where I could just type "fa" and it would complete to "facebook.com". So I built a Chrome extension that hides the news feed from social media sites (Facebook, Twitter, LinkedIn) and stories from Hacker News and Reddit. It's been working great because I can still use other features without getting distracted by the feed.

3) Be aware of your energy level

Lastly, I think one of the key aspects to avoid procrastination is to get to know yourself, specially regarding your energy level. We all have limited willpower to concentrate on work, and it takes energy to do so. Here's a few things I believe is crucial about this:

Identify when you are the most energetic. Personally I prioritize the mornings to do the hard work, so I try to wake up (and go to bed) early and schedule meetings for the afternoon.
Recognize when you are tired and act accordingly. If I'm having a hard time trying to focus on task, I find it's probably better to stop and find activities that doesn't require as much energy, like answering e-mails and reviewing code. Even better is engaging in activities that recharges me, like reading a book or taking a walk outside.
Find out what kinds of activities take you more energy. I always knew I was an introvert, but it was only when I read the book Quiet that I discovered what it meant and it finally clicked: interacting with people takes energy from me. Focusing on work right after a meeting, for example, is very ineffective and frustrates me. So I optimize this by trying to schedule meetings close to breaks, like lunch or end of afternoon.

Thanks for reading!

References and further reading

On Node.js, Go and concurrency

Edney Pitta — Fri, 13 Oct 2017 16:17:36 +0000

Originally published on my blog.

In a recent interview, Ryan Dahl, creator of Node.js, said the following quote when talking about Node's concurrency model:

[...] I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.

That was strong. Why Dahl, who worked so hard to build and advocate Node.js back then, would just give up his creation and promote something else? What does that mean to Node.js and its huge community?

Let's first do a quick recap.

Node.js history

Node.js was inspired on NGINX event-driven architecture non-blocking I/O. Basically it means that instead of relying on threads for concurrency (be it OS, green or coroutines), we have only one thread coordinating asynchronous work through an event loop.

Dahl then built Node.js to make it happen, mixing together other facilities like a simplified web server API, V8 and JavaScript, which is single-threaded.

He believed heavily on this concurrency model. In his first talk presenting Node.js, he claimed that we've been doing I/O wrong. Dealing with multiple threads is misleading for developers and results in a higher consumption of CPU and memory because of context switching and the execution stack that each thread takes.

And given the undeniable success of Node.js, we could only assume he was right. What made him change his mind so dramastically, though?

Go's concurrency model

Go is a language built for concurrency. It's based on CSP (communicating sequential processes), a pattern described in 1977 by Tony Hoare.

Making a long story short, Go is multi-threaded and blocks I/O. Why isn't it slow? The trick is that it's all managed by Go's runtime: when you create a goroutine, you're not actually creating a thread (neither a coroutine). What Go does is combine independent coroutines onto a set of threads, so when a coroutine blocks, the runtime automatically moves other coroutines to a different, runnable thread.

Another important part is that these goroutines communicate via channels, so instead of sharing memory across threads (which introduces awful locking problems), they pass references to data. This ensures that only one goroutine has access to the data at any given time.

Do not communicate by sharing memory; instead, share memory by communicating.

And it's working, apparently. Go's growth has been stunning and it is today a solid choice for concurrent solutions. Of course there is some criticism about it–usually when compared to Erlang's actor model–, but its success is obvious. There are a lot¹ ² of success stories about people migrating from other languages to Go and they do make sense.

Conclusion

So what will happen with Node.js, since there's a language out there with an arguably better concurrent model?

Well, nothing. Go may be better than Node regarding concurrency, but it doesn't make much difference if you're not building a massive web server. And even if you are, you can always scale out (for which there's a built-in module in Node's standard library). Still on concurrency, one of the most debated issues around Node's model has been solved: callback hell. Since version 7.6, Node supports async/await out of the box, which doesn't require callbacks and still doesn't block I/O.

But what I find most interesting in this whole story and what will keep Node alive and growing is that, maybe, Node didn't become popular just because of its revolutionary concurrency model. In fact, there were other libraries that did non-blocking I/O in other languages at the time, like Twisted for Python and Netty for Java.

What made Node one of the largest platforms for building web applications was precisely its community and ecosystem. The reasons are:

First, the language: JavaScript was already heavily used in front-end web development. Being able to use it in the back-end meant that you could become a full-stack developer using only one language, which lowered the barrier for web development.
Then, the concurrency model. But not only because of its performance; the key was that everybody started building libraries based on this new model, unlike the libraries I mentioned above, which were non-blocking I/O in a threaded land.
Since the ecosystem is an important factor, having a well-designed package manager, NPM, surely helped as well.

And these things will never die ~~until the next hype~~

Thanks for reading!