DEV Community: Gio Lodi

Don't check your inbox. Process it!

Gio Lodi — Wed, 02 Aug 2023 20:22:36 +0000

Do you ever find yourself filling moments of boredom by checking your inbox?

Maybe you're waiting for a build to compile, and you go check Slack.
Or perhaps your manager is late for the one-on-one meeting, and you scroll through emails in the meantime?

Harmless on the surface, a quick inbox check is dangerous both in the moment and in the long run.

The quick check trap

One problem with inboxes is that you never know what you might find in there.
The more people have access to you, the higher the chance you'll find messages requiring your attention in there.

Especially in big organizations, your inbox will often contain a question from a colleague, a comment that rubs you the wrong way, or a link to an article that will capture your attention.
Whatever you find on your "quick check" will force you to context switch.

Context switching is the number one enemy of cognitive efficiency.
Our brains cannot seamlessly switch between tasks.
There's a cost to pay every time.

UNI professor Gloria Mark has spent her career studying people's attention in the workplace.
Here's what she writes in her book Attention Span:

When people switch attention between different tasks [...] they need to reconfigure their internal representation of one task to the internal representation of the next task."

Reconfiguring one's internal representation is a gradual process that takes time to complete.
The contents of the previous center of our attention remain in the periphery afterward, reducing the available mental bandwidth.

Again from Gloria Mark:

Rapid attention-shifting has repercussions on our ability to process information.
What one looked at previously can interfere with what one is currently looking at.

Interruptions and context-switching decrease the quality of our focus and, in turn, compromise the quality of our results.

If you want to protect your ability to perform, you must be careful in how you interact with your inboxes.
Stop checking. Process them instead.

From checking to processing

Processing an inbox means working through each new item and deciding what to do with it.
Should it be addressed immediately, or can it be scheduled?
Can you delegate it?
Is it something you might need in the future?
Do you need to update your daily plan because of the new information the item carries?

Notice how this approach is intentional and focused.
It requires shifting gears into planning mode and big-picture thinking.
This kind of interaction with your inbox can only be achieved if you give it your full attention, not while you are already deep into something else.

Treat looking at your inboxes like a standalone task, not a time-filler.

From reactive to proactive

Checking your inbox while waiting for something is a reaction to boredom.

Our brains crave novelty.
When faced with a hint of boredom, they'll try to find something else to do.
With a computer or phone at hand, a brain that fears being bored has plenty of opportunities to distract itself.

There are times when being reactive is essential.
If there's a fire to put out, be that login infrastructure suddenly offline or a literal fire in the building, you better be responsive.

But if you react to every input, you'll never make progress on what truly matters to you.
Whether it's your brain's need for entertainment or the stream of messages in your work chat, you should not let others dictate where you direct your attention.

Processing your inboxes is a proactive approach.
You still need to deal with whatever you'll find in there, but you give yourself the opportunity to do it strategically.

Look at your inbox as a whole, and you'll identify the most important items to tackle—the ones that move the needle.
When you continuously check your inbox, your day risks becoming a jumble of unfinished work, with each new entry setting you off in a different direction.

Open your inbox only when you have the time and mental bandwidth to address whatever you'll find in it, either by tackling it or by organizing it into your trusted system.

Don't check.
Process.

Originally published on giolodi.com

Cover credits Rinck Content Studio, with edits mine.

Subscribe here to receive new posts right in your inbox and access exclusive content.

What does it mean to be a productive software developer?

Gio Lodi — Fri, 08 Jul 2022 21:03:22 +0000

This is a re-blog from giolodi.com. Checkout the original for more links and posts.

Productivity is often thought of as "getting things done."
This definition is intuitive to grasp and makes it easy to measure productivity.
But in the context of software development, and knowledge work at large, "getting things done" is a hopelessly short-sighted way to define productivity.

A machine cranking widgets is as productive as the number of widgets it cranks.
The widgets are all the same, so the more the machine can crank in a given time, the more productive it is.
However, the tasks on a software developer's plate are not all equal.
Someone could spend a whole day relentlessly ticking off tasks on their to-do list, but if those tasks are useless, the day will not have a productive one.

Productive software developers don't merely get things done. They get impactful things done.

Productivity is tied to impact.
It is a measure of results, not raw output.
So, stop counting how many tickets you moved into the done column of your Jira board.

Impactful work is work that generates positive change in the business.
Yes, the business.
As important as self-determination is, as crucial as it is to exert mastery and to find work that is inherently satisfying, we need to come to terms with the fact that productivity in the workplace depends on the effect we have on the bottom line.

If software development is your hobby, then a productive session might just be one where you have fun, even if all you do is tinker with your .vimrc.
But if software development is your job, then you need to ask yourself whether you produced something valuable, and, as Derek Sivers put it, "money is a neutral indicator of value."

Using impact as a lens to understand productivity, it becomes clear that cleaning up your inbox is not as productive as reviewing a colleague's pull request to unblock them.
Likewise, fixing a bug that trims the last word in the last cell of your settings screen is not as important as fixing a bug that prevents users from signing up to your service.

Impact, value delivered, is the true measure of a software developer's productivity.
But impact doesn't exist in isolation.
There is another crucial dimension of productivity, one that is too often left out of the conversation: time horizon.

Some activities might not seem productive in the context of a particular day, but do contribute to mid-to-long term productivity.

