DEV Community: Tamas Fodor

How to FOMO

Tamas Fodor — Thu, 14 Mar 2019 18:22:11 +0000

Has it ever happened to you when you tried to be as productive as you can to kick the day in the ass, but rather you ended up constantly checking the latest technology news on whatever platform you're stuck into? At the end of the day, you feel like you're worthless, unproductive, anxious and overwhelmed.

The good news is that you're not alone. The bad news? You have nothing to do about it. Well, that is just not true but you definitely can't get rid of it entirely. You can just get better control over it. Ladies and gentlemen, behold FOMO, a.k.a. Fear of Missing Out programmed deep inside our genes, Thanks to our prefrontal cortex or whatever part of the brain that is responsible for bringing this bastard into play.

When you look after FOMO on the Internet, you more likely stumble upon articles about the social aspects. From my perspective, as a developer, it's a little bit different. Just a little bit.

Impostor syndrome

I've been working in the Web development industry for over ten years now. I don't have a computer science degree which is a very important component in my case. I don't know much about you but in my country, it's still a thing to rank people based on what paper they have. I still question my value. I still question whether I have the right to work with those smart people around me, whether I'm good enough to accept the challenge and do my best to solve the problem. When it comes to impostor syndrome, FOMO follows.

So you've just got the opportunity to be the part of a team, full of talented people at a new job, huh? Congratulations, dude! It's your first day and right after the onboarding process, you're looking at the new codebase you're going to work on. Until that point, you might have convinced yourself that you're a decent developer. Your colleagues seemed nice. What could go wrong? And then, all of a sudden something has changed. You're like "Oh my gosh! What the heck is this theoretical physics I'm staring at?". The impostor syndrome is about starting to eat you from the inside. You're suffering from it and you're eventually ended up reconsidering your whole life until that point. This is a very bad feeling and you don't want to feel it again, EVER! So you've decided to take action. The outcome? Endless amount of newsletter subscriptions in your mailbox and the number just goes up every day. You've already ordered 3 bestselling books from Amazon on a particular topic just to feel it more tangible. Constantly seeking articles on the Internet to avoid a tiny bit of a possibility to miss anything you think you should know about. Or even worse, spending tons of money on online courses which are totally irrelevant.

That is just ridiculous! And you have to stop doing it RIGHT NOW!

Stick to the goal

Yeah, I hear you. You've been told by all the gurus and coaches and even by your managers that you have to set your own goals. "What goals are you talking about? My goal is to survive this embarrassing situation and fake it `til I make it." Well, I have to be the bad guy this time. They're right. You can't just go to work and hang around. Completing a task here, completing a task there. No. Life is too short to spend your whole day at your 9-5 job just because they give you money and Netflix doesn't accept sand and mud in return for their services.
There must have been a reason why you chose that job. If the job is to create a single page React application, you don't have to focus on Angular or Vue just because "what if they would fire me tomorrow and my next project will be based on them". If your first task is increasing the test coverage, you should focus on learning about the tools you have to use to write unit tests, learning about testing best practices and so on. If you're a front end developer, you don't have to learn about Kubernetes just because your colleagues talk about it during lunch time and you don't want to look foolish and stay silent. If it's for your own entertainment and you're really interested in the topic with all your honesty, that's ok of course.

Staying at the testing example for a moment, suppose your goal is becoming a pro in all the tools you've been using at work to make sure your React app works. The goal itself is too big, you need a plan and break it down in order to accomplish. Forget all the distracting things around you and stick to the plan. Forget Angular, Vue, and Kubernetes. And believe me, it's time to declutter your mailbox.

It's ok to say, I don't know

The reason why we tend to FOMO at work is the fear of being involved in an embarrassing situation when you're asked about something you think you're supposed to know but you don't. That's only in your head. It doesn't really exist. If it happens to get the chance to have a nice conversation with your colleagues during the lunch break about something you don't know, it's ok to say "I don't know". Say "That's interesting. Tell me more about it." They will be more than happy to tell you more about the topic. It's a great opportunity to touch something on the surface and not to mention the opportunity to take your social life to the next level at your job.

Stop seeking validation

The other reason why we FOMO at work is that we take other's opinion on us too seriously. "What she's gonna think about me if I don't know this?", "What they're gonna think about me if I don't know that". Would you like to know what the truth is? They don't even care. The Universe is not spinning around you.

Just ignore things

When you're about to move forward on the path of your journey and you stumble upon something that grabs your attention, just ask yourself the question, "Does it support me to reach my goals?" Doesn't matter if it's the brand new React newsletter, a youtube notification, a tweet by Dan Abramov. Doesn't matter. If it's a mutual fit between you and your goal then go for it. If it doesn't, just simply ignore. Don't underestimate the power of ignorance. The World won't collapse if you miss the hype around a new React feature or something mainstream in the tech industry. You and your goal are more important and the rest can wait. That is the best what you can do for your self-esteem.

I've been really into Swift development recently so I decided to declutter my mailbox. I unsubscribed from all the newsletters that don't support me on the path of a Swift developer.

