10 ways iOS is now more Mac-like

After the Big Sur reveal, there’s been a surge of articles about how the Mac has turned iOS-y. Here’s one example. But how about the reverse?

  1. iOS 13 introduced a Files app (ala Finder), that can even browse USB disk drives!
  2. iOS 14 finally allows customisation of Mail & Browser default apps.
  3. iOS 13 on the iPad has support for a mouse or trackpad, with a (perhaps better) adaptive cursor!
  4. iOS 14’s date time pickers are now more Mac-like.
  5. iOS 14 has a Picture in Picture mode, just like Safari.
  6. iOS 14 has an App Library, just like Launchpad (well maybe a lot better).
  7. iOS 14 has widgets, just like… Widgets on the Mac. No these (much older) dashboard widgets on the Mac.
  8. iOS 14 supports encrypted drives, just like much older Mac versions.
  9. iOS 13 brings custom font support to the App Store.
  10. And finally, with iOS 14, iPadOS apps are looking a lot more like Mac apps, and even Universal Search is looking a bit like Spotlight.

I think this list proves 2 things:

  1. You can make comparisons across Apple’s platforms. There is a lot of cross-pollination and prior art.
  2. iOS has slowly, but steadily become more akin to a Mac in the past few years.

Here’s 5 more things I wish Apple borrowed from macOS:

  1. Running iPhone apps windowed on an iPad.
  2. Running signed apps outside the App Store via Gatekeeper. If it’s a by default turned-off option, perhaps flagged under warnings, only “power users” will turn it on. And it’ll solve the number 1 source of frustration advanced Mac users have about iOS.
  3. Bring versions of developer focused apps such as Xcode, Terminal, Activity Monitor, et. al. Make the iPad developer friendly.
  4. Introduce proper multiple audio support.
  5. Allow some mechanism to run long-running processes, perhaps after adequate warnings. Running long-running downloads on iOS for e.g. is a terrible experience right now since you can’t “switch away” from the app.

My Workday Routine

Several times in the last couple of months I’ve been asked about my daily work routine, and so I thought I’ll write about it. It’s honestly nothing particularly different or innovative, in fact if there’s an analogy that comes to mind, it’s farming: plowing through every day in search of a good harvest.

3 ground rules to start

First off, some basic pre-requisites that I realised I must have in a workday:

  1. Goals & Cadence. Setting clear goals and striving to meet them is something I like to do. It’s also important to analyse and break down these bigger goals so that you have weekly goals and a daily sequence of small wins. I dedicate some time to do this planning work every day.
  2. Deep work. Prioritising for deep work is something that I’ve always wanted to do. Now that I’ve switched jobs, it’s become much more of a reality, and I like to clock close to the 4 hour limit whenever possible. Most of my time is now spent in deep work.
  3. Regular exercise. Some chronic back pain last year finally made me realise that incorporating some amount of exercise every day was important. It’s now an essential part of my workday, and I do some exercise during every break.

A note about Planning Tools

I think 2 kind of tools are necessary for my routine:

  1. A todo list/note taker that allows you to maintain a daily checklist of tasks to do. I currently use Todoist (duh), but I used to use Apple Notes (not Reminders, just Notes with its in-built todos) before.
  2. A time tracker to time my deep work sessions. I use Focus Keeper Pro now. I used to use the basic Apple clock timer before.

One thing that’s super important to understand is that you’ll never ever get the perfect tool for the job, so I lean towards more flexible ones that are not so opinionated in how they function. Frankly I use Todoist now because I use it at work already, so I get to dogfood it, and it’s one less tool to learn.

And now onto the phases:

Wakeup: 6:30-8:45

Wakeup is when I do my morning routines, and it’s honestly pretty much the same every day regardless of whether it’s a workday or not. I’m not going to go into more detail here about this except to say: I wake up at 6.30, I do some yoga and morning pages, and then take a shower. Because I usually do a 16-8 fast, I don’t have breakfast in the morning on workdays. Just some green tea. I’m usually done with Wakeup by 8.45am.

While I feel Wakeup is a good part of why I’m able to remain sane, it’s not really essential to the rest of the routine.

Startup: ~9:00-9:30

Startup is where I plan my day. I’ve written about this before so I’m not going to go into a lot of detail as to the why here, but the how looks like this:

  1. Spend around 10-15 minutes catching up on email, Twist, and Github. This is just to understand if there are any emergencies or unplanned work that has popped up from my previous day’s Shutdown.
  2. Figure out some 2-3 goals for the day. Sometimes I mark one of these as “must do”, usually in Todoist with a higher priority, and add that to my daily checkin.
  3. There’s no Step 3. That’s pretty much it. Once startup is done, I start Focus.

Here’s how my Todoist project looks like for a typical day:

