tzlee.com/blog

Category: Tech, Code & AI

  • Open Letter to Ministry of Transport to implement SimplyGo Express Travel Card

    Dear <REDACTED>

    Hope this email finds you well. I would like to ask MOT why our SimplyGo isn’t available as an Express Travel Card on Apple’s iOS.

    If you use an iPhone and have been to other countries including Japan, HK, China, Korea and even USA, their travel cards are available in the Apple Wallet and it is very convenient.

    The Express Travel Card allows it to be used without authentication (Face ID) and can even be used when the phone battery is flat. It’s designed for fast entry and exit so users can simply tap their phone without ever having to open up the wallet app and authenticating before presenting the card to the reader.

    In addition, the availability of the travel card on the phone reduces the need for users to buy a physical card, or download and additional app. It’s not only more environmentally friendly – it will also be much more convenient for tourists.

    I hope MOT will consider asking SimplyGo to implement the Express Travel Card on Apple’s iOS. Singapore prides itself as one of the top places in the world for public transportation, and we should keep up with the times.

    For more information:
    https://support.apple.com/en-sg/105123

    Best Regards,
    Justin Lee

  • AI is replacing us because we’re getting lazier

    There are articles all over the Internet suggesting that AI will likely overtake humans because of its superior intelligence. But as an Adjunct Lecturer teaching the next generation of our workforce, I see a very different, more troubling picture. In fact, I’m very, very concerned.

    AI is not replacing people because it’s too smart – it is replacing them because too many (young) people are getting (very) lazy.

    Struggles Cultivate Deep Thinking

    We’ve entered an era where students and professionals alike can summon AI to write essays, generate code, answer technical questions, and even prepare reports with minimal input. I’m not even gonna lie about myself using ChatGPT to assist in writing this article – these tools are undeniably useful.

    But instead of being used to deepen understanding or accelerate learning, AI tools are too often being used to bypass the thinking process altogether.

    In my classes, I’ve noticed a sharp decline in students’ ability to reason through a problem. When presented with a coding exercise or a systems design question, many instinctively turn to ChatGPT or similar tools not as a partner, but as a crutch. They copy, paste, submit, and move on.

    The troubling part isn’t the use of AI. I advocate for responsible use of tools. The problem is the mindset shift. Students no longer struggle with problems; they are outsourcing the struggle. And in doing so, they’re missing the critical phase where actual learning occurs.

    A Systemic Problem

    This habit of mental offloading isn’t just a student issue. It’s a consequence of how we design our assessments, our learning environments, and our expectations.

    Many computer science courses today rely heavily on coursework and take-home assignments, which were great in the past – but today are easily completed with AI assistance. If we’re assessing output without scrutinising the process, we’re inviting this behaviour. We’re telling students: “We care that it’s done, not how you did it.”

    So naturally, they’ll take the fastest (aheem, laziest) route!

    Rethinking Assessment in the Age of AI

    We need to rethink how we teach and assess in AI-enabled classrooms. Here are a few ideas that I believe must become mainstream, especially in coding and technical disciplines:

    1 – Reverting to Closed-Book Assessments

    We need to bring back exam-style assessments. Closed-book exams and practical coding tests can help differentiate between those who’ve genuinely understood material and those who’ve coasted on generated output.

    2 – Live Presentations and Walkthroughs

    More emphasis should be placed on students explaining their thought process aloud – through live code reviews, technical walkthroughs, or project demos. If they can’t articulate why they chose a certain algorithm or how they structured your app, they probably didn’t understand it.

    3 – Practice Testing and Distributed Practice

    Rather than one or two big assignments, we need more frequent, lower-stakes practice tests spread out over time. This supports long-term retention and builds foundational understanding. Students should be repeatedly exposed to problems in slightly varied forms to encourage generalisation of concepts.

    However, it is also important to bear in mind that this also places more workload on teachers.

    4 – Focus on Problem Formulation

    We should assess the ability to ask good questions, define the problem clearly, and justify trade-offs. These are skills AI tools are unable to do without human assistance, and are also skills that remain essential in professional engineering environments.

    Laziness is Human Nature

    AI encourages the human tendency to avoid the hard work of thinking. If we’re not careful, we’re going to raise a generation of engineers who can prompt tools but can’t think critically, debug effectively, or innovate independently.

    The most valuable engineers, designers, and analysts in the future will not be those who blindly use AI, but those who know when to trust it, when to doubt it, and how to surpass it.

  • Why Government Tech Tenders in Singapore Needs Revamp

    I recently spent a considerable amount of time working with a government client to explore an app development project. We went deep into understanding the problem, brainstorming possible solutions, identifying constraints, and scoping out practical approaches. But just as we were starting to make progress, the project got yanked into the familiar black hole of bureaucracy: a rigid, poorly-defined tender was issued, seemingly designed to tick boxes than solve the actual problem.

    This isn’t the first time. But each time it happens, it’s disheartening.

    A Process That Punishes Innovation

    These government procurement processes are built to be transparent and fair, and rightly so. It would work prefectly fine for buying a bunch of laptops, or constructing a basketball court. But when it comes to technology projects, the structure of these tenders is fundamentally broken. The system rewards those who can respond to overly prescriptive, unrealistic tender documents, not those who best understand or can solve the underlying problem.

    Too often, these tenders are written after the agency has already gone out and sought informal advice – sometimes even prototyped or trialed solutions – but instead of incorporating these learnings into an agile, iterative approach, they fall back on old-school waterfall RFPs.

    The Problem with Fixed Requirements

    Technology, unlike construction or hardware supply, is not a domain where you can define everything upfront. The entire software industry has moved away from rigid requirements-gathering for good reason: we don’t always know the end solution, but we do know the problem we’re trying to solve.

    That’s why #Agile practices have become the norm – because they accept uncertainty as a reality and focus on iterative progress toward a shared goal. Yet in the tendering process, government agencies are forced to cast vague assumptions into stone, creating a scope that no vendor can fulfill without overcharging, over-engineering, or outright guessing.

    The result? Vendors quote sky-high prices to protect themselves from the ambiguity – or worse, they underquote, win the bid, and the project collapses mid-flight due to unrealistic expectations, scope creep, or misalignment between the stated requirements and actual user needs.

    Focusing on Process Instead of Problems

    Perhaps the most frustrating aspect is the focus on process over outcomes. So many tenders are framed around implementation timelines, documentation deliverables, and checkbox compliance without clearly articulating the real-world pain points or desired business outcomes.

    We should be seeing tenders that begin with:

    • “Here’s the problem we are trying to solve.”
    • “Here are the constraints and stakeholders.”
    • “We want your expertise in helping us figure out the best solution.”

    Instead, what we get is a 20-page legal document and:

    • “Build X, Y, and Z with ABC tech stack.”
    • “Deliver within six months.”
    • “Provide five user manuals and a training deck.”

    A Call for Change

    Singapore has bold ambitions in tech: Smart Nation, GovTech, digital transformation across the public sector. But these ambitions are being held hostage by legacy procurement practices that actively undermine the principles of good software design and delivery.

    What we need is a new paradigm for technology procurement, one that:

    • Starts with problem statements, not rigid feature lists
    • Embraces agile, iterative delivery models
    • Allows for co-creation with vendors, not just transactional handoffs
    • Encourages value-based evaluation, not just lowest cost or most compliant

    Let’s stop punishing good faith collaboration with broken processes. Let’s start solving real problems together.

    Because if we keep doing this the old way, we’re not just wasting vendors’ time – we’re wasting taxpayers’ money.

  • What is Good Code?

    What is Good Code?

    Many junior to mid-level engineers have misconceptions about what “good code” truly mean. Unfortunately, these misunderstandings are often reinforced by flawed hiring practices. LeetCode problems, parroting SOLID principles, or memorizing framework features might showcase technical knowledge, but they don’t inherently make someone a good Software Engineer.

    Mess is Everywhere

    Throughout my career, I’ve encountered my fair share of messy codebases. An example would be functions/methods that stretched over a thousand lines of business logic—an unmaintainable monstrosity. Such code is a hallmark of inexperienced teams and often plagues poorly managed software outsourcing projects. I’ve probably written my share of such code when younger too.

    Seasoned engineers would say that this is “common.” Even at tech giants like Google or Microsoft, codebases aren’t pristine. Messes are inevitable, and documentation can also be inconsistent.

    Still, there’s a difference between an unavoidable mess and a completely avoidable disaster.

    If It Ain’t Broke, Don’t Touch It?

    A few years ago, I was troubleshooting a particularly stubborn issue with another team. The tech lead said that adding more code to an already bloated, thousand-line controller method was risky. He wasn’t wrong—it could take days to figure out where to make even minor changes, and the risk of breaking something was high. To add to the problem, the codebase did not have unit tests.

    But what happened next left me speechless.

    The Undocumented, Untraceable Code

    The tech lead decided to “solve” the issue by writing a standalone PHP script, completely outside the Laravel framework we were using. His justification? Frameworks were “too slow” and “too complicated.”

    His script lived in some random folder on the server, undocumented and untracked. Hours of debugging later, we stumbled upon it by sheer luck. And it wasn’t a one-off—we later found there were several such scripts scattered across the server, mostly undocumented and introducing untraceable logic into production.

    At that point, nobody cared about the quality of his algorithms (they were terrible, by the way) or whether his code followed SOLID principles (it didn’t). The real issue was far worse: he prioritized personal convenience over team collaboration. His decisions created a codebase that was not only a nightmare to maintain but also actively sabotaged the team’s ability to function effectively.

    Coding Beyond Yourself

    As software engineers, we don’t work in silos. Writing code that you alone can understand is easy. Writing code that a hundred others can maintain? That’s the real challenge.

    The example above is a cautionary tale of what not to do. Good engineering isn’t about showing off your technical prowess; it’s about making thoughtful decisions that benefit the team, ensure long-term maintainability, and foster a culture of collaboration.

  • Rethinking Technical Interviews: Lessons from My Experience

    Rethinking Technical Interviews: Lessons from My Experience

    Earlier this year, after being laid off, I went through several interviews for technical roles. These interviews often involved take-home tests, coding assignments, and live coding sessions. While I completed a few, I eventually started declining most of them, finding many to be time-consuming and, frankly, ineffective.

    The Limits of Coding Tests

    Coding tests can serve as a basic filter for entry-level positions, but their value diminishes when applied to senior-level roles. If you’re hiring a Senior Engineer with 10–20 years of experience, coding proficiency isn’t the primary skill to assess—especially in a world where AI tools like ChatGPT can handle many coding tasks faster and more efficiently.

    Instead, the focus should shift to evaluating Problem-Solving, Critical Thinking, Learning Aptitude, and Communication Skills—competencies that I find many interviews overlook. These are the skills that enable senior engineers to lead, adapt, and contribute meaningfully to a team.

    The Core Skills: Problem Solving, Critical Thinking, Learning, and Communication

    These skills apply to candidates across all experience levels. Over the years, I’ve hired many mid-career switchers, often with limited coding backgrounds. People ask how I gauge their suitability, and my approach is simple:

    • Assess their problem-solving ability.
    • Understand their interests and what excites them.
    • Observe the quality of their questions and how well they articulate their thoughts.

    While I do conduct technical screenings to ensure foundational competency, I avoid assigning time-wasting take-home tasks or algorithmic puzzles that don’t reflect real-world job demands.

    Navigating the Era of AI-Assisted Interviews

    The rise of AI tools this year has also transformed interviews. Candidates can now use AI dicatation off-screen to assist with technical questions, making traditional coding tests even less reliable indicators of ability.

    To counter this, I focus on questions AI can’t answer effectively:

    • What are your hobbies?
    • What are you learning now, and why?
    • If you could explore something new tomorrow, what would it be?
    • What’s the most challenging or interesting project you’ve worked on?
    • How would you approach solving this real-world problem based on a scenario?

    These questions help reveal a candidate’s genuine interests, adaptability, and approach to problem-solving.

    The Rapid Pace of Technology

    Over my 20-year career, technology has evolved very quickly. I’ve worked with Turbo Pascal, PERL, Java, PHP, C, C#/.NET, Swift, Python, JavaScript, and countless frameworks, libraries, tools and operating systems. Every shift required adaptability and a willingness to learn.

    A person who can learn and adapt will thrive as technologies, tools, and frameworks continue to change.

    Final Thoughts

    Hiring the right people isn’t about filtering for a specific tech stack or testing for algorithmic skills your team may never need. It’s about finding individuals who can solve problems, adapt quickly, and communicate effectively. Those are the qualities that matter—and they’re what will drive your team forward.

  • How AI will transform Learning and Hiring in Software Development

    How AI will transform Learning and Hiring in Software Development

    The era of Google

    I remember my time as a student back in 1999: a new search engine, Google, was starting to edge out AltaVista and Yahoo — both of which dominated the Internet search landscape throughout the 90s. It was an exciting time for Computer Engineering, as open-source software like Linux was gaining traction in Enterprises. Microsoft and the Java ecosystem were also equipping us with powerful IDEs like Visual Studio, JBuilder, and IntelliJ with features like code completion. Yet, despite these advancements, we still relied heavily on books as primary sources of information. Exams were still handwritten, even for coding: we memorised library functions and syntax, despite having access to the Internet and some fairly advanced tools.

    Our schools insisted on handwritten code and taught us programming using Notepad instead of IDEs. At the time, student laptops were underpowered, and IDEs were huge memory and CPU hogs, running painfully slow. Despite the inconvenience, students like me made every endeavour to set them up, knowing the efficiencies they offered.

    Today, this all sounds ridiculous. With modern IDEs, who would memorise hundreds of function calls or API structures? I actively work across multiple programming languages and frameworks and use countless DevOps tools and certainly can not memorise everything; perhaps it’s age, but it’s nearly impossible to keep all these details in my head.

    The rise of AI

    Twenty-five years on, the world is vastly different, but education systems still lag in adapting to technological shifts. Educators remain cautious about how AI impacts academic integrity and the assessment of written or coding assignments. While AI use isn’t necessarily discouraged, it’s also not fully encouraged; students are however already using AI, much as we once turned to Google and IDEs in place of traditional textbooks.

    For Software Development, AI coding assistants are here to stay, yet they’re unlikely to replace Software Developers soon — especially those who leverage AI-enabled tools. There are stories of startups built by non-technical founders using AI-generated code, but the actual efficacy of purely AI-driven development remains unproven. 

    So, what should we teach students, and how should we evaluate professionals?

    Educational institutions and hiring managers must rethink how they assess skills in this new landscape.

    Developing Strong Fundamentals

    AI models today, especially large language models (LLMs), are not infallible. They can produce erroneous or nonsensical responses. Strong foundational knowledge enables students and professionals to evaluate AI outputs critically and refine prompts to achieve the desired results. From my experience with students using AI-generated code, those lacking fundamentals struggle to interpret the code correctly and often can’t integrate it with existing codebases. For instance, AI models can generate verbose scaffolding or unnecessary details that may disrupt the intended functionality. Without solid fundamentals, these additional complexities create confusion instead of clarity.

    Cultivating Critical Thinking

    Critical thinking is crucial for discerning when and how to use AI solutions effectively. Humans bring valuable contextual knowledge to problem-solving — something not easily available to AI. Tackling complex real-world problems often involves navigating nuances such as geographical, cultural, and political factors. As a simple example, a form with “first and last name” fields may not be culturally appropriate in some countries, especially in parts of Asia where such naming conventions are uncommon. While an AI model might “know” this in theory, it often requires a user’s insight and critical thinking to specify it in an AI prompt when generating a form.

    Mastering Communication

    Although AI can generate well-structured text, effective communication remains a uniquely human skill. Communication goes beyond words to include emotional intelligence, empathy, and cultural sensitivity. AI may one day grow up with us and learn every little bit of detail of our lives (it is a scary thought, but absolutely possible future) but it won’t easily replicate the nuances of face-to-face interactions, emotional cues, or the subtleties involved in team dynamics. Communication skills, therefore, remain vital for collaborating with others and expressing complex ideas in ways that are both clear and motivating.

    Conclusion

    As we move forward, Software Developers will still need to synthesize large amounts of information before even engaging AI. We may no longer need to memorise every technical detail or write every bit of code, but we’ll still need a robust foundation to understand, prompt, and critically evaluate AI-generated responses. AI is reshaping learning and hiring, but the fundamentals of understanding, thinking critically, and communicating effectively will remain core competencies in software development for the foreseeable future.

    This article was also posted on Medium.com:
    https://medium.com/@detach8/how-ai-will-transform-learning-and-hiring-in-software-development-642e3d678cc5