My experience as a Protege Developer at MYOB

Long Nguyen
9 min readAug 6, 2020

--

On Wednesday 29 May 2019, I received an email saying that I got the role of Protege Developer at MYOB. I was just over the moon.

I applied to MYOB as part of the Professional Placement program from my university, where I got to work in the industry for 1 year before getting back to uni to finish my degree. I started at MYOB on Tuesday 30 July 2019 and Friday 31 July 2020 was my last day as a Protege.

It has been a phenomenal year of learning, growing and meeting exceptional people for me. The experience has exceeded my expectations in every way possible and given me a great start for my journey in the tech industry.

About the role

The Protege Developer role falls under the Future Makers Academy (FMA). It is essentially MYOB’s graduate program and the role is externally referred to as Graduate Software Developer. The program has 2 main phases — Acceleration and Crew Rotation.

In the Acceleration phase, you focus on developing your skills, as well as learn best practices and other key concepts, with the help of your assigned mentors. Then you will put those skills to use in real-world projects when you go into crew rotations, which is when you join different teams/crews in MYOB.

The program aims to equip you with the vital knowledge and skills, regardless of your background, to get started and accelerate you on your path to becoming an effective software developer.

I spent my first 3 months in Acceleration, followed by 3 rotations, each of which also lasted about 3 months. I joined 1 DevOps crew — Replicant, and 2 full-stack crews — Tron and Skytree. All have pretty cool names. Here are just some of the highlights of my learnings and experiences over those 12 months.

Having mentors is more important than I thought

Source: Jonathan Jennings

I never had a mentor before joining MYOB, I don’t think I even knew about the concept of mentorship, hence my extreme surprise when I heard that I would be getting not 1, but 2 mentors when I was in Acceleration. Both of them were amazing.

They took turns to pair with me every single day, teaching me from the simplest yet essential things like keyboard shortcut, to more complex skills like presenting/white-boarding ideas, problem break-down or solution design. Despite their busy schedule, they still made time to sit and do code reviews with me, giving feedback on my understanding of different concepts and coding principles. Hearing them discussing pros and cons of different solutions and sharing their experience was eye-opening.

While learning in university, I felt like I was getting different, separated blocks of knowledge without any links together, hence I didn’t know how to use them at all. My mentors, having been through that experience, helped me fill in those blanks and make sense of the practicality of such knowledge.

While I was in crew rotations, I also had different crew mentors. They were also extremely awesome and I was super grateful for how much care they showed for me. They would pair with me constantly for the first couple of weeks to help me get familiar with the team’s codebase, technology and system of work. In addition to that, we had regularly catch-ups even on the days I was pairing with other developers in the team. I was really surprised that my mentors would block out 1 hour of their day just to explain a concept to me or walk through a piece of code where I got stuck. Their experience bridged my knowledge gaps that would have taken me years to figure out.

Within 12 months, I learnt more than what I did the previous 3 years combined. The growth I had while having mentors was just exponential.

My Acceleration mentors and I at lunch on my last day before I moved to Crew Rotation

Whiteboarding — a new skill I never knew I needed

Developers do whiteboarding quite extensively in MYOB to express ideas, sharing knowledge and invoking insightful conversations.

Since I’m mostly a very visual person, this turns out to be a super helpful tool for me to gain deeper understanding of anything. It helps you reorder and solidify your knowledge by visualising different components, their relations to each other and where they stand in the bigger picture. I find it much easier recalling new learnings when I can remember the image of how they relate to my existing ones.

But there was actually a bit of a learning curve for me transitioning from my usual pen and paper to marker and whiteboard, especially when I was whiteboarding for an audience.

I had to get used to the much larger scale of the image I was drawing (compared to on a piece of paper) and positioning them so that there’s enough space for everything and the audience could clearly see what’s going on. Coordinating all that calculation while talking could be quite challenging. Another mental factor worth mentioning is that it tends to involve at least 2 ‘spectators’ so it would be like a mini presentation where you make your ‘slides’ on the fly and we all know how scary presentation can be 😣.

A couple of things that I’ve done to ease myself into it were trying to talk slower, doing one thing at a time (draw a little bit, then talk about it, then draw another one), taking a step back every now and then even for a few seconds just to see how your drawing is going and taking a breath, and doing some preparation like drawing some drafts beforehand.

From the audience perspective, it would be an interesting experience as well. For example, if you are whiteboarding a topic to your mentors, they can clearly see where you are super confident at and what are the exact information gaps needing to be filled.

A couple of examples of my whiteboarding during my crew rotations:

