My MDM Term 1 Self Retrospective

My first term at MDM was just finished, finally. But it’s not done yet. Looking back, it has been an overall hectic but rewarding term. To wrap up, there’s something that I’d like to reflect on from a developer’s perspective.

If not coding, what else shall I do?

As a developer who’s been working in teams large or small, I didn’t expect any major challenges in teamwork before. Knowing that I would work with people from totally different backgrounds, I merely took it as a good learning opportunity. “I would just do my best job as a developer to fulfill any need in delivering a working application while watching designers create beautiful prototypes, where I could potentially learn about some design principles and practices.” But I was soon proved wrong by the brutal facts. It’s definitely not as simple as that.

It’s no longer like my other school projects where the team just brainstormed and picked one idea and went straight to build it up, and spent tons of time on the actual product development. Here, on the other hand, the design process has been given the highest priority, which was especially the case for my Project 1. So my first lesson was to adjust a solo developer’s mindset and adapt my role to fit into whatever the team needs the most at the moment. Your value doesn’t have to be validated through your profession. Investment in developing a product that no one would use is meaningless. I ended up helping a lot with user research and more grounding work to validate the design before grinding into the code too early.

Should I take the lead?

In my empirical knowledge, PMs are the people who need to take the lead and make a decision for the team. But in a student team like this, there was no strict hierarchical relationship per se. Even when there is a PM on the team, communications are rather flat and open. So what I later found out was that people who were more experienced or working on the main prototype typically had more say on a design-level question or future directions in the development cycle.

Interestingly, being the only developer in both Project 1 and Game Design teams, the roles that I took on and the circumstances that I encountered were quite different. Since I was not developing the main UX prototype for Project 1, I would have to push a bit harder to make my proposed idea sound solid and convincing. But when it came to my Game Design project where I became the hardcore developer for the entire game prototype, I did feel more control over it. When I was creating the core gameplay, I also grew a better understanding of the mechanics, and it just implicitly gave me the privilege to take on a leadership role sometimes, to propose new features to optimize the experience on a firm stand.

Should I take the lead, as a developer? It depends. If you’re not taking the lead role, then it’s sometimes very hard to make a huge impact on the team and push the whole team to move towards your proposed direction. But if you’ve become the lead, what comes to you is more responsibility and much more to be concerned about, ranging from aligning every team member to figuring out the pros and cons of a certain decision, other than doing the developer’s job. It’s rather important to identify your position in the team and balance off your role as a leader and a follower for the team to move further.

Should I still do it if it's not important to the team?

When there is no harsh requirement on the technical side when a UX prototype could suffice, should I still go ahead to do the development work? Is there a point other than proving that I am not bad at coding?

It may bring to a question with regard to the team’s objective v.s. personal objective. When the team’s objective on the technical deliverable is rather loose, and your personal objective is to learn new technologies and expand your skillset, then it won’t hurt sparing some extra time to investigate the technologies you’re interested in and create a proof of concept to demonstrate potentials for future development. The learning and growth are definitely worth the efforts despite being optional. Nonetheless, always remember to do it in your own capacity.

Overall, there were lots of valuable takeaways from the past term’s project work, redefining collaboration, and the role of a developer in a small but diverse team. Looking forward to what the next round of challenges would bring me. More surprises? Aim for good…