Welcome!

Hi!

MDX was a pain to deal with, so I just got rid of it. I don't think I needed it anyway.

This will be a much simpler alternative. I really admire how simple MDBook keeps it.

I'll try porting some of my old blogs maybe to this?

And yeah this blog will be largely stagnant, unless I really feel like talking about something.

That's very rare. I rarely talk anyway.

MDBook should be an easier dependency to both host and deal with in general.

Welp, there's not much here for now, so I'll end here instead of filling this with fluff like I tend to do.

Week 8 of being cruX Secretary

6 July, 2023 - 12 July, 2023

What is this?

Hi. I decided I don't write much, and it would help if I did. So, I'm going to be documenting the things I learn here. I really didn't want to make this a public thing, but I think it keeps me in check in a way. For Google Code-in, I made my posts public from the get go, but I didn't really do that for GSoC. That was the big difference. I never ended up following through with my promise of making blogposts for GSoC.

This is the first week, and I need to lay a lot of groundwork for what exactly I want these blogposts to be. Which is why this blogpost will be much longer than the rest, so bear with me for this one.

What's cruX? What are these blogposts?

cruX is the programming and computing club of BITS Pilani, Hyderabad Campus. I was initially made the Secretary of the club on May 18 2023. Since then, I've tried my level best to push this club to its maximum potential. The last 2 months flew by in the blink of an eye. But, I've come to terms with two thing in the previous 2 months: first, that I am a terrible manager, and second, that I've surrounded myself with yes-men.

The yes-men thing is pretty simple: Every time I ask my friends in the club if I'm a terrible manager, they all instantly go "oh nooo you're not nooo", and tell me about how I've managed to pull outcomes out of this thing for the past 8 weeks, and all the work I've done. But again, for the reasons I'm going to lay out now, I'm not entirely convinced.

These two things are genuinely saddening, and are honestly making me reconsider a fuck-ton of my choices in the past 2 years. I hope the blog posts that follow explain why I think this.

I am a terrible manager

Some more context

I am now in Year 3 of my 5 Year dual degree program. There are 26 members in the club that I am responsible for, including myself. 6 of these are in Year 2, and the rest 20 are in Year 3.

I'll be honest, I've done a lot in the last 8 weeks.

• Week 1: 18 May, 2023 - 24 May, 2023: set up account logins and permissions, decide some goals for things to get from the Student Union, estimate server costs, assessing current cloud hosting situation, reallot work for the semester across projects, make decisions with respect to projects to discontinue, discuss timeline for all projects, discuss designs and ideas for new cruX website with the rest of the club
• Week 2: 25 May, 2023 - 31 May, 2023: decide on Atmos events for the year, discuss this with club members, discuss timeline of the semester ahead, decide on action plan to revive CTF team in cruX, receive and assess the designs members submitted for cruX website figma pages, decide the new approach to cruX forum going forward, greenlight rideshare as the first service in forum, decide on stack and primary features for chronofactorem
• Week 3: 1 June, 2023 - 7 June, 2023: approach BITS-SOS about the future plan with regards to CTFs, finalize event details and strategies for events (collabs, contributors, etc,), assess current financial status of the club, and ensure that all financial transactions and assets now have a paper trail or atleast a log of some sort, discuss project status with game dev
• Week 4: 8 June, 2023 - 14 June, 2023: get access to a free Oracle Cloud account, Dockerize and host the old version of ChronoFactorem on Oracle server, hop on multiple meets to try and finalize the website color scheme, finalize and announce decision to screen Design/UI candidates for inductions, formulate first draft of design screening task, start primary negotiations about Atmos event prize money, event logistics, and collabs
• Week 5: 15 June, 2023 - 21 June, 2023: send design screening tasks to all designers, finalize collab with CSA, submit primary Atmos event details to Student Union, finalize new domain provider due to the unexpected sunsetting of Google Domains, create teams and Discord server for cruXipher 2023, have another review meet with game dev on project, discuss initial structure of rideshare backend and app, finalize schema for ChronoFactorem, finalize the endpoints we need for ChronoFactorem, made sample PR for ChronoFactorem, ironed out build issues with ChronoFactorem
• Week 6: 22 June, 2023 - 28 June, 2023: follow up with designers about design tasks, provide updates and primary feedback, draft problem statements for cruXipher, finalize the finer details of cruXipher, draft publicity posts for Atmos for DePP, fix bugs with ChronoFactorem development, make PRs for ChronoFactorem endpoints, review, and get people to review PRs on ChronoFactorem
• Week 7: 29 June, 2023 - 5 July, 2023: merge the last few endpoint PRs on ChronoFactorem, hold activity review meet for the month of June, discuss a way to hold interviews for design inductees, revamp build system for ChronoFactorem, make a test timetable for ChronoFactorem, start writing unit tests for ChronoFactorem, finalize and submit event problem statements to Student Union
• Week 8: 6 July, 2023 - 12 July, 2023: review the designers' submissions, get feedback from other designers on the submissions, finish writing sample unit tests for ChronoFactorem, reach out to inactive members in the club, put forward out first draft of budget for prize money and inventory for Atmos to Student Union

Now all this is a lot, but there's a critical flaw I've seen myself fall into in the last few weeks. Is it really my job to be doing a lot of that? Am I supposed to be making PRs for API endpoints, or rewrite build systems, or write unit tests? It's not horrible for me to do all that as long as I'm also managing the rest of my "managerial" duties, yes, but the bigger issue is that it prevents others from learning. There are maybe 1 or 2 people in the club that I can trust with rewriting the build systems, or writing the unit tests with no reference point. What I am preventing is the long term growth of the club and its members.

I feel like I have a fundamental misunderstanding of my work. I'm not supposed to be a dev that can also make decisions now, I'm supposed to be a "mentor" of sorts, coordinating club activity, making sure people learn what they need to do, how they need to do it well, and giving them the environment to do it all. I'm supposed to become the road the people drive on, not the fastest driver, or the driver that's leading the parade.

Is it that bad though?

So I threw my weekly log of work into ChatGPT, and asked it to guess the role of the person that wrote this log. It replied with:

Based on the provided log, it appears that the job or role being described is related to managing a student club or organization. Here are some possible job titles that could match the activities mentioned:

1. Student Club President/Chairperson: This role involves setting up account logins and permissions, making decisions about goals and projects, discussing designs and ideas for a club website, deciding on events and strategies, assessing financial status, and interacting with the Student Union.
2. Club Coordinator/Manager: This position involves overseeing various aspects of the club, including project management, event planning, financial management, member coordination, and communication with external organizations such as the Student Union.
3. IT/Technology Coordinator: This role focuses on managing the club's IT infrastructure, including server setup, assessing cloud hosting options, making decisions about technology stacks, managing website development, and collaborating with game developers.

Please note that these are just educated guesses based on the provided log. The actual job title and responsibilities may vary depending on the specific context and organization.

Now this is a pretty spot on answer.

But when I think about my priorities, I always think of the third point. It's always "I need to get my unit test samples out, so that the others can follow the same format", or "I need to review these PRs fast so that others can get back to writing code quickly", never "How do I make sure the Flutter people want to work on their projects?". It makes me feel unfit for the job in a way. I am not a manager. My priorities seem to point to a "tech lead" sort of role. But then I sat with this thought for a while; You won't find anyone in the club that is a manager. You won't find an insanely talented developer on a college campus that says "Oh and I also really like management". This is not a thing that I've seen.

I am unfit for this job

As I write this now, one book title comes to mind: "The Making of a Manager" by Julie Zhuo. The intro to the book argues that managers are made, not born. This makes sense. You rarely see companies "hiring" a manager. Why hire some person that doesn't know your team, your company, your culture, your internals? You always want to turn a designer or developer into your manager, someone that knows how the club runs, who's familiar with the people and the system.

This is another thing I realized from reading the first few parts of the book: I'm behaving like the club is on life support. It really isn't. I'm in there writing code and writing unit tests and shit, as if I don't do that, tomorrow the whole thing will fall apart. I need to let go. I'm having an additive effect, by participating, by being a member of the team, just like the rest. What I should be doing instead, is having a multiplicative effect, by getting the rest of the web dev guys to understand build systems, by getting them to a point where I can have them review code stress-free. It might not help now immediately to get this project done in the next month, but there's month after month after that, where I can't go focus on other teams because I need to be in web dev reviewing PRs.

This is what makes me think: I am not fit for this job. I find writing those build systems, figuring out how to bring readability and beauty to a large, complex system (which is why I fucking love playing Factorio), writing large chunks of the codebase quickly, to beat deadlines. I am a rat.

At the same time, I don't think that prevents me from doing this job. I believe people are way more malleable than they think. Throw a developer into a sales job for a year or two, and initially they'll hate their life, but eventually they'll learn the ropes, understand how the system works and what they need to do to excel at their job. I think I can learn how to do this job well, even if I'm trash at it now.

Conclusion: I am a terrible manager

So far, I think I've pretty much proven that I'm a terrible manager, and an okay team lead. From here, my goal is to become a good manager. The last 8 weeks have taught me that I pretty much hate management, and I never want to do it for a career, but I want to try it as an experiment. I feel like it will test my hypothesis of people being malleable. More importantly, it could teach me that I'm malleable.

All this reminds me of an experience that is now a core memory: So in Year 2 Semester 2, since I am an Econ student, we had a course on Management. It was called "Principles of Management". The first few weeks of classes, I was just speechless. The amount of pointless diagrams, the sheer number of management buzzwords per minute, it was everything I imagined it to be, and more. My dad is a manager, so I've heard all these book names, all these words, and seen all these shenanigans in real life. I thought it was an interesting coincidence, and didn't think much of it. But, one fine evening in that same semester, I found myself at this burger place on campus, with 2 of my friends. Some discussion about management came up, and the 3 of us realized that all our dads are basically carbon copies of each other. They've read the same books, they say similar things, they do similar things, etc. They're all managers. It made me think, there is a real steretype of managers, and this stereotype really exists.

It's like all these managers are being manufactured in a factory. A factory. Huh.

If I want to become a good manager because I care for this club, what its goals are, and I want to try this experiment of trying to beocme a good manager, I have to put myself through this factory. Sounds funny, right?

It's roleplay.

I have a pretty embarrassing story: I've walked into a grocery store on campus in a cockroach costume with a couple of my friends, because I thought it would be a pretty funny practical joke.

I liked it. I had fun doing it.

Another thing I could connect to this: The Eric Andre Show. In Season 2 Episode 3 of The Eric Andre Show, Eric dresses up as a typical stockbroker finance-bro, and goes on the streets, talking into his earpiece loudly. The main objective is to say weird things loudly, and capture the reactions of people around him. The people around him don't have much of a reaction compared to his other skits, but I found the skit particularly funny just because of the idea of it.

Another skit from the Eric Andre Show you could connect to this: In the same episode - Season 2 Episode 3 - Eric dresses up in a large trench-coat, along with another man, and goes out to buy a car. Again, the car salesman's reaction is not that interesting in my opinion, but just the idea of actually dressing up as 2 people in a trench coat tickles my brain.

It's all roleplay.

I think it would be slightly funny to essentially dress up as this stereotype of a manager, and do managerial things. I could be doing a real job, and having an impact on the working of the club, but that's a side effect. I could have fun being a manager because I'm only pretending, and it's all a play/joke to me.

I'll read books, try tricks in real life, try following advice, and try seeing how far I can push the satirization of a work meet. Can I show up with a powerpoint next time? Maybe sprinkle in a word like "synergy" or two? Ask about status updates, meetings, deadlines and action items? How far can I push this exactly, until people realize the bit?

This is the experiment I want to try. I want to put myself in a job I feel like I don't belong in while I play pretend, roleplay as the stereotype, and see what I come out the other end. I believe it will have positive effects on the club, and I'll get to learn a lot all while having fun.

These blogposts are essentially a log of this experiment.

This week

This week wasn't really that eventful.

As I said, I started reading this book called "The Making of a Manager" by Julie Zhuo. My friend sent this book to me, and I've really enjoyed reading it so far. This book is what made me feel like writing these blogposts and doing this experiment, essentially.

I thought I was an okay manager before I started reading the book, but the more I read, the more I'm convinced I'm not. This is why I wanted to do this experiment. Can I become a good manager by dressing up and roleplaying, and can I document this process?

Now since this is all I really did, and all this happened on 12th of July, I'll be sharing specific parts of the book that I found interesting, and trying to contextualize them in interesting incidents from my life so far.

