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:
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.