At work, it happens very often when people around me start talking about something. I just simply ignore them. If it's important, they'll let me know about it for sure. Otherwise, it's just noise.

And last but certainly not least, you should really consider removing all the distracting items from your phone or disabling the notifications at least. They take advantage of human nature and push all the things you don't need at all.
Don't let the information be pushed towards you. You'll pull it when you need it.

Take care!

Understanding Swift Closures - Part 2

Tamas Fodor — Thu, 14 Mar 2019 12:07:48 +0000

This is the second part of a two-part series on Swift Closures. You can read the previous article here: Understanding Swift Closures - Part 1

In this article, we're going to learn about some interesting Swift features related to functions and more specifically, closures:

Inout parameters
Escaping closures
Autoclosures

Let's get dive into it.

Inout parameters

It's not strictly related to closures but to functions in general. By default, the parameters passed to a function or a closure become constants no matter how you've declared them outside the function. That being said, you cannot modify or so to say, mutate the argument inside the function.

It doesn't matter if it's an integer, string or an array, Swift won't let you change the state of the parameter.

func addItem(_ arr: [Int]) {
    arr.append(2) // Cannot use mutating member on immutable value: 'arr' is a 'let' constant
}

addItem([1])

And there's no difference in case of Structs:

struct MyStruct {
  var n = 0
  mutating func increase() {
    n += 1
  }
}

func increaseStruct(_ obj: MyStruct) {
  obj.increase() // Cannot use mutating member on immutable value: 'obj' is a 'let' constant
}

var myObj = MyStruct()

increaseStruct(myObj)

NOTE: However, at first glance, structs are very similar to classes, you can update the state of a class instance inside a function. That's because classes are reference types, not value types.

Mutating an input parameter is not a good idea in my opinion. Modifying the input inside a function means the function has an effect on the surrounding environment. A function should be a well-focused, small block of code that doesn't know much about what's happening in the outside world. When a function has been permitted to modify other parts of the application, it's called a side effect.

Personally, I prefer pure functions and omit side effects as much as I can. It doesn't just make debugging easier but also easier to write unit tests for pure functions. But that's just me. If you don't agree, Swift allows you to update function parameters, just make sure you use the inout keyword right before the type annotation:

func increase(_ number: inout Int) {
  number += 1
}

When we call the increase function with an integer, Swift wants us to make it crystal clear on both ends that the function is going to change the value. When we declare the function, and when we call it. In case of inout parameters, we have to mark the given argument with the ampersand symbol at the place of the invocation.

var n = 0
increase(&n) // -> 1

NOTE: you can't pass the integer directly to the function and mark it with the ampersand. It's the outer scope's responsibility to register a memory pointer by assigning the value to a variable.

Obviously, if you've declared the argument as a constant, Swift won't let you modify the value regardless of the inout keyword at the function declaration.

let n = 0
func increase(_ number: inout Int) {
    number += 1
}
increase(&n) // Cannot pass immutable value as inout argument: 'n' is a 'let' constant

If you want, you can do the same with closures but you have to be explicit regarding the closure parameters:

var n = 0
let increase = { (number: inout Int) in
    number += 1
}
increase(&n) // -> 1

If you define inout parameters but you don't actually mutate them inside the function, you're a very very bad person. Period.

Escaping closures

If you pass a closure to a function and you don't actually call it, guess what? Swift is smart enough to figure and won't let you. It's like "Hey man! I don't know you but if you think you can mess with me, you better wake up earlier." So at this point, you're about to do something weird. But "why would you pass a closure to a function if you don't want to call it?" Simple. I store it for later execution. In that case, it's an escaping closure and you have to mark it with the @escaping keyword right before the type annotation.

Suppose we have an event manager class by which we can be informed if a certain event happens. In order to do that, we add our listeners and tell the event manager "Hey buddy, please let me know about it by calling this function to me!"

struct Event {
    var name = "Click"
}

class EventManager {

    var listeners = [(Event) -> Void]()

    func addEventListener(_ listener: @escaping (Event) -> Void) {
        listeners.append(listener)
    }

    func trigger() {
        for listener in listeners {
            listener(Event())
        }
    }
}


let em = EventManager()

em.addEventListener() { (e: Event) in
    print("\(e.name) happened.")
}

em.trigger() // Click happened.

In the example above, we have an addEventListener method inside the EventManager class. It takes a closure as the first parameter but it doesn't call it before the method returns. It stores the closure in the listeners property which is an array of closures that take an Event parameter and returns nothing. It's an array because it lets you add multiple listeners if you will. The click event can happen anytime. It can happen immediately, or five minutes later. But when it does, the trigger method is responsible for calling each listener inside the listeners array. In case of scenarios like this, we have to explicitly mark them as @escaping closures.

Autoclosures

For convenience purposes, if you have a simple statement but you want it to be executed later, you can ask Swift to wrap your statement inside a closure. These are the so-called Autoclosures:

func whatever(wrapped: @autoclosure () -> Int) {
    print(wrapped())
}

whatever(wrapped: (1 + 2))

In the example above, since wrapped is marked as @autoclosure, Swift takes the statement, which is adding 1 and 2, put it inside a closure, do the math and returns the result of the evaluation. Autoclosures don't accept any incoming parameters.

Basically, it lets you omit the extra braces when you call whatever. And that's it. To be honest, I don't really see the benefits of autoclosures. Yeah sure, I don't have to write the braces but for me, it makes the code a lot harder to follow.

Am I missing something? If you have any experiences with autoclosures and you see the positive or negative parts I might have missed, let me know in the comments section.

Understanding Swift Closures - Part 1

Tamas Fodor — Mon, 04 Mar 2019 20:26:27 +0000

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
― Martin Fowler

As I'm a committed participant of the 100DaysOfSwift challenge by Paul Hudson, it was inevitable to meet closures at some point. Even though I have a solid understanding of what closures (or lambdas) are from other languages and why they're useful, I realized that closures are one of the main reasons why I'm struggling with reading others' Swift code.

After day 7, I didn't want to just simply let it go so I decided to dig deeper. The reason why I'm writing about it is that I'd like to collect my findings and solidify the knowledge I've got during the journey. Hopefully, you will find it beneficial and take the value that is relevant to you.

Alright, let's get started.

What are closures?

According to the official documentation, "Closures are self-contained blocks of functionality that can be passed around and used in your code". The same applies to functions so I'm not far if I'm saying they're functions basically but you can write and use them in a few different ways compared to normal functions in the hope of better code quality.

First-class objects

In programming, the term "First-class" means that you can assign these so-called first-class objects to variables, pass them as function parameters and return them as the result of function execution. This is not different from functions in Swift.
Before you think you have to use the closure syntax in order to assign a function to a variable or pass it as a function parameter, I have to point it out that it's just not true. It's completely up to you which one you choose, normal functions or closures. In my opinion, one is not better than the other and it depends on what works the best for you. If it's easier for you to understand your code by using normal functions then go for it. But it's needless to say that having a decent knowledge around closures is very important, especially if you're not the only developer who's working on a project or you're about to go through a hiring process at your dream company.

The function type annotation

"So I can juggle with functions as I do with Strings, Integers or other types. So far so good, but why would I do that?" Before jumping into the practical parts, let's see how you would write normal functions and closures in Swift.

Since Swift is a strongly typed language, you have to add type annotations at some certain degree to your variables. Fortunately, Swift is smart enough to figure the type of a variable by simply the value you've assigned to it. This is the so-called Type Inference. But let's just be super explicit for now and optimize it later.

In the following example, there's a normal function called countLetters which accepts a String and returns an Integer.

func countLetters(word: String) -> Int {
    return word.count
}

let stillCountLetters: (String) -> Int = countLetters

The function countLetters is assigned to a new variable stillCountLetters. As we agreed, let's be explicit and set the type of stillCountLetters which is (String) -> Int. It means "Hey, I can store a pointer to a function that accepts a String (String) and returns an Integer -> Int". If the arity of a function is zero, which means it doesn't accept anything, you can write an opening and a closing parenthesis and nothing between the two (). If your function returns nothing, you can use the Void type after ->.

So in short, when a function accepts nothing and returns nothing, the type of this function looks this:

let myFunc: () -> Void

At the place of the function declaration, you can omit the type of the return value only if your function returns nothing. That's going to be an implicit Void:

func printMessage(message: String) {
    print(message)
}

instead of Void, you can also use parentheses but for me, that's just too many of them and at the first glance, it confuses me with Tuples which doesn't make sense of course but still:

let myFunc: () -> ()

func myFunc2() -> () {
}

The closure syntax

Alright, in the previous section, we created a normal function and assigned it to a variable. It's time to see how we can write closures.

let countLetters: (String) -> Int = { (word: String) -> Int in
    return word.count
}

As you can see, the type is the same as it is for normal functions. Everything inside the curly brackets is the functionality belonging to the closure. Before the in keyword, you can find the incoming values (word: String) and the type of the return value -> Int. Everything after in is what your function does. What you would normally put between the brackets in case of a normal function.

Why closures?

At this point, you might be like "Ok, this is the closure syntax, fine! It's a little bit different from a normal function. Why do you want to confuse me, Apple?". Yeah, I hear you. It's like the "tabs versus spaces" war, isn't it?
Well, it's not that simple and there are obvious reasons why Apple has introduced closures in Swift.

The main reason behind the idea of closures is convenience. It provides a convenient way to work with functions. It's kind of like following the "Write less, do more" principle. At the beginning when your codebase consists of just a few lines of code it doesn't seem to make any difference. But later on when you're about to scale your application, you add some new features, bugs start to show up and you eventually end up maintaining a huge monster that is not so easy to debug anymore. Not to mention if you have to work with other developers on the project or even worse, you've inherited a big legacy codebase.