Now I do feel like I've convinced myself that I'm a bad manager after reading parts of this book, but I feel like I need to cater my words a bit more towards a future secretary who's in the same situation as me. I feel the need to explain what I mean when I say that I am a bad manager a little further.

A manager's job is outcome oriented

Now I thought I was outcome oriented. Oh boy was I wrong. I thought because I wanted to get a project done, or because I wanted to get people to finish X amount of work, I was outcome oriented. A manager's job is outcome oriented in the "Why"s and not the "What"s. What I just listed out, projects and work is the what. The why, is a multitude of reasons. Why do I want to get projects done? Well, so that members learn programming practices, so they learn how to work in a team, collaborate, learn the tools we use in such situations, and so that people not only use these projects but look at them, and think "Wow I want to build something cool like that."

This is a manager's job. To reach outcomes in the whys. I was completely operating in the whats.

Even in Finance, something you learn is that profitability of a company is much more important than the activity of the company when talking about investing. Of course, one could make the argument that Amazon actually made losses for years on end, while focusing on activity over profitability. But look at that neat semantic trick: They leveraged their activity later in their life, to create profitability. It was all for profitability. The outcome is once again what matters.

Being outcome oriented is... tricky

I feel cringe every time I bring this up, but an exceptional example of just how tricky it is to be outcome oriented is presented perfectly in the show Better Call Saul. Saul's entire character arc hinges on this moral dilemma.

The field of Economics is pretty infamous for its use of assumptions. "Assume that the market is perfect", "Assume that the competition between two firms is perfect", "Assume every person can see infinitely into the future and past, and has all information possible", and so on. Whether or not these assumptions are justified, or whether they're too much for the field of Economics is a whole different can of worms, but the biggest criticism by far, even from Economists of a lot of Economic theories is: "Can you really assume that every person is a perfectly rational, moral, and informed agent?"

The same applies here. Being outcome oriented is so tricky, exactly because we are human and not some kind of perfect spherical frictionless agents. We are bad at predictions as humans. Approximately 98% of day traders end up making a loss on average.

Do you tie all your club members down and electrocute them until they finish the project? Do you ask them for status reports twice a year? Or do you participate in every activity with them, to show them that you all are a team? Do you maybe maintain a strict distance between your members, and maintain hard deadlines, and develop tough, work-oriented culture?

Hey maybe the field of management will have something to say about this? Well, what does management say? "Do what you need to do, to get to your goal." Yeah. Not very helpful.

It's very easy to be disillusioned about management, and to believe that it's all make believe, and stupid jargon and meetings to make managers feel more important. It feels hand-wavey, and bullshit-y. I think that it's because of the subjectivity of the matter at hand. One size doesn't fit all. Heck, even your team might not fit each other, how will you manage to make one solution fit between teams?

If all that wasn't complicated enough, there's something called "Simpson's Paradox." Basically, what applies for a set might not apply to all subsets. For example, maybe you need to make someone in your team worse off to make the rest of your team better off. Sometimes you need to move people away from projects, or force people onto more projects than they want, or even kick people. It might not always make them better off, but if you believe that it is the right thing to do so you can make the entire team better off, so be it.

Giving up control

Even when parenting, you need to let go. You need to let people fall flat on their face, and make mistakes, so they can learn from them. If you always put your kid on training wheels, they're never going to be able to cycle without them. It's okay if you know how to do all the infra right, and you know how to structure the code right, but you need to give them a chance. If they don't try it on their own, when will they learn?

I did do this at some point, where I allowed some members to review Pull Requests and merge them, but eventually that did lead to pretty big mistakes being made. I eventually just stepped in and corrected everything, but what I realize now is that nobody learnt anything from it. Sure, less time was wasted, but in a way we ended up in a worst of all worlds.

Say a bad PR gets merged. Now, this is a pretty big PR and you need to revert significant changes to the code before you can even begin looking at the other PRs. Imagine two scenarios: In the first one, you inform your members about the issue, and watch as they scramble to correct their mistakes, and see them revert the PR, make a new one, correct the mistakes, review it, and then merge it once again. A lot of time and effort is wasted, but a lot of learning happens. Now you have 2 more potential members that can review PRs. That's a 200% boost from when you had just you.

Now imagine a second scenario, where you step in, revert the mistakes, ask the members to correct their code, you review it, and then merge it. Time is again wasted, although lesser. But the fundamental issue is that not only did you waste time, you got no return from that waste of time. You didn't leverage your failure to be helpful in the long run. No growth has happened, and everything that has happened has only pushed back deadlines.

I ended up in scenario 2 for ChronoFactorem, and I now regret it.

Don't walk on eggshells

The entire time I was working on ChronoFactorem, I was walking on eggshells. Everyone was finishing work faster than I'd ever seen them, and the entire backend was written in around 6 days. I was terrified that they will all get burnt out, and would never come back.

I shouldn't have done this. I should have made them take up responsibility for their own actions, which would make them think twice or thrice before submitting a PR. It would have slowed down work, but PRs would then be easier to review, there would be lesser time lag, and the code would be more correct.

Don't let the emotions of your members hold you hostage. They will cry and moan about having more work, but remind them that they caused it, not you. Of course, don't take this to the extent where you blame them for your mistakes. If you can't take responsibility, they will never learn to. Take their emotions into account, hear them out, but when it's their mistake, remind them gently.

Have a multiplicative effect, not an additive one

When we say "infra" in the programming world, we mean infra. Infra is not just the thing that keeps buildings intact, it is the roads, the bridges. It is not just the buildings, but also all the glue in between. Infra is not just a server that hosts nginx on port 443, it also encompasses how the dev environment looks, how it compares to the production environment, the testing to make sure the code is correct, the way a developer can seamlessly push their changes to a staging instance to verify if everything is working before they push to production.

As a manager, the closest thing you can do that still remains technical, or code-related in a way is Infra. A good manager can create these environments for their devs to excel, or atleast has someone like this at their fingertips.

These changes reduce time lag, and speed up the team. If a developer has to put in less effort to ensure their code is correct, then more often than not, they'll end up pushing correct code. If a developer can quickly make a PR, then they are more likely to do that more. These actions reduce the mental cost of these things, and oil your system up to work faster.

One article that comes to mind when I talk about this is: https://jsomers.net/blog/speed-matters

Even as a dev, these things matter. As you move up the chain, you need to make sure that every interaction you have with others minimizes the cost of doing work for others. Seeing this in real life is what convinced me on the reality of this.

At my PS-1 internship, we had this guy called Ajit Trivedi. Ajit would answer to pings at lightning speed, he would review PRs first thing he gets time, he would answer all your questions, move things around on a server or on staging instances all so you could get out of his hair and into work. Even if I wanted to take it a little slow, and figure out the specifics of Spring before diving into the work, I would be forced to do work, because Ajit would make it so easy, so cost-less to get started on that work.

The activation energy for a reaction being that low basically guarantees that the reaction is spontaneous. If you can do that, you have won. You have pulled work out of people that don't even know it.

In my opinion, this is the one thing I've done well during the last 8 weeks. Every day of those 6 days we spent on the ChronoFactorem backend, I constantly tested how fast I can respond, and how quick I can review and move ahead and no longer be the blocking task in their task queue. It worked magic. I have never seen a backend done in 6 days, and guess what, we did an entire rewrite of a project in those 6 days.

This multiplicative effect is what matters. You can be at your laptop for days on end typing code at 100s of WPM, but it will never come close to the situation where all your team members are atleast some fraction of that.

I notice this in Bangalore as well. The number 1 reason Bangalore traffic is so bad compared to Hyderabad traffic, is not because they lack public transport or because the city isn't walkable. These two reasons will certainly reduce the traffic significantly, but I'm comparing it to Hyderabad. Hyderabad isn't insanely walkable, and isn't close to god tier public transport either. It is because of the footpaths. Bangalore cares about its pedestrians too much. In Hyderabad-land, they are merely a speed bump between you and your destination. In Bangalore, they are first class citizens, with "rights".

For a city that big, this is catastrophic. Your roads aren't as wide, meaning that you can fit fewer cars beside each other. This means, more cars are behind each other. Already, you end up with lower area because of the loss of width to the footpaths, but something else has happened, which is the main culprit: The reaction time is now a factor.

This reaction time is catastrophic. If you have even slight variances in these reaction times, you will end up with horrible traffic. This is precisely why Bangalore traffic sucks that much. The cars are behind each other instead of being beside each other.

Here's a CGP Grey video to make it even clearer:

This multiplicative effect of reducing the friction inside your team is what you need to do. You need to become the road. You can no longer remain the rat. If you try to be both, you can end up the rat that's flattened on the road by some car. You don't want that.

Are you on fire?

No, seriously. Are you on fire? If not, take a deep breath, and a step back, and chill. You should be working in an additive manner only when you are on fire. cruXipher in a week, and the event platform is not ready? Get on that shit, go write the code yourself. You are on fire. If you're not, continue working multiplicatively.

Conclusion

That's... all I've read. Surprisingly, I'm only some 35 pages into the book, and this thing has made me realize insane amounts of shit about myself. I've learnt a lot, and I want to continue. Surely I will take time out every week to write a blog like this.

In all seriousness, I miss writing, and I miss the ability to sneak in examples of me being a rat, and being able to casually write sentences like:

Bangalore cares about its pedestrians too much. In Hyderabad-land, they are merely a speed bump between you and your destination. In Bangalore, they are first class citizens, with "rights".

or

You need to become the road. You can no longer remain the rat. If you try to be both, you can end up the rat that's flattened on the road by some car. You don't want that.

This was fun. Fuck I've already hit the end of July 13th before finishing writing this I need to go back to my roleplay session, goodbye.

Week 9 of being cruX Secretary

13 July, 2023 - 19 July, 2023

What is this?; What's cruX? What are these blogposts?

Read the last week's blog posts for a bit more context

This week

• Week 9: finish judgement on designers, reach out to designers about interview, and schedule a date, make sure that 22 batch members were in the loop to some extent, and ensure that they understand how inductions are done, finalize the format of the design interview, take the design inductions, and assign the final task for the designers, finalize course of action with respect to PS it's easy, reach out to inactive members once more, talk to DoTA about contributing to atmos website, decide loosely about an infra sprint, and register for ACC and RAF events

This week I made a lot of progress on the book. I am now on Page 82 and read the chapter on Hiring in advance to prepare for the interview. The Hiring chapter didn't prove to be very useful, because it was primarily oriented towards corporate, but it did stress to me how important inductions are, and just how important the HR round is.

The book, and the interviews were the only fun thing this week. Everything else was pressure from external bodies, dealing with inactive members, and deadlines for our work.

Your transition into your role

Here's the first thing that I felt. You will also feel it: the awkward air around you. Hopefully, when you signed up for wanting to be Sec, you've had peers who you think deserve the role more than, or as much as you. However, due to however things turn out, you ended up as the secretary. It will feel awkward. You have probably worked with the other person, and likely know them well too, making it even worse. You will feel pressure to bend your own goals for the other people you deem capable. Then, once you do realize you are bending your own goals, you will think about whether you're just a puppet for the other guy. It will happen. It's okay. I don't have tips for dealing with it. It goes away with time, that's it. Don't think about it much, and just do your job. You'll get used to it.

Behind the scenes

You will realize just how much work the previous sec was doing behind the scenes. You had no idea. HOWEVER, try your best not to express it to the rest of the people. The behind-the-scenes work is thankless, and that's just the reality. If you tell people about the behind-the-scenes work, you will either divulge information that they shouldn't know yet, or you'll censor yourself and they'll feel like you're saying nothing. Imagine you walk into a meet after a month, and the manager says "You guys have no idea whats happening behind the scenes, my days have been occupied non-stop. You'll be excited to see what's coming."

Nobody's excited. Why would they be? You've said nothing of meaning.

Imagine an advertisment that says "You guys have no idea what we're about to sell you." Nobody's drawn to that. Nobody cares. There is no information to think about. Who are you talking to? What is this for? Why should I be excited?

Same way, never say you're "working on stuff behind the scenes." Nobody likes it, and nobody has opinions on it. It just looks like you're making excuses to slack off, even if you aren't. It is thankless work. Accept it, and move on. The grim reality is that even if your day was occupied by behind-the-scenes work, you have to work overtime to do visible work, otherwise your team simply won't accept you. You will lack that critical sense of leadership.

Legacy

