Unfortunately, my comeback article is not going to be even remotely related to anything else I’ve previously written about. Its not even in the same ballpark.

I’ve always been a fan of constitutional law — so much so that if you could somehow access my searches on Wikipeida, you’d mostly see articles about landmark Supreme Court cases — whether from India or otherwise. The reason I’m specifically interested in just this single branch of government is because in many ways, it represents something very different from the other two branches of government. The legislature is supposed to respond to the will of the people. The executive is supposed to implement the laws passed by the legislature — within a measure of discretion.

But the judiciary is not an elected body — at least not in the same way that the legislature and the executive are. It is supposed to be insulated from the political process. It is supposed to be able to make decisions based on the law and the constitution, not on the whims of the people. This unaccountability(to the people, at least directly) makes the Judiciary perhaps the only forum that can meaningfully expand minority rights.

And the presence of an anti-majoritarian judiciary is perhaps the only way to balance the other two majoritarian branches of government.

And that is the case with the “Right to Die”. We have a majority who either ignores or actively approves penalizing those who’re already on their deathbed. It chooses to criminalize the act of dying — instead of ameliorating the terrible conditions these people are in, it chooses to prolong their suffering. It sentences them to a life of pain and misery — all while pretending to be a champion of human life.

Right to Life

We all have the right to life. What this means in practice is that you should be able to live your life as you please — so long as you don’t infringe on the rights of others. As long as you’re not convicted of a crime and are not otherwise restrained by the law, the government can’t detain you or otherwise restrict your freedom.

But the right to life doesn’t and should not mean “duty to live”. Right to life means that you should be able to live as you so please. If you decide to lock yourself in a room and refuse to come out, the government can’t order you to leave the room and “live” your life. Forcing someone to do something they don’t want to do is antithetical to the very pretext of this action — the right to life.

And so the argument flows — if you can’t force someone to live the way you determine is best for them, then you can’t force them to live at all. If someone wants to end their life — so be it. You cannot put a gun to their head and force them to live. Right to life isn’t really about living — it’s about the right to choose how to live.

The right to life grants freedom from state control — it is not a mandate for state-enforced existence.

Imagine this: if you don’t like the city you live in, you can simply move to a different city. You can choose to live in a different country. But what happens if you don’t want to live at all?

Or perhaps a more direct example: if you’re being treated for a disease, do you not have the right to refuse treatment? What if the rejection leads to your death? Does that mean the state will force you to accept treatment?

At what point do you accept that its your life and the state is not its arbiter?

Elizabeth Bouvia

Killing yourself might seem extreme. The idea of people — en-mass — killing themselves might seem even more so. But what’s actually extreme is the idea of forcing someone to live against their will.

Elizabeth Bouvia was almost completely paralyzed because of cerebral palsy at the age of 24. She wanted to die. She chose to end her life.

Instead of letting her die in peace, the hospital was extremely hostile and combative. When she refused to have food, the hospital staff forced a tube down her throat. She sued but the court ruled in favor of the hospital. In protest of this decision, she bit the tube so hard that it broke.

Following this, four attendants would hold her down while the tubing was inserted into her nose and liquids pumped into her stomach. She screeched and shouted but to no avail.

This is what the crowd against the right to die wants to force upon you. They cannot and will not help you when you’re alive. They don’t care about your life — far from it.

They will literally tie you with chains and force feed you — while in the same breath explaining how good life is, and how you should be grateful for it.

But why die?

This is perhaps the question that most people would ask when they hear about the right to die. Why would anyone want to die? Why would anyone in their right mind want to end their life?

But to even attempt to answer this question is a fallacy. A blanket statement that assumes that everyone wants to live is not only wrong but also harmful. The statement fails for a couple of reasons:

1. It ignores the fact that there is no consent in the act of birth. Unlike the act of dying — which employees the consent of the individual — the act of birth is not a voluntary act. No one chooses to be born. They simply are.

2. Death is(or should be) a choice. Individuals who are terminally ill often choose to end their lives rather than prolong their suffering. This is not them escaping from reality — it is them accepting the reality of their situation and choosing self respect over self denial.

Engaging in ideological quibble about what recoginizing right to die would mean for the society at large is a waste of time. The very purpose of having rights is to protect individual freedoms — not to be at the whims of what society deems is best for you.

The law

As things currently stand, a host of countries have legalized Active voluntary euthanasia — that is, individuals can consult their doctor and get a prescription for euthanasia. This includes countries like Canada, New Zealand, and Switzerland. The right to die isn’t absolute — in most these countries, there are strict guidelines and regulations that apply to the act of euthanasia. But the fact that it is legalized is a step in the right direction.

In countries like India, passive euthanasia is legalized — that is, you’re legally allowed to refuse treatment, even if it will lead to your death. The difference being that in such countries, you cannot actively seek euthanasia.

As you might’ve already guessed, in most of these countries, these rights came along because of the way the judiciary interpreted the right to life. In fact, India’s recognition of the right to die came much earlier than you’d expect. In 1994, The Supreme Court of India struck down Section 309 of the IPC that criminalized suicide.

This decision was eventually overturned in 1996, but as they say, the arc of history is long but bends towards justice. In 2018, the Supreme Court of India legalized passive euthanasia. Suicide is no longer a criminal offence in India.

Conclusion

None of us chose to be here. The fact that you’re reading this is not a consequence of your own choices but rather the result of the choices of your parents. I think its only fair that we should be able to choose how we want to leave this world.