When it comes to creating and maintaining a scalable and testable application which is easy to reason about, it's very common lately to follow the Functional Programming Paradigm in order to write code that meets the aforementioned requirements. Long story short, if FP is your thing and you heavily rely on functions, Swift provides a kind of like a more user-friendly way to deal with them. Period.

In the following sections, I'll go through the cases when closures might come in handy in the future in general or if you decide to get on the Functional Programming bandwagon.

Omitting labels

One of my favorite things is that it's not required to use labels when you invoke a closure with parameters. Moreover, it doesn't even allow you to use them at all. The following code will fail at compile time:

let countLetters = { (word: String) -> Int in 
    return word.count
}

countLetters(word: "Raptors") // error: extraneous argument label 'word:' in call ...

You cannot override the labels for external usage either:

let countLetters = { (of word: String) -> Int in 
    return word.count
}

countLetters(of: "Raptors") // error: closure cannot have keyword arguments

Don't get me wrong. I see and understand the benefits of labels and after reading a few articles by Robert Martin, I'd probably feel like I want to use them everywhere. But I'm not yet used to labels and I always tend to forget writing them when I call functions and they're not optional.

Write less, do more

This section describes a few features available in Swift that help you write shorter code for the sake of readability but it can be dangerous too if you use them inappropriately.

Creating closures in place

As I said earlier, functions are first-class citizens which means you can pass them as function parameters among others. And it's affordable with both normal functions and closures. Suppose you have a function to add two numbers and another function called combine that takes a function with which you can combine that two numbers in a certain way. For now, don't try to understand what the point is of passing functions to other functions. I'll describe it later.

func add(a: Int, b: Int) -> Int {
    return a + b
}

func combine(a: Int, b: Int, by function: (Int, Int) -> Int) -> Int {
    return function(a, b)
}

let result = combine(a: 2, b: 3, by: add)

print(result) // 5

It's totally fine to do this. We're extremely explicit here but it's still valid Swift.

With closures, you can shorten the code above a bit:

func combine(a: Int, b: Int, by function: (Int, Int) -> Int) -> Int {
    return function(a, b);
}

let result = combine(a: 2, b: 3, by: { (a: Int, b: Int) -> Int in 
    return a + b
})

print(result) // 5

You cannot create normal functions at the place of the invocation. By using closures in our example, we could save 3 lines of code. It's not much but imagine a bigger module with hundreds of lines of code. By specifying how our combine function should do the math, we improve readability so the developer doesn't have to jump to another place in the codebase to see what add does when she's investigating our code. By doing this we can avoid "Change blindness":

Change blindness is a perceptual phenomenon that occurs when a change in a visual stimulus is introduced and the observer does not notice it. For example, observers often fail to notice major differences introduced into an image while it flickers off and on again. People's poor ability to detect changes has been argued to reflect fundamental limitations of human attention.

from Wikipedia

And we can keep staying in the flow state:

In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity.

from Wikipedia

The power of Type Inference

As I referred to it previously, If you write your code consistently, Swift is smart enough to figure the types automagically due to Type Inference. Having this in mind, we can do further enhancements.

Since it's stated already in the combine function that the return type of the function parameter must be an Integer, we can omit the type of the return value of the closure when we pass it:

let result = combine(a: 2, b: 3, by: { (a: Int, b: Int) in 
    return a + b
})

The same applies to arguments:

let result = combine(a: 2, b: 3, by: { (a, b) in 
    return a + b
})

If you really want, the code is short enough to write it in one line. But personally, I prefer spreading vertically rather than horizontally:

let result = combine(a: 2, b: 3, by: { (a, b) in return a + b })

Implicit returns

However we could reduce the size of our code to 1 line and 64 characters long (The recommended maximum length is 80 before putting the next line), it's still not the best in terms of readability. We can go further by taking advantage of implicit returns inside closures. If the body of your closure contains only one statement and you want to return the result of it, you can omit the return keyword.

let result = combine(a: 2, b: 3, by: { (a, b) in a + b })

Shorthand arguments

Swift does even let you omit the arguments and use the shorthand version of them. The shorthand syntax is pointing to an item by using its index in the argument list starting from zero. You must prefix the index with a dollar sign. So in our case, the shorthand version of a and b is $0 and $1. By using shorthand arguments you can also omit the in keyword:

let result = combine(a: 2, b: 3, by: { $0 + $1 })

Alright, I think the time has come to point it out that however, it's a very fancy way of solving the problem, it really hurts readability. If we're just experimenting or just hacking something, it's fine. To be fair, even if I'm a less experienced Swift developer, I can presume that this closure adds two numbers. But don't forget that we can concatenate two strings together with the + operator. It's not necessarily clear at first glance what the types are of the two parameters. If XCode is your preferred editor to write Swift, tooltips can come in handy to figure it out. When it comes to making a decision whether you should use shorthand arguments, especially if it's a very complex functionality, think twice, think of your co-workers and your future self.

Operator methods