You will feel immense pressure to do things the way the sec before you did. "We must work on forum!" Why? "I need to satisfy the seniors!" For some reason the seniors suddenly feel like shareholders that you are accountable to. Every day you'll feel like asking the previous guy if you're doing a good job. To an extent, you need to detach yourself from that.

Obviously, if your ways are wildly different from that of the guy before you, your team will feel the shock. Change that fast will just demotivate them, and make them feel like you're not a fit successor. You need to slowly transition the team into your ways.

But that legacy pressure is good. It helps in smoothening the transition to your ways, it maybe even gives you some kind of hint for the best ways to manage your team, especially if the guy before you was good at what he did.

You need to strike a delicate balance between preserving legacy and moving towards what you think is correct.

Agency

Give people agency. I have done a terrible job at this so far. This part will be a little long-winded, but I think it will help explain every move I make for the next 3 weeks.

On the night of 18th July, my roomie was telling me about how his reading speed has plumetted. He told me how he read only some 50 pages in the span of a week, and how he used to read entire books in a day before this. I told him about the book I was reading, and how I read 35 pages a week, but I read 70 pages the following week, and how slowly the speed increases.

Eventually the conversation rolled around to software development, the club, management, differences between SDE1s and SDE2s, etc.

But the most important and influential part of this conversation was the part where he told me I'm a manager at heart. I obviously disagreed, and still disagree, but he said it, and he justified it pretty well. He said that the way I look at leadership or management is the way Jon Snow from Game of Thrones views it: Leadership is a burden. I mostly agree, that is the way I look at it. It's the same way Plato looks at leadership. If you don't step up and steer the ship, the chaos of the drunken sailors will surely drown you all. Thus, you need to step up for your own good and the good of the rest of the people.

I agreed because this was exactly what went through my head when I signed up for Sec. Nobody else wanted to do it then, so I set my mind to it. I decided I was going to sign up for it. Eventually, people around me did sign up for it as well, but when I set my mind to it, that was not the case.

But here's the part where I disagreed that I'm a manager at heart: the situation is unique. I argued that in a corporate environment, people around you are competent, and even if they aren't, I certainly would not care about the outcome or the goal. Some code in production is buggy? I don't care. Some service went down? It will be dealt with on Monday morning.

He, being blackpilled on the state of software engineering disagreed with the first point, but he told me that I will somehow brainwash myself into caring. I again gave him the example: I genuinely do not care if some service goes down. He told me that managers will generally make you the sole person responsible for some product or service or some unit of code, and hold you accountable to it. I said "that's how they get you."

That's how they get you

I'll be honest - I did think about this before. I considered making team leads in the club, and holding them accountable for their team. The only reason I held off from this, was because I saw it fail in clubs. One club that I was part of, the Journal Club (the one for writing, kinda like a Press club) had team leads. In fact, I was one of these team leads. But I never cared, and nor did they.

Somehow, this team-lead situation seems to work in the industry, but it didn't work for Journal Club; Why?

The what-s over the why-s

Funny. Look at that, the words are inverted now. But why? I don't know why. This seems to be the answer.

Managers make team leads in charge of the whats, never the whys. A team lead is a what, while a manager is a why.

Amazon makes team leads in charge of their team's work. If a team is working on EC2, or S3, the managers at Amazon will make the team leads in charge of making sure that EC2 work gets done, or S3 work gets done. You will never see a manager tell a team lead "Hey listen, you are now in charge of making sure Amazon delivers the best cloud compute services in the industry" or "You are now in charge of making sure Amazon contributes to the field of scalable filesystems."

Journal club made people in charge of the whys — their biggest flaw. I was the team lead for tech. My responsibility was to "make sure people write articles that enrich people's tech knowledge and interest on campus."

It's hilarious - you can see this contrast in Journal Club itself, you don't even need to step out of the club. Their most active part of the club is probably the Gazette - the monthly newspaper for the campus. This is because the person that manages the Gazette's job isn't to "ensure they deliver the best monthly newspaper experience to campus that they can"; it is to "make sure people write articles for the gazette."

You can argue that the Gazette lead's job is technically in the whys, but it never gets there functionally. You will never see a gazette lead make a decision that completely changes the format of the gazette or changes up what kind of articles show up. That's because that's the job of the secretary.

On the other side, you can argue that the tech team's lead job is to make sure people write tech articles, and remains in the whats, but there was no clear metric that was given to us; A gazette is a tangible item that you can produce once you have a bunch of articles, there is a set goal. For the tech team's lead? We don't know. Write an article, or don't. Maybe make an instagram post instead. Maybe write a blog post, or a gazette article. Maybe collab, or don't. Somehow someway, make sure people enrich the tech culture of the campus. How many articles per month, or which articles, or what format was never enforced. This fundamental lack of structure is what forced us to think about the whys. If we had a set job, we would have done work.

Conclusion: Agency

I need to get people. What I mean by that is the same as when I say, "That's how they get you." I need to make people in charge of projects. When I initially thought of the team lead idea, I thought maybe I could make a "web dev head." It was probably a bad idea in hindsight. I need to assign people to projects and ensure that someone keeps the rest in check.

This gives members agency over what they do, and makes them think a little bit. It makes them work. I can't always expect people to step up, they need to be nudged a little sometimes.

It makes them more capable; it makes me trust them more. It is fundamental to how a team would work. If I can trust my members and delegate stuff, I can have that multiplicative effect instead of doing things myself.

Feedback

One thing that ended up being true due to the nature of my friend group was that I interacted with few people a lot more than others in the club. I feel like it was hindering the club's activity in a way.

The book gave me this idea, and I liked it a bit; 1 on 1 meets. Think about it. If you have a friend or someone you talk to outside of the club, you often talk about the club outside of the club setting. This doesn't happen for the rest. If I can bridge that gap by catching up with the others every month or so, it could be a strategy that works. It will get them to build a closer relationship to me, maybe make them work more, and add a slightly personal touch to the whole thing. I'm not "the sec" anymore; it humanizes me. They can chat about their goals and stuff unrelated to the club.

It will be awkward at first, but I'm willing to put the time into it if it goes as I think it will.

One big challenge with this will be that I will have to make it informal. If I call it a "monthly one-on-one" it will feel too corporate, and they'll have their guard up the entire time. If possible, I need to invoke this in an informal setting and somehow have control over it.

I need to talk about this idea with a bunch of people and give it a try. If I try it on inactive people, it will be pretty effective; If it works, I can expand it, and if it doesn't, I can just kick them because they remained inactive. Easy!

All I need to do is figure out how I would implement this.

Inductions

HR Round is essential. It is not where you figure out someone's favorite ice cream; it's the critical part of the round to determine if you and your teammates can work with the guy.

The way we did the design inductions was pretty satisfying in my opinion. We had 2 rounds. The two rounds were:

1. Whether you can make a good-looking design (technical)
2. Interview

The interview had 4 parts to it, which was the part I was happiest about.

1. Introduction: Who are you? Why do you do whatever you do? (save the more philosophical or practical stuff for HR)
2. Technical Write: Given a problem statement, can you come up with a solution? If maybe you can't come up with the entire solution on the spot, can you come up with something that starts looking like a solution? Maybe given some days you can come up with one? One important part of this, is that you test a different aspect of their work than round 1. For the designers, if round 1 was making fancy UI, round 2 should be making boring, functional UI that is intuitive.
3. Technical Read: Given a solution, can you decode the problem statement that the person that wrote the solution was trying to solve? So for example maybe you give a guy some codebase and ask them to understand what it does, or you give a designer two finished designs, and ask about how the original designers' intentions differed on various levels (like Product Manager case studies). This tests their ability to quickly understand existing work in their domain.
4. HR Round: Can you dedicate time to this club? Do you understand what we do and why we do it? Do you understand your own motivations for wanting to join the club? What makes you different? What is your idea of skill? Are you someone we can work with?

One thing that we decided to do for part 2 of the interview round was that we added them to the Discord channel for one of our projects after the interview for a week, and we expected them to call meets, chat, collaborate with the rest of the club essentially to come up with the wireframe UI of the project. This tested something that wasn't listed in the above 4 points: Can you open your mouth? Can you have opinions of your own, and voice them? Can you communicate with the rest of your team and discuss your beliefs? Essentially, can you work with us, and fit in? This was one of the best things we've tested in this interview round, and I'm really proud of it.

During the entire interview, we maintained an air of directness, of having no filter, and not being afraid to criticize. If needed, we gave them feedback, but we didn't want to spoonfeed them, so we just insulted them sometimes. This made them open up and be vulnerable easily, making it easier to do the HR round. They couldn't fake anything or maintain a facade.

I'm very happy with how these interviews went, and I want to try and experiment with this format and bring elements of it to dev interviews.

Conclusion

This week was pretty interesting, though towards the end of the week I ended up being busy because of work related to my PS-1 internship. Next week will probably be busier, but I can devote more time per day next week I think.

Basically, I need to give more agency to people. I will be doing this, by making Pal the team lead for Rideshare and the Auth service. I don't want to change stuff around too much because it'll take them time to get acclimated. Instead, my plan is that for snap sorter, Aruna is already doing a good job as team lead. For game dev I think I need to make either Pritam or Varun take charge, for Rideshare web, it'll be Pal, and for the flutter part I can make Shubham the team lead. In the future into Year 3, this team will be less inclined to write code, so I'll probably tell them that they can balance code and PR reviews as they see fit.

And well, for feedback, I need to be a bit more open, slide into conversations a bit more with slightly less active members, and I think this will end up working out.

Week 10 of being cruX Secretary

20 July, 2023 - 26 July, 2023

What is this?; What's cruX? What are these blogposts?

Read the last week's blog posts for a bit more context

This week

• Week 10: induct the designers formally, assign them tasks inside the club, start hosting a minecraft server on the oracle instance, plan and hold an infra sprint, write and setup a sample staging deploy pipeline for the infra sprint, assign unit tests to people on chrono, follow up on unit tests, come up with an action plan we'll use for the next few weeks, as we go into the new semester

Feedback

Feedback is interesting. I don't know if I have a good or bad experience of it, but back during cruXipher last year, I complimented Saurabh Atreya about how he handled his Python stuff. There were no hiccups in how he made his question, implemented it, and sent it over. After that, I made him a member, and since then he hasn't worked much, which I largely suspect is because he's busy doing ML project stuff.

But if you take me, I have a good history with feedback. On 25th July, I asked the previous dev sec and prez about how I was doing and received neutral to good reviews. Last year, Srikant told me I handled web dev inductions well. Both these things pushed me to work more.

Praise Motivates more than Criticism

It's very hard to pull off the Gordon Ramsey kinda way of doing feedback. It's fun, an ego kick and whatnot, but it's very hard. Motivating people to do better while also criticizing their work is hard. Rarely you'll see people that don't put in effort into their work. In cruX, it backfires a little. Either people will write good code, or they won't write it at all. Giving people the lightest criticism can be very hard to get them to work again.

I saw this with Anurav first. Anytime I asked him to change something in his PR, he would say things like "maaaan" or "fuck" or "I won't" or "3-5 business days". He gets demotivated fast, because to him, the work is boring. He's more suited for work where he has to be creative, look for funny jokes to write, UI effects that change the page, etc.

It's very simple: say nice things.

Nitpicking a PR we all can hopefully do, but say nice things.

The Echo

In sound, the word feedback means "a screeching or humming sound resulting from the return of a fraction of the output signal from an amplifier, microphone, or other device to the input of the same device."

But often, the feedback we give is not even close to being coupled to the input. What I mean by that is that we give feedback once it's too late. Feedback happens at monthly review meets, and it happens when you're selecting for a new PoR. Outside of this, you have PRs where it's always "fix this."

Feedback needs to be more realtime. I need to consciously make an effort to analyze and comment on every activity that someone does. There is a lot that can happen in a feedback loop.

The feedback sandwich

A funny anecdote I heard somewhere was about how nobody likes Accountants. Have you ever looked at an accountant and thought "man I love that guy?" No. Here's why: They always talk about how you need to fix something. When you have a broken sink at home, you don't want to think about it. You just want to ignore it, go to work, sleep, watch a movie, or whatever. It's some menial work you need to put in to fix it. Same with accounting. Nobody wants to think about fixing these problems.

When you go to a PR, and ask people to fix shit, they hate it, and you will hate the ensuing process. You know why? Because it feels like getting a sink fixed.

