11 things I learned from my software engineering class

How I was chosen

While (I think) all other classes had their leaders chosen by the instructor, our instructor opted to let the rest of my class choose. For some reason, my classmates didn't even have to stop and think. They just pointed at me. Perhaps that's because my batchmates in UPLB recognize me as some sort of expert. But for whatever reason, they trusted me with one of the biggest projects of their BSCS degree.

Non-technical lessons

1. This is *the* biggest one. You cannot mask ineffective leadership by overcontribution. Yes, I was the one with the most commits, most hours worked. I could give myself a medal. But I realized that's not a good approach because I wasn't going out of my comfort zone. Coding for 14 hours, while difficult, is a difficulty I'm personally accustomed to. But confronting people for their shortcomings, motivating them, and keeping team morale is not something I'm naturally good at.

2. Make people *own* things instead of just handing out tasks. People will end up more passionate about their work if they fully understand why they are doing it and that it is their brainchild so to speak

3. The power of passive aggressive corpo-speak messages insanely underrated and works well to get people to do their shit LMAO

4. Since the last company I worked at was a startup (E-Konsulta), there's sort of a mindset where you should be quick, document as little as possible, and just do the work. When you're leading a bunch of people of which some have underdeveloped communication skills and work ethic, this is less applicable. You should consistently track the tasks of the team.

5. The beginning of any project is crucial in identifying who among in your team are the GOATs, the responsible people who take ownership, and those who tend to lag behind or procrastinate. Use this information wisely throughout the rest of the project to inform decisions on delegation.

6. Democracy is unreliable, and you shouldn't form a subteam without a leader.

Technical lessons

1. Clearly communicate to people that if you code something, you should be the one to ensure that it gets to production.

2. Clearly communicate the concept of code being stale and how a PR only has a life span before siya maging incompatiible with the current production code

3. GitHub Dependabot and Security code scanning should definitely be used for production projects

4. Keep GitHub PR templates simple. Don't add a huge checklist of tests that don't apply to the project.

5. It is NEVER too late to resolve technical debt. I had the choice of whether or not to resolve something 4 weeks before the final deadline. I chose not too because I thought it's too late, but that specific thing was a big headache for those four weeks.