Still not enough?! Ah, you're killing me! Alright! If there's only one statement inside your closure and it's a basic arithmetic operation or comparing a value to another, it's enough to only write the operator and Swift does the rest for you:

let result = combine(a: 2, b: 3, by: +)

BONUS:

Did you know that you don't even have to write anything at all??? Swift can read your mind, so the following code does work like a charm:

let result = combine(a: 2, b: 3, by:)

Just kidding. It doesn't. Sorry for my awkward sense of humor. :(

Trailing closures

Hurray, we've finally arrived at the practical parts. So why would you use closures? Well, that's a very good question but better to ask yourself why would you use Functional Programming. Even if you're not even aware of that, probably you do FP pretty often if you're a full-time Swift developer.

Suppose we have the following view. When the view appears on the screen, it shows a popup window with a greeting. Let's take a closer look inside the viewDidAppear function where the popup window is created and told to be displayed. It creates an alert view and an action, adds the action to the alert and then opens the popup.

import UIKit

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
    }

    func alertActionHandler(_ action: UIAlertAction) {
        print("Great!")
    }

    func alertCompletionHandler() {
        print("Completion feels good.");
    }

    override func viewDidAppear(_ animated: Bool) {

        let alert = UIAlertController(title: "Greeting", message: "Hello, World!", preferredStyle: .alert)
        let action = UIAlertAction(title: "OK", style: .default, handler: alertActionHandler)

        alert.addAction(action)

        self.present(alert, animated: true, completion: alertCompletionHandler)
    }
}

The third argument of the UIAlertAction class accepts a closure called handler. It's like "Alright, action! I'm giving you this function. Would you please so kind, and call it for me when the user hits the action button?".
I'm 100% sure, you've already met these kinds of things and yes, it's Functional Programming. When you pass a function to another function and wait until a certain event happens (User clicks on the OK button in our case), this is the so-called callback design pattern in other languages like NodeJS. It may have a different name in Swift but the concept is the same. It's pretty powerful if you don't want your application to stop until the click event.

As I said earlier, using closures is optional. It's just a convenient way to work with callbacks. If you don't like the idea, you can stay with normal functions. In the example above, I declared the alertActionHandler callback as a member of the ViewController class and passed it to UIAlertAction. Just a quick side note, you can also declare the function inside viewDidAppear method as a nested function. It's pretty powerful if you want to reach variables from the parent context but more on this later.

This is a very good example to demonstrate the power of closures, more precisely the trailing closures. Let's refactor this code and see how it feels like after replacing the class methods with closures. Let's just not use a trailing closure fist.

import UIKit

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
    }

    func alertCompletionHandler() {
        print("Completion feels good.");
    }

    override func viewDidAppear(_ animated: Bool) {

        let alert = UIAlertController(title: "Greeting", message: "Hello, World!", preferredStyle: .alert)
        let action = UIAlertAction(title: "OK", style: .default, handler: { _ in
            print("Great!")
        })

        alert.addAction(action)

        self.present(alert, animated: true, completion: alertCompletionHandler)
    }
}

In my opinion, this is much better because it doesn't grab the user out from the flow since we've declared the callback in place so she doesn't have to scroll up to the class method. The promise of the trailing closure syntax is easier readability so let's see how it looks like. To help you focus on the relevant parts, I've removed the rest of the code:

    let action = UIAlertAction(title: "OK", style: .default) { _ in
        print("Great!")
    }

Here's the thing. If and only if the last parameter of a given function is a closure, you're allowed to use the trailing closure syntax. As you can see, by using it, you can omit the label.
I let you decide if it's easier to read compared to the previous example. If you prefer being more explicit and using labels, it's completely up to you.

You might have noticed that there was another place in the code where I applied the callback pattern. The class's present method accepts a closure as the last parameter so we can take advantage of the trailing closure syntax again to make the code a bit shorter.

import UIKit

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
    }

    override func viewDidAppear(_ animated: Bool) {

        let alert = UIAlertController(title: "Greeting", message: "Hello, World!", preferredStyle: .alert)
        let action = UIAlertAction(title: "OK", style: .default) { _ in
            print("Great!")
        }

        alert.addAction(action)

        self.present(alert, animated: true) {
            print("Completion feels good.");
        }
    }
}

Capturing values

You can also return a function from other functions. Remember? When you declare a function inside of another, it's a nested function. It can be very powerful if you want to store some state in the parent context (which is the function in which the nested function was created) based on certain inputs. The nested function has access to the variables in the parent context. When you call the function that returns a function, it's like "Ok I did what you wanted me to do, here's a function if you want to go further and do other stuff later (based on the stored state)."

In the following code, there's an addUser function with which you can add a user to the database:

var users = Set<String>()

func addUser(_ user: String) -> () -> Void {

    users.insert(user)

    func removeUser() {
        users.remove(user)
    }

    return removeUser
}

let removeJohn = addUser("John")

print(users) // ["John"]

removeJohn()

print(users) // []