You go in, call some plumber, and tell them the problem. Then after spending a few hours or days without a sink, the plumber shows up at an inconvenient time, and then you have to deal with them. They then talk about how they have 2 or 3 options, which you really don't care about, and how they need to get some replacement sink from some hardware store. Then leave, possibly leaving the bathroom in a more dysfunctional state than before, and then come back hours or days later again at an inconvenient time, and finally fix it. Even after all this, the sink looks out of place. The plumber agrees. But, since there's no other option, and this is just the way things played out, this is the solution we move forward with. Nobody's happy, but it needed to be done.

If I haven't painted the picture well enough, let me try that again.

You go to the PR, review it, and tell them that something's broken. Then after spending a few hours or days without a reply, they ping you at an inconvenient time, and then you have to deal with them. They then talk about how they have 2 or 3 options, which you really don't care about, and how they can install some dependency or something, or maybe they ask you to hop on a call. All the ideas discussed in this call are useless, and are all bad implementations. After a few minutes or hours, they leave, possibly leaving the PR, or atleast the idea of what the PR will do in a more dysfunctional state than before. They then come back hours or days later again at an inconvenient time and finally have some kind of solution that isn't utter trash like the one they came up with on the spot on the call. Even after all this, the code feels out of place. The other guy agrees. But, since there's no other option, and this is just the way things played out, this is the solution we move forward with. Nobody's happy, but it needed to be done.

I've seen this situation a lot: especially when working on chrono. We all tried to develop better ways to store warnings, check clashes, or duplicate data correctly so we don't have to make as many DB calls, but in the end, we had something. Everyone did not want that something, but it had to be done.

This is all a long-winded way of saying: not all PR comments need to be: fix this.

I think I have done a terrible job at this and haven't fostered the culture for it.

One diagram that I really like is below:

Source: https://product.voxmedia.com/2018/8/21/17549400/kindness-and-code-reviews-improving-the-way-we-give-feedback

When I look back at my Open Souce contributions, I realized that a lot of the PR reviews, and Issues and Discussions that I was on, had a lot of praise on them, even if it wasn't warranted. The people being so nice made me want to work more. I need to do this at cruX more. Instead of just "LGTM, merging" maybe I could take some time out and give my thoughts on the code quality. Maybe I could comment on how stuff progressed on this PR. I can do a lot, just using those PR comments.

Teaching

I love teaching. Obviously, I get burnt out and I lose all faith in humanity every time I hold a workshop, but I keep coming back. I feel like it's still worth it. Even if the workshop helps one or two people, it's worth it to me. Think about it. When you're managing a club and need others to know stuff so you can take work off your back, you can teach them. How many of them do you need to replace you? One. The rest are just bonuses. If one person can walk out of an infra sprint being able to write a deploy pipeline, then gg it's done. Now someone that is not you can do that work. You can now delegate work.

I know it sounds dumb, and it sounds like cope, but really, what is your goal when you want to teach someone to replace you? One is enough. At best, you only need two. If you need three people to replace you, maybe you need an ego check.

I held an infra sprint during this week, and it went well. I got to teach people how to write really good infra in the span of 3 hours. 3 hours was excessive, and it went on for about double of the average attention span in that meet, but I did end up getting one person to the point he can write a deploy pipeline, and a bunch others that took atleast something from the meet. This was probably by far the most successful workshop I have taken. I believe it was because of how short it was, how aligned I was to everyone's learning speed, and how useful it was in the moment.

Obviously, these things aren't possible in a normal workshop setting, and are very hard to pull off. I was thinking about holding a web dev workshop for 23 batch once they're here, but someone gave me some nice-sounding advice about how I approach workshops recently. I want to try taking that advice first and then moving on and seeing if I can make it work. Once I do, I will write about it. This can take around an year to get done with though.

Are you on fire?

I think so. I think now that we don't have a working design for ChronoFactorem, even though the backend is nicely finished, I think we're on fire. I don't like how nobody wants to acknowledge it. People here would rather give up than speedrun work on ChronoFactorem so we get it done before registration. I don't like it, but it's the harsh reality.

I don't know what to do to motivate a team to work in conditions like this. I feel like at the end of the day the onus to write the frontend for ChronoFactorem will fall on me, and I should do it. After all, if nobody else will, then who will? Somoene needs to move the club ahead. I don't like it though. It isn't satisfying as an answer. I don't like the "you can't." There has to be a way. Do I have to give speeches like Napoleon or some shit? How do I get these people to move, and be as committed to this goal as me? I don't know. Maybe I'll find out. Once I hit that stage though, I think I will have unlocked the full potential of cruX. It would be a club of people working towards making the campus a better place, and getting juniors interested with unwavering commitment.

Conclusion

Well that was all I had to say for this week. I didn't read much, since I got busy with putting the fire out, more on that next week probably.

Updates from last week: The agency gambit seems to be working, and work on rideshare slowly seems to be going independent of me pushing them. I need to keep doing this with other projects as well.

Things are going well as usual, and I think they can be even better. End goal is a state where everyone will work night and day to get a good fucking release out on time, so other people are wowed by it, and it sparks something in them to start learning more about software development.

Week 11 of being cruX Secretary

27 July, 2023 - 3 August, 2023

What is this?; What's cruX? What are these blogposts?

Read the last week's blog posts for a bit more context

This week

• Week 11: i decided we are on fire, disappeared for 5 days, and finished writing a temporary frontend for ChronoFactorem, held the weekly review meet, had another meet with people that stayed after the weekly review meet about cruXipher ideas, worked with designers to decide on a better style of working for them, got an update from Mudit about the chinese super app, talked to ansh about club updates in terms of what we need to submit to tech senate, and discussed potential judges for the hackathon

Being on fire

I don't know if I convinced myself that we were on fire, or if I just really wanted to write code for once. I am starting to think it's the latter, because even now after the rewrite I have a strong urge to write more code.

This week, since i spent 5 of the 7 days on writing the rewrite, I don't really have much to say.

I wrote garbage code. I feel slightly bad, because turns out the final timetable will take some time to come out.

BUT, in that time, I can work on integrating CMS or other things into the existing chrono API.

I didn't make any progress on the book.

Going forward, I think I'll be heavily focusing on integrations between our projects, and integrations with whatever already exists. I feel like it's a huge boost to usage of your stuff, and once you get usage on your stuff, getting funding for doing fun shit is never a problem, since the SU knows the value you bring to campus.

I've realized its increasingly important to prove the value your club brings to the SU, and we've seen time after time the need for it. I can't elaborate too much, but based on how some things go next week, I'll try and maybe talk about it.

Conclusion

This week didn't have much. I apologize. But again, I need to remember that my goal isn't to write nice flashy blog posts that are fun to read, it's to document my journey as I learn about this shit. I need to read the book more going into the next week, since I'll have a lot of free time away from projects, since I won't be involved in much except coordinating and reviewing PRs, while we decide what our work for Atmos looks like.

Week 22 of being cruX Secretary

18 October, 2023 - 18 October, 2023

What is this?; What's cruX? What are these blogposts?

Read the last week's blog posts for a bit more context

Last 11 weeks

I know the last 11 weeks basically just went undocumented, because I basically stopped writing blogposts. I have a new system to keep myself a bit more accountable, lets see if it works. I'll try it for like a month and if it works I've struck gold.

I haven't continued reading the original book I was reading, the "The Making of a Manager" one, but I realized I can just listen to audiobooks when I'm doing mindless work like washing clothes or walking to some place or something like that, so I started listening to this audiobook for the book titled "How to Win Friends and Influence People" by Dale Carnegie. I know, the title sounds extremely fucking cringe, but the sheer amount of people that have told me to read this book is staggering. I think of all people I have discussed books with, 50% or more have mentioned this book. Now this is downright insane, because first, I don't read much at all, and second, I expect the distribution to be more like 10% of all people recommend book X, then the next most recommended one would be recommended by like 6%, then the next one like 3 or 4%, and so on. This book is an outler in terms of how many people have told me to read it, so I decided to give it a try.

Surprisingly, in two sessions of listening to this book, I have already reached page 69, while I've only reached like page 89 in the "The Making of a Manager" book, so I think this strategy is working. I don't want to get too hooked to audiobooks though, because I'd like to have the ability to read a normal pdf that might not have an audiobook. I don't want the audiobook thing to become a problem.

But, I won't let the last 11 weeks go undocumented just like that. I'm writing this quite early into week 22, so I'm hoping if I set aside like 30-45 mins each day, I can eventually go over the last 11 weeks, and analyze some of the stuff I might have done right or wrong. The last 11 weeks were very important for the club, due to the fact that huge mistakes were made in terms of planning, inductions took place, and we had to square with our planning and management issues to decide our plan for ATMoS, the yearly technical fest of the college. In a sense, I am lucky, because like 7 days between Week 21 and Week 22 were midsems, and no club activity really happened. I tried to make sure background tasks happened while midsems happened, and looks like it worked mostly.

I will try my best to do it over the next few days, but I will limit the time I give it, because I don't want to sit one day and finish it all, I want to make it a habit to do this everyday. Accrual is a really cool concept.

This week

• Week 22: contacted the CTFTime team to get cruXipher approved to be hosted on their platform, talked to the App Dev guys to try and see if they could gather resources that we can dump in a post so people learn app dev after midsems, nudged the guys that weren't done writing Round 3 tasks a little bit, got a server provisioned from the CS & IS department for ATMoS and as a server for hosting in general,

Making people feel important

One really cool thing I want to try out from the "How to Win Friends and Influence People" book, is the part where he explains how you can make someone do something.

According to him, the number 1 easiest way to get someone to do something, is to make them want to do it. Very simple. Now, how can you make someone want to do something? The easiest way to do that is to make them feel important. Everybody wants to feel important. Everyone wants to be up on stage being the performer for the audience. Everyone wants to have that confidence and that level of importance. I didn't buy it at first either, but I think I do buy the claim that you can make someone want to do something in more than just one way, this is just one approach that tends to work more.

Additionally, I don't know where I heard this, but I think it was in Bo Burnham's INSIDE. Bo claims that social media blew up because of two things: one is that all your friends are on it, so now you feel the pressure to be on it, the network effect. But, the yellow pages can have the numbers of all your friends, doesn't mean you will then want to be on it, no. The other reason social media blew up so much is because it makes you the celebrity.

Think about it; Pick up all the baby boomers and a good chunk of the millenials too. Most of the people they recognize are Hollywood stars, people in bands, and performers. If you take Gen Z however, I think you'd see a way bigger slide towards recognizing people popular on social media. Now, I'm not saying they only recognize people from social media, or majority of their "stars" are people from social media. All I'm saying is, people today recognize people popular on social media, because social media is popular; everyone uses it.

But, how do you get from point A to point B? How do you become a "star"? In the case of hollywood stars and bands, well, get into the industry somehow, make it your day job, go at it day and night and hope to have the right connections and also be some of the best in the industry, that's how. In the case of social media though, it's a lot more convenient. Maybe it's really not that convenient, and you need to do all the same laundry list of items to get big, but you can gain an easy following of random people just by posting an image every now and then, maybe just a video of something funny, or a cat you see everyday, or fuck it maybe you can pretend to have some kind of political beliefs and you'll find people that way. You don't need to quit your day job, you don't need to be the best in the industry, you just need something. Very easily, will you start feeling important. It'll keep you hooked to the app.

This phenomenon, along with all the examples Dale Carnegie enumerates in the book, is why I now buy that everyone wants to feel important. I feel this need too, I'd be lying if I said it didn't play a conscious or subconscious role in me wanting to become Secretary of this club in the first place.

So, to test this out, I have finally done it. I have imagined someone else doing work instead of me. I sat down and thought of the horrors of me not being the one that does every single thing in the club, and I decided that for the sheer thrill of it, I will do it. I will delegate work, and try and see if I can make people feel important.

I pinged the flutter app devs last night, one active guy, one mediocrely active guy, and 2 inactive guys. I asked them to send resources in the same channel for learning flutter, so we can draft a basic post to encourage people to learn app dev especially right after midsems, and once they're done sending links, I'll get one of them to make a post on Free Expression Group. I know making a post on Free Expression Group isn't much, but I will tell you, it felt nice to make a post about ChronoFactorem in the town square of the campus, despite the state of that fucking project last year. I hope they get DMs and shit, and juniors look at them and think "ooh it's the crux guys." I hope that motivates them a little bit, and makes them do more club work because they get recognized.