Note that I have a big Week Focus section on top which are my weekly goals, and then a Daily Checkin section where I write down what I want to achieve that day. If have certain things I do every day (like review a PR, or do focused work), I make sure to include them here too. Beyond adding to this list, I do no specific scheduling or capacity planning, except perhaps as a thumb rule to not add “too many” tasks to a day. The Week Focus for e.g. might include many things that I don’t plan to tackle on a specific day.

Focus: ~9:30-5

Focus is where I try to spend most of my time. This is where I look up the tasks to do in my Daily Checkin and knock them off one after the other. I usually use my judgement to decide what tasks to pick up, but I usually start with the compulsory ones I do every day (like review PRs), and then the big ticket items.

It’s always true that your plans sometimes fall off the cliff of reality: but that’s ok and to be expected. At the end of the day, you might have a few tasks incomplete that you can either: a) wrap up quickly during overflow & shutdown or b) move to the next day.

I try to get in 6 focused sessions of work. Each session is 50 minutes long, with a 10 minute break in between sessions. I adapted this from Pomodoro timings that felt too short to me. Every 3 sessions I take a longer 1 and half hour break. So it roughly goes like this:

9:30-10:20Focus Session 1
10:20-10:30Short Break
10:30-11:20Focus Session 2
11:20-11:30Short Break
11:30-12:20Focus Session 3
12:20-2:00Long Break
2:00-2:50Focus Session 4
2:50-3:00Short Break
3:00-3:50Focus Session 5
3:50-4:00Short Break
4:00-4:50Focus Session 6
4:50-5:30Overflow & Shutdown

Two things to note:

  1. These timings are not absolute in any way. Sometimes I begin the day early, and end early. During some bad days overflow almost turns into a session. Some days I decide to end the long break early, and get to work quicker. I always stick to this schedule though, even if I skip a few sessions, and the focus session timings are always strictly 50 minutes.
  2. You might have noticed I take a rather large lunch break 🙂. I find that this helps me complete a few personal tasks too, and it gives me a much needed within-day break. Your routine might vary!
  3. Some days (usually 2/5 working days once I’ve started working during Corona hours), I don’t end up completing all of the 6 focused hours. This is usually a bad day for me, but well, shit happens.

Here’s how I use Focus Keeper Pro to keep time:

The first image shows the start of day, and the second the end of a good day. Focus Keeper Pro is a largely unobtrusive application. I tried to use more clever ones, but the artifice of it all quickly got to me. KISS, always.

During focus sessions:

  1. I put my head down and work on the task. There’s no email checking or any interruptions whatsoever. My phone is nowadays on perennial no-notification mode, but I try to refuse any non-urgent calls too. Focus is for deep work.
  2. Fitting tasks into focus sessions is more art than science. I don’t really plan this, and if for example, I only have 10 minutes left in a focus session, and I’m done with a task, and the next one looks like a biggie, I go through the list to see if a shorter task is available. If it’s not, I spend the time checking email or responding to the many interesting threads in Twist or Github.
  3. I try as much as possible not to multi-task. There is sometimes a veneer of inefficiency when you do this, especially for those unavoidable moments in the life of every programmer, but I’d rather wait and take things slow than context-switch. There are of course moments where you have to multi-task, especially if you are waiting on a team-mate in a different timezone, or a review to come in for a PR. At that point, I abandon this “hung task” for this focus session, and switch to a different task, complete that (even if it takes more than this focus session and the next), and only then come back see if I can resume this hung task.

It’s also interesting probably what I do in these short & long breaks. During short breaks:

  1. I go to a different room. If I’m shut in a hotel room like I am now during quarantine, I at least go to the toilet and spend some time there. This helps me mentally switch off from “work mode”. In Delhi, I used to play a record.
  2. I do 10-20 push-ups. I’ve been trying to do 100 pushups a day (cumulative) recently.
  3. Then I do whatever I want that is not work. Usually this means checking NetNewsWire for some news, or if I have some Personal tasks scheduled like a few errands, I try to do that too.

During long breaks:

  1. I have lunch.
  2. I try to read a nice fiction book. Lately it’s been the Frontlines series.
  3. I do things that more time, like longer errands.

Shutdown: ~5:00-5:30

Shutdown (& sometimes Overflow where I finish up some task) is where I switch my brain over to “done for the day” mode, and is an important part of the ritual as well. One of the important things I do during Shutdown is a daily checkout. Public checkouts are a very useful way I’ve found to maintain personal accountability. It’s easy for me to be a slacker when I am working remote, and maintaining a fiction that somebody cares helps quite a bit 🙂

Currently I do Checkouts by taking a snapshot of my Week Focus board to send to my manager. Part of the ritual when I used to work at Lucideus was reading other people’s Checkouts too, but that doesn’t happen (yet 😉) at Doist.