It's a bit silly example but straightforward enough to get the idea. addUser is responsible for adding the given user name to the users Set. It also returns a function with which you can remove the user you just added previously. You don't need to remember how the addUser does its job. It doesn't matter what Collection type it uses behind the scene. If you want to add John, just call the function with the input "John", store the returned remove function which belongs to a parent context where John has been stored as a new user.

We can say that addUser is a nested function inside the global context. So even though I declared the users Set outside from the function, it can "capture" that variable.

Let's see how it looks like with closures:

var users = Set<String>()

func addUser(_ user: String) -> () -> Void {

    users.insert(user)

    return {
        users.remove(user)
    }
}

let removeJohn = addUser("John")

print(users)

removeJohn()

print(users)

Alright, that's all for now. I hope you have a better understanding of closures and find them useful. If not, that's fine too. At the end of the day, what matters is whether or not your App works. Next time I'm going to show you other dirty secrets of closures in Swift. If I missed something important or I was wrong, let me know in the comments section.

Take care!

Atomic habits: Book review and cheat sheet

Tamas Fodor — Mon, 25 Feb 2019 19:15:32 +0000

If you read my previous post about mini habits, you know that I'm a firm believer in the benefits of habit development.

One of my goals for this year is reading two books every month. So I developed a few mini habits to manage this task. If you're interested in the books I've read already this year, you can find the list here. I haven't decided on all the 24 books I'm planning to read so it's a constantly growing list. When I finish a book, I put it on the list.

In the previous post, I gave a brief overview of why mini habits can change our lives significantly and now I want to take it to the next level. Well, it has turned out that there's an entire book on the topic out there.
Ladies and gentlemen! Behold Atomic habits by James Clear, a number one bestselling book on Amazon about how tiny changes can have a huge effect on our every day lives especially if we'd like to achieve success.

Dare I say, it's a great book and a must have on your bookshelf. Especially if you need a step by step guide to change your behaviors in order to build good habits and get rid of bad ones. The book also includes many scientific facts and stories from great habit builders in history which I've found very entertaining. The book touches many different scientific aspects including biology, neuroscience, and psychology. It's like Christmas for me.

As Dan Lok, the famous entrepreneur and businessman once said, "Don't read books, use them!". Yes, reading is a very important part of this concept but you get the idea. So this time I've decided to provide a more useful post rather than a motivational speech. This article is about my thoughts on the book and also provides a cheat sheet and examples from my everyday life to make it easier for you to practice the ideas.

The 4 laws of behavior change

The book is built around the four stages of the habit building process that you should follow. The author refers to it as the Four Laws of Behavior Change:

Make it obvious
Make it attractive
Make it easy
Make it satisfying

Inversion

Speaking of good habits, you might be satisfied with your life. Maybe, you just have some bad habits you want to get rid of like smoking or desperately checking social media to compare yourself to others. The inversion of the four laws comes to the rescue.

Make it invisible
Make it unattractive
Make it difficult
Make it unsatisfying.

I really liked the idea of taking advantage of human nature and instead of focusing on putting a huge amount of energy to become a new next-level superhuman and get rid of what we are in our genes, make it serve us. Human nature comes with a lot of things that stop us from breaking bad habits. Our brain wants instant gratification and doesn't accept the delayed reward. The book lists many good techniques to turn these obstacles to our advantage.

Identity

According to the book, the first step is coming up with the idea of the person who we want to become. When we’re aware of the identity of this person, it’s much easier to collect the habits which support us on the path of becoming that particular person. Otherwise, we're just hanging around probably. Just write them down on a paper or somewhere else. It’s easier to feel like you're committed.

Here’s my list:

I’m a writer
I’m a conference speaker
I’m a teacher
I’m a swift developer
I’m a minimalist

Habits scorecard

The idea of the habits scorecard is about collecting your current habits. The habits you do on a regular basis without failing. It’s very important to keep in mind that it’s a list of all of your habits, not just the good ones. It’s ok if you have some bad habits. Let's just accept it for now.
Once you are done with the list, you should mark each habit based on whether it helps you to build your new identity, prevents you or just simply neutral. The book uses "+" for supportive habits, "-" for unsupportive habits and "=" for neutral habits. If you’re anything like me, you would make it look dope with emojis.

✅ - supportive
❌ - unsupportive
🐒 - neutral

Let me share my list with you. These are my daily habits. The habits I do every day.

My daily morning routine:

Wake up 🐒
Check emails and social media ❌
Check my todos ✅
Make my bed ✅
Go to the kitchen 🐒
Drink a big cup of tap water ✅
Drink a cup of coffee ❌
Go to the bathroom 🐒
Turn on music ❌
Brush my teeth ✅
Wash my face ✅
Get dressed 🐒
Clean the surfaces from water and dust ✅
Leave the bathroom 🐒
Go to the living room 🐒
Learn Swift for an hour ✅
Take on my shoes 🐒
Take on my jacket 🐒
Go to the gym ✅

Work (when I arrive):