Resting is the perfect example of how factoring in the time horizon changes the definition of productive activity.
If you limit your view to impact over a given day, then the more work you can fit into it, the better.
However, as anyone who went through burnout will tell you, overworking is not sustainable.
Unless there's a fire to put out, there's no point "killing it" today if the result is you'll be out of commission for the rest of the week.
An ongoing incident that is losing you money and customers grants burning the midnight oil, all the rest can wait till tomorrow.
(If you are in your twenties and think this example doesn't make any sense, trust this 33-year-old grump—Wait until you cross the 30-threshold, then you'll know what I'm talking about.)
Getting plenty of rest in your day is productive because it ensures you can keep working without catastrophic burnout.

Other activities that are productive in the long run include: reading to learn something new, paying off technical debt, and taking a few minutes at the end of the day to reflect on what went well and what you could have done better.

Once you move beyond the myopic measure of raw output, productivity becomes too nuanced to fit a scorecard.
Productivity is a function of impact over a medium-to-long time horizon, but that is hard to quantify without hindsight.

To be a productive developer, the best you can do is to choose tasks to work on by factoring in business objectives, time horizon, and opportunity cost.

If that sounds hard, it's because it is.
And ambiguous, too.

You won't get it right all the time, but that's not the point.
What matters is being intentional, thinking impact over the long-term, and error-correcting as you go.

This was a re-blog from giolodi.com. Checkout the original for more links and posts.

Enjoyed this post? Get new ones in your inbox 👉📬

Cover image is a remix of the author of this picture by Amr Taha.

Why Teamwork Is In Your Best Self-Interest

Gio Lodi — Mon, 04 Jul 2022 18:39:31 +0000

This is a re-blog from giolodi.com. Checkout the original for more links and posts.

Knowledge work depends on teamwork. It sounds like a cliché, but it's objectively true that working with others s how we achieve better results than we could by ourselves. Our species transformed an inhospitable planet into a home where to thrive through various forms of collaboration and teamwork.

Not everybody likes teamwork. Some people are introverts to the core and might struggle to make their voices heard. Others just want to show up, do their job, and go home, no question asked. You sometimes have a vision for how a project should evolve, but you can't execute it because the people around you "just don't get it." There are also folks that have yet to develop the emotional intelligence required to operate with others.

Regardless of how you feel about teamwork, I want to make a case for you to prioritize it. Teamwork is an essential part of "your work," not something to attend to once you ticked all the other tasks on your to-do list.

Let's get specific. When I refer to teamwork in the context of software development, I'm thinking of all those activities that make other people move forward:

Code reviews
Commenting on RFCs
Brainstorming and planning meetings
Pair programming session to work through gnarly code
Reading your teammates status updates, in case there's something you can do to help

On the face of it, none of those activities help you with your work. If you spend a day doing only those, you might appear behind. But that's a terribly short-sighted view of the matter. Because while it's true that your PR might still be in draft mode, everyone you helped made some progress. The whole team moved forward, likely more than if you had only worked on your task.

One could object that if they always start by helping others, they'll never get to do their work. That's rarely the case because once you unblock someone, they won't immediately have new work for you to review. If you do really find yourself overwhelmed by teamwork tasks, you could adopt a prioritized rationed system: Work on the most important unblocking request, then on your most important task, then on the second most important unblocking request, and so on.

Prioritizing teamwork activities might appear self-less, but you have much to gain from it yourself. Brownie points for a start. If you consistently help people, they'll be more likely to help you. On top of that, unblocking others will likely make your own job easier—assuming the work your team took on board is such that everyone operates towards a common goal, which is a topic for another day.

Here's one more point that will convince even the most self-serving people: From the outside, a top performer in a poor-performing team looks like a poor performer or an average performer at best. In a top-performing team, everyone looks like a top-performer.

If you want a raise, make your team better.

Photo credits Bruno Emmanuelle.

This was a re-blog from giolodi.com. Checkout the original for more links and posts.

Three Tips To Get Started With Deep Work

Gio Lodi — Wed, 20 Apr 2022 10:46:42 +0000

This is a re-blog from giolodi.com. Checkout the original for more links and posts.

So you decided to try out this deep work thing that everyone is talking about.
You added a "Deep Work 🎧" event to your calendar from 10am to 12pm.
Your caffeinated beverage of choice is at hand, your desk is clear, and there's a snack in the drawer, just in case.

Now what?

I have three tips for you, but let's get on the same page on what deep work is first.

Deep work is focused, uninterrupted, single-tasked, specialized work.

Cal Newport coined the term in the book by the same name to identify certain high-value knowledge-work activities and how to best execute them.
If you want to get serious in approaching your work, reading the whole of Deep Work is a great place to start.

Now, on with the tips.

Tip 1: Ease into it

Achieving and maintaining intense focus is hard.
If you are new to deep work, it's best to start gradually.

Aim for quality over quantity of focused time.

That 2 hours block you put in your calendar might be too ambitious.
Consider reducing it to a more realistic 30 minutes.
The more sessions you put under your belt, the longer intervals you'll be able to reach.

Tip 2: Have a plan

Decide what to work on before starting your deep work session.

Having a plan reduces the cognitive effort to get started.
The brain has a natural tendency to conserve energy and, given a choice, will gravitate to more accessible but less meaningful work.
You can bypass that temptation by separating the decision phase from the execution one.

For example, you could start your day by processing all inboxes, identifying the most valuable things to work on, and blocking out deep work time for those in your schedule.

Tip 3: Rest afterward

When done right, deep work is cognitively draining.
Your mind will need a rest after each session.

Taking some time off will help you flush the attention residue from the task you worked on, consolidate the learnings you made, and replenish your mental energy to focus appropriately later.

A good break should involve stepping away from your computer and getting your body moving to compensate for the time you have spent still.
If your schedule is packed, at least take a walk down to the kitchen to get a glass of water.

Bonus Tip: Quit Slack

It should come without saying, but you cannot work deeply if you have Slack or any other instant messaging client open in the background.

Deep work requires uninterrupted intense focus.
Checking notifications during a session is in antithesis to the deep work definition.
This is not only me being a stickler for semantics.
Whether you like it or not, those boxes popping in the corner of your screen hijack your attention.
That hampers your ability to direct as much focus as you can to the task at hand.

Working deeply is both a skill and a habit. As such, it needs to be established and trained.

If you're starting out, don't be surprised or discouraged if it's hard: It's supposed to be!

To make it easier on yourself, aim for quality over quantity in the length of your session, have a plan for what to work on, and make sure to recharge afterward.

Keep at it day after day.
The real value of deep work is not in what you get done in a single session but in the compound results that emerge from stringing together session after session.

This was a re-blog from giolodi.com. Checkout the original for more links and posts.

Enjoyed this post? Get new ones in your inbox 👉📬

Cover image credits: Christina @ wocintechchat.com via Unsplash.

How To Cut Through The Crypto Noise

Gio Lodi — Sun, 17 Apr 2022 20:48:44 +0000

This is a re-blog from [giolodi.com](https://giolodi.com/2022/04/how-to-cut-through-the-crypto-noise/. Checkout the original for more links and posts.

Will we soon be paying for breakfast in Bitcoin, using dollar notes as Monopoly money, or are we on the verge of a bubble that's about to explode?

I've never bought any crypto, but the more time passes, the more I'm experiencing FOMO. Is this my rational brain sensing something promising ahead, or my emotional brain scared of not doing what everyone else seems to be doing?

It's tough to form an opinion on cryptocurrencies. There's a lot of noise in the discourse online, and it's challenging to find trusted sources. Many big names in tech promote crypto. But are they genuine, or are they playing a speculation game? Basically, doing PR for whatever coin or startup they just invested in?

In a case like this, it helps to apply a dialectic inspired process. Take some of the best arguments in favor and against a topic and clash them. Look for contradictions and ideas that stand on their own feet, regardless of which side brought them forward.

An argument against crypto I came across recently is Ezra Klein's interview with Dan Olsen about the topics of his video essay Line Goes Up.

On the other end of the spectrum, Balaji Srinivasan is one of the most articulate defenders of crypto and Web3. His interview on The Knowledge Project podcast is a good place to start.

Finally, this conversation with Ethereum's creator Vitalik Buterin and investors Naval Ravikant and Haseeb Qureshi dives into interesting technical details.

I won't tell you where I stand after listening to those podcasts. The whole point of the exercise is for one to form their own opinion.

If you want to chat more about crypto (or anything else), get in touch on Twitter. And if you have similar well-thought, high-signal conversations to recommend, please send them my way. There's always more to learn.

This was a re-blog from [giolodi.com](https://giolodi.com/2022/04/how-to-cut-through-the-crypto-noise/. Checkout the original for more links and posts.

Enjoyed this post? Get new ones in your inbox 👉📬

Photo credits: Kanchanara on Unsplash. Modified by the author.

How to merge pull requests with a commit that improves your Git history

Gio Lodi — Wed, 25 Nov 2020 13:13:45 +0000

When you "Squash and merge" a pull request on GitHub, the merge commit title defaults to the PR title.

Using the pull request title, or any descriptive title with the PR id, makes a massive difference in how readable your Git history is.

I wish GitHub had the same behavior for "Merge pull request" instead, it uses Git's default merge title "Merge pull request #123 from username/branch-name".

Luckily, it takes just a few seconds to copy the PR title into the merge commit field.

Is the effort worth it? You bet!

Before we continue, an obvious solution to the problem would be to "Squash and merge" all PRs instead. Obvious, yes, but sometimes not desirable and other times not possible because of established team conventions. This post doesn't want to be an argument for merging vs. squashing.
The idea of keeping a clear and informative Git history is valid regardless of how we get our changes into it.

Why does the merge commit title matter?

Imagine someone offered you a million dollars if you can guess what the latest commit on a repository does by only reading its title. Would you rather the commit title was this:

Merge pull request #123 from add-author-label

or this:

Add author label to blogpost description view (#123)

Obviously, no one will ever ask you to guess what a commit does only by reading its title – let alone offer you a million dollars. Still, understanding what code does and working with it is something you are being paid for. The easier you can do that the more value you can bring to the table.

It's true that the GitHub UI makes it easy to bring up extra information for a commit, as well as the PR it belongs to. Even though the extra information is only one click away, the second commit is more explicit than the first. There is less friction for the reader to understand what the commit does.

Shorten the path to understanding

Software developers appreciate the value of clean, readable code. Clean code is easy to follow, making it easy to understand and, in turn, easy to work with.

Clean code is what every programmer opening an unfamiliar codebase hopes to find. The cleaner the code, the less time it will take to get up to speed and be productive.

The productivity advantages of clarity apply to Git commits as well as code. If you can shorten the path to understanding your Git history, every developer who will read it will benefit from it – including your future self.

Turn your Git log into a readable story

Consistently using descriptive titles for your merge commits will turn your Git log messages into a human-readable history of the changes that made it into the codebase.

The git log command has an option called --first-parents to follow only the first parent commit upon seeing a merge commit. When applied to the log on the main branch of a repository, where all the PRs get merged, the result is a list of merge commits only.

Compare the output when using a descriptive title to the PR merge commit vs. the default one:

$ git log --pretty=oneline --abbrev-commit --first-parent

a2055b7 (HEAD -> trunk, origin/trunk) Merge pull request #4 from mokagio/feature-author-label
64344e0 Merge pull request #3 from mokagio/improve-mobile-layout
70ba8ac Merge pull request #2 from mokagio/feature-more-negative-space
7d5c9da Merge pull request #1 from mokagio/feature-dark-mode-css-support

git log --pretty=oneline --abbrev-commit --first-parent

a2055b7 (HEAD -> trunk, origin/trunk) Add author label to post metadata component (#4)
64344e0 Improve layout on mobile devices (#3)
70ba8ac Use more negative space (#2)
7d5c9da Support dark mode via CSS media query (#1)

The second log reads like a story. The first has little information to offer other than the fact that stuff got merge in this branch.

When you pull the latest changes from your main branch, you can run this filtered git log to get an idea of the recent changes. Tip: define an alias for it to make it easier to call it; mine is glgf.

Using a descriptive title when you merge your pull requests on GitHub is a process that adds friction in the short run to remove friction in the long run.

It takes longer to merge a PR when you need to copy its tile or come up with a succinct one for the commit. Those extra seconds, a couple of minutes in the worse scenario, will pay off because every time a developer will look at the history, they'll benefit from its greater clarity.

The asymmetry between the one time cost of crafting the merge and the many times people will read the history makes the tradeoff all the more worth it.

So, next time you're about to click that merge button, spend a few extra seconds to add a descriptive title. Your team, the users of your open source software, your future self, they'll all thank you for it.

What do you think of this approach? What are your best practices for effective GitHub pull requests and tidy Git history? I'd love to hear from you! Leave a comment below or get in touch on Twitter at @mokagio.

How to make the View to ViewModel relationship clear in SwiftUI

Gio Lodi — Thu, 05 Nov 2020 09:37:31 +0000

SwiftUI lends itself well to be used together with the Model-View-ViewModel (MVVM) pattern. You can keep the view lean by moving all of the presentation logic and behavior into a view model with little to no code to sync between the two, thanks to framework tools like @ObservedObject.

While, in theory, you could have a view model power different views, like a row in a list as well as a detail screen, in practice, there is usually a 1-to-1 relationship between a view and its view model.

To make this connection clearer, we can use a Swift language feature called nested types. We can define the view model as a type within the view.

Nested Type View Model

Nested types allow us to "nest supporting enumerations, classes, and structures within the definition of the type they support."

When there is a 1-to-1 relationship between a view and view model, when the view model supports a single view, a nested type is a great way to make that relationship explicit.

struct BookDetail: View {

    @ObservedObject private(set) var viewModel: ViewModel

    var body: some View { ... }
}

extension BookDetail {

    class ViewModel: ObservableObject { ... }
}

You can find a working example of this code in action on GitHub.

Thanks to the nested type, the full name of the view model is BookDetail.ViewModel. This makes it obvious at a semantic level that the view model is related to BookDetail.

You could argue that BookDetail.ViewModel is not that different from BookDetailViewModel. Plus, since Xcode has fuzzy auto-completion – when it works, that is – there is no difference when typing the two.

While that's all true, this approach has some advantages compared to keeping the two concepts in unrelated types.

Advantages — Clearer and less error-prone

First of all, it's worth reiterating that using a nested type makes the relationship between the two types more evident than merely relying on their names. I feel this modeling expresses the design at a more precise level, making it easier to understand the code.

Within the view definition, we can reference the view model just as ViewModel, which leaves the code more compact.

The nested type also makes refactoring simpler.
If we ever need to rename the view, we won't need to touch the ViewModel.

It's impossible for the names of the two types to diverge.
We can't forget to update the view model after updating the view because there is no update to make on it; we'll never have a BookDetail view using a BookInfoViewModel.

In the same way, there is no chance to make a typo in the root of the view model type name – one can still mistype ViewModel, though.

As much as I like the purity of this approach, it comes with a downside that it's hard to look past: it makes it harder to find the view model code with Open Quickly.

One disadvantage with Open Quickly

Open Quickly is an Xcode feature that allows you to fuzzy find files and types by typing their name. Press Shift Cmd O, and a search field will appear on screen. As you type your query, Xcode will show the results.

In the case of nested type view models, there is no query, fuzzy or not, that can easily bring up the right type.

For example, "bookdet" will show the BookDetail.swift file, but there's no mention of the view model class. If we jump to that file, we'll have to find the class by scrolling or with Cmd F.

Searching for "bookdetailviewmodel" brings up no results, despite the query being more explicit. "viewmodel" returns all the view model classes, and you need to read the little file name field on each line to identify the right one.

The only solution I found is to keep the view models in dedicated files. If you do that, then a fuzzy query like "bdvm" will bring up BookDetail.ViewModel.swift.

Extracting the view models in dedicated files is something you'd probably want to do anyways to keep the domains separated and avoid the chance of merge conflicts when two developers are working on the view and the view model in parallel on different branches. Still, it's annoying to have to do it to find the objects efficiently.

Yay or Nay?

None of the advantages of using nested types for view models are life-changing. This approach won't make your app better from a functionality point of view, nor will it save you time or reduce the chance of making mistakes. It's all syntax sugar, at best.

Is the smarter looking code worth it, or is it better to do a bit more typing and trust the devs in the team will still get the 1-to-1 relationship based on the name of the types, and that code review will catch the cases in which the two diverge?

I haven't had the chance to use this pattern on a team in the real world, so I can't answer that for sure. I just found this approach fascinating and wanted to share it with you.

What do you think? I'd love to hear from you! Leave a comment below or get in touch on Twitter at @mokagio.

Dependency Injection in SwiftUI

Gio Lodi — Thu, 29 Oct 2020 11:03:05 +0000

There are different ways to do dependency injection in SwiftUI. In this post, we'll look at two of them:

Using the @EnvironmentObject property wrapper
Using a View Model Factory

Dependency Injection

Dependency injection, DI for short, is the practice of providing an object with the other objects it depends on rather than creating them internally.

// Without dependency injection
class Foo {
    let bar: Bar = Bar()
}

// With dependecy injection
class Foo {
    let bar: Bar

    init(bar: Bar) {
        self.bar = bar
    }
}

DI makes the design more flexible, keeps your code honest, and, when paired with a protocol, allows you to test the object behavior by providing test doubles.

The challenge with dependency injection is how to provide components with the dependencies they need without manually passing them through all of their ancestors in the hierarchy. @EnvironmentObject and the View Model Factory both provide a clean solution to this.

To compare these two approaches, let's imagine we're building a library reading list app. A tab view hosts two screens: one shows you all the books in the library, another your to-read list. You can select a title from the library list to see its details, then add it or remove it from your to-read list.

The to-read list and book detail views both need access to the reading list storage; let's call it ReadingListController.

import Combine

class ReadingListController: ObservableObject {

    // By publishing the reading list, we can leverage SwiftUI to automatically
    // update the UI when a book is added or removed.
    //
    // For the sake of this example, let's use in-memory storage. In the real
    // world, we'd be storing to disk and/or calling a remote API.
    @Published private(set) var readingList: [Book] = []

    func isBookInList(_ book: Book) -> Bool { ... }

    func add(_ book: Book) { ... }

    func remove(_ book: Book) { ... }
}

Let's have a look at the two approaches to inject this dependency.

`@EnvironmentObject`

SwiftUI offers the @EnvironmentObject property wrapper to define "an observable object supplied by a parent or ancestor view." Every time the wrapped ObservableObject emits a change, the framework will invalidate the view, resulting in a redraw.

@EnvironmentObject allows us to inject dependencies because it looks for its value in the SwiftUI environment. This means that a view deep in the hierarchy can access a dependency without its parent passing it through.

The way to add the dependency into the environment is to call the [environmentObject(_:)](https://developer.apple.com/documentation/swiftui/view/environmentobject(_:%29) method on any ancestor of the view that needs to access it. I find this is best done at the top level: in the App implementation or in the UIWindowSceneDelegate if you are mix-and-matching SwiftUI with UIKit.

Let's look at some code; you can get the source for this example here.

import SwiftUI

@main
struct ReadingListApp: App {

    // The interface with the reading list storage.
    // This is the only place where we instantiate ReadingListController; no
    // singletons or static shared instances needed.
    let readingListController = ReadingListController()

    var body: some Scene {
        WindowGroup {
            TabView {
                NavigationView {
                    ToReadList().navigationTitle("To Read 📖")
                }
                .tabItem { Text("To Read") }

                NavigationView {
                    BookList().navigationTitle("Books 📚")
                }
                .tabItem { Text("All Books") }
            }
            // Here we inject the ReadingListController instance in the
            // environment
            .environmentObject(readingListController)
        }
    }
}

The views that need access to ReadingListController can get it via @EnvironmentObject; the others don't have to know about it.

struct BookList: View {

    // Let's skip how to load the library books for the sake of brevity
    let books: [Book] = ...

    var body: some View {
        List(books) { item in
            // BookList defines the view where to navigate when a row is
            // selected, but notice how it doesn't provide it with a reference
            // to a ReadingListController.
            NavigationLink(destination: BookDetail(book: item)) {
                Text(item.title)
            }
        }
    }
}

struct BookDetail: View {

    let book: Book

    // Here, we access our injected dependency from the environment
    @EnvironmentObject var readingListController: ReadingListController

    var body: some View {
        VStack {
            Text(book.title)
            Text(book.author)

            if readingListController.isBookInList(book) {
                Button(action: { self.readingListController.remove(book) }) {
                    Text("Remove from reading list")
                }
            } else {
                Button(action: { self.readingListController.add(book) }) {
                    Text("Add to reading list")
                }
            }
        }
    }
}

struct ToReadList: View {

    // Here, too, we get our ReadingListController from the environment
    @EnvironmentObject var readingListController: ReadingListController

    var body: some View {
        List(readingListController.readingList) { item in
            Text(item.title)
            Text(item.author)
        }
    }
}

The code above is tidy and easy to follow once you wrap your head around how @EnvironmentObject works. Thanks to the SwiftUI framework internals, we don't have to write any code to keep the to-read list and book detail screens in sync; everything is taken care of for us.

There's a catch, though, if you don't call environmentObject, or if someone removes it by accident, the app will crash.

The next approach removes the risk of runtime crashes.

View Models & View Model Factory

If you use the MVVM pattern in SwiftUI, giving each view a view model containing all of the logic to present data and act on it, you can use it to inject dependencies by:

Moving the responsibility to build the views to show from the view layer to the view model;
Passing the logic to build views in the view models at init time; and
Creating the view models in a centralized place, which can inject the dependency as part as the view-building logic in the init.

Views should delegate all logic to their view models, be it what view to use as the destination of a NavigationLink or what text to show in a button.

import SwiftUI

struct BookList: View {

    let viewModel: BookListViewModel

    var body: some View {
        List(viewModel.books) { item in
            // The view model tells the view what's the NavigationLink destination
            NavigationLink(destination: viewModel.viewForSelectedBook(item)) {
                Text(item.title)
            }
        }
    }
}

struct BookDetail: View {

    @ObservedObject var viewModel: BookDetailViewModel

    var body: some View {
        VStack {
            Text(viewModel.title)
            Text(viewModel.author)
            // The view models take care of actioning on the reading list.
            // Because of that, the view only need an instance of the view
            // model; the ReadingListController dependency is hidden inside it.
            Button(action: viewModel.addOrRemoveBook) {
                Text(viewModel.addOrRemoveButtonText)
            }
        }
    }
}

You can find the code sample for this approach here.

Notice how BookDetail has no if-else conditional now.
The view is humble; it does what the view model tells it without any extra logic.

The view models themselves don't know how to build views; they ask for that knowledge in the form of a closure at init time.
Have a look at BookListViewModel:

import Combine

class BookListViewModel: ObservableObject {

    let books: [Book]

    // When creating the view model, inject the logic to create the detail view
    // for a given book.
    let viewForSelectedBook: (Book) -> BookDetail

    init(books: [Book], viewForSelectedBook: @escaping (Book) -> BookDetail) {
        self.books = books
        self.viewForSelectedBook = viewForSelectedBook
    }
}

class BookDetailViewModel: ObservableObject {

    private let book: Book
    private let readingListController: ReadingListController

    let title: String { book.title }
    let author: String { book.author }

    @Published var addOrRemoveButtonText: String

    init(book: Book, readingListController: ReadingListController) {
        self.book = book
        self.readingListController = readingListController

        // This method is defined in a private extension below to DRY the code
        // without having to define a static function that could be accessed
        // here when self is not yet available.
        addOrRemoveButtonText = readingListController.textForAddOrRemoveButton(for: book)
    }

    func addOrRemoveBook() {
        if readingListController.isBookInList(book) {
            readingListController.remove(book)
        } else {
            readingListController.add(book)
        }

        addOrRemoveButtonText = readingListController.textForAddOrRemoveButton(for: book)
    }
}

private extension ReadingListController {

    func textForAddOrRemoveButton(for book: Book) -> String {
        isBookInList(book) ? "Remove from reading list" : "Add to reading list"
    }
}

The final piece of the puzzle is the actual injection of the ReadingListController dependency from a centralized location. This object will be the only one instantiating ReadingListController and will create the view models, passing the dependency to those that need it.

A good name for an object whose sole purpose is to create other objects is factory, a hint to the factory pattern, although stripped of the functionality to let a class defer the instantiation of its components to its subclasses.

class ViewModelFactory {

    // Like when using the environment approach, ViewModelFactory is the only
    // point where we instantiate ReadingListController; no singletons or
    // static shared instances needed.
    let readingListController = ReadingListController()

    // Once again, let's gloss over how to load the books for the sake of
    // brevity.
    let books: [Book] = ...

    func makeBookListViewModel() -> BookListViewModel {
        return BookListViewModel(
            books: books,
            viewForSelectedBook: { [unowned self] in
                BookDetail(viewModel: self.makeBookDetailViewModel(for: $0))
            }
        )
    }

    func makeBookDetailViewModel(for book: Book) -> BookDetailViewModel {
        return BookDetailViewModel(book: book, readingListController: readingListController)
    }

    func makeToReadListViewModel() -> ToReadListViewModel {
        return ToReadListViewModel(readingListController: readingListController)
    }
}

This pattern removes the need to pass dependencies down each node of the hierarchy because ViewModelFactory builds all of the view models and each view model receives the logic to construct the views at init time.

We can call ViewModelFactory at the top level of our SwiftUI application, be it the App or UIWindowSceneDelegate implementation, to get the view models for the root views.

import SwiftUI

@main
struct ReadingListApp: App {

    let viewModelFactory = ViewModelFactory()

    var body: some Scene {
        WindowGroup {
            TabView {
                NavigationView {
                    ToReadList(viewModel: viewModelFactory.makeToReadListViewModel())
                        .navigationTitle("To Read 📖")
                }
                .tabItem { Text("To Read") }

                NavigationView {
                    BookList(viewModel: viewModelFactory.makeBookListViewModel())
                        .navigationTitle("Books 📚")
                }
                .tabItem { Text("All Books") }
            }
        }
    }
}

Pros & Cons

@EnvironmentObject trades runtime-safety for conciseness and is a more text-book SwiftUI approach, but it can crash your app.

Using view models for dependency injection requires a bit more work and conventions that developers need to respect but is safe at runtime.

Writing some extra code when what you get in return is runtime safety seems like a reasonable tradeoff; that's the approach I prefer. I'm still new to SwiftUI, though, and often wonder how much of my thinking within the framework is impeded by the mindset and habits developed after years of working with UIKit.

Which of these two ways do you prefer? Have you got other ways to inject dependencies in SwiftUI? I'd love to hear from you!
Leave a comment below or get in touch on Twitter at @mokagio.

This is a cross-post from my blog mokacoding.com. Head over there for more content on Swift, testing, and productivity.

Thanks to Adam Campbell and Rogerio Paula Assis for reviewing an early draft of this post.

How to test view controllers navigation

Gio Lodi ・ Apr 17 '19

#swift #testing #ios

Test Doubles in Swift: Dummies, Fakes, Stubs, and Spies.

Gio Lodi ・ Feb 15 '19

#swift #testing #tdd

Ten Productivity Books You Won't Regret Reading

Gio Lodi ・ Mar 27 '19

#productivity #books

Hyperfocus by Chris Bailey

Gio Lodi — Tue, 13 Oct 2020 09:17:22 +0000

Hyperfocus by Chris Bailey is an easy read on the topics of productivity and creativity, a good entry-level book for any knowledge worker looking to use their brain to its full potential.

The book, divided into two parts, covers first how to configure your environment and schedule to focus effectively, then how to foster creativity insights by taking productive breaks.
It is a natural follow up to Chris' previous book The Productivity Project, diving deeper into the topic of how to use your most crucial productivity tool: attention.

Hyperfocus

Hyperfocus, a term originating from the ADHD literature, is the author's jargon for the process of managing your environment and schedule to minimize distraction and maximize the quality and duration of your attention.
If you already read a few books on the topic, such as Deep Work or Indistractable, the framework and its suggestions will sound familiar.

To practice hyperfocus:

1. Choose a productive and meaningful target for your attention;
2. Eliminate as many external and internal distractions as you can;
3. Focus on that chosen object of attention; and
4. Continually draw your focus back to that one object

The final point is the one less touched upon by other productivity books, and the one Chris Bailey does an excellent job at unpacking.

Monitoring where your attention is at and nudge it back on track when it wanders off is fundamental to achieving peak focus levels.
Our minds are built for distraction.
Reading, writing, coding... those are all activities that hijack parts of our brain to do something they didn't evolve for.
Don't beat yourself up when your mind loses concentration while trying to solve a complex problem; gently steer it back on track.

Hyperfocus is a framework to get the most out of your brain when working on challenging problems, but not everything a knowledge worker requires this kind of laser-focused attention.

Tasks that require more creativity or long term vision are better executed when the mind has space to wander.
The trick here is to give your attention a leash long enough to jump around and make unexpected connections but short enough that it won't get lost in the woods.
Chris calls this process scatterfocus.

Scatterfocus

While hyperfocus involves directing your attention outward, scatterfocus is about directing it inward, inside your own mind.

To practice scatterfocus, take a break from your computer and engage in something habitual and relaxing, like going for a walk, having a coffee out, or sorting the laundry (I find that relaxing, okay? Don't judge).
While doing so, let your mind wander, following where it goes without trying to steer it.
Make sure to have a pen and paper at hand to note down the ideas that surface this way.

Chris defines three particular modes to scatterfocus.

Capture mode
Problem-crunching mode
Habitual mode

Capture mode

Capture mode is similar to the mind-sweep practice that David Allen defines in his Getting Things Done framework.
Simply sit down and dump everything that's on your mind.
This might seem awkward at first, but you'll see that tasks and worries will start to pour out on the paper once you get started.

Scatterfocus in capture mode is an excellent remedy to the feeling of being overwhelmed.
Get stuff off your head and into a medium on which you can organize them and plan how to tackle them.
I find this is best paired with a hot drink at a cafe or at home with some instrumental music.

Problem-crunching mode

When you are stuck on a problem, the problem-crunching scatterfocus mode will help you find the answer.
You probably experienced this already: you're out on lunch break when suddenly the solution to the problem you struggled with all morning materializes in front of you.
This mode is the intentional deployment of the same mechanism that resulted in that eureka moment.

The mind-wandering in problem-crunching mode is more constrained than in the other modes.
When you notice you're thinking about something unrelated to your problem, nudge your attention back to it.

Cal Newport proposes a similar technique in Deep Work, calling it productive meditation.
Take a time when you are occupied physically but not mentally, like walking, exercising, or driving, and focus on a well-defined professional problem.
The main benefit of this practice, he argues, is in training your ability to focus intensely on a single problem.

Habitual mode

Finally, habitual scatterfocus is the practice of letting your mind wander freely and see where it ends up.
This is Chris' favorite mode and the one he recommends the most.
Through this process, your mind will end up making unexpected connections and generating insights, new ideas, and plans for the future.

When done right, habitual scatterfocus can also boost your mood and better recharge you.

Intention and awareness are the two underlying themes in Hyperfocus and Chris Bailey's productivity approach.

The foundation on which all the book's techniques stand is the idea that we cannot live in autopilot, but ought to take charge and make the most of our limited time and attention.
Hyperfocus and scatterfocus might be unnecessary names for tactics that are neither new nor revolutionary, but they are nevertheless worth exploring and practicing.

Scatterfocus, in particular, is my stand-out concept from the book.
Not only it gives clear and practical instructions on how to take productive breaks, but it also makes a case for the value of stepping away from your computer.
If you are anything like me, this is something you need a constant reminder of.

Get in touch on Twitter at @mokagio or leave a comment below to discuss hyper- and scatterfocus or anything else productivity-related.

This is a crosspost from my blog, mokacoding.com.

Clutter is costly & Optimization matters

Gio Lodi ・ Feb 28 '19 ・ 5 min read

#books #productivity #softwaredesign

Ten Productivity Books You Won't Regret Reading

Gio Lodi ・ Mar 27 '19 ・ 6 min read

#productivity #books

How To Become An Indistractable Developer

Gio Lodi ・ Jun 4 ・ 9 min read

#productivity #books

How To Become An Indistractable Developer

Gio Lodi — Thu, 04 Jun 2020 11:46:46 +0000

Have you ever gotten to the end of a workday exhausted but at the same time feeling like you didn't accomplish anything? You went through a lot of tasks, had a lot of conversations, yet there's little to show for. Where did all that time go? Frustrating, isn't it?

The thing is, feeling like you haven't gotten anything meaningful done is not just frustrating; it could also be dangerous for your career.

More and more tech companies clearly state that they measure their employees' performance based on the impact they have on the business. The Netflix culture memo has a section on impact: "You accomplish amazing amounts of important work. You demonstrate consistently strong performance so colleagues can rely upon you." "It's not a ladder like it is at the banks –instead, you're measured by what you've done, by taking on a larger scope, and by the real impact of your daily work," says the Facebook careers page.

Impact is directly proportional to your value with your employer and in the market. Many external factors affect the impact, such as being in a good team, a manager that "gets you," a personal life that doesn't get in the way of work. There is something entirely within our control, though, and that is the quality of our work.

The quality of our work is directly proportional to our impact. Therefore, the quality of our work is directly proportional to our value in the market.

Even if the project you are working on seems like a lost cause, you won't regret delivering to the best of your ability. You may actually increase its chances to succeed and show your team what you can do. It's still a learning opportunity. If none of that applies, at least you'll get it done faster and move on sooner.

How can we raise the quality bar of our work? In his book Deep Work, Cal Newport proposes this law of productivity:

High-Quality Work Produced = (Time Spent) x (Intensity of Focus)

To produce quality work, you need to spend time working in a state of intense focus. "Programmers need long uninterrupted periods of focus time," goes the adage.

One way to increase both the time you spend focused and its intensity is to follow the model proposed by Nir Eyal in his book Indistractable.

Indistractable

To be Indistractable means to be able to do what you set out to do while avoiding those things that pull you away from your goals.

Image sourced from this post by the author.

"Traction" are those activities that move you forward towards your objective, while distractions are those that pull you away.

The arrows in the model show how both external and internal triggers, which we'll talk about shortly, affect both distraction and traction. To maximize traction, one needs to channel as much energy as possible in the arrows that go towards it. To spend long uninterrupted time producing quality work, we need to tame both internal and external triggers so that they help with focus, not distraction.

Let's look at the four areas of the model individually, starting from the more practical ones.

Make Time for Traction

If you want to prioritize something in life, you'll have to be intentional. You'll need to make time for it. When it comes to making time for focus, your calendar is your best friend.

Eyal suggests to timebox your schedule. That is, meticulously allocate time in your calendar for all the tasks in your day, then do your best to stick to your plan.

"Keeping a timeboxed schedule is the only way to know if you are distracted; if you're not spending your time doing what you'd planned, you're off-track."

At the start of the day, or even better at the end of the previous one, look ahead and plan how you'll spend your time. Ideally, your schedule should reflect your priorities. If you want to make progress on your coding tasks, there should be a big block of time dedicated to them. But don't stop at just scheduling your work time, schedule your distractions as well.

I've found having predefined times in my calendar where to be distracted to be an excellent cure for FOMO. For example, checking the Slacks of the communities I'm part of once a day is often enough to be on top of what's happening there. The same goes for texts and emails.

Being a bit slower in responding to texts will make little difference in your social life, but it will make a huge difference in the quality and length of your focus time. To be safe, you can always let the important people in your life know that if they need to reach you urgently, they should call, not text.

Laura Vanderkam wrote extensively about the power of scheduling in her books 168 Hours: You Have More Time Than You Think and I Know How She Does It. Check them out if you want to learn how to build a successful schedule and how to start tracking your time to understand how to make the most of it.

Finally, you should schedule time in your calendar to review how you schedule time in your calendar. This meta task is a way to verify that you have been consistent with your priorities and to discover the sources of distraction that pulled you away from focus.

Hack Back External Triggers

External triggers are those interruptions coming from the outside world. The colleague tapping on your shoulder, the push notification on your phone, the new message in the group chat.

It might seem like we don't have any control over those interruptions, but, to a degree, we do.

Here are a few ways to fight off external distractions that software developers often face:

You can avoid colleagues interrupting your work in the office by implementing the headphones rule, or, even better, by working from home or a library if your workplace allows it when you need to be Indistractable.
You can avoid notifications distracting you on your phone and computer by enabling Do Not Disturb. The cool thing about Do Not Disturb is that you can configure it to let apps with notifications you cannot afford to miss go through.
Put your phone where you cannot see it.
Install a browser extension to block social media and other distracting sites you open on auto-pilot.
Constantly work to keep your builds, tests, and other feedback loops as fast as possible, so that you won't be tempted to do something else while they run.

Master Internal Triggers

Whereas external triggers are those distractions coming from the outside world, internal triggers are those coming from within ourselves.

In the book, Eyal explores how evolution has built into us the need for distraction. "Our tendencies towards boredom, negativity bias, rumination, and hedonic adaptation conspire to make sure we're never satisfied for long." It's this constant dissatisfaction that is responsible for our advancement as a species. It is a powerful mechanism, but one that can backfire, preventing us from getting anything done.

The best way to master distraction is simply to accept that it's a normal behavior of our brain, then learn to deal with it from within.

I often procrastinate or get distracted when I have to do some tasks that I don't like, say pruning the Jira backlog. Needless to say, neither procrastinating nor getting distracted helps to get rid of the annoying task sooner. Eyal's practical suggestion to stay focused and tackle this annoying work is to reimagine the task.

While pruning the Jira backlog might not be the most interesting work for me, there are ways to make it a bit more so. For example, I can challenge myself to do so only using keyboard shortcuts. Or, I could timebox it for 30 minutes and see how many tickets I can go through.

If nothing seems to work to spark your interest, you can always use it as a training exercise in focus. Fighting back distractions while working on that annoying task is like a training session for your focus muscles.

Prevent Distractions with Pacts

As we've seen, being focused and Indistractable is as much a matter of keeping distractions out as it is of reigning ourselves in. The final strategy Eyal proposes is to make pacts with our future selves to fight off distractions. A pact is a precommitment we make against distraction and serves at keeping us in check.

If you still find it hard to focus on your work after implementing the previous areas of the Indistractable model, you should consider putting some pacts in place to help you.

You could, for example, implement an effort pact and make unwanted behavior more difficult to do. Make a deal with a coworker to work focused next to each other; the first one to get distracted pays lunch. If the browser extension you set up to avoid going on social media is not enough to stop you, then ask a friend to change your password and give it back to you only when the weekend comes. The added social pressure will make it harder to fall into unwanted behaviors.

In my opinion, pacts are the least concrete of the strategies. You should resolve to pacts only as a last resort. The previous three steps are much better at creating habits and an environment conducive to long term quality focus.

Conclusion

The problem with productivity and self-help books is that they are like diet books. A new one is published every week. Most of them provide solid advice, although sometimes it's borderline common sense –of course, you shouldn't eat a tub of ice cream a day if you want to lose weight; of course, you shouldn't check your phone every 5 minutes if you're trying to write some complicated piece of code. A productivity framework (or a diet) is only as effective as our ability to implement them.

This post contains lots of advice, definitely too much to take on in one go, and Eyal's book even more so. If you want to get started, I'd recommend you pick only one thing out of here and try it out over the next week. Just one thing. If you're successful, pick another one on top of it for the week after. If you're not successful, don't beat yourself up. Either try again or pick a different one.

Doing something, no matter how little, is better than not doing anything at all. If you agree with me that the quality of the work you produce is directly proportional to your value in the market, then any little improvement will pay off. Even more so, if you manage to stack little improvement after little improvement.

Grab yourself a copy of Indistractable to learn more about the nuances of the framework. And if you want to learn more about the value of focus and how to maintain it, Deep Work is the go-to resource.

I'd love to hear about the tactics you use to avoid distractions. Happy focused work.

This is a crosspost from my blog, mokacoding.com.

Clutter is costly & Optimization matters

Gio Lodi ・ Feb 28 '19

#books #productivity

Ten Productivity Books You Won't Regret Reading

Gio Lodi ・ Mar 27 '19

#productivity #books

Is social media in charge of your schedule?

Gio Lodi ・ May 2 '19

#productivity

Is social media in charge of your schedule?

Gio Lodi — Thu, 02 May 2019 02:48:03 +0000

A simple fact of life is that there are only 24 hours in a day.
Whatever your definition of being productive is, a crucial part of achieving it is spending those 24 hours as best as you can.

The average internet user spends more than 2 hours on social media a day.¹
I'd wager most of these people could spend that time better.

But I'm not here to wage war against social media, preaching you should delete all your accounts today.
On the contrary, if you think one or more platform is useful to you, you should keep using it.
What I'd like to focus on is how to use them.

I'll use Twitter as a personal example.
I have long stopped using Facebook and Instagram, but I look at Twitter almost daily.
It's one of my sources of tech news, a way for me to share my work, and a place keep in touch with friends from the tech community.

On the other hand, my browsing of Twitter can quickly degenerate into mindless scrolling looking for something to click, and before I know it I've wasted half an hour.

To my defense, it's not all my fault.
It's not just a matter of will power.
Twitter and all the other social media and infotainment platforms have spent years tailoring their webpages and apps to become engaging and addictive.
These technologies exploit shortcomings of our brains to make us stay with them longer and return often, so we can see the ads that generate their revenue.
This post by design ethicist Tristan Harris is an excellent introduction to the techniques they use.

How can we use social media, infotainment sites, streaming platforms, and all the other inventions of the internet age productively?
How can we get what we need out of them without being sucked in?

Social Media Operating Procedures

In his book Digital Minimalism Cal Newport introduces the concept of standard operating procedures.

In business lingo, a standard operating procedure is a "set of step-by-step instructions compiled by an organization to help workers carry out complex routine operations"².

Applied to social media and other entertainment platforms, these are rules that describe when and how to use those technologies.

By clearly defining the way we interact with any given site or app we can counterbalance how tech giants have optimized their products to make us addicted.

With these rules we can be more intentional in our usage of social media and the likes, taking control back into our own hands.

Here's a concrete example. These are my operating procedures for Twitter.

Twitter Operating Procedures

Only check Twitter twice a day; after lunch and after finishing work.
No Twitter during the weekend, it's a time to spend with the family and rest.
Stay away from the homepage and its engagement optimizations; use lists instead.
Only check Twitter when alone, don't let it distract you from other people.
No Twitter on the phone, to avoid the temptation of using it as a boredom fix.

I mostly browse Twitter through the TweetDeck desktop app.
I like it because it allows you to show lists, notifications, etc. one next to the other, without ever having to visit the homepage.^*

On the web, I use the refined Twitter plugin to remove a lot of the noise from the UI.

Thanks to these simple rules and tweaks I have lost the urge, and I rarely end up scrolling mindlessly, without having to give up what I find valuable in the platform.

How to develop your own operating procedures

The goal of a standard operating procedure is to optimize your use of a given technology.

You should develop your own procedures to get more value out of a platform and at the same time experience less of the negative aspects of it.

Take a look at how you use the technology and think if there's a better way to get value out of it.
You could use filters to only show content you really like, or bookmark the pages you want to keep up with to make them easier to reach while at the same time cutting off the distractions of the homepage.
To stay up to date with the news, you could bypass shallow infotainment news aggregators and subscribe to a few highly curated newsletters instead.

Also, think about what you don't like in a technology or in how you use it, is there a way to minimize that?
In Digital Minimalism the author shares how one of his readers only watches Netflix with their partner, to avoid isolating themselves and binge watching.
A friend of mine is into videogames but is also wary of how they tend to suck you in.
He schedules a few hours of uninterrupted play a week, during which he's fully immersed in the game.
This is enough to let him enjoy himself, and knowing he hasn't compromised his productivity gives him great satisfaction.
Moreover, he has the next scheduled session to look forward to, which makes it even more enjoyable.

Time-bound

A useful way to optimize your technology interactions is to trigger them at a particular time of the day or to time-box them.

By scheduling the times in which you interact with social media you can add an extra layer of control and intentionality.
A big danger of these technologies is that they need you to constantly use them during the day to make money.
Having predetermined times to visit them is a way to resist the urge to have a quick look.

For me, checking Twitter only at prefixed times was a shift from a reactive approach to a proactive one.
Instead of "I feel slightly bored, let me mindlessly scroll," I now think "It's time to catch up with my feed."
Not only you'll make it harder to become addicted, but you'll also enjoy the technology more, because you'll be intentionally using with it, rather than responding to a boredom stimulus.

In the same way, time-boxing your interaction is a way to ensure these technologies don't take over your schedule.
Admittedly, time-boxing requires will power.
It's easy to say "just another few minutes," and quickly lose track of time.

A way to make time-boxing easier is to automate it.
Have a look at these tools to set time limits for interactions with apps and websites.

StayFocused is a browser plugin to limit the time spent on a blacklist of sites.
Freedom is a software to set time limits, and much more, across websites and other apps.
With iOS 12, Apple introduced the ability to set app-specific time limits.

The freedom of constraints

A common concern with this scheduling approach is that it'll end up sucking away all the spontaneity from life.

It turns out to be quite the opposite.
Having allotted time slots for social media and other tasks frees up more time in my day for real spontaneous activities, like going for a walk, write to a friend, or have a tickle wrestle with my son.

The more I structure my days around routines and rituals, the more I find myself relaxed, and in control.
It's in the days in which my plans are disrupted that I end up being flustered and unproductive.

If at any point during the day I feel like visiting Twitter, knowing I have already scheduled a time for it later settles my mind, avoiding what could have been a time consuming and focus ruining distraction.

As software developers, it's easy to feel the urge to try out every new app and tool.
It often feels like time well spent researching what other people are doing in the industry.
The shiny new object syndrome applies as well to social media, apps, and infotainment websites as it does to frameworks and tools.

The Digital Minimalism philosophy encourages us to take a thoughtful approach to the use we make of technologies in our lives.

Critically assess every platform you use, and keep only the ones that are genuinely useful and in line with what you value.
For those, ideally few, technologies that make the cut, take an extra step and make sure you optimize the way you use them so that they are value generating tools, not time sucking addictions.

For me, Twitter is a technology with the potential to generate value.
But for this potential to materialize, I need to be the one in charge of the interaction, not the other way around.
Defining an operating procedure is a way to makes sure Twitter remains a tool for me, and I don't become a tool for Twitter.

Being intentional and present in everything we do is a recipe for living a good life.
Being intentional with how we interact with technology is a step in that direction.

What technologies do you find valuables?
Do you have operating procedures to interact with them?
I'd love to hear from you, leave a comment below or get in touch on Twitter @mokagio.

Footnotes

"more than 2 hours on social media a day." Data from the 2019 GlobalWebIndex report, via Digital Information World.

"set of step-by-step instructions compiled by an organization to help workers carry out complex routine operations." Source: Wikipedia.

TweetDeck. The cynical in me wouldn't be surprised if Twitter soon removed the lists feature and sunset TweetDeck to force users to interact with their algorithmic timeline. Only time will tell.

How to run a single test in Xcode

Gio Lodi — Wed, 24 Apr 2019 11:23:44 +0000

When building software, you should try to optimize the speed of your feedback loop.
The faster you can learn if your code works and how, the better you'll be at delivering value to your users.

When it comes to testing and TDD, a fast feedback loop means a test suite that runs in no more than a few seconds.
If I stare at a progress bar for more than a few seconds, my mind will start getting distracted.
At that point, I'll have to expend a lot of mental energy not to set off to do something else and disrupt my concentration.

Having a test suite that runs in a few seconds is hard though, especially as our codebases grow.
A technique to speed up the feedback loop when working in a codebase with a long-running test suite is to only run a subset of the tests.

By running only the tests relevant to the code you're changing, you can significantly speed-up the suite execution time, increasing the speed of our feedback loop.

Xcode offers a few different ways to run a subset of the tests.
Let's take a look.

From the gutter

You can run a single test class or a single test method by clicking the corresponding test diamond in the gutter.

With a keyboard shortcut

Hit ^ ⌥ ⌘ U to run the tests for the cursor's context.

If you are inside a test method, like in the example below, the context will be that method.
If your cursor is in a test class, but outside a method, the context will be that test calls; all its tests will run.

I love keyboard shortcuts, and this is my favorite testing shortcut. I use it many many times every day.

From the scheme

Another way to run a subset of tests is to select them in the scheme configuration.

I can only think of a handful of cases when you might want to use this approach.
For example, you might have a long-running integration suite that would slow down your continuous integration pipeline.
You could create a new scheme with only the core tests in the suite and run only those on CI for every repository check-in while keeping the long-running suite as something you run every night.

I'm wary of this approach.
These configurations are buried in the scheme settings; it's far too easy to forget about them.
You might disable some tests and accidentally check-in the change to the scheme, and suddenly find yourself missing an important part of your unit tests suite.

From the terminal

If you are running your tests from the terminal, you can use the -only-testing xcodebuild flag to run a subset of tests.

xcodebuild test \
  -scheme YourScheme \
  -project YourProject.xcodeproj \
  -destination 'platform=iOS Simulator,name=iPhone Xs' \
  -only-testing YourTests/YourClassTests/testSomething

You can add as many -only-testing as you want.

The option supports different granularities of identifiers: TestTarget[/TestClass[/TestMethod]].
This means that in the example above you can run all the tests in YourClassTests by using -only-testing YourTests/YourClassTests.

Worth noting that you can also run all the tests other than a subset, using the -skip-testing option instead.

Bonus: Focused tests in Quick

If you are using the testing framework Quick to enjoy a more descriptive way of defining your tests you might notice that Xcode doesn't add the diamonds in the gutter.

You can still run a subset of tests by focusing them.
This can be done by adding an f in front of on an example or group: fit, fcontext, fdescribe.

fit("is loud") {
  // ...only this focused example will be run.
}

it("has a high frequency") {
  // ...this example is not focused, and will not be run.
}

A word of caution

Running one test or a subset of tests will make your feedback loop faster, but will also reduce the confidence in your change not breaking any part of the codebase.

My recommendation is to run the subset of tests for the code you are working on only during the intermediate steps of development.
Once you're done implementing the change, fix, or feature, run the whole test suite.
Develop the habit of always running the tests before committing, and never make a commit if the tests are not passing.

What do you think of these methods to run a single test in Xcode? Do you know any other?

I'd love to hear from you, get in touch on Twitter @mokagio or leave a comment below.

DEV Community: Gio Lodi

Don't check your inbox. Process it!

The quick check trap

From checking to processing

From reactive to proactive

What does it mean to be a productive software developer?

Why Teamwork Is In Your Best Self-Interest

Three Tips To Get Started With Deep Work

Tip 1: Ease into it

Tip 2: Have a plan

Tip 3: Rest afterward

Bonus Tip: Quit Slack

How To Cut Through The Crypto Noise

How to merge pull requests with a commit that improves your Git history

Why does the merge commit title matter?

Shorten the path to understanding

Turn your Git log into a readable story

How to make the View to ViewModel relationship clear in SwiftUI

Nested Type View Model

Advantages — Clearer and less error-prone

One disadvantage with Open Quickly

Yay or Nay?

Dependency Injection in SwiftUI

Dependency Injection

@EnvironmentObject

View Models & View Model Factory

Pros & Cons

Related Posts

How to test view controllers navigation

Gio Lodi ・ Apr 17 '19

Test Doubles in Swift: Dummies, Fakes, Stubs, and Spies.

Gio Lodi ・ Feb 15 '19

Ten Productivity Books You Won't Regret Reading

Gio Lodi ・ Mar 27 '19

Hyperfocus by Chris Bailey

Hyperfocus

Scatterfocus

Capture mode

Problem-crunching mode

Habitual mode

Related Posts

Clutter is costly & Optimization matters

Gio Lodi ・ Feb 28 '19 ・ 5 min read

Ten Productivity Books You Won't Regret Reading

Gio Lodi ・ Mar 27 '19 ・ 6 min read

How To Become An Indistractable Developer

Gio Lodi ・ Jun 4 ・ 9 min read

How To Become An Indistractable Developer

Indistractable

Make Time for Traction

Hack Back External Triggers

Master Internal Triggers

Prevent Distractions with Pacts

Conclusion

Related Posts

Clutter is costly & Optimization matters

Gio Lodi ・ Feb 28 '19

Ten Productivity Books You Won't Regret Reading

Gio Lodi ・ Mar 27 '19

Is social media in charge of your schedule?

Gio Lodi ・ May 2 '19

Is social media in charge of your schedule?

Social Media Operating Procedures

Twitter Operating Procedures

How to develop your own operating procedures

Time-bound

The freedom of constraints

Footnotes

How to run a single test in Xcode

From the gutter

With a keyboard shortcut

From the scheme

From the terminal

Bonus: Focused tests in Quick

A word of caution

Related Posts

How to TDD in Swift, a step by step guide

Gio Lodi ・ Feb 13 '19 ・ 14 min read

How to test view controllers navigation

Gio Lodi ・ Apr 17 '19 ・ 5 min read

`@EnvironmentObject`