Favorite posts on Noetic Nought

Why my Elfeed index was 0 bytes

Fri, 30 Jan 2026 16:58:00 +0530

My Linux machine crashed, while I was in the middle of a video call. I restarted quickly, and continued the discussion. Later, when I was trying to sync Elfeed updates onto the Elfeed Offline app on my phone, I found it acting weird. All the bazillion things needed to get it working were in place, but it was still complaining about the Emacs Elfeed server not being accessible. I tried opening Elfeed inside Emacs and failed! The index file in Elfeed’s DB was empty! Gone! Poof!

Frustrating, but I didn’t have time to look into what happened. I would’ve been furious if I had been using Elfeed for longer and had a lot more metadata saved. But, it was only a few weeks of lost metadata - posts I read, starred, etc. I quickly setup a Git based backup to prevent future losses and moved on.

Later, I found time to dig into what might have happened…

The breadcrumbs

Elfeed stores all the metadata for all the posts in an index file with a content addressed store of the contents of each of the posts. The index file is simply a dump of the hash-table containing the metadata for the subscribed feeds, their entries and metadata like tags, read/unread status, etc.

The DB save happens in elfeed-db-save, which simply dumps the hash-table to disk inside a call to the with-temp-file macro.

(defun elfeed-db-save ()
  ; <snip>
  (with-temp-file (expand-file-name "index" elfeed-db-directory)
    ; ...
    (princ (format ";;; Elfeed Database Index (version %s)\n\n"
                       elfeed-db-version))
    ; ...
    (prin1 elfeed-db)
    ;...
    ))

with-temp-file, as its documentation says, lets you create a new buffer, evaluate the body there, and write the buffer to file. For a moment, I thought there was some temporary file involved, but nope! I guess the name comes as an extension from with-temp-buffer which does create a temporary buffer where the body of the macro gets evaluated. Stripped to its core, this function is:

`(let ((,temp-file ,file)
       (,temp-buffer (generate-new-buffer " *temp file*" t)))
   (prog1
       (with-current-buffer ,temp-buffer
         ,@body)
     (with-current-buffer ,temp-buffer
       (write-region nil nil ,temp-file nil 0))))

`write-region` and `O_TRUNC`

So, write-region is the workhorse which writes the contents of the temporary buffer to disk. It’s a roughly 300 line long C function that essentially opens the file with the flags O_WRONLY | O_CREAT | O_TRUNC (in this case) and then does something to write the contents to the file, etc. Honestly, I didn’t look at anything else too carefully after I spotted the O_TRUNC.

The man page of open explains O_TRUNC as follows:

O_TRUNC :: If the file already exists and is a regular file and the access mode allows writing (i.e., is O_RDWR or O_WRONLY) it will be truncated to length 0.

Voilà!

The write is not atomic. The file first gets truncated to length 0, and then we hope that the new contents get correctly written before something goes wrong.

It now makes sense why the file got truncated to 0 bytes. The crash happened after the open, but before the write. Somehow the crash happened in this short window, and poof!

Emacs has backup files, doesn’t it?

Temporary files with ~ in their file extensions have definitely annoyed me in the past when Emacs created them where I didn’t want them. So, I do know that Emacs has back-up mechanisms out of the box. But, it turns out that the backups occur in code paths that are more interactive, like save-buffer, write-file, etc. And not via the programmatic APIs like write-region or the higher level with-temp-file. save-buffer calls backup-buffer before writing, but write-region is much more low-level and doesn’t deal with backups.

The fix

My “fix” for this is to backup the Elfeed data in a git repository to be able to recover from any such corruptions of data, which I already wrote about here.

I know that any code that uses with-temp-file (or write-region) could be affected by this, and the right fix for this may be to write to a temporary file and rename it. Maybe next time I lose data I’ll actually fix it properly.

An offline-friendly Elfeed web UI

Wed, 07 Jan 2026 02:31:00 +0530

I want to read articles from my RSS subscriptions on my phone without signing up to a hosted service or running a public server.

Elfeed, the Emacs feed reader, already lets me manage my subscriptions and read from within Emacs. It comes with an experimental web UI, but needs the server (running on my laptop) to be accessible whenever I want to read. My phone becomes useless the moment my laptop sleeps.

So, I built an alternate web UI with a service worker that caches content on the client side for a smooth offline reading experience. It’s written in OCaml and compiled to JavaScript using js_of_ocaml.

Why bother with RSS feeds?

It is annoyingly easy to fall into the trap of short form videos or other algorithmically “curated” feeds and get sucked into scrolling mindlessly. I fear this is going to get even worse with all the generative AI stuff.

I want to be more deliberate about what I consume. RSS feels calmer and gives me a greater sense of control. Or it may just be nostalgia from good old Google Reader days.

Why Emacs and Elfeed?

Since Google Reader was killed, I’ve bounced between many readers but none of them has really stuck with me. I’ve had different phases of using Elfeed, over the years, though.

I like the fact that everything is local with Elfeed – no hosted services, no public servers. And since it lives inside Emacs, everything from tagging to how entries are displayed can be tweaked.

Why Elfeed offline?

Elfeed also ships a basic web UI that lets me read my feeds from a different device, but only when my laptop is online and reachable. I’d like to be able to read these posts even when I’m “on the road”, say, while waiting for a train or while taking a cab ride.

I knew it should be possible to do this with some client side caching. And, I considered improving the web UI of Elfeed itself but it doesn’t seem to be actively maintained in the last couple of years. Creating a separate project would also give me more freedom to experiment.

How does it work?

Elfeed offline comes with a tiny Dream based webserver that acts as a proxy in front of the Emacs Elfeed webserver for the API requests. The Dream web server also serves the static assets like the HTML, JavaScript, stylesheets and the Service Worker for the web app. The diagram below shows how data flows between the different components.

+---------------+     +-----------------+
|  Emacs Elfeed |<--->|     Dream       |
|     Server    |     |   Web-server    |
+---------------+     +-----------------+
                               ^
                               |
                               v
 +------------+        +----------------+       +---------+
 |    Web     |        |    Service     |       | Browser |
 |  Client    |<------>|     Worker     |<----->|  Cache  |
 +------------+        +----------------+       +---------+

The Service Worker intercepts all the GET requests from the client and responds using a cache-first-with-cache-refresh strategy. This makes the reading experience feel very responsive. The web client also implements a “good enough” clone of the original search functionality of Elfeed to allow searching and filtering content while offline.

The web app also lets me mark entries as read or star them when I’m offline. The Service Worker caches these operations and updates the server when the server becomes reachable. There’s no smart conflict resolution here, and the API requests just overwrite and update the state on the server.

I have been using this for a couple of weeks now, and am quite happy with how responsive the UI feels and the number of posts I managed to read so far.

But, there are definitely some rough edges to smoothen out.

It’s a pain to make sure that both the servers are running when I’m online and want to sync new updates to my phone. I’m considering adding a tiny Emacs helper to manage this.
I need to remember to open the app on my phone to trigger a cache update before stepping away from my laptop. I want to explore using the Background Sync API (not available on Firefox) to possibly make this easier.
The UI could use some improvements to indicate pending syncs when offline and also indicate the last sync with the server to help ensure everything is synced before stepping away from my laptop.
Service workers need the server to be accessible via https. I have a wrapper script around mkcert to make this easy, but some apps on my phone refuse to work correctly when there are user installed certificates.

Why OCaml?

At work, I write OCaml every day and enjoy it. This project seemed like a good one to try out js_of_ocaml since everything is local and I don’t need to worry about bundle sizes, etc.

js_of_ocaml makes it quite convenient to share code between the server and the client side. And given there’s also a “third” Service Worker component in the mix, I thought it would make life easier. For instance, the message types and the serialization code for the messages between the client and the service worker are shared.

I’m also using this project to experiment with Dune’s “soon to be released”™ package management that our team at Tarides is working on building.

How can you use it?

You can try out Elfeed offline’s UI here as a static site (with some posts from Planet Emacslife and The OCaml Planet). You should be able to read posts, search and filter for posts, mark them as read or star them. Any changes you make should be preserved between reloads.

If you are an Emacs user but don’t use Elfeed, you can checkout the Elfeed’s README for instructions to set it up. It also has links to a bunch of blog posts and videos that show off the features of Elfeed.

If you are already using Elfeed, you should be able to set it up quite easily if you’re happy installing some OCaml tooling. The installations instructions are available in the README.

Outro

I have been enjoying using Elfeed offline for the past couple of weeks. And I’m hoping I’ll end up spending much more time reading in it, than fixing and building it. It currently definitely feels like something I built for myself, but I’d love to hear from others who try it out.

An innocent query that caused Zulip downtime

Thu, 28 May 2020 11:34:00 +0530

Introduction

Recently, a change that I contributed caused some downtime on the Zulip cloud (zulipchat.com). Here’s a user tweeting at us, about this.

I shared this with some friends (who use Zulip) and they asked me to share more about what happened. I began writing an explanation, and it eventually turned into a blog post. The post tries to explain what caused the down-time, without assuming too much knowledge of the Zulip DB schema, but it would help if you used Zulip a little.

The goal of my change was to change how Zulip backend calculates the furthest_read_time for a user – the time stamp indicating when the last message was read.

Previously, the code used simply kept track of the message ID of the messages being read by a user in a field called the “pointer”. My change was to move away from this pointer approach to using the actual timestamp of when a user last read a message.

What is the pointer?

Put very simply, the pointer is just a message ID¹ – ideally, the ID of the “last message” a user has read. Message IDs in Zulip are incremental – a message that has arrived after another one, would have a higher ID than the older message. So, it would’ve been a great way to keep track of the last read message, if all the messages were in “one continuous feed”. But, guess what, Zulip has streams and topics which are precisely what make Zulip such a valuable communication tool!

The pointer can be set to the ID of the message that is currently being read, but only when we are in the “All messages” view. In this view, all messages are ordered chronologically, so any message that is after another message would have arrived after it, and would have an ID greater than the other message. So reading a message in this view means, any message with a lower ID must’ve already been read.

When you are reading messages in a stream/topic (narrowed) view, the pointer is not updated. We can’t be sure that all messages with ID lower than the current message’s ID have already been read. There could be a whole bunch of unread messages in other streams/topics than the current one you are reading. So, the pointer doesn’t get updated until you go to the “All messages” view and scroll over the messages, even if you have already read them in a narrowed view.

Why change this?

Using the pointer to compute the furthest_read_time doesn’t work very well, because it is only updated in the “All messages” view. In other words, furthest_read_time turned out to actually mean something like furthest_read_time_in_all_messages_view.

The furthest_read_time is used in the UI to display the bankruptcy banner – a prompt shown to a user to mark all messages as read, if they have “too many” unreads, and haven’t read new messages in the last 48 hours.

But, this is a problem, especially in Zulip instances with a lot of traffic, where people leave a lot of messages unread until they have the time to catch-up. It is common for people to communicate only in a handful of streams/topics, and leave a lot of messages unread in other streams or topics, that they are hoping to catch-up on, when they have more time at hand. Such users would avoid using the “All messages” view at any cost.

Even in not-so-high-traffic realms, some users just prefer not to use the “All messages” view, and just stick to narrowed views.

So, for these users the furthest_read_time would get updated very rarely, and could potentially remain at a date way back in the past. This meant the users would see the bankruptcy banner despite actively participating in the Realm, even if only in a few topics/streams. This is annoying UX, and what something we wanted to fix.

What did we change this to?

We decided to use the last read message time as the message to consider for the furthest_read_time. The following “innocent looking” query should do that for us, we thought…

UserMessage.objects.filter(user_profile=user_profile, flags=UserMessage.flags.read).last()

Well, it does, but not without bringing down the whole of zulipchat.com after a deploy! 🙈 But, why?!

Some background on how data is stored would be useful to see why.

UserMessage table is huge, my friend

Zulip’s data model has a Message table that stores the content of each message, when it was sent, by whom, to which topic, etc. The UserMessage table is then used to keep track of what the status of this message is, for each user that has received the message. A 32 bit flag field is used to keep track of things like, whether the user has read a message, starred a message, has been mentioned in a message, etc. So, if a messages is sent to a stream with N users, it creates 1 row in the Message table and N rows in the UserMessage table. If M such messages are sent, it would create M*N rows in the UserMessage table. So, pretty soon, the UserMessage table becomes huge! ²

To make common queries on this table efficient, the DB has indexes for them. Some of the indexes on the UserMessage table are documented here, though the documentation was created in the migration context for production deployments. There are indexes for various things, including unread messages.

And here’s our innocent looking query, as a reminder.

UserMessage.objects.filter(user_profile=user_profile, flags=UserMessage.flags.read).last()

This query searches through the read messages for a particular user, and tries to figure out the last message they read. Note that the DB only has indexes for unread messages, not read messages! So, this query isn’t using DB indexes to search for this needle in the haystack, and ends up being pretty damn slow!

Additionally, this query is run for every user when the “home page” is loaded since we want to calculate their furthest_read_time to decide if should show the bankruptcy banner.

Also, Zulip’s architecture is designed to allow using the same app server and DB to host multiple different realms. And zulipchat.com is such a deployment where a few servers are used to serve all the realms. (I don’t know too much about the deployment setup, though).

When a new change is deployed to zulipchat.com and the server is restarted, all the clients of all the users reload. Having an expensive query in that path, would just kill the DB. And this innocent looking query didn’t disappoint!

How did we fix this?

Well, this change was reverted immediately by Tim, and things were kicked back into a usable state.

Later, we decided to take a different approach. We decided to look at a different table (UserActivity) that tracks user activity, mainly for the purpose of analytics. This table keeps track of the last time a user performed an action based on the API calls made.

Among other things, changing any of the flags in the 32-bit flag field is one of the actions that is tracked. Marking a message as read was being tracked too. We use the last time this action was performed to compute the last time a user was “active”, and based on that decide if we should show the bankruptcy banner or not.

Here’s the actual commit that makes this change. But, it turns out that needed a follow-up fix too. 🙈

Thanks to Tim Abbott and Shantanu for reading drafts of this post.

The pointer was used to do a bunch of useful things, but we are currently in the process of removing it. ↩︎
Zulip’s code base uses a concept called soft-deactivation to mitigate this problem on Realms where there are a lot of users who log in very infrequently, or don’t login after an initial period of activity. So, the number of rows are not exactly M*N in all the cases, but in the worst case they are. ↩︎

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.

Been there, done that, and still doing it!

Thu, 05 Sep 2019 12:23:00 +0530

I was talking to a friend a few days ago about a new internship she got. She wasn’t sure if and how much she was going to get paid for it. Unpaid internships aren’t cool, and experience doesn’t pay the bills, as they say. Eventually, it turned out that she was indeed going to get paid for it.

But, when she found out that she’ll be paid, she felt way more pressure to “not screw up”. I think working in this mode of “don’t screw up” isn’t very productive. Staying in the mindset of “learn as much as I can” would still be the best way to go about the internship.

Screwing up is a part of the job. People make mistakes and learn from them. Screwing up is a part of gaining experience, and learning. To let people feel comfortable and safe while they are learning, it’s important to have better fallback and recovery mechanisms when things go wrong. The productivity gains are worth investing time into such systems.

I’m going to write down a couple of times I screwed up – one of them in my very first job after college, and the other just a month or so ago. People screw up every day, irrespective of how much experience they have.

Corrupted a server’s hard-disk

In my first job, I had screwed up big time in the first couple of weeks of my job. It’s been a while, and a lot of the details escape me now.

I was supposed to resize partitions on a server’s hard disk so that there’s more space available for the media that we were going to store on the server. The server was pretty newly setup, and there wasn’t all that much data on it, but my bosses (Asokan and Prabhu) had spent some time on configuring it, and setting up user accounts, etc., for all the people that were going to join the project.

I tested the resize operation on a machine locally in the office that I worked in, and it seemed to work. I replicated this on the server, and it went kaput! All the data was lost and I could no longer SSH into it. I was totally freaking out!

But my boss ended up being really calm about it, and asked me to just write to the server hosting service to get a new machine with a bigger media disk. And no, I didn’t get fired from the job. I worked with him for 5-6 years after that, including being hired again at a company he started working for.

Almost Deleted 7-8 years of email

A few weeks ago, I screwed up again. It could’ve been pretty bad, but luckily for me it wasn’t.

I administer a legacy Google Suite for UPAI. We have only 10 email IDs to allocate, and we often recycle them. Recently, I had to merge 3 accounts into a single one to free up 2 new accounts. I transferred data from two of them to the third, and went ahead and deleted them. I did this with a couple of other email accounts before, but they were barely used and nobody really cared about them.

I hadn’t paid attention to what data gets transferred, and what doesn’t. It turns out emails don’t get transferred, and only data in the Google Drive gets transferred. This meant I had lost years of important email communication for the organisation. I freaked out!

My “boss” was again pretty calm, and asked me to write to Google to see if I could get them to restore the data. I looked around, and found that Google allowed restoring deleted accounts for 20 days! I restored those accounts, transferred the email and then deleted the accounts again.

Learning from screw-ups

Learning and improving the systems in-place to prevent such screw-ups is the best thing that we can do from such screw-ups. Just like a piece of software gets hardened by bug reports that are acted upon, over the course of time, other systems can and should too.

As described in this blog post by GitLab on how to take advantage of screw-ups, acknowledging mistakes, fixing them, and improving the systems in-place to prevent such mistakes is a good way to go about it.

Systems needn’t always be super complicated things, but just a little bit of automation, and even simple checklists go a long way in improving work-flows and making processes less error prone. Google’s recovery mechanism definitely helped, and gives me confidence to continue working with these user accounts. Our server had a system admin pretty soon, and he had automated back-ups and the usual stuff in place, for us!

The way a team deals with mistakes sets the tone for how the team works, takes responsibility, and feels about working together. I still screw up after working for about a decade as a developer, and being paid for it. I’m sure I’ll continue to have my screw-ups, even though I’d like to have none. What was nice in both the cases was the way in which my mentors/bosses reacted, and how calm they were about the whole situation.

May you have screw-ups that you learn and grow from!

PS: Google’s Data Migration Service doesn’t support legacy Google Suite accounts, and I ended up using Got Your Back to move email from the accounts I wanted to delete to the other accounts. It worked pretty smoothly!

Thanks to Aishwarya, Meghana, Tejaa and Shantanu for reading drafts of this post.

Self-care tips for new developers

Wed, 24 Oct 2018 20:14:00 +0530

A couple of weeks ago, I was at PyCon India – the 10th edition, the 8th PyCon I was attending. It was great to see so many enthusiastic young developers, attending their first PyCon. With each year, as the event gets bigger, you see more and more of them. Lot of curiosity, and enthusiasm to become better programmers.

The conference had a whole bunch of talks, catering to people with varied interests, at different stages in their career – war stories, tips and tricks, helpful advice on getting started with a library or tool, thoughts on the community culture, etc. With each passing year, there are more and more proposals for talks, and a lot of good talks have to be left out due to constraints on the number of talks that the conference can accommodate.

Having said that, I’d have liked to see a talk on self-care tips for developers – advice on staying sane and productive in the long run. It is quite common for programmers to get burnt-out. I’m sure there are some useful lessons to be shared by everyone who has been programming professionally for a while – ranging from about a couple of years to many decades!

In a hallway conversation, Noufal was telling some of us about the Okinawa martial art lessons he’s been taking - it was inspiring to see how seriously he takes the lessons. A lot of programmers that I know, who have been programming for a while, have other interests that they pursue quite seriously, to take time off from programming. It would be nice to have someone speak about mental health and self care in a talk, rather than hope that people pick it up in hallway conversations. Explicit is better than implicit.

I was considering doing a lightning talk on this, but I didn’t get in touch with the organizers early enough to get a slot. So, here’s a blog post.

Disclaimer: Not all of these are things I’m good at doing consistently, but they are things that have at some point helped me. This post is also a way for me to write down things that I (or others) can come back to whenever necessary.

Take breaks

We are often so engrossed in getting something to work, that we lose track of time – slumping in our chairs for hours on end, forgetting to eat, hydrate or move around.

Our bodies weren’t made for this – we were built to move around. Also, stepping away from the problem for a bit, after wrestling with it for a while, brings a fresh perspective and new ideas.

You could use a tool like workrave to remind you to take regular breaks and stretch. Or use a Pomodoro timer. Another trick is to drink keep drinking water regularly, so you are forced to get up and take a piss, every once in a while.

Hydrate, Eat and Sleep

Being dehydrated can make one feel tired and sleepy, making it hard to focus well. Same goes for being hungry and sleep-deprived. Not having enough glucose in your blood has been shown to cause people to make bad decisions.

Mental work uses up a lot of energy, even if we seem to be just sitting around all day, and not expending much more energy than sleeping. It is important to feel good physically to work effectively.

You could have a bottle of water next to you, that you frequently drink from and keep re-filling at breaks. Don’t skip on your lunch to use that extra half an hour being productive. Keeping some snack accessible for you to eat towards the end of the day, when you are tired, helps. Use a sleep tracker or just roughly track sleep each night manually. Make sure you are getting enough of it.

Invest in a good set-up

We spend around half of our waking time at work - over a life time, that’s a lot of time! Sitting in a bad posture, or doing a only-slightly-uncomfortable action over and over, can easily grow into bigger problems in the long run.

You deserve good quality equipment, that “fits” you well. Get yourself a good keyboard and mouse, an external monitor, or whatever it is that you think will make your body thank you. If you end-up working a lot from your home office, invest in a good chair and a table.

Sunlight & Exercise

Being locked up in our office buildings all day doesn’t help with how much exposure we get to the sun. Not getting enough sunlight regularly can effect us both mentally and physically. Same goes for exercise. Getting some exercise everyday has been shown to have significant mental and physical health benefits.

You can start playing a sport, if hitting the gym or doing something alone seems like a chore. Playing a team sport helps even more since there are other people you are accountable to. Try to get some sunlight every morning, even if it is just standing out in the sun, while you drink your coffee.

Take Vacations

Switch off completely, and give your body and mind the rest they deserve. The break not only lets you rejuvenate physically, but also gives your brain the time to synthesize all the inputs it has, and come back with surprising ideas or solutions to problems that have been troubling you for a while.

The importance of taking a break is often forgotten, when we have so much to do. Honestly, I’m not very good at taking regular vacations, myself.

But, having a fixed time every year to take a vacation is something that I’ve seen working. For example, 2 weeks around your birthday every year, you can decide to take a vacation.

Do other things

We get into the game because we are really excited by the things we can build by flipping bits. We get so obsessed with it, that we lose ourselves in it, oblivious to the world outside. All the people we hangout with are people very similar to us.

Often, we are building stuff for people very unlike us. It’s very helpful to see the world from a different perspective than ours. Also, there is only so much we can express through code. There is a whole lot of us that can be expressed in other ways.

Pick up a team sport, do improv/stand-up, draw or paint, write, learn a martial art, join a cross fit gym – anything that you find interesting, other than writing code. Hangout with people who do very different things everyday than what you do. Their completely different perspective at life will make you a better programmer and a better person.

Avoid distractions

The internet can be so distracting! But, as developers, we tend to be constantly connected, leaving ourselves vulnerable to all this distraction. All these distractions can lead to very expensive context switches.

I’ve found getting into, and working in flow-states to be enormously satisfying. What I’m actually working on, doesn’t matter very much when I’m to deeply focus on something I want to be doing.

Creating an environment for yourself, where its easy to get into these states, is totally worth it. I’ve found using Pomodoros to be quite helpful, when I’m feeling distracted. Shutting off the Internet, or using a tool like get-shit-done helps with stopping myself from getting distracted by cat videos on the internet. Turning off all notifications on my phone and computer is another thing that is quite effective I also find it helpful to not be able to constantly have sight of the clock on my computer - so I work with all my windows full-screen. Leaving the phone in another room or in my bag works great, too. You can find a lot more tips on the internet, if these tricks aren’t up your alley.

If you see your team over-working themselves, and holding exhaustion as a badge of honour, please be the person to strike conversations around self care. Your team will thank you.

I’ve only listed down some of the things that I’ve found helpful. But, I hope this serves as a good starting point. Also, do take a look at selfcare.tech for more resources and advice.

Thanks Akilesh Mani and Shantanu Choudhary for reading drafts of this and giving helpful suggestions.

Software development practices for sports teams

Sun, 23 Sep 2018 11:31:00 +0530

Motivation

A few weeks ago, I came across a talk on Mob programming — a technique for working on a software project as a team, that was accidentally discovered by a team trying to figure out how to work well together. The speaker lets us in on how they stumbled on it, and how they fine-tuned it to make it more effective while being relaxed and enjoyable.

A few days before that, I shared a post on “getting feedback (as a software developer)” with my Ultimate Frisbee team-mates and it seemed to resonate with them. I’m often looking at things happening in my sports team from a software guy’s perspective, since I spend a lot of time being the software guy. But, I rarely, if ever, directly share these thoughts and ideas with my team-mates.

But, the mob programming talk inspired me to make a conscious effort to look for software development patterns that could be adopted by our (sports) team.

Most players on our team have been playing Ultimate for a while now (2-5 years). So, we have more problems due to miscommunication and everyone not being on the same page, than we have due to lack of skills or knowledge. When someone on the team does not understand the plan, the whole plan goes for a toss.

How do we make sure that everyone understands what the team is trying to do and is able to contribute their bit to the team’s plans and success? How do we make playing with each other as enjoyable as it can be?

“The object isn’t to make art, it’s to be in that wonderful state which makes art inevitable.” — Robert Henri

Some ideas for adoption

Here are some ideas that, I think, could be adopted by our team. Some of these are things that teams, including ours, do in some shape or form. But, identifying and naming would make it easier for people to talk about them and develop a common understanding of why and how to do them.

Ubiquitous Language

Eric Evans, in his book Domain Driven Design, talks about building a Ubiquitous language in the team. It grows as the team’s understanding of the problem grows, and helps the team communicate clearly throughout the development cycle.

Our team plays a lot of zone defense, and it usually works well for us But, it wasn’t working particularly well, during one of the tournaments last year. Luckily, we had Moby playing with us, and he asked us some probing questions around the objective of the play and the roles of each of the players. With just a short chat and a few small adjustments, the zone became way more effective. Essentially, we built a common understanding of the objective of the defense and brought everyone onto the same page.

Ultimate teams use a lot of lingo – a lot. New players just pick it up by osmosis, at practice, from the senior folks. This works most of the time, except when it doesn’t. Each person on the team has a slightly different understanding of what a term means, and the difference is sometimes big enough to cause a plan to fail due to miscommunication. Spending time building a common understanding would make the team communicate and operate more effectively. Practicing game scenarios is essentially a way of doing this, but it would be worth thinking about and discussing the terms and the language being used.

Off-field lingo should also be clarified using a similar process – for instance, what does “good sideline support” mean? What does giving or not giving “feedback on the field” mean?

Sprints

Agile development recommends continuous development of software. Often software teams use 2-4 week development cycles, called sprints. For each sprint, the team sets itself a goal, and the whole team prioritizes tasks and makes decisions in-line with this goal.

Sports teams would also benefit from sprints – short and focused practice cycles, where everyone on the team is aware of the team’s goal. This would make it much easier for players to help each other out. Also, players can align their individual goals with the team goal, making practices much more effective.

Retrospectives

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. — The Agile Manifesto

Most Ultimate teams do some kind of post-practice retrospectives, though, they don’t call it that. These retrospectives are a discussion of the good, bad and the ugly. Usually, no conscious decisions are made about what practices are working well for the team, and what should be taken forward to upcoming ones.

Slightly longer term retrospectives would be quite useful too. If a team adopts the idea of sprints, each new sprint should start with a retrospective of the last one and planning for the next.

A retrospective’s participants are expected to follow the prime directive.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. — Norm Kerth, Project Retrospectives: A Handbook for Team Review

Internalising this would be really helpful especially during post-tournament retrospectives, where emotions can run high – it would keep the discussion positive and focused on identifying problems and finding solutions, rather than spiraling into blame games, defensive arguments, etc.

Daily Stand-ups

Agile teams gather each day at the start of the work-day, to let each know about the progress of the work-items. The team tries to help each other get rid of the impediments to progress.

Ultimate teams could also benefit operating in this style – everyone shares with each other what they are working on, and the problems in their learning. This would make it easier for others to look out for things to help with. Team-mates would limit themselves to giving feedback to the thing that a player is working on.

Players setting themselves a small number of clear focus points would also force them to consciously think about and work on their game more effectively.

Face-to-face communication

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. — The Agile Manifesto

As our team has grown larger over the years, more and more communication has moved to the WhatsApp group. Keeping everyone informed via face-to-face communication, at this team size needs a lot of co-ordination and planning, and the time at practice is considered to be too precious to be spent talking and not practicing.

But, clearly WhatsApp doesn’t seem like the best medium to have discussions. Discussions rarely, if ever, happen on our groups. It often just seems to be information dissemination. Using a better communication tool could mitigate a few of these problems, but face-to-face discussions have other benefits. They bring about a greater sense of belonging to the team and increase buy-in into the team’s plans.

Unit tests vs. Integration tests

Practice games are helpful to gauge if a team is playing well together and if its plans are working. This seems analogous to integration tests — checking that we have functional software, end-to-end.

But, in the early stages of development, it’s common to write unit-tests – tests to ensure that each of the individual components works well in isolation. An analogous thing would be to have individual evaluations to help players identify weak areas, and to measure progress in those areas. It would also prevent players from slipping on important “indicators”.

Other ideas to think about

Some ideas that I find interesting, but don’t yet know if and how they can be adopted by sports teams are below.

Mob programming

In a mob programming session, everyone on the team is working on the same computer, in the same room, at the same time. This seems tremendously ineffective at the face of it, but turns out to be a good way to produce high quality software, quickly.

Hammock driven development

Bugs are incredibly expensive to be found and fixed in production software. They are cheaper to fix in the development phase. But, the design phase is the best place to fix them.

Rich Hickey recommends feeding a lot of information about the problem you are trying to solve to your waking mind, so that your background mind can feed off of it while you are asleep, and make useful connections.

Conclusion

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. — The Agile manifesto

This sounds exactly like what players in our team need too. The captains and the mentors in the team should work towards providing the environment and the support everyone on the team needs, and trust them to do the job.

Thanks Meghana Iyer, Ravitheja Tetali, Shantanu Choudhary, Vandith PSR, Varun Rangarajan and Vivek Krishnaswamy for reading drafts of this post and giving helpful suggestions.

Cycling from Manali to Leh - An FAQ

Thu, 26 Oct 2017 12:55:00 +0530

Table of Contents

So, you cycled from Manali to Leh?

Well, Not really. We cycled from Kalath to Whiskey Nala – a distance of 280km – which is about 60% of the Manali-Leh route.

Who is “we”?

Vivek and I were on the bikes. Shabu was our guide helping us fix our bikes and fixing up our meals, but more than anything else, ensuring that we don’t freeze to death. Susheel was driving along and cheering us.

How did you decide to do this?

Vivek and I were going to Coorg with Prats and Addy, and Prats told us a whole lot of stories of her adventures in the mountains. Not sure how bicycles came into the picture, but as soon as they did, both of us got really excited about it. This was on some sort of a bucket list for me, ever since I read Vatsap’s cycling story many years ago. Soon, after we were back in town, the ball was set rolling…

What is the maximum elevation you cycled to?

We started off at around 1.8km and went up to about 5km in a span of 5 days. We also spent a day in Manali, getting our cycles fixed and acclimatizing. You can see the elevation profile here.

How long did the whole ride take?

Our plan was to finish the whole distance in 7 days. We couldn’t get to our designated camp on the 5th day, and had to use the support car to get to camp before it got dark. We decided to end the ride once we took our bikes off the road.

Was it really hard? Why couldn’t you finish the ride?

We expected the primary challenges to be:

the altitude and lack of oxygen
the fatigue from riding day after day after day…

But, cold played a much bigger role than we thought it would. As we got higher and higher, it got so cold that we spent a significant amount of energy and brain cycles on trying to fight the cold, rather than enjoying the views or pushing ourselves to keep going despite the non-cold-related discomfort.

So, you do really need a support vehicle?

Not really, if you were riding in better weather or were better prepared. The Manali to Leh route usually has a lot of temporary shops setup during the season, where you could crash, if it was too cold to just crash in your tent. Since, we were going after the season had almost ended, many of these shops were no longer open, and having the support car turned out to be quite useful on the last day.

How much did the support vehicle cost you?

It turned out to be quite an expense for something we originally didn’t have in mind. We spent about 20k on the vehicle, fuel and the driver’s fee. We also paid our guide + cook + bicycle expert, separately.

Did you carry your own bikes?

Yes.

Flew from Bengaluru to Delhi
Took a bus from Delhi to Manali
Carried the bikes on the support car from Whiskey Nala to Leh
Flew back from Leh to Delhi

Did the flights charge you for the bikes?

The carrier (IndiGo) from BLR to DEL charged us a handling fees of Rs. 1000. The carrier (Vistara) on the return journey didn’t.

You could find bikes on rent, both in Manali and Leh, for about 500 to 700 per day. It would cost about 5-7k, based on how you plan your ride, to rent a bike. You’ll have to make arrangements to get the bike returned back to the place you rent it from – this can get a little tricky.

If you already own a bike, and can it packed in a proper box, I would highly recommend that. The derailleurs, the shifters, and other such moving parts need to be well packed and guarded. Use a box or a cycling bag to put it in. Get professional help from a cycle retailer nearby, if required. This is one thing you cannot take any chances on, or your whole trip may be jeopardized!

We hadn’t paid enough attention to packing our bikes, and one of our bikes took quite some beating on the way to Delhi. On the way back, we managed to get the bike packed in a box and it was a breeze.

What cycle spares/tools did you carry?

We were sort of ill prepared in this department. We only had the following:

Hand pump
Puncture kit
Spare tubes (2 nos.)
Allen key set

Based on advice from Shabu, I think you should also take these things:

Brake cables
Gear cables
Spare tyre (1 Nos.)
Brake shoes/pads
Few spokes
Chain oil

What sort of preparation did you do for this ride?

We did a handful of 50-100km rides on weekends before this one. The only real elevation training/trial that we did was the Kalhatti climb, one weekend before this ride. This turned out to be pretty useful, and we found all the other climbs during this ride much less steeper than some of the Kalhatti ones.

What we actually rode

Day	Start	End	Distance	Elevation gain	Comments
0	Kalath	-	-		Fix cycles and acclimatize
1	Kalath	Marhi	45km	1675m	Prepare to cross Rohtang!
2	Marhi	Keylong	80km	-210m	Crossed Rohtang (3970m)
3	Keylong	Patseo	48km	+644m	Easy ride; Deepak Tal!
4	Patseo	Sarchu	64km	+522m	Crossed Baralachala(4902m)!
5	Sarchu	Whiskey Nala	48km	+465m	Gata loops & Nakeela(4924m)

Original plan

Day	Start	End	Distance	Elevation gain	Comments
5	Sarchu	Pang	73km	+225m	Gata-loops, Nakeela(4924m) & Lachung La(5065m)
6	Pang	Lato	103km	-530m	Moore Plains, Tanglang La (5328m)
7	Lato	Leh	70km	-600m	Lots of downhill!

What was a typical day during the trip, like?

Wake up between 7 and 8, depending on when you can see/feel the warm sun. Laze in bed if you woke up too early, and the sun hasn’t yet warmed the place up.
Eat porridge, and a few slices of bread with peanut butter.
Pack ourselves up in as many layers of clothing as we can, while still being able to pedal.
Check the bikes for any loose/fallen-off/broken parts, blow, etc.
Start pedaling away - usually between 9 and 10. It’s too cold to start earlier. Keep adjusting the clothing, based on how cold/warm it is, and the wind chill.
Keep munching, or sipping on some water (plain or mixed with some energizer).
Continue pedaling, and start looking at the milestones a little more carefully. Lunch is on our mind, already.
Lunch at around 1:30pm - usually, a couple of boiled eggs, and a potato. May be a chocolate, and some Frooti.
More pedaling. The kilometers start getting harder, the chill is getting harsher.
Huff and puff, and reach our camp for the day. Hi-fives! We’d try and reach the camp while there is still some sunlight there to keep us warm.
Stretch it out, and switch into dry, warm clothes.
Grab a quick snack - whole packets of biscuits would just disappear, alongside some tea.
Talk, walk around, ponder about life, think about the day that’s been, think about the day that is to come, and all that jazz.
Eat dinner - dal and rice, mostly.
Sleep like logs. Unless, there’s a rat in the room that’s attacking our dry fruits.

What was the most enjoyable part of the ride?

I really enjoyed sitting at Deepak Tal, and just looking at the clear water
The climb to Baralacha La was the most challenging part of the ride. We could see that the weather was really bad in all the peaks around us, and it was getting really cold. Briefly, it was even snowing very lightly and we could see tiny snow flakes floating in front of us.
The feeling of reaching the top of passes was quite thrilling, for both Rohtang and Baralacha La. Nakee La, not so much, since we still had about 30km ahead of us to finish the day.
It was humbling to see all the BRO folks working to keep the roads open and functional! A big salute to them!
Each time we had a truck or some bikers pass by, we would wave at them or show thumbs up, and it would give us some additional energy to keep pushing ahead.
The tree covered road in Sissu was just mind blowingly beautiful, with all the trees golden and yellow, preparing for the fall.
It was also nice to turn 30, in the hills. Vivek tried to make it as special, for me, as he could.

What was the most challenging part of the ride?

The cold. (See, the answer on why we didn’t finish the ride).

You keep saying it was cold, how cold was it really?

On the night we camped at Sarchu, the water in our bottles and unwashed cups had frozen. We had gone to sub zero temperatures on many nights, it looks like. The winds during the day were quite chilly, and got worse as we gained altitude.

Did you meet any interesting people en-route?

We met a guy from Slovenia who has been taking a couple or so months off for the past 10 years. He was riding around with a 55kg weighing bike for the past 3 weeks, and was going from Leh to Manali, when we met him. He had a lot of stories to tell – including recommending that we go cycling in Iceland, and enjoy watching the Northern lights from hot water baths.
Shabu himself had a lot of stories to tell about all the people he had taken on this ride - from guys with a $6k bike to a 70 year old doing the route his 4th time to the guy who would eat only olive oil mixed in rice to safeguard his tummy, and more!
All the aachos and aamas in the shops/guest houses/etc that we went to were really nice to us. Most of the folks in the shops were planning to leave in a few days after we had met them since it had gotten really cold.
We had our camp-site at Marhi in the compound of a HP state guest house. The care taker walks up to us, while we are setting up the tent, and says, “Idhar kahi par bhi baithna mana hai, 10 hazaar ka fine lag jaayega. Udhar toilet bana hua hai”, pointing to the public toilets in a distance, “paisa nahi lagega”. We had a good laugh, and ended up wondering if it was Swach Bharat showing some effect.

We probably would’ve talked to a lot more people, and met a lot more interesting people, if we were there in better weather and didn’t have a support vehicle taking care of us. Next time!

Would you do this again?

May be. We feel like we got a taste of the challenge of the ride, and the rest of the route wouldn’t be anymore challenging than what we already saw, if we did it in better weather. But, the better weather would also mean more traffic and noise on the road.

If yes, which part of the year would you do it?

Late August to mid-September might be a better time. We’d also need to look out for rains and land-slides, though.

If not, what other routes would you try?

Cycling around Europe sounds like a fun thing to try
Rides in the western ghats and/or Kerala seem promising
A Tour of Meghalaya was something a friend suggested
Pushing that a little more, ride all the way to Singapore/Indonesia, starting at home

You can find some pictures and videos here. The album also includes some pictures from our practice rides.

Google Trends, Clickbaits, and PV Sindhu

Sat, 20 Aug 2016 22:59:13 +0530

TL;DR

Am I saying India doesn’t have a caste problem?

No, it’s definitely a HUGE problem!
Are these articles on Google Trends and Sindhu’s caste useful at all?

Just more click-baits and no useful contribution to the discussion on caste.

First of all, congratulations to PV Sindhu on making it to the finals and giving the world number one a hard fight!

This post, though, is not a celebratory one. I read this article – While PV Sindhu fought hard for a medal, many Indians googled her caste – by the News Minute thanks to a re-tweet by TM Krishna. I probably wouldn’t have paid much attention to it, if not for the retweet by TMK.

Caste is a huge problem for the country, and if you still like to pretend it isn’t – read this for a start. I’m not surprised that some people searched for Sindhu’s caste while she was battling it out at Rio. But, some people also searched for Badminton rules, and others for Sania Mirza! What surprises me is that the article doesn’t try to put the data in a context at all. Nor do I understand the contribution this article makes to the discussion on caste.

I played around a little more with these search terms and Google Trends, and here are a few things that I thought were worth sharing.

Indian trends

First of all, the article says “Many Indians”, and gives off cumulative month-wise numbers (UPDATE [2016-08-21 Sun 12:15]: which are so wrong! See Sankrant Sanu’s excellent article on India Facts). But, what does it really mean?

I don’t know if anybody actually wrote about how many people actually followed the match, but Sindhu actually managed to get a whole lot of people interested!

More people searched for PV Sindhu than the daily average number of searches (not hits) for Facebook and very close to the daily number of searches for Porn – two of the biggest things Internet is allegedly used for. Can you see the red line at the bottom? That is the number of people who actually searched for Sindhu’s caste – a tiny blip.

Let’s take a closer look. Here’s a plot of some of the other auto suggest terms + badminton rules & courts compared to Sindhu’s name.

Nothing other than badminton rules (which is at about 1% of max. searches) is even visible, clearly.

So, these other terms (wiki & caste being auto-suggested ones) are nowhere near the actual number of searches being made for PV Sindhu’s name alone.

Let’s get rid of the name graph to get a closer look at the other terms.

The maximum number of people searching for Sindhu’s caste is at about a fifth of the maximum number of people searching for badminton rules. Interpreting it is upto you. But, I’m not surprised knowing how significant caste has been in our society. Also, notice that searches for wiki and caste fall off more gradually than the searches for the rules which peak while the game is being played and watched.
Unsurprisingly, a bulk of the searches appear to be coming from Andhra and Telangana. Notice that the other states are searching more for the rules or her wiki page.

Do you notice that the red (caste), blue (wiki) and violet (images) lines following a similar trend, until the last few hours? What do you think is happening there? It’s the shitty click baits working! Look at the trends from ~8:30AM to ~12:30AM below – the red has spread to other states as well!

And this is how it looks by the evening (17:00-21:00). Well done, folks! The click bait articles totally succeeded!

If you are wondering how much effect the auto suggestions are having in suggesting people to try searching for caste, I don’t think that is much because wiki and images are the other auto-suggest terms, with no such surges in the number of searches.

Trends from the Telugu states

We could see that the two Telugu states were more worried about the caste, than the rest of the country. Let’s see how abnormal they are.

You can definitely see the red line more prominently. In case of Andhra the peak searches for caste are at about 5% of the name searches. A statistically significant difference from the rest of the country.

Let’s zoom in at the auto-suggest terms alone.

Woah, Andhra is definitely quite an aberration from the rest of the country. From about 1/5th of the maximum number of searches for rules, the maximum number of caste searches jumps to about twice. Telangana also is different, but much less so.

Tamil Nadu’s trends below for comparison. You can’t help noticing the last few hours, can you?

NOTE: The trends and screen-shots for the states are slightly more recent than the others.

Conclusion

Without a context, I don’t really see the point of these “news” articles. It seems more click-bait-y than useful to me.

If you still feel many Indians were searching for Sindhu’s caste, while she was fighting it out, go ahead and play with Google trends here. Add/remove terms, change the time and location filters. Some terms that could be interesting to add to the comparison are: Kashmir, Independence day, Facebook.

Later, I looked at the search results and then found that this article wasn’t the only one like it. I didn’t bother to read the others, but I really hope at least some of them are talking sense. Is any of them really trying to contribute to the discussion on caste, meaningfully?

Also, the actual search results don’t seem to give useful answers to the folks so curious about Sindhu’s caste. I hope none of these articles are trying to help them out.

Finally, if you are using Google Trends to write an article, Danny Page has some really good advice.

Thanks to Kamal, baali and 9 for reading and reviewing drafts of this. Errors mine, obviously.

I love FOSS. How do I start contributing (code)?

Mon, 28 Mar 2011 00:34:00 +0530

Why this article?

I teach (Science and Engineering) students and teachers to use Python for their computational tasks. I’m occasionally asked this question or something similar. I remember, it was not too long ago, that I asked this question very often. I asked anybody who was more experienced than me, “How do I start contributing (code) to FOSS?” and all the answers I got, were very similar. Also, my answer is not going to be radically different. But, I would still like to answer this question, because -

All the answers I got, were from big-time, experienced contributors. I suspect, they only vaguely remember how it feels to be just starting off. But, I am just starting off and I think my answer brings a slightly different perspective that would help others¹.
This piece of writing is meant to be one comprehensive compilation of things I want to share, if and when I’m asked this question in the future².
More than anything else, a reminder and reference for myself. I still have a long way to go. I only have a handful of contributions against my name (none of them earth shattering). I haven’t (yet) done my 10,000 hours of programming nor have I learned anything like half a dozen programming languages.³

Thanks to baali, Ringo and Voodoo for reading drafts of this article and giving some very valuable feedback to improve it.

What should I do?

I know how exciting the FOSS world seems, the first time we discover it. You are dying to contribute. You want to contribute, Right Now! But you’ve no clue, what, where and how. Relax. Give yourself time. You’ve a lifetime ahead of you. Explore. Explore, even more. Play with things, Try out stuff, Break stuff, Spill things all over the place. Have fun!⁴

Given that you are reading this, I presume that, you do have access to the Internet. But, if you don’t, it could turn an impediment to your goal. Easy access to a decent internet connection is a prerequisite.

Learn a programming language, well³. By learning, I don’t mean getting familiar with the syntax or passing a bunch of exams. Get familiar with the paradigms of the language. Learn to think in that language. Write code that does something real, instead of doing toy examples.⁵ Also, it helps know bits and pieces about the history and evolution of the language. This will give you a sense of why some features are present (or absent) and will help you program better, in that language⁶.

Some projects will definitely catch your eye, while you are exploring. Start using the ones that you need. Follow them!

Start with using the bleeding edge ⁷ software. Bleeding edge refers to the latest sources of the project, where the active development is going on. Given the continuous nature of software development, using the latest source,

prevents you from wasting time on fixing bugs that have already been fixed and
lets you look at the latest changes being made and contribute effectively and easily

Also, start following the project’s mailing lists – both the dev and the user lists, if they are separate. The user-list discussions will help you discover functionality and possibly give you some chance to peek at the source code, too. Don’t be surprised or worried if you don’t follow most of what goes on, in the dev-list. Be patient and keep at it. You will learn a lot about the what, why and how of the project. Also don’t be afraid to look foolish there! There wouldn’t be one developer who doesn’t have some embarrassing logs of stuff she said in public, in her initial days.

Slowly you’ll start to learn the dynamics of the community – how things function, the DOs and DON’Ts, etc ⁸. Also, there’s a good chance that the project has an active IRC channel. If it does, hanging out there will give you more insights. Contributing to the documentation, is often a useful step before contributing code. Cleaning up the documentation or writing documentation, often requires you to read the code and helps you understand it better.

Next, start acting on Bug reports (or tiny feature requests). Start with trying to reproduce the bugs and sending confirmations. Gradually, start looking at the source and trying to figure out where the problem is. Be patient, with this ⁹. Once you get comfortable with the code and the coding style, start sending code snippets and comments, explaining what you think might be the problem. One fine day, you will be able to send a full working patch! But, before that don’t hesitate to send partial fixes. You can learn a lot from the comments of the devs and looking at how they finally fixed it. Also, IRC could be a good place to ask for help, if you are stuck and are looking for some quick help, so you can move further.

In all of this, it helps if you have one (or a bunch of) favorite area(s) or module(s) of the project, specially in a big project. You should pounce upon any issues in your favorite area.

Participate in sprints. It’s not uncommon for projects to have regular sprints. Make it there ¹⁰! Also, a couple of developers may decide to meet up on a weekend and hack. If it’s happening in your neighborhood, ask if you can join. Don’t be surprised, if they shout out a big YES! You will definitely learn a lot, when there is help so close-by.

A shortcut would be to start your own project! It is easier (in some ways) to release your own code under a FOSS license, than contribute to some of the existing projects. You don’t have to have your code approved by the project leads, you don’t need to mould your code to fit the standards of the project, you don’t have to read and understand all the (relevant parts of the) existing code, etc. But all of this, definitely teaches you a lot.

As a beginner, I think it is important to solve your own problems, problems that you care about (at least at that point in time). Most of the projects, started off with their developers wanting to solve their own problems. Only, incidentally, they solved some of the World’s problems, too!

Start small, though. Don’t start off with a project that aims to replace Chrome or Firefox as the best browser, or an editor to replace Vim or Emacs. Writing extensions to your favorite software could be a good place to start, for instance an Emacs minor/major mode¹¹, a Chrome extension¹², etc. Stand on the shoulders of giants!

Also, take this as an opportunity to gain some of the skills that would be useful, when you want to start contributing to others projects.

Learn to use Version Control (Git + GitHub is awesome!)
Learn to use build and setup tools.
Learn about packaging and distributing your software.
Learn how to license your code.
Learn to Collaborate!

All of this, I hope, would suffice to get your first contribution in. But, there are a few things that will help you in the long run.

Good English. Specially written communication, since that is how you would be communicating, more often than not. Fair or not, hackers are known to be very particular about good communication. I’m not exaggerating when I say, what you say may be ignored even if it makes perfect sense, if you said it in sloppy English.

Using a *nix would put you in some great company. At the very least, you save time when looking for solutions to known problems. Using a good editor and learning to type quickly can be big productivity gains. You only get 24 hours a day!

An understanding of licensing issues, can come in handy, many a times.

For more, read How to Become a Hacker by Eric Raymond.

Happy Hacking!

I’m writing in the Indian context. ↩︎
All of this is generic advice, but students applying to programs like GSoC, may find it useful. ↩︎
Teach Yourself Programming in Ten Years by Peter Norvig. ↩︎ ↩︎
Getting yourself a GitHub account and socializing there is a lot of fun and helps quite a bit. GitHub is my Facebook! ↩︎
I started learning Python from the Python tutorial and some other sources and doing the examples in them. It was good, but I think I started learning more, and better, when I started solving problems from Project Euler. And writing an IRC bot in Python, taught me a lot more than all of this. ↩︎
I recommend Python, but I am definitely biased. Any language that is generic enough would do, really. 1. It gets you off the blocks, very quickly. 2. It is easy to learn. 3. It is batteries included. Read as, comes bundled with a huge bunch of libraries. 4. It is general purpose enough. Read as, it has libraries that let you do anything, you’d possibly want to do. 5. There’s a lot of Python code around, that you can read andlearn from. ↩︎
You may have to learn to use a version control system; at the very least cloning and pulling updates. ↩︎
Org-mode is the only project that I really contribute to, actively. I really liked the way the community gels together and the kind of people on the list. There are some really knowledgeable, friendly and helpful people. It feels great to be a part of the community. ↩︎
There have been instances, where it took me half a day to fix something, that would’ve been fixed in about an hour by someone more comfortable with the code. But, I think everybody goes through this stage. This is how you learn. ↩︎
A few months ago, I was part of a sprint on the numpy-scipy eco-system. We had somewhere around 50 patches (a lot of them were documentation fixes) submitted to all the projects! Most of the people were submitting their first patch and I think it was a great opportunity for them to start. [I should try and get back to them.] ↩︎
Org-mode is really awesome, and I use it for everything I write. Blog posts are a big part of what I write, and so, I wanted to write them in orgmode. And so, org2blog was born. ↩︎
I recently wrote a Chrome extension, thanks to a friend’s idea. Inspired by Gmail notifications, a GitHub addict wanted notifications for activity in GitHub. ↩︎

Favorite posts on Noetic Nought

Why my Elfeed index was 0 bytes

The breadcrumbs

write-region and O_TRUNC

Emacs has backup files, doesn’t it?

The fix

An offline-friendly Elfeed web UI

Why bother with RSS feeds?

Why Emacs and Elfeed?

Why Elfeed offline?

How does it work?

Why OCaml?

How can you use it?

Outro

An innocent query that caused Zulip downtime

Introduction

What is the pointer?

Why change this?

What did we change this to?

UserMessage table is huge, my friend

How did we fix this?

The tools we build change us

Been there, done that, and still doing it!

Corrupted a server’s hard-disk

Almost Deleted 7-8 years of email

Learning from screw-ups

Self-care tips for new developers

Take breaks

Hydrate, Eat and Sleep

Invest in a good set-up

Sunlight & Exercise

Take Vacations

Do other things

Avoid distractions

Software development practices for sports teams

Motivation

Some ideas for adoption

Ubiquitous Language

Sprints

Retrospectives

Daily Stand-ups

Face-to-face communication

Unit tests vs. Integration tests

Other ideas to think about

Mob programming

Hammock driven development

Conclusion

Cycling from Manali to Leh - An FAQ

So, you cycled from Manali to Leh?

Who is “we”?

How did you decide to do this?

What is the maximum elevation you cycled to?

How long did the whole ride take?

Was it really hard? Why couldn’t you finish the ride?

So, you do really need a support vehicle?

How much did the support vehicle cost you?

Did you carry your own bikes?

Did the flights charge you for the bikes?

Would you recommend me to carry my bike?

What cycle spares/tools did you carry?

What sort of preparation did you do for this ride?

Can you share your ride plan?

What we actually rode

Original plan

What was a typical day during the trip, like?

What was the most enjoyable part of the ride?

What was the most challenging part of the ride?

You keep saying it was cold, how cold was it really?

Did you meet any interesting people en-route?

Would you do this again?

If yes, which part of the year would you do it?

If not, what other routes would you try?

Do you have any pictures that you can share?

Google Trends, Clickbaits, and PV Sindhu

Indian trends

Trends from the Telugu states

Conclusion

I love FOSS. How do I start contributing (code)?

Why this article?

What should I do?

`write-region` and `O_TRUNC`