This is not about glorifying death. I’m not here suggesting that we should all rush to the doctor and get a prescription for euthanasia. But if someone truly wants to end their life — for whatever reason — trying to stop them will cause more harm than good.

Long live the right to die.

The 180

There was a time when I was quite active on social media, especially Quora and Reddit. I would argue day and night with people about politics, religion, and every other controversial topic under the sun. I was eventually banned from Quora after I became popular in a few spaces. I knew this would happen one day — India’s political climate is not exactly known for its tolerance of views that differ from the mainstream — so it was only a matter of time.

I was angry, I was frustrated and perhaps most importantly, I was powerless. But I still believed in standing up for what I believed in.

Not anymore.

Not because I think I was — or am — wrong, but because I’ve become the very thing I hated and chastised. I have become a hypocrite. While I can tell right from wrong, I’ve lost all the courage it takes to actually state it out loud.

And the weight of that hypocrisy is unbearable. But it’s also protective. When you live in a country like ours, you realize that the only way to stay safe is to keep your mouth shut. It’s unfair, it’s selfish and it’s a million other deplorable things but at what point do you accept that the country is destined to hell? That you are just a passenger on a bus heading straight for a cliff?

You can either scream at the driver or sit quietly, close your eyes and hope for the best. I chose the latter.

They say that ostriches bury their heads in the sand when they are scared. That is false. It is us humans who do that.

Where to draw the line

This is something I’ve been grappling with for a while now. True — self preservation is important but at what cost? Today, I’m ignoring the problems of people I have never met and will never meet. It’s easier to sleep at night when you don’t know the faces of the people you are ignoring.

But what happens when the faces start becoming familiar? What happens when the target isn’t a distant silhouette but someone you’re close to? This isn’t even about politics anymore — say a co-worker of yours is being mistreated at work. Do you ignore it because it doesn’t affect you? Or do you speak up and risk your own job?

I want to say that I would speak up. I want to say that I would stand up for what is right, even if it means putting myself in danger. True — the consequences of standing up to a mean boss are less severe than standing up to a rogue government — but even so, the fear is real. The fear of losing your job, your livelihood, your security. It’s a fear that is all too real for many people in today’s world.

I’ve always convinced myself that these two situations are different. That I can ignore the politics because it doesn’t affect me directly. But the truth is, it does. It affects all of us. And by ignoring it, I’m only making it worse.

I don’t know what the answer is. All I know is that we’re all part of the problem.

Why isn’t anyone talking about it?

Why are we all so afraid to speak?

Is it because we don’t want to rock the boat — or because deep down we know we’d be the first ones thrown overboard?

Conclusion

I wish I had a neat, inspiring conclusion for this. But the truth is, the more I think about it, the more confused I become.

Maybe I’m too small a fish for any of this to matter. But that doesn’t make it feel any less real.

For now, I’ll keep doing what I’ve been doing: stay quiet, stay safe, and hope that when I finally come out of this self-inflicted coma, the world will be a little better than the one I closed my eyes to.

People say ignorance is bliss. I don’t know if that’s true.

But I do know that ignorance is safe. And in a world where safety is a luxury — I’ll take it.

Rules are meant to be broken

I’ve never been one for rules. You tell me I’m not supposed to do something without giving me a good reason, and I’ll do it just to spite you. Especially if you’re someone who’s in anyway above me in the social hierarchy — be it a teacher, a boss or even a parent. I’ve always had a problem with authority and have been a rebel without a cause for as long as I can remember.

I have been in trouble more times than I can count for breaking rules. I’ve been kicked out of the class for talking back to the teacher, I’ve been put in front of a whole school assembly for not saying the morning prayer and as I wrote about in my last post, I’ve been refused a job for having the audacity to expect my boss to treat me like a human being.

But I’ve never regretted any of it. I’ve never regretted standing up for what I believe in, even if it meant breaking a few rules along the way. Is there a way to register your protest without breaking the rules? Sure and I always try to do that first. But remember — the rules were designed by the very people you are protesting — they were designed specifically to protect the status quo.

I don’t wish to harp on my previous post, but I think it’s a good example of what I’m talking about. I tried to raise my concerns through the official channels, but they were ignored. So I did what I had to do. I did the silliest of things to annoy them. I turned everything into a spectacle and made sure the entire office knew that it was my last day.

Did it change anything? Obviously not. But I’ve realized that the best way to annoy authority is by making them feel completely powerless over you. You cannot — you literally cannot — argue with someone who refuses to listen.

The one rule to rule them all

But despite what I said above, there is one rule I have always believed in. One rule I refuse to break. And that’s to never punch down.

I think my feelings about it can be pretty much explained by this Dumbledore quote

“Youth can not know how age thinks and feels. But old men are guilty if they forget what it was to be young.”

– Albus Dumbledore, Harry Potter and the Order of the Phoenix

This quote might be about age but it maps to everything really — if you’re reading this, I imagine you’re relatively well off. Answer this — have you ever lost temper or spoken rudely to someone who was in a lower social position than you? Maybe a waiter, a janitor, a security guard or even a junior at work?

I’m not here to judge you. I’ve done it a handful of times you — we’re all human after all. But every time I’ve done it, I’ve tried to make amends.

This is not to say don’t fight back. Just make sure you’re fighting with someone who can actually take a punch. Even when you’re right, what use is it to fight with a waiter who’s just following orders? Or a delivery boy who’s just trying to make a living?

I end this post with another quote from Harry Potter. This time from Sirius Black

“If you want to know what a man’s like, take a good look at how he treats his inferiors, not his equals.”

