|

Personal Summary:

I joined IBM Consulting in Singapore in late January 2026. My first few months were a mix of short ad hoc pieces of work: some Python scripting, and a lot of documentation. The biggest skill I picked up was learning a project's context quickly, and turning large, messy contexts into clear, structured documents.

In July I was onboarded onto my current project as a DevSecOps engineer. In practice it's closer to being a forward deployed engineer at the infrastructure level. The first few weeks were spent learning how to bring our COTS products into an air-gapped environment: downloading them, scanning the images with Trivy, and getting them ready to transfer across.

From there I moved onto OpenShift, deploying IBM API Connect. Its installation is quite barebones, so every resource is applied individually at the YAML level. The earlier deployments had been done under a lot of time pressure, so while shadowing one I organised the YAMLs into phases and documented everything, including a few manual UI steps that aren't obvious. I also wrote Bash scripts for each phase. Honestly, they're as much documentation as automation, and they mostly exist to make my own life easier.

The part that has stuck with me most came during security hardening. Our first attempt at restricting network access broke the application, because of a certificate it didn't recognise. Working out why meant tracing how our hostnames were resolved and which load balancer each request actually went through. That's when networking and certificates stopped being abstract concepts I had no interest in. I still don't fully understand them, but watching them change in real time has genuinely sparked an interest.

Next on my list is the AWS Solutions Architect Associate certification, once this project wraps up.

Personal Summary:

I was first approached by Mia, the founder, whilst doing some of my programming work at the bouldering gym

When she asked if I wanted to help out with her team, I immediately said yes. I have always wanted to use my programming skills for a cause that is personal and genuine to me. The purpose of this app and company aligned with my goals, and as such I joined without hesitation.

I quickly found out that I was pretty much the sole front-end developer, to which I took on the mantle without hesitation.

Once I properly wrapped my head around our use case, I proposed a tech stack that would fit the goals of our application, with technologies that I had some familiarity with.

I consulted with our back-end developer what his plans were for the back-end, and made sure that my proposed front-end (NextJS), could incorporate his vision as well.

The starting process wasn't easy. I often found myself stuck in analysis paralysis at times, not wanting to head in the wrong direction. However, once I got the ball rolling, things were much easier.

I utilised various external resources to build the front-end, and consulted with GPT-4 on the best course of action on technologies to implement.

Once I finished building the state management component, things were much more streamlined from then on. We have since managed to secure a spot as an industry partner for a UniMelb masters subject, which essentially saw us taking on a group of software developer students as our interns.

Taking on a pseudo managerial position was quite interesting, as I saw myself being faced with questions that required me to quickly identify the root cause of.

One particular instance was when I was told our external call to a Google API seemed to not work suddenly. I was given little information, and I had to get the student to contact me, asking them context questions to identify the root cause. Ultimately, we found that our Google Cloud Project hadn't enabled `Places API`, which was strange since this was working prior even without this API enabled.

One of the biggest lessons I have learned so far is working with different coding styles. Being flexible in different ways of coding is key, as I needed to understand their implementations in order to give proper advice and thoughts.

Another lesson is in managing external expectations, particularly with parties that don't have much developing experience. I needed to explain things in ways that were understandable for them, highlighting why certain features and app pages may take a certain time frame to implement.

Recently, I had the pleasure of representing the company (alongside other members) at a networking event. It was inspiring to connect with so many other passionate groups of people.

Personal Summary:

Due to signing an NDA, I can't give too detailed of a summary unfortunately.

In summary, I am training AI models by testing responses given by various LLMs (language learning models), mostly relating to code. These could be anything from simple python `hello world` programs, to slightly less-simple react and nextjs applications.

As such, I am constantly refreshing my memory on these technologies, as well as consistently learning new ones.

Being fully remote and able to set my own hours, I’m incredibly grateful for the opportunity to explore my passions and hobbies in my spare time. These include regularly contributing to a startup I’m involved in (Circula) and upskilling through study towards my AWS Associate Solutions Architect certification.

Personal Summary:

My time at U-SWS was a fruitful one. As the company size was small, I had the privilege of experiencing being a software developer in an intimate environment. Being situated in Croydon, I enjoyed going against the flow of traffic every commute, and got to enjoy the lovely cafes and shops of an outer suburb.

Our application is in summary, a logistics management app. This app allows our clients to schedule jobs, take in requests from their own clients, as well as pass on requests to us. It also allows them to manage their employees' timesheets, and various other administrative tasks. Requests that were passed on to us ranged from simple clarifications, to making new app pages, implementing new features, as well as scheduling reports.

