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)