– Sirius Black, Harry Potter and the Goblet of Fire

I think that’s a good rule to live by. And I hope you do too.

Truth is a curious thing. It’s not always what you want to hear. It’s not always what you want to say. But it’s always there — lurking in the shadows, waiting to be told by someone — anyone — with just a shred of integrity.

So here I am

Summary for those in a hurry

There’s a reason I’ve added a redirect to this page from https://thetrio.dev/rant — because it is in fact a long and rambling rant.

So for those in a hurry, I’ll summarize the whole thing — I was an intern at Autodesk for the first 6 months of 2024. Unfortunately, things didn’t go as expected with me being thrown into a project without a technical mentor.

I had no one to answer my questions and my superiors either gaslit me or straight up mocked and chastised me for every little thing.

I broke down several times in the office, and countless more times at home. I was left feeling like I was the problem — that I was the one who was incompetent and not cut out for the job.

Thankfully, I had plenty of support from the rest of the interns and several employees aware of my situation.

But no one — not one person — in a position of power did anything to make things better.

Now on to the whole story. Because believe me, it gets worse.

A lot worse.

How it happened

Autodesk visited our college for campus placements in October last year. I had to clear an online test and 3 rounds of interviews but within a few days, the fate of my next 6 months was sealed — I was going to be in the Autodesk Pune office from January 8, 2024.

Early Days

The first few weeks were all about meeting the interns and everyone else at the office. To say that my first week was packed with social events would be an understatement — I frankly cannot recall a single day in that week when I didn’t go out. Be it having a dinner with all the managers, visiting the nearby mall with a few interns, or having the flagship annual Autodesk party at Conrad. The first week was the best start I could’ve hoped for — no work pressure and all the time in the world to see so many new faces.

Little did I know how downhill it would go from there.

The Work Begins

With everything settled after the first week, I was finally hoping to get to know exactly which team I would be working with and what I would be working on. Fast forward to 3 weeks later, and I’m still as clueless as I was on the first day. All I had been told was that there were two teams I could be a part of and that because of some constraints, I would have a different acting manager than the one I was supposed to have.

Now here’s the deal — in all these 3 weeks, I was left completely alone. No scrum meetings, no standups, no nothing.

I was told I would be assigned a mentor/buddy who would help me get started but that never happened. When I pointed this out to my acting manager, he simply said that he was my buddy. And he proceeded to give me a task that was so vague that I had no idea where to even begin. There wasn’t any JIRA about it, we didn’t even have a meeting to discuss it. I was just sent a Slack message and that was it.

But I was determined to make the most of it. I started working on the task and within a few days, I thought I had made a breakthrough. But to test it out, I needed to push the code to the repository. And that’s when I found out that I didn’t have access to do that. I asked my acting manager about it and he said he would look into it.

I didn’t get the access for another month.

The Scrum

I was however finally assigned a team and had daily scrums. I thought this would be the turning point — sure, my acting manager was too busy to help me out but at least I would have a team to guide me.

That wasn’t to be.

The tasks that I was assigned were created by my acting manager and no one on the team had any clue about them.

I think I made fairly good progress on these tasks given that I was working alone and only had my acting manager — who wasn’t that technical — to discuss it with. But sooner or later, I knew I would hit a roadblock. And when that would happen, I would have no one to turn to — not because people weren’t willing to help but because my work was so isolated that no one else could be of any help unless they were willing to spend hours googling the same things I was. Which is too much to ask of anyone who isn’t your mentor.

And that’s exactly what happened.

Cry for Help

By this time, more than half of my internship was over and I had nothing to show for it. It was the end of March and my Github contributions looked the same as they did on the first day — empty.

Without anyone with whom I could bounce ideas, I was stuck, always second-guessing myself. Not only that, I was also starting to wonder if these tasks were even feasible — and even if they were, were they worth it? And soon, I hit a wall. This time I couldn’t even see a way around it.

But fortunately, a few people took notice of my task and offered to help. The irony of course was that they weren’t on my team — they weren’t even based in India. But they were willing to help and that meant the world to me.

I got on a few calls with some of these people and we spent hours trying to figure out what was wrong. It took us a while — like I said repeatedly, these tasks weren’t trivial, certainly not for an intern — but we finally managed to get it working. I was ecstatic — I had finally made some progress.

But that was short-lived.

We soon discovered another issue - and this wasn’t something we could work around. Fixing it would involve updating a dependency for a core service used by the entire company. No way was that going to happen in the time I had left. I tried to point this out to my acting manager but he didn’t seem to understand — he seemed to think that I was just making excuses.

In the end, I ended up convincing him by showing him my conversation with a Principal Engineer based somewhere outside India — one of the few people who had helped me out.

He finally agreed to let me work on something else. With barely a little over a month left in the internship, I was quite nervous knowing that what I had worked on for the past 4 or so months was not even completed — but I hoped against hope that my sincere efforts in trying to see this through wouldn’t go unnoticed.

How wrong I was.

The Interview

I was told that I would be having an interview to decide if I would be given a full-time offer. By this time, I was almost certain that I wouldn’t be getting one. But I was determined to give it my best shot. I spent literal days preparing for it. But I knew all was lost the moment I joined the call.

My interview was being conducted by my acting manager.

I won’t go into the details of the interview but suffice to say, it was a disaster. I imagine this is what happens when you ask a manager to interview someone for a technical role. I was left showing him Google searches to prove that my answers weren’t wrong despite him insisting that I was. I assume that’s what set him off. He was visibly annoyed and made one final punch - he asked me if I had ever written a single line of Java code in my life, and whether I’d even be able to write a Hello World program in it.