I will try and compliment people a bit more during this week, like consciously think about it, and see of that works out, and it makes them want to do more.

Update: So the whole thing happened, and they responded pretty well to it. The inactive guy has started attending meets again, and even asked me stuff after the meet, and has been responsive to an alright degree, I hope that continues. I realize that this won't yield results in the short term, and maybe it's a long term thing.

Recently we got a server at some point, and in every mail I wrote the guys, I've been very nice and considerate of their time (partially because I know how much time and effort one needs to put in to just maintain a server). I've opened with things like "We thank you for your prompt response" or "your cooperation with us", and prefaced emails saying he can choose to respond once it's a working day again, and instantly even though Saturday night the working day had ended, this man resolved my issues at 12:00AM in the night, even though it was a long weekend where Monday was a holiday as well.

It seems to have worked so far, and I'll keep doing it more.

Open with what they're interested in

This is another trick that Dale Carnegie talks about in the book. People's attention spans are small, and if you open with what they want instead of what you want, you can work wonders. If the result is not something they want and it's only something you want, chances are, you are wasting your time by talking to them in the first place.

I did this with last meet. The people that didn't attend the meet got an interesting message that I had never imagined I'd send an year ago.

It started with:

Overall approach

• My overall approach for ATMoS is that I know you aren't too hyped for organizing the event, and I don't want to make you do more work than you want to. You want to have fun during ATMoS and not have to organize a 48-hour event. Based on this, I've come up with a flow to make your experience as smooth as possible, while getting the event done well.
• You don't want to do extra work. This is why, you need to come up with only the idea for questions now, and after quality checking the questions, we'll decide which ones will make it and which ones won't. Only after that, we'll implement whatever code is needed for the questions. You don't want to have your work wasted, and we don't want our time wasted.
• You want to chill in ATMoS and win shit instead of slaving. This is why, let's get whatever little work we have done in advance. I expect everyone to come up with atleast 2 ideas by 22nd October. This way, we can have everything ready for the event by 29th, after which you can basically chill.
• Around 29th, we'll go through the questions with their implementations again, and see if these questions are of good quality. If they are, they will make it to the final event.
• After this, since our only job is to quality check stuff, and make sure all our ducks are in order, most of the work is mine, and you can basically chill for ATMoS.
• We will be collaborating with BITS-SOS as well, so their members will contribute some questions as well.
• We can have our cake and eat it. We can have a fun and free ATMoS, while still having a better quality event than last time, so let's do this.

and then some other details about the work itself.

I was surprised to see, that even people that didn't attend the meet were doing work. In fact, of the 9 people that didn't attend, 7 responded and added something to the sheet. Whether or not these 7 people will contribute good questions is a thing we'll have to see.

Delegating

I think I probably talked about this before, but you have to let go. I talk a lot about it, but I haven't done it at all.

This time I finally did it. It took club members and a senior yelling at me to finally delegate work that I like. I delegated infra to Karthik Prakash, and gave him full range. I think the exmaples that I've set up before for chrono and the infra sprint are sufficient for him to setup a staging pipeline of his own.

I think it'll get done, but it has made my life significantly better. The weeks leading upto ATMoS don't feel like hell and instead it feels like I'm a member.

Though I don't think I'll credit my sanity to that alone. I reduced my expectations for ATMoS significantly and also stopped caring about it as much. If we have the leverage to do things that are fun, then we should use it and focus it to have fun instead of forcing people to work for an event they don't care about, and were never told during inductions that they'd have to do.

Conclusion

I think this week was pretty interesting, since I got a few new ideas and got to try them out. I think next week will be significantly less interesting because the results won't be as ideal as I thought, and it'll make me significantly less optimistic with respect to this. Hopefully I get to read a bit more too.

One day I think I'll just sit and read through old posts and see if I've made progress on any of those, and seen any expected results. I realize it's more of an experiment than roleplay, and I'm still excited for it.

Notes for the Dev Sec by the Dev Sec

This is my final blogpost as the Dev Sec. I was not able to keep up with how much I wanted to write every week, and so the project failed. I should have not been as ambitious, and maintained a monthly log instead. Either way, I have condensed whatever I want to say into a slightly longer document. This document is slightly abridged and some contents have been redacted.

So I'm putting this list at the top because I want you to open this doc whenever you feel like it, and go through the list below. It's much easier than reading the full doc, and it will convey exactly what I'm saying without reading all of it again. But, to understand it at first, you need to read this document fully.

Some important phrases that I will use that you need to drill into your head:

• you are important
• if it's not working out, one of you leaves
• some level of buy-in
• developer of last resort
• speed
• you need to genuinely like everyone
• dev members' dad
• meat people
• make them feel important
• this is not a club, this is THE club
• meet juniors and make them meet each other
• mandatory fun
• maintain standards
• making dying a little easier
• making the next guy's job easier

Before I get into the list, I have to say, if there is one thing you take away from this document, it should be the maintain standards part. The point ties into so many other points on this list, and simply by maintaining standards, you subconsciously start doing a bunch of other things on this list. This is why it is the single most important thing on this list.

Hi, I think this is the document I have put the most work in for, across my life. I would also say that the role of Dev Sec is the single most amount of effort I have ever put into a role/job/position.

I think I have learnt a fuckton and gained a lot of experience as Dev Sec, and the only way for me to pass on this experience is this document. At the end of this document is a huge Addendum where I talk about the context of why I wanted to be Dev Sec and why I cared about the role. If you want to read that, you can. I think the context and history will be useful to gauge how much of an impact someone can really have on a club, and maybe inspire you to push the boundaries of how successful your senate can really be.

General Notes

You are important

There is a reason we decided to make you the Dev Sec despite you wanting to be the president.

You and the CC sec are the most important member of the senate. If you want to reframe this, you can say: The president is the most useless member of the senate. This is my opinion, and the circumstances might change year-to-year.

Every single time there has been a discussion about the formation of the senate since 2018 batch was senate, there has always been one common point brought up: Maybe we should get rid of the president.

With regards to 21 batch senate, you know the story of what happened. Ansh was chosen as prez. He was unfortunately a horrible pick. He never interacted with any of the members, all he did was interact with the seniors. This is why the seniors saw him as an active member, but there was no work to show, because the club as a whole was doing no work. When he did become prez, you can ask any member in dev at that time, but his presence was not felt. It felt like I was running dev alone. The only time he would rear his head in that entire year was when I wanted to make Design inductees members, but he wouldn't let me.

Even after his impeachment, 20 batch senate wanted to leave the President spot empty. Eventually, after I begged and prayed because that would double my de-facto responsibilities, they did appoint a president.

It is possible that someone is a good candidate for President but not a good candidate for Dev Sec. The Secretaries are in my opinion, the most managerial part of the PoRs.

Some qualities you do not want in a Dev Sec:

• Being a bad manager: If the person in question cannot for his life watch someone be slow or fail. They will always step in, and do their work for them. This limits the members' abilities and growth severely, and in the long term the club will suffer, and whatever we have built will rot.

  I used to do this in my 2nd year. Throughout my summer, I made sure I will try my best not to do someone's work for them, and only in my 3-2 did I become good at delegating. Luckily, I think my harm to the club is limited to the ChronoFactorem code. I tried to mitigate that later by getting docs written for it, but only time will tell how bad of a job I have done.

• Their style of work doesn't fit with what we are: If you bring up any dev problem, or some server side problem you are trying to find a way to do, some people will always pull out a tool for it. This is a good thing in a developer. You should be aware of the tools at your disposal. But all these solutions for the club are pretty bad at best, and harmful to members at worst.

  For example, if you bring up the fact that we have no DB backups for our server, or the fact that we need to write a pipeline.yml GitHub action for each new project, someone might suggest a tool like Coolify. This is not a solution, it is an alternative.

  Think about it this way: When you leave the club, do you want members to say "Wow I learnt how to use Coolify and Vercel!" Never. This means you have failed as a club partly. You'd much rather have them learn Nginx, Apache, or fuck it maybe even Caddy. These are widely used tools that are used in the real world. Even if Coolify is a better experience by all means, simply by making sure members learn how to use Docker, Nginx, Linux cron and other basic widespread tools, you are doing them a service.

  The point of the club is not to build quick prototypes like a startup. We are not Venture Capital whores. We are a club in a university, and part of our responsibility is to make sure that our members become good fucking software developers. You would never hire someone that says "Oh I don't need to know SQL I use Prisma." Why? Because you know that someone like this will instantly break once Prisma is out of the question. Instead, hire a developer that knows SQL and he'll adapt to any query builder, ORM, anything you throw at them. You want flexible, knowledgeable devs over fast ones. You will develop good members and good developers and you will take pride in that fact.

• They don't understand complexity: Any good developer that has worked in a team will know that complexity is the #1 enemy. It's not how many npm packages you use or how much existing code you rewrote inhouse, that makes your project bad. What makes it bad is complexity.

  You want every single dipshit that walks into the club (or fuck it, maybe even from outside the club) to be able to understand the codebase, deployment system instantly. Use simple tools like GitHub actions, Linux cron over using specialized tools. If you use fancy tools, in the best case, your members learn nothing from it except from being able to press a button to redeploy something. In the worst case, your members have no idea why it's broken, and now need to figure out the internals of the tools to find the root cause.

  Stay away from complexity, dumb shit down for the average idiot. You don't want 1-hour meets to explain the DB schema and why it is that way. Put the DB schema in a doc or some link in the README and be done with it. As a dev sec, I think I have failed to make it this easy, but I am proud of how easy it is to learn how to deploy shit on the cruX server still.

• Having chronic shiny toy syndrome: You might not notice this in the first few months of working with them, you will only notice this at the end of your 3-1. Mark my words. People like this will become drastically less interested in their duties and kind of become tired of their work. This is expected. It happens to everyone. To an extent it might even happen to you. But that's not the issue. The issue is that it should not happen to the Dev Sec at any cost.

  They will not recognize that some work is important or critical. Even if they do, they will brush it off saying they need to prioritize himself. They will quickly lose interest because the toy is no longer shiny and new, and will make it a low priority thing. You will really need to push them to work on it more. This is why I am of the opinion such people shouldn't be directly involved in a large project or responsibility spanning 1 year, where they are critically needed. As President, this affects the club way less than it does if he was Dev Sec.

If it's not working out, one of you leaves

The senate is the most important part of the club. If at any point you feel like you have disagreements with regards to the direction of the club with any other senate member, bring this up immediately to the previous senate.

The gradual accumulation of my disagreements with Ansh ended up painting a full picture of what he saw the club as, what his vision was, and his intentions. His intentions weren't bad in my opinion, they were just misaligned with the club. Whatever he did, if he did it in CSA or ACM, he would be applauded and he would be considered a good President by all the members. That's not a bad thing. Every club has its own style. It's just that cruX doesn't have that style of working. We don't care as much about partying or rewarding our members for work, or attempting to pull big profits in ATMoS. That's just not what we are. CSA and ACM however, do care about some of those things. Ansh was just in the wrong place at the wrong time, he didn't do anything wrong from a global perspective.

Of course, I do think whatever ACM and CSA do, in terms of having puppet winners, and routing prize money to themselves, or selling useless workshops or selling out in general to make ATMoS profits is all unethical. But that is my value judgement, not something global. Ansh was absolutely doing unethical stuff in my view. But at the end of the day, it's my view. My view simply happens to align more with the members' core principles in the club than Ansh's.

I discussed every single disagreement with Ansh in detail with Aayushi and Srikant the moment these came up. Eventually, the build up of these disagreements is what helped us decide he should be impeached. I think I remember explicitly telling Varun approximately 2 hours after I found out, that I had made my mind up, and Ansh needs to be impeached. The process took 21 days only because of constitutional hurdles, which the new senate quickly got rid of. Now, it is possible to impeach senate members in mere minutes after finding wrongdoing.

My point isn't that if someone indulges in wrongdoing, you impeach them. My point is that simply if your view for the club doesn't align, or you face issues in trying to convince other senate members about your decision, you should consider impeaching. Bring these issues no matter how small to the previous senate members immediately, and you will save yourself months of headaches. Remember this: a boring president is much better than a bad one.

Some examples of me noticing early on, that I cannot work effectively with Ansh, and many times I am better off just doing what I want independent of the prez:

Arunachala was a boring president in my opinion (in his defense, tech senate is very boring, and he likes club internal stuff more anyways). He mostly put his priorities above the club's. He didn't go to many senate meets because he felt like doing something else. Even during tech senate screening he told me he wanted to play RDR2 instead. Even towards the end of his term, he got tired of being President in 1 semester. Ansh would never do this, but I'd take Arunachala over Ansh any day because it's much easier to get work done with Arunachala even if I have to push him every now and then.

This is why, maintain good relations and contacts with your previous senate members, because you might just end up needing them. You and I would rather have a bad president impeached instead of you losing hope in the club and resigning.

Buy-in

Understand one very basic thing: there needs to be a buy-in. I mean both from members, and from you.

There is a set amount of time, set amount of money, set amount of energy and effort, set amount of CG that you will probably have to bid goodbye to when you are dev sec.

I am not asking you to sacrifice any of this, I am just saying that there is a set amount you are willing to lose. You don't need to; maybe you can manage it. My second sem as dev sec I think I am looking at approximately a 9, or a high 8, when my CG is 8.3. It doesn't need to fall, but if it does fall, you need to be ready for it and accept it, and try to manage yourself and your time better next sem.

Developer of Last Resort

I am sorry but you will have to start programming less. Get used to excel sheets, google forms, discord, whatsapp, and docs. This is your new life now.

Don't get me wrong: you can write code, nobody is stopping you. You can write as much as you want. But you should write only as much as you need to write.

I was an exception: the club had not seen an in-house built project for 2-3 years other than cruX Forum when I became dev sec. I had to think both of the short term, and the long term. I had to think about how to get people excited to write code then and there. You don't have to worry about this as much. I had to lead the first few projects completely on my own. Nobody had the drive to create stuff just because I told them to; they couldn't, not because they sucked, but because they did not know what that looked like. I had to participate in the game and win at it to get people excited about the game.

This was completely my goal for the first sem. You will notice I barely wrote any code in my second sem. In the second sem I focused more on delegating work away, making sure other people in the club are capable instead of just excited.

One story that will stick with me forever is one my finance prof, Niranjan Swain told us in class. Imagine a scenario: your dad brings home a guest. What happens next?

Yes, your mom probably brings out the water first as your dad and the guest chat on the sofa. What next? Tea or Coffee maybe? Then what? Dinner.

Who's having dinner first? Not you. The guest, and dad. Okay cool, now imagine if the guest wasn't there. Maybe the entire family at once, but say everyone ends up eating at a different time, say in case of a family gathering: The kids are eating first, then maybe the dads.

Alright, but what does this mean?

Shareholders have the last claim on a company's assets or cashflow.

Your mom is probably eating last. The actual shareholder that owns and produces the assets and their cashflows, has last claim on any of that. Lenders have first claim on the assets and cashflow.

How realistic the example is, or how sexist it is, or how much of a stretch it is doesn't matter. What matters is the lesson you take away: You, as the head of dev are the developer of last resort.

As the dev sec, if you pick up a junior's job, you are starving the junior of experience. You should never do this. If you writing code is harming someone and starving them of work and experience, do not write it. I don't care how much faster you might be. Your job is not to write code, or make questions or something. If you are free and there's extra work lying around when every single dev is busy, sure you can do that work. But if not, then you will endlessly push someone else to be utilized and gain experience from that work.

Instead, focus your excitement and energy towards making it easier and more fun or more rewarding to write code. This can include:

• improving devops to make dev cycles easier
• finding ways to make people have fun when working in the club, e.g. games after meets, etc.
• figuring out incentive structures or trying to get rewards from competitions or tech senate for projects

But remember: only if shit is fucked and everything is on fire, or you want to show a junior or someone doing a disappointing job how good shit is done, only then should you be writing code. You are the developer of last resort. More generally, you are the shareholder and you will close for the club. When leaving a room you will be the one making sure all the stuff is kept in place, all the members are out, and you will be the one turning off the lights. Get used to it.

Speed

If a developer has to put in less effort to ensure their code is correct, then more often than not, they'll end up pushing correct code. If a developer can quickly make a PR, then they are more likely to do that more. These actions reduce the mental cost of these things, and oil your system up to work faster.

One article that comes to mind when I talk about this is: https://jsomers.net/blog/speed-matters

Even as a dev, these things matter. As you move up the chain, you need to make sure that every interaction you have with others minimizes the cost of doing work for others. Seeing this in real life is what convinced me on the reality of this.

At my PS-1, we had this guy called Ajit Trivedi. Ajit would answer to pings at lightning speed, he would review PRs first thing he gets time, he would answer all your questions, move things around on a server or on staging instances all so you could get out of his hair and into work. Even if I wanted to take it a little slow, and figure out the specifics of Spring before diving into the work, I would be forced to do work, because Ajit would make it so easy, so cost-less to get started on that work.

The activation energy for a reaction being that low basically guarantees that the reaction is spontaneous. If you can do that, you have won. You have pulled work out of people that don't even know it.

In the initial days of the ChronoFactorem rewrite project, I constantly tested how fast I can respond, and how quick I can review and move ahead and no longer be the blocking task in their task queue. It worked magic. I have never seen so much backend code written by a team (not a single person) coordinating and agreeing on APIs and formats, etc. so fast.

When you are Dev Sec, this is what will matter. Getting work done through a team. I don't care if you can rewrite it in 2 days, it doesn't make you a good Dev Sec.

General Demeanor

You need to genuinely like everyone

Most important thing: You need to genuinely like them.

I know it sounds rude, but think about it. Does that imply you can only fake-like someone? Does that imply I don't like some people?

If you had to write one or two things you like about each member, you should be able to do it very easily. If you don't know someone that well yet, you absolutely need to go somehow interact with them. Whether it's oversee them on a project or go to their room randomly one day for fun, anything.

I suggest you do this exercise right now right this moment and pick up the member's list and write one thing you like about everyone. It shouldn't be superficial like "I like his hair". You should have real sentences to write about their personalities, and their behavior or their coding style or ability.

Dev members' dad

For all intents and purposes, you are basically supposed to act like a friendly dad to everyone in the club. No matter how much you like or dislike the member, no matter how small or big an achievement, club-related or unrelated, for every single moment that the members will cherish, you need to share that with them. I will clarify what this means in a second.

If your members are competing somewhere or they are performing on stage or somehow somewhere they are doing something where they showcase their talent, you should be there. This makes them feel more connected to you, and makes them feel much closer to you, since you are involved in their life outside the club. Treat this as work, and make yourself go.

In the long term, people might get tired of you pushing new projects on them, but as your friend, as someone close to you, they are much more likely to disclose what they feel like, and what they might not feel like doing. This will absolutely help the club members like you in the long term, and favor your decisions and will foster a culture of a club.

Meat People

Relevant clip for the title: https://www.youtube.com/watch?v=2AjVY9gkFUc from 0:00 to 0:15 idk i just needed something that's easy to remember for the title

As dev sec you should be the one running around with your FIC, with the CS department, with AUGSD, with TTD, with CCIT. Once you meet these guys and build a rapport or a relationship, life becomes easier. Ask them their names, where they're from, etc. If you are from the same place, try and talk a little in the language for fun.

Eventually, best case scenario, you want to be at a point where you can go out for coffee with these guys. They should know you that well. This is how pulling favors worked for me. I never got to the coffee stage, but they all knew my face and/or my name. This is how I got the CSIS server for cruX, this is how I got a subdomain for us on bits-hyderabad.ac.in, this is how I opened up so many ports on the server even against CCIT's own policies, this is how I got SSH access to AUGSD and TTD servers, this is how I got CMS admin perms to fix shit on my own, and this is why we get quick reimbursements and approvals from these guys.

Meet people. It helps so much. If you can befriend them, they are basically in your pocket. But of course, do not misuse the power you get from this. If you're trusted with all of cruX dev, I assume you can be trusted with this.

Make People Feel Important

One of the most important things you need to do is to make people feel important. When they are the ones being called "Chrono Dev" or "Lex Dev" or "Rideshare Dev" by their friends, it makes them feel important. When they are the ones writing the Facebook posts for updates and releases, it makes them feel important. Try to delegate away this stuff. You need to make your members visible in the public circle. This gives them some sort of pride in what they are doing for the club, and this status will make them feel personally responsible for their projects. This might prompt them to write more features, fix bugs, document more code, refactor and clean more code, etc. These are all tasks that you want to incentivize, and this is a great way of doing it.

Of course, you should ask them to write the FB post, and always ask them to wait for your approval before posting. You should make sure that the text is properly formatted, the first few lines of the post highlight the main incentive or main point of the post, that the post has a proper H1 heading, that it has an image attached to it no matter what, etc. These are things that they don't know, and you need to make them aware of it.

In fact, some of this work starts even before they are inducted. Until the 3rd round, don't have any praise in your emails for being selected to the next round. Only when you send them the mail saying that they are selected for the 3rd round, tell them that you have identified them as some of the best developers on campus. You need to make them feel important and capable. Members that are not confident will refrain from trying new things, going to competitions, and growing. You need to make them confident.

Once they are inducted, in the intro meet make sure you tell them how good they are, and that they should keep that in mind. Instill confidence in them. Let's be real, any of our first year members at the time of writing are definitely capable of applying for a GSoC. How many of them actually get it is a secondary question, but the fact that they aren't even trying is a problem.

This is not a club, this is THE club

Most clubs on campus are extremely inactive compared to us. Almost all the time, all our members in dev are working on something or the other. You need to maintain this as much as possible. Along with this, you need to maintain a certain culture of being a tight-knit community in the club.

Find articles from hackernews, dump them on general chat. Make members discuss about this. You are not just a software development club, you want people to talk about general interesting tech stuff as well. Once you do this, and do more things to build culture within the club, you will succeed at your goal of making people understand that this isn't just a club that they are part of, and that this is the main club they are in.

The music club actually does something similar. By simply being active, by cultivating a culture in their club, and openly talking about how they can do better performances, or winning contests and competitions, they have cultivated an idea that they are not like any other club. Similar to them, our analogue would be to have members understand that GDSC, IEEE, ACM, or CSA don't really do much compared to us. We are one of the most active tech clubs for a reason. Make them understand that ACM or IEEE workshops are much lower quality than our work, and make sure they are. They need to see cruX as a different league altogether, one where no other body on campus that focuses on computing can even come close to competing with how good we are.

Right after inductions, during intros, ask them which other clubs they are in, and actively try and compete with these clubs. In the members' heads, you are competing for their time in terms of work output. You need to be able to convince them that we are simply so good that they should forget completely about the other club and that their time is much better spent here. Of course, don't say any of this explicitly because it makes you look cringe and tryhard-y.

And note that this is not just convincing. Your work output really needs to be that much better in terms of quality compared to any of these other clubs. Once they see it, they will believe it.

The more you do this, the more time they will be willing to spend in the club, and the more they will work enthusiastically. Once you achieve this, you are smooth sailing and your senate can make sure the club is growing and working on great shit. You don't want them wasting their time doing a shitty ML workshop that costs 200 rupees in ATMoS where they scam the newest batch, you want them building out the future of tech on campus, and building good fucking software.

Culture

Meet Juniors and make them meet each other

Every sem, we hold inductions, and in the intro meet we make the new inductees do stupid shit as "interactions." We don't just do this for our own entertainment. It's an ice breaker. It's culture.

The more the activities involve talking to each other or calling each other by name, the better. This makes the members familiar with each other in mere minutes. You will forget people's names for the first week or so when you meet them, but not if something like this happens.

If you are not happy with the ideas of the club, fine. Maybe that evening wasn't that great. Some other evening in the free part of the sem, go to their rooms, ask them if they "want to go on an adventure" and take them to other juniors' rooms. Eventually gather like 3-5 of them, and make them do funny shit in the room itself. Fuck it, involve their roomies if they're chill with it.

Again, this is extremely important for the club juniors to know each other. I believe the only reason 23 batch is this well-connected with each other and everyone knows everyone else is because I did this twice during my term. It might sound silly and optional, but this is one way of getting new juniors to understanding that you are not just any other club, you are THE club, and that they need to treat this club specially. This is how you make them more willing to spend more time on this club instead of other clubs.

Mandatory Fun

I worked at a startup in my PS-1 called Lemnisk/Immensitas. Every Friday, HR would plan surprise activities at some random time in the afternoon for "Fun Friday." This would involve everyone in that small office, and all of us would do these activities together.

One day, my co-PS student asked me "Why do they make us do this? It's so clear from their faces that few people enjoy this." I simply smiled back saying "The fact that we are talking about how cringe the activity just shows that HR won."

