I was a bit delayed writing this blog post as this week was a bit busy as there were two important things I had to deal with, and one additional personal thing.
I had to manage and take some midterm exams at university and additionally I also was applying and signing contracts for part-time work in order to make some money to fund a personal trip in June 2024.
However, the major sink of my time was that I was struck with creative inspiration for a personal coding project, and wanted to strike while the fire was hot. I chose not to track the time I spent on this new project, and in hindsight that was a mistake as it might have been at least 20+ hours worth of worth in under a week. But without tracking my time I wouldn’t know for sure.
This post will discuss ‘The Project’ first, covering my goals, expectations and objectives with it as well as discussing what it was. Then it will discuss some reflection on the mid-term progress at my final academic semester at university. Finally the post will briefly discuss part-time employment stuff that I am working with and my thoughts there.
The ‘Forever’ Project
Last week, I had discussed my progress on a simple Bomberman but Turn-Based Clone for a game jam. It was a humble project and small in scope.
Since then, however, I have transitioned the project to be much bigger in scope, including the creation of a custom prototyping engine… twice. This will be my most ambitious personal project I have ever undertaken, and I intend this to be a ‘Forever Project’ that I work on for years.
First we will cover what the project’s pitch and concept actually is, and then the post will discuss how all my previous game jam and personal projects have been building up to this. Finally, the section will end off by giving some brief technical overviews.
But what is this project actually?
So originally I had planned to do this whole section and go into detail about everything and so on. But in truth I had written this draft on Monday 19th Feb 2024 and I had been busy training for my part-time work this whole week. So instead I am going to literally leave the TODOs as a silly ‘sneak peak’ and I will make a follow up post on this later instead.
TODO: Write what the project is
- TODO: Explain the origins and inspiration
- TODO: Write about using Unciv as a core source of inspiration
Learning Objectives
How does my past work lead up to this?
TODO: Write how it relates to bomberman and past game jam projects
Technical Details and ‘Overengineering’
TODO: Write about the technical stuff OR write a separate blog post about it that can be linked here
School Stuff
TODO: Write about Android Class TODO: Write about VR Class
Part Time Stuff
I needed to save up some money to go on a trip to visit my partner again in the States. I also had time in the weekend evenings freed up. I decided to take up a part-time service staff job to work at the Breadtalk near me. I chose to do an actual service orientated job instead of doing freelance coding work for many reasons, I have two primary ones that I felt are worth mentioning.
The following section is comparing my expectations of the skills I would develop working as a service crew member in contrast with my experiences as an undergraduate sipping canned coffee or energy drinks while having two coding assignments opened on different screens. I can’t wait to write the followup on how true this prediction is in a few months.
‘Undergrad’ vs ‘Real World’
Time Management
The first is that I wanted some solid real world exposure working in a strict, professional and structured corporate environment after spending four years in the shelter of undergrad.
In undergraduate, it is an environment where someone can develop a lot of valuable technical skills regarding their study matter, both hands-on and in theory. A student also eventually learns manage ‘fluid time’ well due to the nature of university. I consider the time management of university to be ‘fluid time’ as someone has to account for the time between classes, strange scheduling, studying for deadlines and exams, having to accommodate project members or sudden events (like career talks, or lecturer consultations/office hours, long presentation for projects). Why I would write that this time management is very ‘fluid’ is that you make the best over being very adaptive to what is happening that week. If there is a test on Subject A happening next week and your classmates are studying for it, prioritizing Subject A over Subject B would make more sense. I can imagine that this mindset translates well to dealing with the fluid timelines of project focused work in an office, with meetings and unexpected overtime.
University, however, is a terrible place to practice working with ‘structured time’ in a way. While classes schedules are structured, it tends to not be as disciplined even in environments with mandatory attendance. Many professors would close one eye to students being late for a lecture, or coming to class with slippers or drinks. I had a common technique at undergraduate of simply going to the lecture hall or venue of my next class early and allowing myself to be fully immersed in my studying or reading or playing video games on my Nintendo DS without worrying about being late for something. This technique wasn’t bad, but it did mean that I didn’t have to worry about time management of actually making it to places on time as much as I could just go extra early.
It was also common to ‘borrow time’ from one class to another, in the form of studying or doing work from it inside the lecture time of the other. Sometimes it might be the same class’s material, but sometimes its not. I have done this before, but I regretted doing so as in hindsight I found it was disrespectful to the professor while also not being that much of a time save (since you have to study the material that you didn’t fully pay attention to again at a later date anyways to make up for it!). But it is something you can do, and it is something that is socially acceptable (while some professors rightly do not like it, many don’t have the energy to call it out or care).
I knew that this attitude wouldn’t be as acceptable in a service staff role though. For one, you have to wear a specific uniform and have stricter grooming standards, such as tying hair up into the cap. Being late for things was not only rude and unprofessional but actively disruptive to the operation of people doing their jobs, whereas in university its just seen as merely lazy. But you also can’t be too early either.
It made sense to develop the professional habit of not taking other people’s time for granted early and drill it into me before graduation.
Focus
You can’t multitask unrelated activities during a service role. Everything you do at a role like this is relevant to your job and nothing else. Even if someone is jumping between the cashier, packing, and cleaning their work station these tasks are all related to their job as the service crew. For almost the full shift, you have to be ‘in-tune’ to that role, and the short breaks are for recovery to get back to being in-tune.
Why is this mentioned? Well, in an undergraduate environment, it can be culturally acceptable or even expected to multitask, such as in the ‘borrowed time’ example mentioned earlier. A student could be rushing two assignments at once, or breaking up tasks in a fluid way that suits their energy level. This is not necessarily a bad thing, and can even be a very positive attitude especially for the more creative aspects of work such as writing code, planning out task deadlines, or general problem solving. I have had many debugging sessions that involved having to go for a walk, and I am glad I was able to develop this mindset and skill through both personal and academic projects. Even a last minute rush or crunch for a project is one that is still fully ‘in your control’ as you set the order and sequence of what you need to do, even if the expectations are too fast for comfort.
But there are bad aspects too. Someone might be in a Zoom meeting with project members ‘discussing’ a group project while in another tab ‘rushing assignments’. Someone might be ‘physically present’ for something, and not actually multitasking a different activity, but mentally focused on another thing. This is common attitude during lectures and meetings, but it just sucks honestly.
Even in focused, rigorous and disciplined study culture, its still normal to be ‘fluid’ about it. The pomodoro technique is commonplace, where breaks are both mandatory and structured, but you do get the breaks at the expected time. The pace is fully controlled by the individual.
In service work, however, you are only able in control of managing external stimulus with full attention, but you can’t control what that stimulus is. The rush hour does not care about ‘optimal learning patterns’ or anything, it just needs a predictable and consistent job done well and to the set standard. At best you might get lucky to have a situation manageable enough to play non-distracting non-lyrical music in your earphones, but ‘podcasts’ and ‘recorded lectures’ are a no-go.
The opportunity to be able to develop this skill and resilience in something as fast-paced and pragmatic as a cashier seemed like a good one. There is even a lower tolerance for errors and carelessness, especially when counting money or handling food.
I hope that this attitude would be transferable to a clerical workplace, where having the discipline to just be fully focused in meetings and pay really attention to what’s going on without a wondering mind. It would make communication in an office so much more productive.
Of course, the creative ability to problem solve and think through stuff in showers, jogs and non-destructive procrastinating would still an important complimentary attitude, but I know that to really thrive as a productive member of a team I’d need both.
This week was all training, and it was pretty in-depth and intense. I was lucky that it happened to be on the same week as the ‘break semester’ for university.
Chose it because the company is reputable and the location is very near my place, allowing an easy commute.
I learned a lot about what goes on ‘behind the scenes’ even at a simple bakery. There is a lot of professionalism, code of conduct and standards to meet, especially as I would be handling both food and with money directly.
So far I have been coping with the training well. On Thursday I had returned from my first shift doing actual cashier work at an actual outlet, although supervised and trained. Tomorrow (as of the day posting this post), I’d be doing my first non-training shift.
Food Safety
On Tuesday (22nd Feb) I attended a FOOD SAFETY COURSE LEVEL 1 course as per SFA Regulation. I was taught a lot of things formally that might seem like ‘common sense’ to many, such as the fact that raw footage in a chiller should be placed below ‘Ready To Eat’ food to prevent the leakage of juice/bacteria from the top to the bottom, as well as proper labelling of everything…. or how far trash bins and sinks should be from the prepration of food.
Growing up in Singapore in apartments, its possible to be sheltered from the fact that pests like rats do exist here, and that a lot of work is done behind the scenes to properly prevent infestations.
The next section is more of an exploratory thought comparing network security to food safety.
What if we did have Cyber Safety classes too?
I almost wish we had similar mandatory regulated safety classes and certificates but for software engineering. Sure it might be ‘common sense’ to do things like sanitize your inputs, consider buffer overflow attacks , to never send money or password data unencrypted through a network, or know what a TCP/SSL handshake is, but ‘common sense’ isn’t good enough when it comes to safety. If it were good enough, food safety regulators wouldn’t be wasting time enforcing refresher classes that remind chefs working more than five years in the industry not to use the same chopping board for raw meat and raw vegetables, or not to touch money with gloves that are used to handle food. Likewise, there’s many articles on common sense for networking clearly aimed at intermediate or advanced software engineers that still cover the basics such as this one on game engine networking.
Sure, someone who passed secondary school biology or chemistry class could put together that germs can spread through airborne contamination in a fridge, that non food-grade plastic chemicals can seep into food, that plastic could melt at high enough temperature and also seep in food, or that pests will be attracted to bags of ingredients left too near the floor and chew on the side.
In that same way, someone who passed their Computer Environments and Computer Networking classes would realize that buffer overflow attacks could happen when sockets are sent over a network, putting their two classes together.
Maybe no network engineer could be employable not knowing this language, the same as a chef wouldn’t be able to work in a higher end restaurant not knowing what temperature chicken is cooked at, but the dishwasher and cashiers have to undergo similar training too. In that same light, it is possible for a front-end or UI programmer, or a graphics programmer or especially a tools programmer (who is used to their work being used only internally by other team members), to have that gap in their knowledge even if they are aware of the individual components in isolation.
After all, maybe they have only ever developed applications that worked on localhost or even if they worked on a network, only did so through a library that handled that stuff for them, and so the only difference between UDP and TCP they might have vague memories of years ago might be from university is that one is ‘reliable’ and the other isn’t and that is assuming they even attended university to begin with.
I did not know that the temperature of which bacteria and germs multiply at intensely in the context of food was between 5 to 65 degrees Celsius prior to this week. I also only was reminded that Buffer Overreads existed earlier this week, doing research for a personal game engine project that I wanted to incorporate networking in… and had to revise what TLS was too.
Maybe it’s not big deal. When working as a cashier, I only have to remember to never touch the food with my hands. Maybe all the stuff I learned in a food safety class would never become relevant in my own shifts, the same way I would never have to send sockets directly in my own personal programming projects outside localhost or connecting with directly with a friend through a temporarily opened forwarded port.
But I still feel my life is enriched just knowing this stuff, and since we can’t predict the future, I would never know when I’d have wish I had known it. It’s nice to be taught ‘common sense’ sometimes.
POS Systems
The following section details some thoughts and observations I have made having a first exposure at Point-Of-Sale Systems during cashier training, having taken them for granted as a consumer. I dedicated this section to such a long ramble on something as benign as cashier software because of its relevance to software engineering as a whole.
On Wednesday, I attended training at Breadtalk’s HQ where I was trained to use the cashier POS system. It gave me an interesting look at the interfaces of software that ‘ground-level’ employees must interact with that are sold on a B2B level, rather than to consumers directly.
I don’t think I can share detailed descriptions of the interface, but imagine just a lot of buttons on grid layout. It almost reminds me of the CSS Grid or Flexbox in a way.
One thing that was important that I observed and inferred is that the ability for backend technical staff to add new POS Systems internally for the necessity of the ground level staff must be accounted for. Every retailer has different specifications, and need to be able to make those modifications internally without dependence on the POS System manufacturer’s software team.
One of the three concrete examples that I could infer would be how a lot of local retailers would become apart of the Yuu Rewards Club and so the POS System would need to be updated internally in order for cashiers to allow the reward card to be tracked. The system’s interface needs to be modified to accommodate the Yuu card as a button for staff to press, and the security in the backend needs to be able to track and get relevant information potentially from a secured api.
Reward Cards
There could be minor bugs that can be worked around, such as the fact that scanning the Yuu Rewards Card too early would cause the system to hang, so the compromises must consider the potential disruption (if the entire system has to be rebooted during a rush hour, this is unacceptable, but if its hangs only a bit it becomes a high priority bug rather than critical).
The seond of the third example would be to try and accommodate as many common interfaces as possible in a seamless way, as this allows staff to be much more efficient and less prone to errors especially during a rush hour. In my experience with Breadtalk’s POS System, I observed this in how the POS System is programmed to use the same button for ‘credit card’, ‘PayNow’, NETS payment, even though the interface for payment for the customer side is different. Having to press only a single button improves the efficiency of the service crew staff greatly, as they can focus their attention on the next order or packaging.
Programmers and UX/UI designers must consider that ‘why not just have different buttons for different payment modes’ is not good enough outside isolated testing modes, but I can imagine them being easy to miss if sheltered from the ground level. Then that UI must be tested rigorously and with automation, so that new payment systems don’t break it.
Language and ‘Strange’ Text
The final example would be language settings. There are many retailers that have monolingual staff in multilingual teams or consumer bases. In Singapore, this is seen as obvious but it is still worth reminding. For example, in Breadtalk it is possible for a staff member to only know Mandarin or only know English, and so the POS System for the product names here have a simple easy to use toggle to preview the Chinese/English names of products quickly and non-disruptively on the fly.
The font rendering for this toggle must be legible and to the same standard. The button’s layout must not change or be resorted despite being rendered in a different language, to maintain consistency as cashiers memorize the position of items in a layout for efficiency.
Some products may have marketing and branding that uses unconventional font rendering and unicode, and so sometimes POS Systems have to accommodate for that (and sometimes they do not). For example, there is a BreadTalk item stylized as ‘#Custard’, because of the pattern on its design and wordplay for the Hashtag.
This item is actually registered as #Custard in the POS System, but it is still listed alphabetically with the C category instead of being sorted above A despite the # symbol. I have not spent the time doing research on ‘strange product names’ and I do not plan to, but I imagine that symbols such as !, @ and $ might end up being common choices. Where a POS System might put hypothetical products with strange names like $nakes or @Home would have to be considered on a case-by-case basis by internal staff, but cashiers must be able to recognize and find it easily.
Both of these details imply that the value is registered using an internal name or ID that is separate from the rendering. It can be unpredictable what sort of product names a brand’s marketing might come up with for any product, and the system needs to be flexible to a reasonable extent.
I can imagine that this can prove extraordinarily challenging for POS Systems that need to accommodate right-to-left and left-to-right writing systems concurrently, such as Arabic, while also accommodating English text. I have not been to Egypt, but I imagine that their POS Systems might encounter this issue as they have a bilingual population of both English speakers and Arabic speakers, so there is a high chance of monolingual people who only are comfortable with one or the other.
Conclusion
My past work experience at NTU was being able to problem solve and program at my own pace to meet deadlines. While being a coding intern for a Unity project did give me a lot of experience writing code to meet specifications as well as be able to self manage and set my own deadlines, I do wonder if working part-time as a cashier would give me another edge of experience to deal with pressure and professionalism.
So that was how my week(s) has been after Chinese New Year. As a reader, you might have also noticed that I didn’t mention the Blog Writing Automation Script Followup mentioned last week.
This is because I realized that measuring the performance and profiling it would be a bit of a case of pre-mature optimization, since the tool works already and the number of attachments it needs to convert is relatively low so far. I may revisit and profile it if it ever starts to lag, or take longer than 5 seconds to convert any Obsidian markdown file to a blog post.
Future posts about the Forever Project in the Projects Category, giving posts relating to it its own category. Weekly posts may reference them, but technical posts do deserve their own spot to shine.
Alright, time to upload this post, putting it through my tool (even though it’s only to extract one picture this time… I originally had more planned but I wanted to save the content for its own post). Even though I had made a ton of simple automated tests for it, I still sometimes get nervous if it’d just break. I can’t imagine having any confidence running outside a controlled environment anything without testing now… and maybe that’s the way it should be.
Comments powered by Disqus.