It was at this point that I seriously considered pressing the leave button on Zoom. Yet I didn’t. I sat through the rest of the interview, answered his questions as best as I could, and then asked him how he thought it went.

He said I had done terribly — it was then that I finally pressed the leave button.

The Grudge

Soon thereafter, I was told that I wouldn’t be getting a full-time offer. I was devastated. I knew this was coming but that didn’t prepare me for the reality of it. I had spent the last 6 months working on something that was never going to see the light of day, through no fault of my own.

I was angry, I was sad, I was frustrated. But most of all, I was disappointed. I had always wanted to work at Autodesk — it was a dream come true when I got the offer. But now, I was left wondering if it was all worth it.

But if I thought the worst was over, I was wrong. I soon had to deal with what I would consider pretty unprofessional behavior from my acting manager. He told other interns how much he tried to get me a job but that I didn’t give him anything to work with. He refused to even give me any feedback — something other managers provided to their interns every week. He even told me that were I to focus on interviewing for other companies and spend a little less time on my tasks, he would have to lower my feedback even further. I wasn’t even spared in the office — I was hunted by him and asked to tell him exactly what I had worked on that day. This level of micromanagement was something I had never experienced before.

Fighting Back

While I knew I wasn’t going to get a full-time offer, I was determined to make the most of the time I had left. I wanted everyone to know what I had gone through — not because I wanted to get back at my acting manager but because I wanted to make sure that no future intern had to go through what I did.

People kept telling me that I shouldn’t speak up, that I should just let it go. But I couldn’t. I had to speak up. I had to make sure that my voice was heard.

I had a call with my recruiter and told them everything that had happened. They were shocked — they had no idea that this was happening. They told me that they would look into it and get back to me.

They never did.

But I didn’t want to give up. I scheduled a meeting with my manager — the one I was supposed to have but never did. I didn’t know what to expect but I was hopeful. I started by telling him how I wasn’t assigned a mentor, how no one on my team was aware of my tasks, and how I was left alone to fend for myself.

I was expecting him to be shocked, to be apologetic. But he wasn’t. He was dismissive. He told me that they want interns who don’t need to be assigned a mentor. That assigning a mentor lowers the overall productivity of the team.

I was speechless. Not only did other teams assign mentors to their interns, but it was also company policy to do so. When one of the VPs at Autodesk came to visit the Autodesk Pune office, he specifically asked the interns if everyone had been assigned a mentor. You might wonder why I didn’t say anything then — believe me, I wanted to.

But my manager had told me that if I were to say this publicly, it might put a lot of blame on my acting manager and that he would try to solve this internally. I trusted him. I trusted that he would do the right thing.

He never did.

Acceptance

I’m not sure how to feel. I made some incredible friends here — not only among the interns but also among the full-time employees. It’s just a shame that my managers weren’t one of them.

I have no bad blood with Autodesk — I still think it’s a great company to work for. I just had the misfortune of being surrounded by those who aren’t the most welcoming. Now that I look back at it, I find it unsettling that one person can have such a huge impact on your life — both professionally and personally. But when that one person is your manager/mentor/buddy/scrum-master all rolled into one, anything is possible.

This blog barely scratches the surface of what I went through. For every incident I’ve mentioned here, there are countless others that I’ve left out.

But so is life when you ruffle the feathers of the powers that be.

Conclusion

I’ve always hated it when people crib and complain about not clearing an interview or not getting a job after the fact. It feels like they’re just trying to find someone to blame for their own shortcomings.

Yet here I am.

Which is why I know that this entire post might just sound like the cribbings of an intern who didn’t get a full-time offer.

So take it with a grain of salt. Maybe I made everything up — there’s no proof I can provide to show that I didn’t. But I know what I went through — I know how I felt. And so do the several lovely folks at the Pune office who were there to witness and support me through it all.

And that’s all that matters.

But writing is not just about the words that you use. It’s about the way you use them — and most importantly — how you string them together — Punctuation. I’ve often felt that punctuation is an underappreciated part of writing. It’s not just about the rules — it’s about the rhythm.

And the em dash is the one which rules them all.

Ok but what is an em dash?

Firstly, here’s what it looks like: —. Notice how it’s longer than a hyphen(-). It’s called so because it’s the width of the capital letter ‘M’.

But what’s more important is how it’s used. It’s used to indicate a break in thought or a pause in speech — similar to a comma or a colon. But it’s more than just those two — it can even be used in pairs to indicate a parenthetical statement. It’s also used to indicate a sudden change in thought or tone.

Suffice it to say, it’s a multitude of punctuation marks rolled into one.

Shut up already and show me some examples

Here are some examples of the em dash in action. I have taken these examples from TheWritePractice and Merriam-Webster.

And the wide range of its hours of operation — 6 a.m. to 6 p.m.— certainly showed concern for customers’ manifold circumstances.

Andy scanned the budgets on his desk, noting that Margot’s handwriting — and most of her work, in fact — was less than satisfactory.

And my favorite use of it — as an aside, an act of breaking the fourth wall so to speak:

While you may choose more than one value — perhaps a value for a subplot or the internal genre — if you try to move your story on too many values it will become muddied and will be very hard to work with in your second draft.

Why do I love it so much?

If you’ve read any of my blog posts, you’ll notice that I use the em dash a lot. Well, that’s not actually true. I used the hyphen(-) a lot. That’s because until recently, I wasn’t aware of the em dash. But that just proves my point — even without reading about it anywhere, I was using it instinctively. If that’s not a sign of a good punctuation mark, I don’t know what is.

