MAd.

Hi there 👋

I'm Mario Adisurya, and I'm a software engineer.

More specifically, I'm a web developer, and I can build web apps that your users and developers will love, with the expertise and experience to contribute across the entire stack.

Some ways I can make a postive impact to your business

📈 I can deliver value.

Whether it’s providing business impact by delivering new features, or by paying down technical debt or helping improve processes so that the business and product will have more long term sustainability.

👨‍💻 I can contribute beyond just writing code.

Beyond authoring code that is readable and maintainable, I have experience providing technical leadership on a diverse set of projects and can also contribute to product scoping and decisions, and a robust, sustainable, and pragmatic technical design.

📊 I can help your business make more informed decisions.

I can help your business make more informed decisions by advocating for a more research-based, data-driven and outcome-driven culture in the team. It’s important to do prior user research to understand the problems that users are facing and come up with the relevant solution, but it’s also equally as important to be able to quantitatively measure the ROI and if the solution actually succeeded or not and solved the initial user problem. Being able to measure what’s successful or not will provide clarity and give your business more insight on which areas of the product and tech that should be invested in.

Recent work experience

Genesis Energy

One of New Zealand's leading power and gas providers

genesisenergy.co.nz

During my tenure at Genesis Energy, I worked on their flagship Energy IQ application which provided self service capabilities for their customers.

Most notably, I was instrumental to Energy IQ's modern cloud and Infrastructure-as-Code migration, helping them escape "researching themselves into paralysis". I contributed to the technical design, scoped out the work required for the migration, and successfully setup and implemented a functional MVP of the migration--putting the team in a strong position to deliver after I had left.

I was also intrumental in improving the development teams writing culture by introducing the request for comments (RFC) document for communicating substantial changes and the postmortem document for facilitating meaningful post-incident retrospectives.

Crimson Global Academy

The world's first fully-registered online global high school

crimsonglobalacademy.school

My role consisted mostly of individual contributor tasks such as feature development and paying down technical debt, as well as supporting and mentoring more junior engineers.

My most notable work includes streamlining the CGA tech teams kanban process to ensure better collaboration between product and engineering, and feature leading a complex data integration project that required re-designing, implementing and migrating to a new database schema model.

Latest

Most recent blog posts of my learnings or opinions on tech.
If you have more appetite for short-form content, checkout my threads!

  • Published on
    Speed is critical to business success, where delivering too slowly can result in a business losing its competitive edge. Some of the most successful people I’ve worked with, the ones who you just know can thrive in any business, all have this one particular characteristic (or skill?): to be able to discriminate and know when one can move fast and when one can’t, and isn’t afraid to face uncertainty head-on and move fast when they can. I believe that this is attributed to having a strong culture that embraces iteration and continuous improvement. Below, I share some of my perspectives on areas you can focus on to foster, strengthen, and embrace to integrate iteration and continuous improvement into your company culture.
  • Published on
    The first part of many(?) blog posts curating my observations and opinions of podcasts I listened to or blogs I’ve read regarding software management practices. In this blog post, I discuss using product/software requirements and when it’s appropriate to use an agile vs a non-agile approach.
  • Published on
    Imagine a perfect world, where you have an unlimited amount of time to produce quality software without ever needing to cut corners and incur any technical debt. Unfortunately, such a world is unrealistic, and in most cases, you or your team will have to incur tech debt whether you like it or not. What’s important is to be pragmatic and considerate when approaching technical debt and instead of focusing on being “tech debt free forever”, we should focus on answering questions such as “when is it appropriate to avoid tech debt in favour of delivering faster?”, and “how should we prioritise tech debt in conjunction with other items on the product roadmap?”