Think about it. When they leave the office or when they go on Tea breaks after Fun Friday, what do you think happens? Do they stay silent in their own corners? No. They talk to each other about the activity. Some talk about how some team was very competitive, some talk about how they enjoyed it, some talk about how cringe it was. Either way, they are talking. It gives them something to talk about.

Mandatory fun. That's what that is. Whether you like it or not, it works.

This is one way to build culture. Of course, it's even nicer if you can make them actually like the event, say in the case of an outing, or an ANC treat, or just a gaming meet. But the reason companies do cringe shit instead of this is: it's controversial. The more people talk about it, the better.

It is cringe and that's exactly why I will quote one of my favorite movies, The Lunchbox (2013) (a movie you should absolutely watch btw):

I think we forget things if we have nobody to tell them to.

And this is why you should give them things to tell each other, and to their friends. That's how you stay memorable. That's how you keep people thinking about the club on their free time, and that's how you nudge them closer and closer to doing work.

Work Related

Maintain standards

You need to be very stringent on standards. The standard itself is not a goal. In reality, nothing on Earth fundamentally changes if all our commits are conventional commits. What matters is that they understand that their work reaches a certain standard when they work in this club. Their commits are properly done, their PRs are reviewed properly, their code is formatted and well structured, etc. These standards of course make a codebase more readable, approachable, beautiful and more maintainable, but more importantly, getting the first PR merged feels like an achievement for any member. It is a stamp of approval saying that their work meets a certain level of quality.

This instills confidence in them, and it comes back to the point that it makes them feel more important. Unless you are in an emergency situation where you need to act in a matter of minutes, maintain these standards. Make sure every PR is reviewed, make sure code is well formatted, make sure code is well documented, make sure commits are properly formatted. If any of this is not maintained, ask the members to fix it. Rebasing is an important git skill to learn.

These things will make repos nicer, and it shows a level of understanding, experience, and expertise on both yours' and the members' side. When I shared my room with a senior software developer in his 30s in my PS-1, when he overheard the ChronoFactorem meets, he asked me why I was working overtime during an internship. When I clarified that this was a club, he was actually shocked to see that level of attention to detail in a student club, and said that he's only heard this kinda stuff from senior SDEs at Amazon. The amount of care we put into our work is industry-level, and you should maintain that.

This also comes back to the point of making members understanding that this is THE club. Your work output needs to be high quality to convince them of it.

If there is one thing in this document you do, it is this.

Making dying a little easier

When you end your term, you will feel old. You will be a 4th year. It's a scary feeling to reckon with. Your college life will probably end in a semester or two. Your friends won't live a few steps away, they might end up in different cities, they might even disappear forever. It will be quite a shock. You might even have regrets as to what you could have done better for the club, or maybe you'll have regrets that you were too busy and didn't spend enough time with your friends.

It's a pretty scary shock, but you will face it. Me describing it will not even make you remotely ready to comprehend it when it's in your face. The shock is bad for you and for the club. But, it doesn't need to be that way. Here's how to make dying, retiring and fading into obscurity a little easier.

Few things you need to remember:

• After or during the 2nd semester's inductions, when all the members are present, bring up the words "next senate." Maybe even ask hopeful applicants if they are thinking of applying. This sudden realization paired with a sentence like "Hey listen you guys need to know this because next semester one of you will be sitting where I am sitting, making people move around and making sure interviews are going smoothly." will absolutely evoke imagery, and you need to make use of that. This makes them consider it more strongly. It is in your interests to market the senate position to juniors and make them think about it, because you want good applicants. You want a good next senate so that your work isn't forgotten and wiped away. You didn't do all that work for nothing.
• Talk and show members what you are doing and why. In Techweek, I attended Penty and Advik's workshop, and while leaving, I made sure I showed them every single one of my conscious decisions. I told them why we stayed in the room till the end of the booking time to avoid issues where someone else would do something bad, and the room would be open in our name, causing liability issues. I told them that if we really didn't need the room how I would talk to the security guard to lock it early to avoid liability issues. I pointed out how I made sure everyone left, and I was the one to turn off the switches and equipment to once again avoid liability issues. I made every single one of these things transparent, and told them that if they end up being senate members, they need to remember these kinds of things. Even if the people in the room aren't hopeful applicants, atleast make sure to transfer this info to them or some junior. It might be helpful to them even if they don't end up in the senate.
• Kidnap juniors for work sometimes. When you visit TTD, or AUGSD, or CCIT, try and find some junior near the library or some junior that's free, and take them with you. Tell them that they will shut the fuck up and watch what you are doing. After this is done, once you are done, you can explain why you went there and for what work, and why you talked the way you did and used some words over others.
• Ignore Techweek completely. The only work you should be doing for techweek is getting juniors to finalize the event list, finalizing PoCs, and attending these events as a spectator. Once you are done with all this, just observe. The process of seeing juniors bump into walls and find solutions to their problems in techweek will show you in real time people's ability as PoRs. The fact that someone is enthusiastic and ready to take up leadership roles like PoCs is also another good indicator. Techweek is a great way to judge members for the future senate.

Make the next guy's job easier

Funnily enough, at the end of your term, you will be an infinitely more capable Dev Sec than anyone else in the club at that time. Unfortunately, even if you are better for the club than others, your term has to come to an end.

But that doesn't mean that the next senate needs to bump into the same hurdles as you did. Pass on your experience. Pass on what you learnt, and what stuff you experimented with. Pass on what you think will work for the club. Pass on your regrets, and suggestions. Make an edited version of this document and pass it on to the next guy to explain how to do a good job as dev sec.

You can never force the next senate to listen to you, but if they're smart they will at the very least listen to you.

There's a reason I maintained 2 separate docs. This is the doc containing all the successful experiments and the statements I am absolutely sure of. This doc is the doc with my successes and what I have learnt. The other doc, is the doc with my regrets. It contains my suggestions. It is what I observe as my failures, and ways to improve on them, and become a more successful senate than mine.

The reason I suggest these be 2 separate docs is because this one is more or less timeless. Aside from commentary about contemporary events that happened in my senate, all these points are true for the club regardless of time. The other doc however, contains suggestions. We don't know if those suggestions will succeed or not. We don't know how useful these suggestions might be to future senates.

This doc can be quickly edited and you can add some headings in here to reflect some new stuff you have learnt. The other doc should be completely rewritten top-down. If you are at a point where you want to edit the other doc, you have failed. Ideally, you should have tried all of those suggestions, and reported on their success. If they were successful, they end up here. If not, they are removed.

Either way, I hope this doc helps. Either now, or over the course of your term, I hope this doc helps. The motivation for writing such a doc with such detailed advice with examples was the fact that I had to figure all of this out by myself. Srikant never told me what he learnt, or how to be a good dev sec. I had to do all of this by myself. I hope you don't have to go through the same slow process of learning, and that's why I wrote this doc.

By far, applying for Dev Sec was the best decision I've made in my life because of how much I learnt from it, and how much I was able to achieve. I got to build insane social skills, and I got to watch a more-or-less dead club become one of the most important, active, and close-knit club on campus, and for that I am endlessly thankful. Thank you 20 batch for making me Dev Sec, and thank you for not impeaching me.

I hope that at the end of your term you look back and feel similarly good about your term.

Thanks, and good luck.

~ Soumitra Shewale (21 batch senate)

Addendum:

Context: Why I Wanted to be Sec & why I cared

The next part is me giving context about why I put in so much effort, and why I cared so much about this role. I think the context and history will be useful to gauge how much of an impact someone can really have on a club. I want you to look at this history and realize how lucky you guys are. If we started from these scraps and reached this point, if you guys start off from here, you can build insane shit, and really take stuff to the next level. This amount of growth is unprecedented, and I want you to acknowledge that and promise to uphold it, and not wipe all our work away.

When I first joined the club, the club was pretty inactive because right after COVID, this was the first time everyone was on campus. I, being the impatient fuck I was, since I just got into the club, I really wanted something to do. Almost every other day, I bugged seniors to give me work, and I mostly just got ignored, or met with a "wait". Eventually, I think I ranted on the cruX WhatsApp (complete logs of which I have lost, partial logs are in this doc), and the seniors ended up scolding me for not respecting their time.

Some examples:

I eventually gave up on cruX for a while, and wanted to start a new club with my wingies, that would replace cruX and be more committed to Open Source contributions. Sarthak and I wanted this the most, because we saw just how dysfunctional cruX was at the time. Even after getting in after the months of inductions, and begging for work, I basically got nothing.

I'm adding a few more screenshots to show the perception of cruX at that time. Looking back, it is almost funny how the state of the club is now almost completely reversed.

And then eventually, I ended up meeting the ex-prez of cruX, and I asked him a bunch of questions about cruX, and what the club is supposed to be. This cleared up a lot of my misunderstandings about the club, and the state of the campus tech culture at that point.

Eventually, seeing the absolute state of things, I wanted to hold a workshop that would introduce people to development. The idea was to use Python in a fuckton of ways to show people the cool stuff you can build with it. My hope was that people would see this and try and build something similarly cool, and that would be their gateway to dev.

And here you can kinda see why I don't care about CC at all. Today probably I will have the opposite opinion, since CC seems to really be struggling with getting people interested. Hopefully Varun does a good job.

And then eventually you can see me losing interest in the club I wanted to make, because my workshop was greenlit, and I started work on it finally.

Sarthak of course, still retained his interest in the Open Source club, and eventually it became what we now know as Society of Open Source. Their goal changed from making more people contribute to open source, to getting people interested in the usage of Open Source software and the propagation of Free Software and Open Source ideology.

Eventually, I ended up staying in cruX because the members finally decided they wanted to make the club active again.

And then ofc this was the legendary time I got scolded on cruX group

The actual WhatsApp log was actually before the workshop was organized ofc. Since this guy was the prez, I had to go through him for all this.

And then eventually we came up with the primal idea of an ARG, which due to timing and feasibility constraints got reduced to cruXipher

This one isn't even relevant I just think it's a cool screenshot because of how true it became. Today all 3 of the users in the screenshot have worked on ChronoFactorem rewrite.

Again, please realize how lucky you guys are. You can build insane shit, and I really hope you have the spark in you, to try and do it. Of course, the natural request is to atleast maintain the work we have done, and not let it go to waste, but I hope you have the drive to go above and beyond this. The club at this point has so much potential to do good, and I hope after seeing this history, you are moved to turn that potential into reality over the course of your term.

Good luck, and I hope this document helps.

Thanks, and good luck.

~ Soumitra Shewale (21 batch senate)

Recommendations for CRUx Senate AY2024-25

This document is completely different from the previous one. In this document, I will discuss some ideas for the senate that we realized could be good for the club during our term, during the senate interviews, etc. I will list them in 2 categories: first, what NOT to do, and second what to do.

Of course, as is true with all the docs we send you, you can choose to completely ignore our advice. However, since I believe our term was more than reasonably successful in terms of reviving club activity and culture, I believe that at the end of our term I am much wiser, and I have a better idea of what ideas will work for the club, and which won't.

What NOT to do

1. cruX Forum

I think it is finally time we retire this name. Alumni, 21 batch, and 22 batch all have very different conceptions of these words.

There are 3 definitions of this word as per my understanding that are floating around:

• The project and group of repos that cruX worked on back in 2020-2022. The project was meant to be purely a Facebook replacement.
• The idea that we should build services like Multipartus, Chrono, Rideshare, etc., and eventually Buy&Sell, Shoutbox, FreeExpressionGroup, etc. to create a network of services that we maintain for campus, which will eventually aim to replace the usage of Facebook with our apps.
• The idea that we should build services like Multipartus, Chrono, Rideshare, cruXAuth, etc., to create a network of services that we maintain for campus. This is the extent of the idea, and there is no intention of replacing Facebook. All we want is integrations between cruX services instead of having them be completely standalone.

I believe that simply because of the confusing name, we should retire this name completely. I stuck with the name because I believed people's perceptions would switch over, but I don't think this has happened.

Let's be clear: cruX should not be working to replace Facebook in it's entirety or a major chunk of it in the short term. Our job is not to build and maintain a huge communication network. It is too big of a project for the members of cruX, and it will end up being a burden on us.

The General Body already does not value ChronoFactorem and Rideshare, and they will likely find Lex to be cool for the first few months, and then stop valuing it as well. What I mean by this, is that any outage, whether it's your fault or not, will be blamed on you, and it will hurt the GB's perception of you.