But now that I’m finally enlightened, I’m going to do what any evangelist would do — spread the word.

But that still doesn’t answer the question — why do I love it so much? I think the main reason is that it’s very simple yet effective. I don’t know why, but just reading an article littered with semi-colons and colons makes me feel like I’m reading a research paper. I’m not saying that they’re bad — they have their uses — but they feel a bit too formal for my taste. The em dash, on the other hand, is very informal. It’s like a friend who’s telling you a story — and that’s the kind of writing I like.

It also suits my writing style. If you’ve read any of my blog posts, you know this — I write as if I’m talking to you. And that’s because, in some ways, I am. As soon as I start having an aside or go off on a tangent — which I do a lot, this included — I use the em dash. It’s like a pause in the current speech — a break in thought — to be resumed later. You can kind of — but not really — do this with a comma or parentheses, but they look ugly so here we are.

And that’s why I love it so much.

Why should I care?

Because it’s awesome and anyone who says otherwise is wrong.

The Problem

The reason so few people know about the em dash is because it’s not present on most keyboards. You can use the hyphen(-) instead, but it doesn’t look as good. You can also use two hyphens(--) instead, but that’s just ugly. You can also use the en dash(–), but that’s just wrong.

The way to type it depends on the operating system you’re using. On macOS, you can use the shortcut Option + Shift + -. Typing it on Windows is a bit more involved. You can read about it here

Conclusion

Now that you know about the em dash, the next step is simple — repeat after me:

Em dash on the page,

Silent pause in language’s dance —

Words linger, entranced.

Congratulations, you’re now a member of the church of the em dash! Go forth and spread the word!

How it happened

ClearFeed is a startup based in Bangalore that is aiming to simplify the workflow between customers and support teams. I had applied to ClearFeed first in the month of March this year. I was told that since I was still attending college full-time, I won’t have the time to commit to the internship. I was a bit disappointed and started looking for other opportunities. A couple of months pass by and I see that the opening for interns is still open. I message the CTO and asks if he could consider me now - given that my semester was about to end and I would have a lot of time on my hands. He agrees and within minutes I receive a call to schedule an interview.

The interviews were fairly straightforward if you’re familiar with the basics of JavaScript, some React and some (probably unnecessary)trivia - which is to say quite different from most interviews I had given up until this point. The second round was focussed more on standard low level system design questions. In the end, I was asked for my stipend expectations and within a few hours, I had an offer letter in my inbox.

The internship

I worked on a multitude of tasks during my internship - mostly on the backend. During the initial 3 months of my internship, my tasks were mostly small and concise. I was given plenty of time to understand the codebase and explore the task at hand and never did I feel like I was being rushed.

Everyone on the team - and I won’t name names here since I’ll probably miss someone - was very helpful and always ready to answer any questions I had. I never actually watched any of their onboarding videos - something I probably should have - which meant that I had to ask a lot of questions - but they were always answered patiently.

In the month of July, I was asked to come to Bangalore for a month to meet everyone in person and work from the office. I was a bit apprehensive at first - while I always wanted to visit Bangalore, I was hoping for a shorter stay. But I decided to go for it anyway. I’m glad I did. I got to meet everyone in person and we even had a team outing during that time. I also had a lot of fun in Bangalore - I got to meet a lot of my friends and even made some new ones!

After that, I had to work remotely again since my college had started. This time, I was given tasks which were a bit more involved and required me to do a lot of research. Initially, I must admit I was a bit overwhelmed - I had never worked on anything like this before. I was also very conscious of the fact that I had to deliver a feature within a certain time frame. This meant late night calls, a lot of debugging and even more frustration during code reviews.

This all happened in the span of less than 2 months and its when I learnt the most - not only about the product and the codebase but also about myself. I realized that - despite everything - I prefer to work alone and asynchronously. As soon as a call, meeting or a deadline is involved, I start to panic and my productivity, unsurprisingly, takes a hit.

The End

This is also when my on-campus placements started and a few off-campus companies I was interested in also started hiring for interns.

I was conflicted - I had spent a lot of time here and was finally starting to get a hang of things. The safe option of course was to stay here - I knew the people, I knew the codebase and I knew what was expected of me. But I decided to take the leap and try something new. I’m not sure if it was the right decision - only time will tell - but once you have made a decision, you have to stick with it. I talked with a lot of people - my friends, several folks at ClearFeed - and everyone had a different opinion. In the end, I decided to go with my gut feeling.

I’m still not sure what lies ahead of me but I’ll take the lessons I learnt here with me wherever I go next. I’m grateful to everyone at ClearFeed for giving me this opportunity and I wish them all the best for the future. If you’re looking for an internship and are interested in the work they do, I would highly recommend you to apply - you won’t regret it.

And as always, thanks for reading!

And yet here I am, 3 months later. I haven’t written a lot of code to be fair but I’ve come to realize that - at least this year - the code wasn’t the most important thing. And so unlike last year’s report, you’ll find that this report is more about the experience, the things I learned, and the people I talked to rather than about the code I wrote.

So without further ado, let’s get started!

Project Details

• Name: Shashwat Khanna
• Project Name: Wiki Education Dashboard
• Organization: Wikimedia Foundation
• Mentors: Sage Ross

Overview

As always, for those new, here’s a quick overview of the dashboard and what my project aimed to do. I’ve taken this from my proposal so it is a bit outdated but I think it still does a good job of explaining the project.