Make a cup of coffee ❌
Have a breakfast ❌
Tweet about my Swift learning progress ✅
Watch a maximum 10-minute motivational video ✅
Check work-related emails 🐒
Check my sprint progress in a PM tool ✅
Check social media ❌

My daily evening routine:

Go to the bathroom 🐒
Turn on music ❌
Have a shower ✅
Wash my face ✅
Brush my teeth ✅
Put on deodorant ✅
Take on my pajamas 🐒
Leave the bathroom 🐒
Pack my gym bag ✅
Go to bed 🐒
Check social media ❌
Read a chapter ✅

Implementation Intention

Based on several studies, we more likely stick with a habit if we attach it to a certain time and location. This is the so-called implementation intention. There’re a lot of other components of successfully sticking with a habit of course and it may not be the best for you. I know from experience that it’s very difficult to be on schedule if it’s not clarified. Use the formula and write it down.

The formula is the following:

I will [BEHAVIOR] at [TIME] in [LOCATION]

Here’s my list:

I will exercise for one hour at 6 a.m. in the gym
I will learn Swift for one hour every day at 8 a.m. at my desk
I will write an article every Sunday at 6 a.m. at my desk

Habit stacking

Another great way to form a new habit is by connecting it to an already existing one. If implementation intention is not your thing, this might work for you. You can also use the two together of course.
Since we already have a list of our habits, we can easily find a good place for a new one. It’s better to connect the new habit to a good habit obviously because you probably want to get rid of the bad ones. It’s just a matter of time.

Formula:

After [CURRENT HABIT], I will [NEW HABIT]

Environment

It happens very often that where we live or work prevents us from forming habits. It's not about the place but rather how we organize the things around us. Make your room your friend instead of your enemy. If you want to read every day, put a book on your pillow every morning. If you want to play on the guitar, put it in the middle of your living room, and so on.

I think I’m mostly fine with this part but there are always rooms to improve. For example, I work on my sleep quality and I don’t have a television in my bedroom but I read books on my phone before sleep time. I use the Twilight app to filter the blue light but it’s not just about that. I tend to check social media between chapters. I have a Kindle but I don’t have a reading lamp near my bed so I think it’s time to buy one. :)

The Two-minute rule

It's about procrastination. As I pointed it out earlier many times and basically this is the whole idea behind atomic habits, we tend to give up because the expectations are too high. Go small! At first, create habits that require only two minutes to get them done.

If it's easier for you to use some tools to figure your own plans, you can find many resources and templates on the official website of the book.

The Habits Cheat Sheet
Habits Scorecard Template
Implementation Intentions Template
Habit Stacking Template
Habit Tracker template
Habit Contract template and example

I highly recommend you to get this book. For me, it was worth every penny and I'm 100 % sure that I'll read it again to get some motivation on those sad rainy days when I feel stuck.

Remember! Don't just read it. Use it!

The power of mini habits

Tamas Fodor — Sun, 17 Feb 2019 17:23:35 +0000

Hi! I'm Tamas. 32 years old web developer located in Budapest, Hungary. Let me have the chance to use this channel and introduce myself to the dev community.
I'm a procrastinator. A very kind way of calling myself a loser. And definitely not a finisher. You may find it inappropriate or offensive. But that's a fact and here I'm to confess.

Why am I calling myself a loser?

I have dreams to pursue. We all do. And when it comes to pursuing our dreams we all have excuses to convince ourselves why it's ok not taking an action to get closer, why it's ok to do it next day instead of immediately. "I don't have time." "I have a family to take care of". "I have a full-time job, I'm very tired." You know all the forms of these bastards I'm sure.
I don't know you but if you're fine with that, that's ok. But I'm sick and tired of it. So I've eventually decided to take the next step to accomplish my goals.

I've always wanted to write. To spread my ideas with the World. I've been planning to finally start it for years. Many years, almost a decade. Geez!
But why is that? If this is one of my biggest dreams, why is it so hard to do? If I want to do that, it must be easy, joyful and super cool, right?
Well, it's not that easy and that's ok.
"You're a coder. You're just not good enough at writing" I told myself. Actually, I was pretty good at writing in my student years according to the grades I got from my teachers. so nice try, Tamas, but it wouldn't work this time. "Alright, but I'd like to write in English to target a bigger audience and English is not my primary language". Hmm, getting better.

See? I'm the ultimate master of finding a good excuse to not do anything to reach my goals.

It must be the willpower I thought. Well, yes and no. It's a more complex problem including many components. Partially it's the willpower, yes. But it's a huge topic. And in order to deal with big issues effectively, we have to split it down to smaller chunks, right?
Before diving deep into this, let me talk about how I get here and realize the source of all evil.

I've always been a book guy and as many of us who want to become a better person, I've read a shit load of books on self-discipline, forming good habits and such things. To be honest, at first, I desperately tried to find a secret formula, a secret mantra or pill with which I could immediately get where I wanted to be. Yeah, right. Guess what? There weren't any but I didn't give up reading and many books later I finally got to a certain point where everything started to become clearer and made more sense.