-- Full stack development --
Making new pages was decently simple, thanks to the lead developer implementing a 'template editor' page on the app, which comprised of a code editor with multiple tabs(using Monaco). This allowed us to build app pages in house, without ever needing to modify source code. This was mainly done through Javascript, HTML and CSS. This 'template editor' also had some JSON and Javascript pages that took in some additional flags and environment variables, which allowed us to pull in data from different parts of the service. Often times, we would have to first pull in the data using these flags, manipulate them using Javascript to fit some kind of mapping format, and then parse that out through a javascript object. It was fun and challenging, as this was where I largely improved my functional programming. Some important skills include arrow functions, asyncronous functions, anonymous functions, and using array and object functions (Array.prototype.map(), Array.prototype.filter(), Object.groupBy()).

-- API Calls --
Our API used RESTFul services, using various statements to perform CRUD operations. The first most often 'form' I would use this in would be to make a READ call in the URL, using Select statements as well as filtering somehow to get the data I needed. The app we had allowed for making API calls in the URL, and it was immensely useful in allowing me to make fetch calls and seeing what I got from the browser. This would simply be a fetch call, followed by a string that resembled a URL (containing those select and filter statements). The next method was more verbose, but had the ability to make all 4 CRUD calls. This took the form of a payload, as well as some kind of call to a certain entity within the service (through a URL, without select and filter statements). The payload contained the select and filters I needed, through a Javascript object, which allowed for much more control over the filters as this also allowed for group filters and nested 'And'/'Or' statements on these filters. Ultimately these methods would be useful for when we needed to mass update some dataset, or to check for special cases in an existing dataset.

-- Scheduling things --
Although more rare, scheduling tasks (such as daily reports, daily acknowledgements, etc.) would usually manifest themselves in the form of a plugin, using VB.NET. This usually involved making some API call to the server, manipulating that data, and then using some library to get the output we needed. In the example of daily reports, it would be something like manipulating the data for that day into an excel format, and sending that excel file to some person through another API call.

-- Modifying source code --
This was usually done when we had to change the way our application worked (in TypeScript). One task I worked on involved page routing, where initially our app was routing to the wrong pages in some niche scenarios. It essentially involved taking in the URL string through an object, making some comparisons after splicing it, and returning the right pages afterwards. Another task that I worked on involved cleaning up our existing code to be TypeScript 5.5 friendly, as certain ignore flags would not be allowed once updating to that version. I often found myself changing TypeScript objects to maps, as the way maps were initialised still followed the standards of TypeScript, yet still being flexible enough where it did not involve changing things outside the function scope.

-- Dev workflow --
Our dev workflow was decently simple. Whenever we had a task from a client, we (the dev team and project manager) would hold a teams call discussing the context as well as what needs to be done, before discussing how we want to allocate this task. If it was simple then usually the task could be wholely given to a single junior developer, otherwise the entire team would have a crack at it. If it was making an app page, then it was as simple as hitting save on our in house template editor, and changing some flags elsewhere on our database to have it deployed as a page. If it involved changing the source code, we would follow a more 'traditional' workflow, creating a separate branch on Azure Devops, committing and pushing regularly, before eventually making a Pull Request where the Lead Developer would have a code review and merge it with the main branch.

Personal Summary:

I was given a testing script from a full-time developer, coded using Python Selenium. Although functional, the previous developer was in a time crunch, and as such I was tasked to make it more stable, user friendly, and reusable. Additionally, I had to make a new script that was similar, with its purpose to test another part of the website.

After some brainstorming, I decided to first split the single python file with 10,000 lines into multiple files, as well as add in the function of taking in multiple parameters when running to account for different testing scenarios.

I also made it possible to start from an intermediate step (in the user story), for situations when the testing script stopped at a certain step, for whatever reason.

Lastly, I introduced the idea of using a screen recorder while running the testing script. This improved efficiency, as there were situations where we had to check the recording and align the scenario with what was recorded in the database. Previously, the developers relied on their memory of what the script executed on the website. My use of the screen recorder got rid of the possibility for human error, making sure that every single step was recorded and accounted for.

Ultimately, my internship period was over before the project deadline. However, I was told from my coworkers who stayed on that they continued with my methods, with minimal changes to my code. The project eventually completed, to which I have faith that my contributions have made its testing much more efficient.