Wiki Education Dashboard is a complex web app for keeping track of contributions to Wikimedia projects. It’s widely used by the global Wikimedia community for edit-a-thons, classroom wiki writing assignments, and a variety of other initiatives.

The dashboard currently supports a variety of methods to track articles within the “Article scoped program” event type - namely categories, PetScan, PagePile, and templates. In a nutshell, all of these scoping methods make it easier to group and track a set of articles with a single condition, greatly reducing the effort for tracking related or similar articles. However, currently, these tracking options are not obvious to find. This project aims to remedy that by incorporating these features into the course creation modal window itself - along with adding new features(like auto-complete, presets, etc) - to make discovering and editing these values easier

What did I do?

To make things a bit simpler to understand, I think it would be best to divide my work into 2 major categories - user research and code contributions. As I mentioned above, I didn’t write a lot of code this summer but I did do a lot of user research. So let’s start with that.

User Research

What is user research? Well, it’s exactly what it sounds like - research about the users. In this case, the users of the dashboard. I had never done user research before so I was quite excited to get started. I had a lot of help from my mentor Sage who sent an email to the dashboard mailing list asking for volunteers to talk to me. I also reached out to people on my own. I got some responses and while scheduling the interviews took a bit of time - I had to work around timezones and other commitments - I was able to talk to a few people and get some valuable insights.

Going over all the interviews in detail would take a lot of time and likely wouldn’t be very interesting to read so I’ll just limit myself to the major takeaways from the interviews.

Major Takeaways

Since the entire project revolved around Article Scoped Programs, I wanted to know how people were using them and what they thought about them. I wasn’t surprised to find that most people weren’t even aware of the feature - something my project aims to remedy. Even those who were using Article Scoped Programs weren’t using them to their full potential. Most people were using the category option and a few were using the PetScan option.

In one of my interviews, I talked to a user who only just discovered the features of Article Scoped Programs and was quite excited to use them. She found out about it from a video tutorial on YouTube. This was quite interesting to me - while I did know that the scoping methods were a bit hidden away, I didn’t realize how difficult to find they were - not to mention that the lack of a guided setup meant that users could easily miss out on these features.

This made the work on adding scoping methods to the course creation modal even more important. If you put everything front and center, people are more likely to use it. And if you guide them through the process, they’re more likely to use it correctly. This is where the auto-complete, error handling, and other nice-to-have features come in. It’s very easy to make a mistake when adding a category or a template - especially when you’re working across multiple wikis.

The design was also important. I had a few ideas even before I got selected but none of them were ideal - they involved compromising between functionality and simplicity and I wasn’t happy with that. After discussing with Sage and demoing a few prototypes to users, I was able to come up with a design that worked better for most people.

Other Feature Requests

There are some things that I knew I would have to do even before the interviews - the previous section is all about them. I wasn’t sure about the specifics - something the interviews helped with. For example, I knew that I would have to add the scoping methods to the course creation modal. But there were a few feature requests that I didn’t think about before I talked with folks using the dashboard. Let’s go over a few of them.

One was adding a way to find which articles were being tracked by a particular scoping method. This comes in handy when you are sure that you’re tracking an article but you still can’t see its edits on the dashboard. The idea was to add a “View Articles” button to each scoping method that would open up a modal listing all the articles the Dashboard associated with that scoping method. Add in a search bar and some hyperlinks and you have a fairly functional interface for finding tracked articles. A related feature request was a way to somehow summarize a PetScan ID with the things it was tracking - the logic being that it’s easy to think in terms of categories and templates but not so much in terms of PetScan IDs. While I did plan on working on this, I feel like the “View Articles” button is a better solution - not only because it’s easier to implement but also because it’s more flexible and works for all scoping methods.

Another feature request was a way to track multiple categories across wikis and with different sub-category depths at once. This would significantly reduce the amount of time spent on configuring scoping methods. This did take a bit more effort than I initially anticipated, but I was able to get it working in the end.

Of course, I couldn’t get everything done. One of them was to add a way to track an article - say about Albert Einstein - but across wikis of different languages. This is to say that tracking Albert Einstein on the English Wikipedia would also track Albert Einstein on the German Wikipedia without having to manually add de:wiki Albert_Einstein. I think this is a great idea but unfortunately, I couldn’t figure out a good way to implement it. I imagine it would require the use of WikiData to figure out the various articles on a topic/person across languages or wikis but unfortunately, I never got the time to work on it. I do hope to work on it in the future though.

Code Contributions

If you’re here for the code, this is for you. Here are all the pull requests I made this summer:

• #5396 - add scoping methods to course creator
• #5430 - improve styling for articles that don’t exist
• #5445 - add url to official page pile tool
• #5451 - add tests for new scoping methods in course creation modal
• #5471 - Improve UI for modifying scoping methods after course has been created
• #5476 - Make depth category specific when editing tracked categories for article scoped program
• #5483 - prevent subcategories from showing up in article titles

In a nutshell, my primary focus was to ensure that everything I did - from the scoping methods in the course creation modal to the scoping methods in the course edit modal - was modular. This is the reason that it took me a while to get this done. Building new components for each scoping method in the course creation modal and then another set for when you edit the course would have been much easier but it would have been a nightmare to maintain. Finding the right balance between abstraction and readability was a challenge but I think I did a good job. The result of going down this route is that any feature added to the course creation modal is automatically available in the course edit modal. This not only means that it’s easier to maintain but also that the user experience is consistent - regardless of whether you’re creating a course or editing one.