This is how my most recent Checkout snapshot looks like. As you can see, some tasks as incomplete, and I only got 5 sessions done.


  1. I don’t do any planning for the next day during Shutdown. The remnants of the Daily Checkin section are a plan in themselves, and it provides a foundation & continuity for the next day.
  2. One other thing I do in my Shutdown is to go through Twist, email, and Github, and see if there are no loose-ends.
  3. I reflect about what I am feeling about the workday that just ended. Sometimes I feel that the day has been good even if I didn’t achieve all 6 sessions, sometimes I feel it’s been terrible even if the overflow goes on for ever. There are good days and bad days always. One thing you should always remember: regardless of whatever shit that hits the fan, there are always bright and beautiful days ahead.

Wind Down: ~5:30-10:30

Wind Down is everything not work. Usually for me that means a few things:

  1. If you can afford it, switch to a different computer. I did this during my days at Lucideus and it made a huge difference, mostly because as a programmer a lot of what you do for fun is also programming. If you do it on the same machine, it’s easy to get started thinking about work again. Currently I only have one laptop, but I have a few interesting ways in which I’m exploring having a different machine. That’s a topic for a different blog post.
  2. Do things that seem fun for you. One of the most important takeaways for me from Artist’s Way is that for creativity to flourish, you need to nurture your inner child. Have fun, even if—in these cold Corona times—it’s watching Netflix or catching up with friends on Zoom or a call, or gasp, going out for a walk in the guise of getting medicine or groceries.
  3. Sleeping early. I try to sleep by 10:30. I have a Bedtime alarm that reminds me of this, and an Apple Watch that tracks sleep quality. Sleep for me is very, very important, and unless I get a solid 8-8:30 hours, I’m dead on my feet by the weekend.
  4. And every once in a while, break all these rules & strictures and just let go.

Well that’s how I work! If you found this useful, you should follow me on Twitter.

Recommending fnm for node version switching

So I’m a distant admirer of Reason, and one of the benefits it brings is the ability to have a single language that both compiles down to Javascript so you can use it on the web, and also have a native backend so you can write incredibly fast command-line tools.

fnm is one such native ReasonML tool that’s at least 100x faster than any other node version switcher. Recommended!

Pragmatic Programming

Sajith asked me to talk about a programming topic with the good folks at Shopper.com recently, and I picked something near and dear to my heart: how to engineer with pragmatism at heart, how to navigate the challenges between business folks who want really fast turnaround time, and your engineering soul that wants good, maintainable craftsman-worthy code.

This wasn’t my finest presentation, but I liked the discussion that came up in between Sajith & me, and there were several things I’d improve if I were to give this talk again (this requires that you have either watched the video or at least skimmed through the slides above):

  1. I wish I had called this Pragmatic Engineering instead because a) there is very little programming in these slides, and b) people will think this is from the book, when it’s clearly not.
  2. Sajith brought up a good point in between that pragmatism is only possible because you lean on the shoulders of giants who wrote code before you (i.e. open source code). And that work priority is independent of these decisions: you plan & prioritise based on what makes sense to your organisation. I somehow should make this clearer in the slides and the talk that “big rocks” doesn’t necessarily imply a work priority.
  3. I think the ending is very weak. I didn’t directly address what measures are possible for a pragmatic organisation. Here’s an attempt:
    1. Since the primary thumb-rule emphasises change, let’s measure speed of change or velocity. This is a leading measure, and a corresponding lagging one could be customer features delivered / quarter.
    2. A corresponding negative measure related to velocity could be defect counts, and defect escape rates, these can be measured from leading to lagging, as in DERs caught by PR reviews, your staging or QA environment, your beta and the worst of em all: in production.
    3. If there’s one thing that impacts the velocity of the team it’s good test coverage. So both code and feature coverage[1] measures, and test resiliency metrics like false negatives should be measured and constantly improved. These are all leading measures.
    4. Measuring the warts in your code (e.g. FIXME/TODO lines, or “known issues”) is also a good leading measure. This should trend down.
    5. And finally, measure Cycle Time, but segmented by business use cases. The intent here is that all non-“Big Rock” items should have low Cycle Time. If not: maybe you don’t have the right processes or pragmatic software selection there yet. As an example: if a marketing page typo fix takes your company a week to execute (perhaps because it has to be prioritised in a sprint backlog), then might have a problem.

I’m willing and excited to do more such talks! If you’d like me to speak to a small group, do send me a message!

[1]: Feature coverage was a term we invented at Lucideus to measure how many important features were covered by integration tests. Unit test coverage is easy to measure, integration tests aren’t, and only if you measure something can you consistently improve. The eventual definition ended up being something along the lines of “The % of test cases with priority Critical or High that were automated.” We reported these metrics segmented by feature.