Workflow on Noetic Nought

The tools we build change us

Wed, 22 Apr 2020 12:54:00 +0530

A couple of weeks ago, I spent some time building a couple of “automation tools” for myself. It is still early days to talk about their impact, but I have already noticed some changes, and have some thoughts to share.

Thanks to the lock-down, I felt like I needed to do something to get more fresh-air and sunlight. I figured out a nice setup to work from my balcony, when I feel like it. It’s nice to sit in the balcony, since there’s not as much traffic, and there’s enough fresh-air and sunlight.

I usually work with dark themes in all my tools - code editor, terminal, OS, chat clients, etc. But, switching to the balcony during the day makes it harder to read text in dark mode. I have to switch all my tools to light mode. And then switch back, when I come back in. It takes me about a minute or so, each time to make this switch. In a few days, this started to seem like work! And I could see myself needing to push myself to step out, or step back in.

A few days later, I spent about half a day writing a tool that could switch modes for all of these programs with one command. If I was doing the switches manually each time, it would take 2-4 months for the switching time to add up to the 4-6 hours, I spent on getting everything working correctly. So, it’s not really a bad investment. But, what matters more is that I don’t feel a mental block to alternate between indoors and outdoors because of all the extra work that manual theme switching felt like. I am getting some fresh air and sunlight everyday. :)

The other tool I wrote recently was for generating a daily summary of what I worked on from my org-mode based clock entries. I add more detail to the bulleted-list summary that gets generated, and then post it on our team’s Zulip. I noticed a couple of changes because of this.

First, I clock things more diligently than I did before. If I forget to clock into something, I go back and add some manual entries, to maintain a proper log. Second, a couple of other people on my team also have started posting a summary of their day’s work, which is quite nice. This tool may have triggered a change in my teammates’ behavior, though I didn’t really intend it to.

We are creatures of habit, often going through the motions, without needing to think about what we are doing. This is evolution helping us save energy for the more critical tasks. But, our environments can have a big impact on our habits. Having tools around us, that are easy to use, can help us nudge ourselves in directions that we want to be nudged in.

The tools we build can change us; if we let them.

Thanks to Rajesh, Ritesh, Tejaa and Shantanu for reading drafts of this post.

Automation and Habits

Wed, 15 Aug 2018 18:44:00 +0530

We usually see automation as a thing we do to save time. But, there’s more to it than just saving time.

Several years ago, I built a tool called org2blog that let me write blog posts in my text-editor, and publish them with just a couple of key-strokes. I spent several man-weeks getting it to work well – adding lots of features including image uploads. The time I spent on developing and maintaining it dwarfs the time saved by automation.

But, in the three months following this, I published 30 blog posts – as many as I would’ve otherwise published during the whole year. org2blog wasn’t just saving time – it drastically reduced the friction to publish new posts. On some occasions where I would’ve previously avoided writing a new post, I ended up writing one because org2blog made it a breeze. I could focus on actually writing the post and not let my attention be hijacked by the repetitive and boring steps that were previously required to start writing a new post and publish it.

Automation abstracts away the details that we would’ve otherwise had to spend our attention on. This reduced mental overload encourages us to “do the right thing”, when we would’ve otherwise been lazy and taken the easier route of not doing something. No wonder, Douglas Adams confessed to happily spending a day on automating something that would’ve taken him ten seconds.

When extended to a team setting this would mean our (automation) tools nudging everyone on the team towards better habits and behavior. We must recognize this and treat our tools as an integral part of our team, and not just time-savers. The Zulip community is a good example of this. Tim, the lead developer of Zulip, pays particular attention to developer workflows in Zulip and is constantly on the lookout to automate tasks and/or eliminate unnecessary tasks, to make it easier for everyone to “do things right”.

The tools we build aren’t just saving us time, but are changing us back. Building better tools helps build better teams. Go forth and automate!

PS: This post is inspired from this talk by Jessica Kerr where, among other things, she talks about Automation and some reasons for doing it.

PPS: Jason Silva talks about humans as being a technology creating species, and how the tools we create change us, and how we change them to change us further. This seems a lot like the idea in this post, except at a much larger scale.

Thanks to Shantanu for reviewing this blog post.

Tedium in work-flows

Thu, 19 May 2016 00:00:00 +0530

I use Nikola for generating this blog. When creating a new post, it prompts for a title, and creates a file for the post.

Often I’m starting off with only a vague idea that needs to be fleshed out before it can be published (or discarded). It is quite difficult to come up with a title at this stage. I just want to start a draft and write things down!

I could use a “draft-title” and change it after finishing a post, but this feels tedious – requires 3 steps – change the title, post filename and post slug. The last two steps are optional, really, but I feel they are important especially when the original title is very different from the new one.

Being forced to come up with a title before anything else, feels tedious and, adds to the effort required to start off a new post. I shouldn’t really be worrying about the effort required to change the title of an unwritten post, but it happens subconsciously.

To work around this, I now have a “re-title utility” in my editor that takes care of all the tedious details. I can start with a random title, like Draft-1, and change it when I’m done with the post. I feel this is going to lead to a lot more drafts, at the very least, if not published posts.

Another work-flow related thing I came across recently was @Malabarba’s issue on CIDER (an IDE for Clojure in Emacs). The REPL takes a while to startup and this caused him to not use CIDER for running tests, if there wasn’t an already open REPL.

The tedium that people feel effects how they use the tool. Not surprisingly, making tedious-feeling tasks a breeze with the tool also effects how and how much they use it. Subtle variations in a work-flow could make or break it. How do you discover such potential work-flow make-or-break-ers? I think, these things would help:

Use the tool yourself (dog-food)
Talk to (or watch!) people using your tool
Look at work-flows in other similar tools
Thinking explicitly about various scenarios and simplifying or improving work-flows

I’d love to hear examples of this, and any ideas or thoughts you may have on identifying and fixing such things!