Another thing I was rather stubborn about was testing. I wanted to make sure that everything I did was well-tested. I wrote rspec feature tests for the new functionality that I had implemented. These ensured that everything - from the basic stuff like actually tracking an article - to more advanced stuff like auto-completing articles from across wikis - worked as expected.

Conclusion

There’s a lot more that I could talk about but I think this is a good place to stop. I’m really happy with the work that I did over the summer and even more happy with the feedback I got from the community. I got nothing but respect and admiration from everyone I talked to and that helped me stay motivated.

Sage was an amazing mentor and I’m grateful for all the independence he gave me. I can easily imagine Sage contacting people, setting up the interviews, and even attending those interviews with me. But he didn’t. I can’t thank him enough for that - those interviews were a great learning experience and I’m glad I got to do them at my own pace.

I would also like to thank everyone else who reached out to me and helped me with the project. I’m grateful for all the feedback I got and I’m glad I got to work with such an amazing community.

And that’s about it. I still can’t believe how quickly these three months went by. While I can no longer participate in GSoC the next year, I hope to stay involved and continue contributing to the project.

Until next time!

Note: This is my 6^th Bi-Weekly blog. You can find the rest of them here

Summary

Like the last time, I worked mostly on the UI side and since the majority of the time was spent coming up with a good design, there’s not a lot of code to show. I did however end up discovering a bug in the way the dashboard tracked categories while working on the articles modal - more on that later.

The UI area I was working on this time was a feature request I received from at least a couple of users - a way to see and filter the articles being tracked by a particular scoping method. I still haven’t finalized the design yet but currently, it looks something like this

To nil or not to nil

Before I get to the actual UI work I planned on doing, let me talk about the bug I discovered first - not only because I think it is hard to find one, but because it is relevant across languages and codebases.

So here’s the setup - I noticed that for some reason, the dashboard keeps track of subcategories as if they were actual articles. This is a problem - since tracking a category in theory should only track its mainspace articles. Before, this problem wasn’t apparent because a user couldn’t see the articles being tracked by a category. Now that they can, it is a problem. Not to mention it also messes up the numbers on the dashboard.

So that’s the gist of the problem. I spent an hour or so trying to figure out why this was happening when I saw it. Let’s take a look at the code

def category_query(category, namespace=0)
  { list: 'categorymembers',
    cmtitle: category,
    cmlimit: 500,
    cmnamespace: namespace, # mainspace articles by default
    continue: '' }
end

Ok, so for those not familiar with Ruby, let me help you out. This is a function that takes in two arguments - a category and a namespace. It then returns a hash which is used to query the MediaWiki API for the category members of the given category.

Now, when this function was called for an article, the namespace was passed as nil. Unlike in javascript, however, when passing undefined to a function is the same as not passing anything, in ruby, it is not. In ruby, if you pass nil to a function, nothing of that sort happens.

So the namespace=0 part of the function definition essentially did nothing - the namespace was always nil. This meant that the dashboard was always tracking all the articles in a category, not just the mainspace ones.

The fix was simple - I just had to change the function definition to

def category_query(category, namespace)
  { list: 'categorymembers',
    cmtitle: category,
    cmlimit: 500,
    cmnamespace: namespace || 0, # mainspace articles by default
    continue: '' }
end

namespace || 0 evaluates to namespace if it is not nil and 0 otherwise. And Voila! It’s fixed.

The UI

With that bug out of the way, let’s get to the feature I was working on. As I mentioned before, I was working on a way to see and filter the articles being tracked by a particular scoping method. Let’s see why this is a useful feature request first.

Say you have a category called Physics. It’s not that hard to guess which articles would be tracked by this category. Now, let’s introduce the subcategory depth parameter - if this depth is 0, only the mainspace articles in the category are tracked. If it is 1, the mainspace articles in the category and its subcategories are tracked, and so on.

Now, it is a bit more difficult to guess which articles are being tracked by category. But it’s still manageable. Now, say you are tracking articles using PetScan with an ID of 4341. Yes, you can open up the PetScan page and see which articles are being tracked but that’s a bit of a hassle. Not to mention that the dashboard only tracks articles from one wiki - even though your PetScan ID might be tracking articles from multiple wikis. This is something we point out in the dashboard, but it is still easy to miss.

So what’s the solution to all of these problems? Since the Dashboard already keeps track of the articles being tracked by a particular scoping method, why not just show them to the user? And that’s exactly what I did.

There are still some edge cases to consider - like what happens when the Dashboard hasn’t run an update on a category yet - in which case, the articles being tracked by that category are empty. But I’ll figure out something after discussing it with Sage.

Conclusion

And that’s about it for this blog post! Sage has been busy with other things so I haven’t had a chance to get these changes reviewed and merged, but I still have a week left so hopefully I can get all this done before the final evaluations.

This might well be my last blog post for GSoC which is a bit sad. I enjoyed writing these and hope that they helped you in some form or another. I will be writing a final report soon though so keep an eye out for that!

And as always, thanks for reading!

Enough talk, let’s get started!

Note: This is my 5^th Bi-Weekly blog. You can find the rest of them here

Summary

For those in a hurry, you’re in luck! This time, I worked on updating the UI for editing the scoping methods for an article-scoped program after the course has been created.

In the end, here’s how it looked!

And now, let’s get into the details!

The Designs

I won’t elaborate too much on this since I’ve already talked about it in my last blog post. Suffice it to say, the designs are identical to the ones used in the course creation modal. There are some minor changes here and there but even down to the React code, I have used the same components.