I'm not a big fan of new year's resolutions because I think it's a huge lie and just another excuse to procrastinate.
"Alright, This is the last chocolate cake and it's over. From January, I won't eat any of this shit I swear. My grandma put a lot of effort to bake it to me anyways." Familiar? But for some reasons, it gives people a huge amount of motivation to achieve something great if they can attach the starting point to a certain event. To start it at least. Doing it consistently? Well, that's another question we all know it. It was the same with me of course but it happened to finally press the red button a few days later after New year's eve. So basically I took an action immediately right?

The power of habits

I'm sorry for the emotional start but now let's start talking about the solutions. So as a good first step I googled for the best possible books on willpower out there. I found a few promising books but also, a lot of books about habits came along the way. I remembered that I had heard about the positive effects of building good habits but I had never really dived deep into the topic. "The seven habits of highly successful people". "You have to wake up 4 am every single day, or even better 3 or 2 am" and stuff like that. I stopped being sarcastic immediately, kept focusing and pick a book.

The first book of my choice was Habit stacking by S. J. Scott. It's not the most popular book on habits but after reading it I realized that it borrowed lots of great ideas from other books like the famous Power of habits by Charles Duhigg and many others. So essentially it was a good start to warm up.

In my opinion, it's a really good book and had a huge effect on me. It tells you the basics of habit building and also comes with a huge list of habits to start with in case you're not that creative to come up with your own.

And at this point, I'd like to grab the chance to highlight the most powerful idea included by the book. Mini habits. It was the one that gave me the fuel to take the necessary actions immediately because this fundamental made everything so easy and straightforward.

As a programmer, I like keeping things super simple so I needed something to make it easier because it's obvious that building good habits makes you a better person. But it's very hard to build them. This is how our brain works. It's very difficult to be consistent and follow our new routines every single day until it really becomes our own and we do it without being aware of it. And if you're like me, you want to grab the best habits all at once to take it to the next level immediately right? Well... Not so fast.

Mini habits

It won't work so you better forget it. But that is exactly the point of mini habits. To make it super simple. I love them! Suppose we have a big goal like losing weight, learning a new language or writing blog posts on a regular basis. These are the goals. In order to reach them, we have to build habits to move forward because it's impossible to accomplish them all of a sudden.
But we tend to go big, especially when we're full of motivation at the early stage of our journey. Let's settle at the losing weight analogy. However, writing is my biggest goals for the year, I wanted to start with something easier. I love sports but I tend to do it inappropriately so I decided to practice habit stacking connected to working out.

So we go to the gym every single day of the week and do exercises for hours. We got all the good advice about weight lifting, cardio, and stretching. We want to do them all at once. What could go wrong? The bigger the effort and the more the work we do, the sooner we get there, right?
This is the main reason why we give up after a few weeks or a month. The expectations are so big, we feel overwhelmed and lose all the motivation. Eventually, we stop doing the hard work no matter how much effort we put in.

Stop focusing on the results. Focus on the process which is habit building. Who told us we had to train like Arnold Schwarzenegger. We can of course but it's stupid to start like that. Want to get that beach body? Alright! Let's add those mini habits. Here's mine.

I decided to go to the gym in the morning. Dare I say it's more difficult. So I told myself. Ok, Tamas. Just wake up! Go to the bathroom. Wash your teeth! Wash your face! Take your clothes on! Grab your bag and get out of the house. I have to mention another mini support habit here I've found super useful. Usually, I pack my bag the night before so I don't have to mess with that in the morning.
So the first day I went to the gym. Ran 10 for minutes on the treadmill. Did a few pushups and got familiar with the machines and the tools. Especially with those tools, I use for leg exercises because I had planned a leg day for the next time. And that is all! The next day I did exactly the same. Went to the gym, ran 10 minutes on the treadmill and did a few squats.
See? It's that simple. The point wasn't training like a spartan warrior. The point was taking my ass to the gym and start "something" at 8 am on a consistent basis.
It was very difficult at the beginning but it was getting easier and easier every day. Next week, I started to change the habits a little bit. I woke up a bit earlier and increase the number of exercises after the 10-minute treadmill.
The result? Priceless. It's not necessary to mention but I got to the point when it was super easy and I could not even imagine my mornings without the training. It's even better when you start to see the results. Now I do this morning routine in autopilot mode. When I have to skip, it hurts.

The same with writing. I don't have to write a book with 200,000 words in one day. First, just decide what you want to write about. Give it a title. Pick a day and write your thoughts down. Don't give up half-way! Finish it. Once it's done, it's great. Do the same a week later. Try to write a blog post every week. Just one! It's going to be easier. You're going to be better at writing. When you get bored and it's not a challenge anymore, increase the number of posts and write two each week instead of one.

I'm hoping you got the point of mini habits. Take these tiny steel lego blocks and start putting together your routines. Remember! Take it easy and once it's super-solid, add more or take the existing ones to the next level. Use them mindfully and be consistent! These are the foundation of your future greatness.

Happy habit stacking!