This was one of my first whiteboarding sessions during my rotation in Replicant. In it, I explained what I had learnt about different AWS services and how they work. I was drawing a simple architecture of a regular web application deployed on VPC while utilising Route53, S3, ELB, ASG, etc.

Whiteboarding AWS services

In the white-boarding session after that, I explained Docker architecture, Docker networking and just the usage of Docker in general.

Whiteboarding Docker

Since the start of COVID-19 pandemic, I had to make a transition to digital whiteboarding — which was an interesting experience.

This was my white-boarding session about Kubernetes basics. It was a bit harder to draw with your mouse, but the benefit of whiteboarding was still there.

Whiteboarding Kubernetes basic architecture — not my best hand/mouse writing

Later on, when I moved to Skytree team, I also had a few whiteboarding sessions with my mentors about topics like BFF pattern, flux model, etc. But for this time, I used draw.io so that my drawing/writing could be easier to read 😂.

A fraction of the whole architecture where flux model is in use

“A team that dines together performs better together”

I borrowed that quote from Skytree’s homepage because it captured quite well one of the findings that I think was interesting. I did a quick Google search too and there was a study about this from Cornell University. I think this quote by no means is saying that teams that do not eat together will not perform well, but more about teams that understand each other on a more personal level tend to perform better. It just happens that dining together is a good activity for bonding and I guess, it rhymes better.

I was lucky enough that the 3 teams that I’ve joined were all amazing and high-functioning teams. They all have that same attribute of teammates knowing each other more than just the working context and having regular bonding activities like eating lunch, having daily casual chats, playing games together or sharing the joy of each other’s achievements. For Tron, we were having daily lunches together; for Replicant, it was the early morning chats about brewing beers; for Skytree, it was our daily bevvy chats with quizzes or games.

Skytree playing Geoguessr together

I always felt like I was in a very trusting environment while I was in these crews. Everyone, including me, felt comfortable asking questions, sharing their learnings and personal experiences, expressing their ideas. We felt safe to say “I am not sure about this, can anyone give me a hand” because we know the other members would respond or back us up.

This kind of synergy helps not only existing members strengthen their bonds but also helps newcomers to the team get along and fit in quickly. For a Protege who is basically a temporary team member like me, I think that would be one of the biggest contributor to a successful crew rotation. It helps me get out of my invisible fear of weighing the team down with silly questions or not contributing enough quicker and start learning because my team knows me, my background, my motivations and I know theirs.

In addition to that, when I understand my team more, I have this urge of contributing to the team. I put my focus on “what can I do to help the team” rather than simply “what could I learn from this rotation”. I feel like helping the team is a stronger and more effective driver for me and I do learn a lot from doing that.

Some other miscellaneous learnings

Technical learnings

While being a Protege, I got to learn about coding principles/practices like SOLID principles, 4 rules of simple design, Test Driven Development and technologies like Docker, Kubernetes, AWS, Azure, React, .NET and applied them to real-world problems, working on production systems. Using tools like Git and Jira were also something I got a lot better at.

Other developers in the company host regular brown bag sessions sharing their knowledge of new technologies, practices or architectural design which are really interesting and insightful. I have been to a React 16 brown bag, an “async await in JS” brown bag. There are even workshops organised by different teams. Some of the ones I went to were Web Vulnerabilities 101 by the security team, Linux and Docker 101 by DevOps teams.

Collaboration with other roles

While acquiring technical knowledge, I also got the chance to learn about other roles that a developer would work closely with like business analyst (BA), quality analyst (QA), product designer (PD), engineering manager (EM), delivery manager (DM) and product manager (PM). I got exposed to different activities like backlog grooming, backlog prioritisation, regression testing, user research, etc. It helps with my understanding of the end to end process, being more T-shape oriented and having more empathy towards other roles.

Servant leadership

I was fortunate enough to have the chance to work under some amazing Leaders and Managers. I first heard of this concept while talking with one of my managers. All of the development leads or managers I have met in MYOB have this kind of mindset. Their goal is to enable people and provide the team with the best environment to do their job. They take the lead in sharing their stories, creating a sense of community which makes them more human and close to the team. They help you align your personal development goal with the team’s goals, finding and giving you opportunities to grow and achieve those.

Final words

My one year in MYOB as a Protege has equipped me with vital tools, knowledge, attitude and perspective to get started on my journey in the tech industry. I’m deeply grateful for the opportunities to have worked with many amazing people and to have learnt and grown under all of my mentors.

My experience here just consolidates how much I love working in tech. I am pleased to say that my journey with MYOB still continues as I was fortunate enough to have been offered a part-time position of Associate Developer while I return to full-time uni to complete my degree.

Until next time. Happy reading!

--

--