As always, you can find my Figma designs here

The Code

The problem right from the start was - how much abstraction is a good thing? I could use two different sets of components for the course creation modal and the ones used after the course has been created. It would result in code duplication, yes but it would also mean that in the future, adding specific features to say the course creation modal wouldn’t involve a complete rewrite.

Initially, I did go down this path - not because I felt that there was a feature that I would implement only for one of those two but because there didn’t seem like a good way to keep the components generic without making them too complex. Of course, I was wrong - there was a better, far simpler way to do this and while it took me a week of hacking around to figure, it ended up working perfectly. Without any changes to either of the components, they started working for both the course creation modal and the one used for editing the scoping methods - just like that. It almost felt like magic.

Once I had that figured out, it was mostly a done deal. I did need to change the Rails backend code a bit. This was because users could now add scoping methods across multiple wikis at once. I had a demo of this for Sage and he liked the new UI. There were a few suggestions - for example, we decided to always show the wiki prefix for the scoping method. This was because users could add scoping methods across multiple wikis and it would be confusing if the wiki prefix wasn’t shown for some of them.

After that, I wrote a few tests for this, and voila! The code is now merged and should be available on the production server soon!

What’s Next?

There’s some work still left, but for all intents and purposes, with this PR merged, my project is complete. I have a few interviews lined up for the next couple of weeks and they should serve as a good way to gauge how much impact my project has had on the Dashboard and the way people use it.

One of my priorities now is to write a more formal document about what I learned from the various interviews that I conducted. Fortunately, I have a lot of notes from the interviews and I should be able to put together something soon. The idea here is that even if I don’t end up working on these issues, someone else can pick them up.

There’s still a little under a month left for GSoC to end which means I have plenty of time to tidy things up, write documentation, and maybe even work on a few more issues.

And that’s it for this blog post! I’ll see you in the next one!

Note: This is my 4^th Bi-Weekly blog. You can find the rest of them here

Summary

As always, for folks in a hurry, here’s a quick summary of what I’ve been up to.

The course creation modal PR has been merged and is now live on the Dashboard! With that out of the way, I got started on writing tests for the new UI, which also got merged yesterday.

With that, the work on the course creation modal is (mostly) done. Now, we move on to the next phase of the project - adding different scoping methods to an existing course. I haven’t started coding yet, but I’ve been doing a bit of design work and after discussing with Sage, I think I have a good idea of how to proceed.

And now, let’s get into the details!

The Tests

Tests are a really fun thing to write. I know that’s not a popular opinion but I imagine that stems mostly from people writing redundant and often useless unit tests. A lot of the pain stems from the fact that to test a piece of code, you must what that code does and how it does it - not to mention the fact that you have to mock everything under the roof to make sure that your tests are isolated and you’re not spamming external APIs.

But in the past year or so, I’ve realized that for the web at least, there exists a much more painless way to test your application - end-to-end tests. These tests are written from the perspective of the user and test the application as a whole. This means that you don’t have to worry about mocking anything - you just write the test as if you were a user and the test runner takes care of the rest. This means that your tests will fail if an external API you rely on is down, but that’s a good thing - you want to know when your application is broken. The users will know, so you might as well know too.

All this requires a different mindset than what you’d use for unit tests. But once you get the hang of it, it’s a lot more fun and more importantly, infinitely more useful. Even debugging is a lot easier since you can see the browser doing its thing and you figure out exactly what’s going wrong. The power of having a real browser at your disposal is not to be underestimated - I can’t count the number of times I’ve put in a sleep statement in my code just to get a chance to mess around with the browser and see what’s going on.

Having said all that, I did run into a few issues. Making sure that the environment the tests run in the CI is the same as the one on my machine was a bit of a pain. I’m not even talking about browser versions here - just that some Dashboard configuration options were different on my machine and the CI. But once I got that sorted out, it was smooth sailing from there.

With that merged in through #5451, the course creation modal is well and truly done

The Next Phase

With my focus moving to the UI after the course has been created, I have started to think about how it should look and work. I’ve been working on a few designs and after some discussion with Sage, I have pretty much finalized how this will end up looking like.

My designs can be found on Figma here - these contain the designs for the course creation modal as well as the ones for the next phase of the project.

The idea in its simplest form is to have a consistent interface - we reuse the same UI we had for the course creation modal. Not only does that simplify the code, but it also makes it easier for the user to understand what’s going on. Currently for example there’s autocomplete for categories, templates, and pages in the course creation modal. But there’s no autocomplete for the same in the UI after the course has been created. There’s an option to change the wiki in the Articles tab after the course has been created, but not in the course creation modal. And so and so forth. All of these are small things, but they add up and make the experience quite jarring.

This is what my goal for the next few weeks is - to unify these interfaces and make sure both have the same functionality, along with the same look and feel.

Conclusion

It might not feel like it, but there’s a lot of work that goes into making a UI look and feel good. I’ve been working on this for a while now and I’m still not done. But I’m getting there, and I’m excited to see how this turns out.

On the GSoC side of things, the mid-term evaluations are over and I’m happy to say that I passed! I know Sage is tired of hearing this, but I’m grateful for all the help and support I’ve received from him.

As for how much more work is left, I’d say there’s not a lot. If I had the time and energy, I could probably get this done in a couple of weeks. But there’s no need to rush - I’d rather take my time and make sure that the result is something that I’m proud of.

And that’s it for this blog post! I’ll see you in the next one! I don’t know when that will be, but I’ll try to get it out as soon as I can. Until then, take care!