Finding my passion for software engineering late (in this case meaning a few years after college) meant that my first real taste of a programming language was with JavaScript. I went through a career transition like many others with a bootcamp, which focused on teaching us skills that could be immediately applied to real jobs, i.e. JavaScript (also React, but it really is just part of JavaScript). However, I wasn’t satisfied with what I was learning; I wanted more; I wanted to learn what goes on in the layers below that have been abstracted away from us.

Teleterm Chat Part 1

- 11 mins read

Series: Teleterm Chat

The first thing I learnt from this project has nothing to do with software. It’s that asking the right questions can make a huge difference to how I feel and how I approach the problem at hand. I eventually landed on figuring out how to call C code from Rust as the first problem to solve. Asking better questions Having no experience creating command-line applications, I was at a loss for where to start.

Teleterm Chat - Part 0

- 3 mins read

Series: Teleterm Chat

I want to build a terminal application for myself to solve a use case that I have. (I’m also using this use-case as an excuse for me to learn and write more Rust!) However, instead of just building it, I want to try something new. Going with my theme for 2024, I want to try writing about my process of building the app as well. More creating, so I’ll code AND write!
At the end of 2023, I left the company that first kickstarted my journey as a software engineer due to my disagreements with the company’s culture. I learnt plenty from my first stint, picking up skills and technologies far beyond what my bootcamp and personal learnings had taught. Docker, microservices, Expo, and React Native were some of the additional technologies that I picked up within the first month just to be able to make useful contributions to my team.

Theme for 2024

- 2 mins read
More less; less more. That is my theme for 2024. For the past few years in my life, I have been focusing on more of everything. More learning; more reading; more coding; more working; more consuming; more creating; more knowledge gathering. This is in large part due to my current position in life. I recently switched careers to be a software engineer, and while I love it, I also realised how far behind I was compared to my peers, especially those who have been developing software since they were young.
Introduction Setting up a debugger was not easy or straightforward for me. Nothing works out of the box as compared to common IDEs, such as VS Code, so there was plenty of learning needed to get me to my current point. I wrote this piece in hopes that it might help someone else understand a little bit more about debuggers through trying to set one up for their own Neovim configurations too.
I came across this saying from ThePrimeagen, that as a software engineer, we should not ask for permission to do things. Instead, when we see a potential solution to a problem, create prototypes to show others the solution. Then, if things don’t work out, ask for forgiveness. This is in contrast to asking for permission to work on a potential solution before actually getting down to creating anything. The reason given is that it is difficult for others to fully understand your ideas from an explanation with only text.
I’ve recently become a software engineer after a career switch from marketing. In my short time so far, I’ve come to realise the importance of writing regularly. Clear communication is an essential part of any work, but even more so in software development. We interact with computers that understand code, not the communication that we’re used to with other fellow humans. The nature of code makes it such that we need to be highly specific with our instructions for the computers.
A while back, I was tasked with improving the performance of our mobile app. Performance optimisation is not a new thing to me, as I’ve seen YouTubers doing various kinds of performance benchmark comparisons of different tools. However, it was my first time trying to optimise a real production app, and I found it fun! I detail some of my investigations and discoveries during the process, and share what I learnt from this experience.

Learning vs Delivering

- 2 mins read
Software is complex. Developing a feature that is user-friendly, performant, and secure, while also writing code that is clean is already a real challenge. There are many articles and videos that discuss the various tradeoffs that businesses face when developing software. Take too long to develop, and the business won’t meet its delivery goals; develop too quickly, and we might miss out critical issues like security. As a new software engineer, there is plenty that I don’t know.