GB projects are great because they give us leverage over the tech senate and the GB. However, if we want to maintain this leverage, we need to make sure these projects are maintained, and they are maintained well. Their operation must be buttery smooth. Only then, is there a room for expansion of GB projects.

I wholeheartedly believe that we are not at a phase where we should be expanding into more GB projects, and we should spend time into making the existing GB projects more maintainable, and polishing the features of the existing GB projects. Only once the existing GB projects are running buttery smooth, and they all have systems in place to check validity of releases, and have adequate documentation, we should branch out into more projects.

Even after this, ShoutBox and FreeExpressionGroup are some of the last services we should be building. The case for a separate app is much more pronounced and obvious in the case of Buy&Sell, and Rideshare. Simply broadcasting text and media to the rest of the campus is not an urgent use case. Buy&Sell, and other similar such specialized groups on Facebook should be the ones we target next.

So, when we mean that cruX forum is a very long term outlook to tech culture on this campus, we mean long term in the span of multiple senates. Maybe 5-10 years down the line, we will find that the campus communicates not on Facebook, but on WhatsApp, or maybe even some new app. The dynamics of such a change should not be our concern right now.

2. Too much dependence on proposed "BITS Summer/Winter of Code"

One idea proposed during the senate interviews was a workshop/contest/event where we encourage GB members to contribute to some of our repos. To be clear, the idea is not bad. The idea is actually pretty good. However, as we stand now, there are many issues with this, and I will highlight them.

None of our projects are at the point where we can expect external contributors to contribute. Our projects are horribly documented, the documentation is not available to the public, the DB schema is not well explained in the README, and usually the README contains only the most basic stuff.

Beyond just this, we do not have enough projects to expect contributions on. Lex is still in progress, and much of it is in the stage where we need to make core decisions with respect to how we want the app to be. ChronoFactorem and Rideshare are the only finished projects that are in production. Beyond this, we do have cruX website, but that's not exactly a great repo for people to learn from, since it's laser focused on implementing what's in the Figma and nothing else.

Other than this, we have Lumos, BITSGPT, and the torrent client. All of these are pretty unknown in the sense that they are all experimental projects, where the final outcome is not known. We are just kinda trying stuff and seeing if it works.

To summarize, we don't have enough projects, and the few projects that we do have, we cannot in their current state expect people to contribute to them. To get them to that state, we need to have a concerted effort throughout the club to effectively document all existing projects.

There will need to be a lot of work put in before we can even dream of something like a BITS Summer/Winter of Code.

What to do

1. Project Leads/PoCs

Assign one PoC or project lead to every project. Maybe even assign multiple (a max of 2). These PoCs need to make sure that the projects are progressing as normal, and they will be the ones updating the Dev Sec and President about the status of these projects in the review meets.

Project leads will be way more effective than a domain lead, since a domain is usually split into many parts working on different projects. Project members will also now have a person to answer to, and this delegates away the Dev Sec's job of personally reminding all project members about the project progress.

Of course, the project PoCs chosen will need to be active and trusted members of the club. These PoCs will also hopefully make the future decisions of whom to make Dev Sec or President more apparent.

2. Summer groups

Last year, dev was unable to hold a summer group because Ansh Kanotra (Tech Sec) requested us to hold the summer groups during the semester. Since ATMoS work overwhelmed dev members, we decided that CC will hold their summer group during Sem I, and dev will do so in Sem II.

However, during ATMoS the senate was replaced, and at that point we had other more important things to worry about than summer groups. It felt as if the club was crumbling, and we had to act quickly to get the club back where it was. Our inductions got stretched into the next sem due to this, and that caused further delays.

In the second part of the semester, we ended up having to worry about TechWeek as well, and we ended up doing whatever little work on projects we could. Sem II inductions also started around that time.

Due to this, we are massively overdue for a summer group, and in some ways I'd argue it has affected our member intake. We are noticing that the size of the club for 22 batch and below has significantly reduced compared to 21 batch's size.

I highly recommend hosting:

• Dev summer groups (however many domains you have)
• UI/UX summer group (since we are suffering from a lack of UI/UX members)
• CTF summer group (to keep the momentum of the relatively alive CTF division going)

I recommend that these summer groups post their content on GitBook, or Rust MDBook, or even Astro's MD/MDX formatter, and keep both WhatsApp and Discord groups for summer groups. This will maximize the reach of the summer groups, while still allowing you to maintain a structured discord server. Of course, you have more work when posting, but all you need to do is copy paste a discord announcement with a website link onto WhatsApp.

I believe this is the thing we need the most during the summer, and members that aren't working on summer groups should work on maintaining and completing our existing projects.

I also recommend holding a hackathon or CTF contest at the end of the summer groups, since this allows you to properly gauge the effect you have had on the people following along.

3. Increase the number of workshops and sprints

Since we seem to be running out of new ideas for projects, we should focus on maintaining our existing projects or finishing them. The members that are free, should heavily consider holding workshops or sprints internally or for the GB. The senate needs to find incentives that will make it easier than ever for members to host workshops.

A basic programming workshop would be a good idea in Sem I, since 24 batch will just arrive on campus. If this general purpose programming workshop helps them grasp programming better, in the long run it will benefit more advanced workshops, and it might even benefit dev and CC inductions, since more people are nudged towards learning about these topics.

This workshop could also be a good means to advertise or link the summer groups that happened over the summer. Interested students can go through the summer groups at their own pace as well.

As for sprints, I believe another Docker or Nginx basic deployment sprint is needed, since we will have new members at the end of this induction cycle, who have no idea about how we deploy and automate things here at cruX. Maybe a better alternative would be to document all this in a common place, with some other conventions we use in cruX. This should be done while engaging the new inductees, because this is something they will need regardless, and it's a pretty small task.

4. Create a knowledge base for CTFs

This one is pretty easy. The new cruX website is in Astro, and Astro has a nice markdown plugin we can easily use to maintain our knowledge base. This doesn't necessarily need to be a list of writeups, it can just be interesting concepts or questions that someone might have done a deep dive into.

5. Fix the project stagnation issue

The biggest issue with projects in dev right now is the fact that projects have in some form stagnated. Once you become senate, in your first meet, please go over the list of projects in dev, and ask the members what they see as the future of the project. I believe Lumos might not see a future, and Game Dev might have to think of new projects, since the original maintainers will be gone at the end of next semester.

Beyond this, the projects that are in dire need of good understanding of maintenance across years, are terribly documented, and a lot of the code could be cleaner and refactored. This refers to ChronoFactorem, Rideshare and Lex.

One of your biggest priorities should be finishing, polishing, and documenting these projects and their know-how. Once this is done, we can go back to maintaining then for a few months and testing if we can branch into newer projects.

If you have more innovative solutions, please discuss them, or bring them up to the previous senate.

6. Create a culture of doing challenges and events together

When I say events it need not mean hackathons or competitions. It could mean simple challenges.

For example, you could try and rope in a bunch of people interested in learning any new language and creating an accountability group that makes sure everyone else did the Advent of Code challenge for that day.

Another example was the 1 Billion Row Challenge: https://1brc.dev/

You could also look at specific code golf or automation or scripting challenges.

Small trends and challenges like these will build a culture of doing something together that's not necessarily club work, out of their own will.

cruX is a club of hobbyists, but funnily enough we don't participate in programming as a hobby together, and as a club there is some potential to be explored there.

7. Event and Project Post-Mortems

For any given event, say a workshop you conduct, or a summer group, or some ATMoS or TechWeek event, sit the organizers or whoever was involved down in a meet, with maybe a few other interested people in the club, and discuss what you did well, and what we could have done better.

Discuss why things went the way they did, and discuss if you could improve on some of these things. In my entire term, I ended up doing this only once, but it was extremely helpful in retrospect.

This whole idea can be applied to Project releases as well. ChronoFactorem and Rideshare have releases that are around the start/end of semesters, and these are fairly periodic events after which you can hold a meet with everyone involved in the project.

8. Encourage GSoC and other event participation

GSoC seems to be the most prestigious and most worth-it event in terms of time spent. Try and make sure that 1st years apply at the end of their 1-2, since this is the prime time for them. Since these members got inducted in their 1st year, chances are that they are probably really good from the get go.

Try and nudge them towards Open Source contributions, and explain to them the potential they have. You will have to put the idea in their head months before the application deadline, so that they get time to not only consider applying, but acting on it.

Higher amount of participation in GSoC will obviously make us look better in the eyes of the GB and senate, but it will also boost our prestige outside of this campus, and even in open source communities.

If you can manage to create a cycle next year encouraging 1st years to apply to GSoC in their free summer break, this would be great for both them and you. It's likely that this will be the only free summer they have in their college life, due to PS-1, SI Prep, and SI.

9. Speed up induction process

The round 1 sheet should be released instantly as the form is opened, so that over the period that the sheet is opened, people can review the sheet and fill in their remarks. The whole round 1 process should not exceed 48 hours after the form closes. You can do this by incentivizing free ANC treats to the one that reviews most submissions.

If you can manage this, it means you can manage holding R2 in the same week. If you can do that, then you can send out R3 tasks the next week, leaving them 10-14 days for R3. After those 10-14 days, you can schedule their interviews over a week, or 10 days at max.

This gives you an inductions scenario of 20-30 days. This is still a good case. In these 20-30 days, 10-14 will be spent waiting for the projects to be submitted. You need to make sure this time is spent wisely, because with 1 induction cycle per sem, and 1 midsem and 1 compre every sem, you are left with a total of 12 - 2(1 + 1 + 1) = 6 months of real work.

Out of these 6 months, 2 are spent in the summer on summer groups, giving only 4 months of project work that you can use. This is why having inductions faster and finishing them as fast as you can is critical. If you can save time and get those 2 months back somehow by being smart with scheduling, you can net a gain of 50% time in your tenure.

A 50% gain on time is one to kill for.

Speed up inductions. Inductions put the club into a freezer.

10. More interactive feedback for R3

There are a lot of devs that get to R3, but they lack certain skills, or aren't as experienced or polished. Usually, these guys get rejected, and we hope that they apply next sem, by dangling a direct R3 selection in front of them.

Instead of this, if you can assign them a capable mentor, maybe the person that took their R3, and give them 2 more weeks or a month or so to fix their shortcomings, this is a much better strategy to ensuring quicker induction turnovers. Of course, on paper, their name will come out in the next sem's Facebook post, but you can unofficially induct such members into the club earlier.

It's extremely important that inductions result in better prospective members if rejected, and that inductions are sped up.

In conclusion, these are all the suggestions I have for the CRUx Senate AY2024-25. I believe if all of these ideas were implemented, you would see unimaginable growth in terms of the member quality, and the quality of the work we produce, and your senate will be a huge success.

I hope you guys take some of this advice for your own good, and continue this newfound tradition of imparting knowledge and experience to the next senate. I believe this is what will help the club progress in the long term, and truly cause growth in the tech culture both inside the club, and on campus as well.

If you have the ability to give a shit about this, the change you could bring to this campus will be unimaginable.

I hope that when I look back at AY2024-25, when I leave for my PS or Thesis, I look back at the senate's progress and say "My senate walked so their senate could launch rockets to the fucking moon."

Thanks, and good luck.

~ Soumitra Shewale (21 batch senate)

Voting

This will be a short one. There's this one quote I thought about a lot when reading news about the 2024 US Presidential Elections, and it's this one:

Remember, there are no reluctant votes or hesitant votes or compromising votes or votes with asterisks next to them. There are only votes.

I like this quote a lot, and I wish more people thought about it as they go vote in elections, especially this cycle of elections (2024).

Disclaimers

You can go seek the original source of this quote but I don't want to explicitly disclose it. I want to make it perfectly clear that I don't endorse the original source, nor explicitly disagree with the original source. I neither endorse nor disavow the source article, and the person that wrote said article. This is because I try not to explicitly state my political opinions and leanings in public, and I will try not to do that on this blog unless I feel very strongly about it.

To clear up another possible misunderstanding, I think this quote should not be construed as an endorsement of voting for a third-party candidate in a system that favors a two-party arrangement. I think the Spoiler Effect is very real, and you should always vote for the lesser of two evils in such a system. Even in such a scenario, if you re-read this quote, you might notice that it applies to you as well. There are no votes with asterisks that allow that vote to be transferred to another party in case your candidate loses (unless your voting system allows for runoff voting). In a multi-party system that allows for coalitions, it makes sense to vote for a smaller party.