DEV Community: Luke Tong

Can I Let AI Work While I Drink Coffee? A Hard-Learned Lesson

Luke Tong — Tue, 26 Aug 2025 23:09:39 +0000

Can I Let AI Work While I Drink Coffee? A Hard-Learned Lesson

"Can I let AI work while I drink coffee?"

That was the question I asked myself recently.

The dream is simple: AI takes care of the heavy lifting, while I sit back and enjoy a latte. The reality, as I found out, is far more complicated.

The Story: Debugging a SOAP Microservice

I was working on a microservice that had to call downstream legacy systems.

Downstream system A only supported SOAP 1.1.
Downstream system B only supported SOAP 1.2.

When I ran the service, I got a nasty 500 Internal Server Error.

So I turned to AI for help.

AI quickly generated three suggestions and was about to try them one by one:

Change the payload value from 20000 to 20000.00.
Add a non-mandatory field into the payload.
Switch the client to use the correct SOAP 1.2 class instead of the wrong SOAP 1.1 one.

My Reaction

Looking at the list, I immediately thought:

Option 1 and 2 would at most cause a 400 Bad Request (schema or validation issue).
Option 3 was the real killer — a protocol mismatch that could definitely lead to a 500 Internal Server Error.

So I stopped AI right there and told it to skip straight to option 3.

And yes, that solved the problem.

The Lesson Learned

This experience taught me a few things:

AI is fast, but lacks sense of severity.

It treats cosmetic payload tweaks and fatal protocol mismatches as equals.
Human expertise is still crucial.

An experienced engineer can immediately judge which error source is most plausible.
Supervising AI can be exhausting.

If I have to stare at logs all the time, I don’t feel like I’ve delegated anything.

In short, AI felt less like an autopilot and more like a very fast but inexperienced intern.

How to Work Smarter With AI

So, what can we do to make AI genuinely useful without draining our attention?

Ask for explanations and prioritization first.

Don’t let AI execute fixes blindly. Have it rank possible causes with reasoning.
Restrict the action scope.

Let AI propose fixes, but you decide which one to run.
Provide a knowledge base.

Feed AI some rules like:
- 500 + SOAP call → likely protocol/endpoint mismatch.
- 400 → payload/schema issue.

This way, AI can learn from your experience instead of brute-forcing random fixes.

Wrapping Up

So, can I let AI work while I drink coffee?

Not yet.

But if I set up the right guardrails and workflows, maybe one day I really can.

Until then, I’ll keep one hand on my coffee and the other on the AI logs. ☕️👀

Have you had a similar experience supervising AI? Share your story — I’d love to hear how others balance trust and control.

Am I Getting Lazy with AI? A Software Engineer’s Honest Reflection

Luke Tong — Wed, 06 Aug 2025 04:11:27 +0000

Am I Getting Lazy with AI? A Software Engineer's Honest Reflection

✍️ Introduction

As a software engineer, I know sorting algorithms like the back of my hand. I’ve studied their time complexities, edge cases, and when to use one over another.

But recently, something happened:

Faced with a simple task — sort a list of numbers — I asked AI to write the code. It did. Fast and clean.

There was a small bug; I fixed it. No big deal. But then I paused.

“If I keep doing this… will I forget how to sort at all?”

That question led to a deeper concern:

Am I becoming too dependent on AI? Am I just outsourcing my thinking?

🧪 Two Scenarios That Made Me Think

Let me break this down with two real-world examples:

✅ Scenario 1: Simple Task, AI-Generated Code

I ask AI to write a sorting function. It returns it in seconds.

I tweak something minor, and move on.

Over time, I realize:

I haven't manually written a sorting algorithm in months.

Sure, I still understand it. I can discuss quicksort vs. mergesort, in-place vs. stable, O(n log n) vs. O(n²). But my hands… have forgotten the feel of writing it.

⚙️ Scenario 2: Complex Workflow with AI as a Helper

A real business problem: first do A, then sort, then trigger B and C.

I ask AI to help implement this sequence.

It gives me blocks of code. I connect them. It works. I test and deploy.

Here, AI didn't solve the whole problem. It helped with pieces. I still designed the sequence, validated the flow, and ensured it aligned with the business goal.

But again, I wonder:

Am I letting AI think for me? Am I cutting corners?

🤖 Am I Getting Lazy?

Let’s get honest.

AI is changing how we work. It’s tempting to offload everything — code, test cases, even architecture sketches. But where do we draw the line?

Here’s the key distinction I’ve come to:

It’s not about whether you use AI. It’s about whether you stop thinking.

Let’s break it down:

Situation	Lazy?
Copying code without understanding it	✅ Yes
Skipping testing and assuming AI is right	✅ Yes
Using AI code but auditing it line-by-line	❌ No
Leveraging AI to go faster and solve deeper problems	❌ No
Losing some "hand feel" but keeping conceptual clarity	⚠️ Maybe — monitor it

🚗 The Best Analogy I Can Think Of

Using AI as a developer is a lot like driving an automatic transmission car.

You don’t shift gears manually anymore.
You might forget how a clutch works.
But you drive smoother, faster, and farther.
And if you're paying attention to the road, that’s what matters.

You’ve lost the “gear-shifting hand feel”, but gained speed and freedom to look further ahead.

However, if you stop looking at the road just because the car is doing more — that’s when you crash.

AI helps me move faster. But I still steer. I still decide where to go, when to stop, what to avoid.

And I’ve realized — that’s not lazy. That’s evolution.

🧠 What Really Matters

Here’s what I ask myself now, before labeling anything “lazy”:

Am I still evaluating the problem with clarity?
Do I understand the code AI gave me?
Am I using saved time to work on more meaningful, complex problems?
Am I growing as an engineer — even if in a different direction?

If the answer is yes, then I’m not outsourcing my intelligence. I’m amplifying it.

✅ Conclusion: Use the Tool. Stay the Driver.

I’ve accepted it: I won’t write sorting functions by hand very often anymore. And that’s okay.

Because now, I’m solving more impactful problems — designing systems, exploring trade-offs, mentoring others, delivering value.

AI is my automatic transmission. But I’m still in control of the wheel.

And as long as I keep steering with intent, I’m not getting lazy — I’m getting smarter.

Have you ever felt like AI is making you a bit “softer” as a dev? Let me know in the comments — I’d love to hear how you're navigating this shift.

Why I Canceled My AI Copilot — And Solved the Bug Myself

Luke Tong — Mon, 21 Jul 2025 06:27:35 +0000

Meta Description:

AI is fast, powerful, and relentless — but in the real world, experience and human reasoning still matter. Here's what happened when I let my instincts override the AI.

As a senior software engineer, I still debug faster than AI.

One day, after updating a YAML configuration file, my test cases started failing.

As usual, I pasted the exception logs into my AI copilot and let it begin its diagnosis.

It started scanning — meticulously, systematically, line by line.

Meanwhile, I casually reviewed what I had just changed.

Then I realized it: I had updated the API endpoint in the YAML file, but forgot to update the corresponding URL in the test cases.

That was the issue.

The AI was still busy scanning. I canceled the session and fixed the problem myself.

🧠 AI Scans, I Reason

This experience reminded me of a fundamental difference between human engineers and AI copilots.

AI is powerful — it can parse and analyze thousands of lines of code in seconds.

But it lacks the one thing that experienced engineers bring to the table: contextual intuition.

I didn’t need to read every line of code. I knew where the high-risk change was.

I remembered what I just modified.

And based on years of experience, I formed a hypothesis and validated it — all within seconds.

⚙️ AI’s “Full Scan” vs. Human “Hypothesis”

AI approaches each bug like a blank slate. It doesn't know which areas are more likely to be the cause. So it starts with a brute-force scan of the entire codebase.

But as a senior engineer, I don't need to start from zero.

I can zoom in on the most probable cause using:

Knowledge of recent code changes
Familiarity with system architecture
Pattern recognition from past issues
And above all, the ability to form and revise hypotheses

Debugging isn’t about reading every line — it’s about asking: What’s the most likely root cause?

❌ AI Doesn’t Know When It’s Wrong

AI copilots also tend to commit to a direction and keep going — even when it’s wrong.

In this case, it assumed the problem was inside the code logic.

It didn’t stop to consider: Maybe it’s not the code, but the configuration.

But I did — immediately.

This is what I call the "direction sense" that experienced engineers develop.

It’s not magic. It’s the result of seeing dozens, if not hundreds, of similar bugs.

I knew the AI was digging in the wrong place. And I didn’t waste time letting it continue.

🎯 Experience Is Compressed Intelligence

There’s something deeply human about remembering, “Wait, didn’t I just change that YAML file?”

That memory isn’t in the AI.

It doesn’t have temporal awareness. It doesn’t know what just happened in your IDE five minutes ago.

This kind of “mental diff” — comparing current state with recent changes — is a uniquely human advantage.

It allows us to shortcut the entire diagnosis process, while AI is still loading the full context.

🔄 When I’m Stuck, AI’s Brute Force Becomes an Asset

Of course, this doesn’t mean I always outsmart AI.

There are moments when I hit a wall — when nothing obvious stands out, and my intuition fails to spark.

In those cases, AI’s brute-force approach becomes not just helpful, but necessary.

It scans without fatigue.

It doesn’t get discouraged.

It doesn't care if the problem is obscure, tedious, or buried in legacy code.

And sometimes, in that exhaustive analysis, it highlights things I would’ve completely overlooked.

So yes — while experience can beat AI in many scenarios, AI shines when there’s no shortcut, no hunch, and no recent change to trace back.

It’s not a competition.

It’s a collaboration — and knowing when to rely on which partner is the real skill.

Be a context engineering

Luke Tong — Thu, 10 Jul 2025 07:01:38 +0000

A few months ago, I came across the term prompt engineer — someone who crafts precise instructions for AI tools like ChatGPT or Copilot, tuning their inputs to get better outputs.

Back then, I thought, Interesting. That’s a skill.

But today, I believe that role has already evolved.

We're not just engineering prompts anymore — we're engineering context.

🛠 What Does a Context Engineer Do?

To me, a context engineer is someone who takes full ownership of the whole system. It’s no longer about getting the syntax of a prompt right. It’s about understanding the architecture, the business constraints, the flow, and then guiding the AI through that terrain like a well-briefed junior developer.

We design the mission.

We define the environment.

We decide what AI does — and more importantly, what it doesn’t do.

Let me show you what I mean.

📦 Real-Life Scenario: AI as My Coding Assistant

Suppose I need to create a new REST endpoint called createCustomer using Java and Spring Boot. Like any real-world situation, there are legal and business constraints defined by the company, and there are existing configurations and components I must respect.

Here’s the kind of prompt I give to the AI:

As a senior software engineer, your task is to create an endpoint createCustomer. You must use full JDK21 features and best practices. To achieve this, you need to:

Understand the endpoint by scanning the YAML file at /aaa/bbb/ccc/myproject.yaml.

Create the createCustomer endpoint in the controller.

Create a service class to handle this logic.

Apply our business logic in the service layer: – Map field1 from MySource to fieldA in MyDest. – Map field2 from MySource to fieldB in MyDest. – Use a dedicated mapper class. Check out YourMapper.java for reference.

Call MyRestClient: – Autowire it (already defined in MyConfig). – Make a POST call to the destination (see application-local.yml). – Ensure it returns a YourDest object as defined in the YAML.

Create another mapper class to reverse-map YourDest to YourSource.

I don’t write a single line of code in this process — but I design every step of how the code should be written.

Why? Because I know the system. I know the constraints. I know how to delegate effectively — even to an AI.

And because I know all that, I can be fully responsible for the result.

👨‍💻 I Still Review the Code — Because I’m Responsible for It

Let’s be clear: I don’t just blindly accept whatever the AI gives me.

Yes, I use AI to avoid repetition.

Yes, I let it scaffold classes, write boilerplate, and even suggest elegant solutions.

But ultimately, I own the code.

I read every single line.

If the AI comes up with something surprising — great! But I’ll ask it to explain it clearly. And if the explanation sounds too clever, I’ll say:

"Explain this to me like I’m a high school student."

If it can’t teach it clearly, it probably didn’t understand it either.

This isn't about ego. It’s about ownership.

🤖 AI Is Not Magic — It’s Your Junior Developer

Here’s what I’ve realized over time: the most productive way to work with AI is to treat it like a very fast, context-hungry, slightly naive junior dev.

It doesn't know what your business cares about.

It doesn't know your company's weird YAML structure.

It doesn't know what happened in the last project that blew up in production.

But you do.

So your job is to set the scene, break down the tasks, refer to existing assets, and guide the AI as if it were a teammate.

That’s what being a context engineer is all about.

🚀 Final Thoughts

We're entering a new phase of software engineering — one where AI isn’t just a Copilot, but a collaborator.

To thrive in this new era, we don’t need to become AI whisperers.

We need to become context architects.

People who understand the system, the goals, and how to lead a machine through the forest of complexity — without losing sight of the destination.

So no, I don’t write most of the code anymore.

But I still build.

And I still take full responsibility.

Because I’m not just prompting the AI — I’m engineering the context in which it thinks.

Do not use AI wrongly

Luke Tong — Thu, 26 Jun 2025 06:56:02 +0000

In recent years, AI has become the centerpiece of conversation in many engineering teams—and rightfully so. Tools like GitHub Copilot, Copilot Chat, and other AI pair programmers have reshaped how we write code, document systems, and reason about complexity.

But there’s a line between leveraging AI and abdication of engineering responsibility. And when that line is crossed, the result isn’t acceleration—it’s dysfunction.

Here’s a real story from within our company.

🧓 The Veteran Engineer Who Gave Up on Coding

We have a senior developer on our team. He's respected, experienced, and not far from retirement. Over the last few years, he’s become fixated on AI—convinced that within two years, large language models will replace most of our roles. As a sort of “legacy project” before he retires, he’s set out to train and integrate an AI model to automate our internal development pipeline.

At first glance, this seems aligned with the company’s goals. We’ve been early adopters of GitHub Copilot, and we’ve successfully integrated other AI tooling into our workflows. We encourage experimentation.

But what’s happening here goes far beyond “reasonable usage.”

❌ From Developer to AI Prompt Engineer—Literally

This engineer has stopped writing code himself. Completely. He refuses to hand-craft PRs or write patches manually. Instead, his workflow looks like this:

He copies the contents of Jira tickets into Copilot Chat or a similar AI.
He waits for a pull request to be generated.
He does not review or edit the code.
If the generated code is broken, he refuses to debug it directly. Instead, he tries to "teach" the AI to fix it by adding new comments or prompts.

The result? A simple task estimated to take one day ends up dragging on for five—full of bugs, blocked reviewers, and broken functionality.

His justification? “It’s fine if we’re slower now. Once the AI matures, we’ll recover the time tenfold.”

🧠 But Here's the Reality

This approach is not innovation. It’s negligence. And it reveals a deeper misunderstanding about what AI can and should do in a professional engineering context.

Let’s break it down:

1. AI is a tool—not a replacement for ownership

Copilot is meant to assist, not to take full responsibility. A developer who cannot explain, debug, or adapt generated code is not working with AI—they’re being replaced by it in a very literal sense.

2. Code quality suffers when understanding vanishes

AI-generated code is only as good as the person reviewing and integrating it. When bugs arise—and they always do—the developer must be able to dive in, reason through the logic, and make decisions. Otherwise, debugging becomes a game of prompt roulette.

3. “Training” Copilot with comments is a fantasy

Copilot is not a fine-tunable LLM in your IDE. Adding comments in hopes that it will “learn” better behaviors across sessions is fundamentally flawed. This isn’t Reinforcement Learning. It’s wishful thinking.

4. Your team pays the price

The engineer may believe they're leading innovation, but in practice, they’re slowing the team down. Others must compensate, fix broken PRs, and decipher logic that even the original author doesn’t understand.

✅ Healthy AI Usage Patterns

To avoid this kind of misuse, teams should define clear guidelines. Here are a few that have worked for us:

You own the code you commit. Period.

AI can draft, suggest, and autocomplete—but responsibility doesn’t shift.
AI involvement should be transparent.

If 80% of a PR was generated by AI, state it. Let reviewers calibrate expectations.
PRs must be understandable and maintainable by humans.

No black-box code. If you can’t explain it, don’t ship it.
Review and debugging are not optional.

AI may generate code, but it won’t rescue you from runtime bugs, broken APIs, or business logic mismatches.

🧭 Final Thoughts: Use AI Responsibly

AI is here to stay. It will change how we develop software—but not by removing responsibility from engineers. Instead, it amplifies both good and bad engineering practices. If you cut corners, AI cuts them faster. If you build clean, modular, well-documented systems, AI can help accelerate that process.

But the moment we stop thinking, stop understanding, and stop caring—that’s when AI stops being a tool and becomes a crutch.

Let’s not mistake delegation for abdication.

Let’s use AI as professionals.

Summary: Over-relying on AI isn't innovation—it's negligence. Use AI to assist, not replace your understanding, ownership, and responsibility.

Rethinking the software engineer's role in the era of LLMs, agents, and intelligent automation

Luke Tong — Mon, 16 Jun 2025 04:29:23 +0000

As AI tools like Copilot and agent-based frameworks evolve, I’ve noticed something quietly shifting in my day-to-day workflow. I no longer see myself as someone who writes code line-by-line. Instead, I break down my objectives into well-defined tasks, hand them off to an agent, and then—critically—I review the outcome.

In other words, my role is transforming: from engineer-as-implementer to engineer-as-orchestrator.

The Core Skills Are Still Essential

Despite AI’s ability to generate high-quality code (sometimes better than mine), I’ve learned this doesn’t absolve me from needing strong fundamentals. On the contrary:

I still need to perform micro-decisions.

Even the best-generated code often requires judgment calls on architecture, trade-offs, and edge cases.
I need to spot AI hallucinations.

LLMs can confidently produce subtle but critical logical errors. Recognizing them is a senior engineer’s job.
I need to deeply review what I didn't write.

If I don't understand the code, I can't guarantee its correctness—or maintainability.

The Paradox: Great Code That’s Incomprehensible

Sometimes the code produced by my AI assistant is too good. It’s elegant. Modular. Efficient. But so abstract or deeply nested that it becomes difficult for a human engineer—even an experienced one—to fully grasp in a short time.

Now here’s the problem: if such “perfect-looking” code contains a tiny mistake, the resulting bug becomes both unpredictable and hard to trace. Worse still, most debugging tools aren’t designed to help you untangle code you didn’t write.

That’s not just a problem. That’s a production risk.

Rethinking Interviews: Prompt Engineering > Syntax

If I were hiring today, I wouldn’t focus on whether a candidate knows every language feature. Instead, I’d ask:

Can you break down an ambiguous, multi-part requirement into manageable components?
Can you design high-leverage prompts to get useful results from an agent?
Can you architect systems where humans and agents collaborate meaningfully?

In that sense, prompt literacy is becoming just as important as code literacy.

The Road Ahead: Human-in-the-Loop Programming

We’re not moving toward a future where developers become obsolete.

We’re moving toward one where developers become more human:

Less typing, more thinking
Less repetition, more orchestration
Less syntax, more semantics

I don’t know where AI will take us next. A year ago, the tools I use today didn’t even exist. But I do know this:

I no longer measure myself by how much code I can write. I measure myself by how well I can direct, verify, and refine what AI writes.

That’s the new senior engineer mindset.

Final Thought

“It’s not just about writing code anymore. It’s about managing meaning across agents, tools, and human intent. That’s engineering at the next level.”

Clean Code: The Art of Self-Documenting Code

Luke Tong — Wed, 04 Jun 2025 06:08:43 +0000

As a senior software engineer with over a decade of experience, I’ve seen how comments in code can evolve from helpful documentation to misleading traps. Today, I want to share some insights about writing cleaner, self-documenting code.

The Problem with Comments

Why Im so down on comments? Because they lie. Not always, not intentionally but too often. The older the comment is the more likely it is to be wrong. The reason is software engineers maintain the code but not the comments. Code will not lie to you but comment will; Code evolves but comments not. Thus comments sometimes will be misleading.

Therefore although comments are sometimes necessary, we need to try to minumise them.

One of the common motivation for comments is bad code. We wrote a piece of code and we know it is complex, confusing and hard to understand. So we say to ourselves, “It is good for readers, I need to write down my thoughts here”. But we have another choice, we can spend time in cleaning it.

Have a look at the below piece of code:

//does the module from the list depend on the subsystem?
if(module.getDependSubsystems().contain(othermodule.getSubSystem()))

At first glance, the comment seems helpful. But let’s break down why this isn’t ideal:

- The comment is explaining what the code does (which should be obvious from the code itself)
- There’s a typo in the method name (contain vs. contains)
- The variable names aren’t as descriptive as they could be ###The Better Approach Here’s how we can refactor this code to be self-documenting:

List<String> dependentSubsystems = module.getDependentSubsystems();
String targetSubSystem = otherModule.getSubSystem();
boolean isModuleDependentOnSubSystem = dependentSubsystems.contains(targetSubSystem);

if (isModuleDependentOnSubSystem) {
    // handle dependency case
}

Let’s analyze the improvements:

Meaningful Variable Names: dependentSubsystems and targetSubSystem clearly describe their purpose
Extracted Boolean Logic: The condition is now stored in a well-named boolean variable
Proper Method Names: Fixed the typo in contains
No Comments Needed: The code is now self-explanatory

When Are Comments Appropriate?

Comments aren’t always bad. They’re useful for:

Legal requirements
API documentation
Complex algorithms that can’t be simplified further
Explaining why something is done, not what is being done

Conclusion

Remember: The best code is code that tells its own story. Before adding a comment, ask yourself: “Could I make this clearer through better code structure?”

Beyond double: Essential BigDecimal Practices for Accurate Financial Calculations

Luke Tong — Wed, 28 May 2025 05:25:19 +0000

If you’ve been around software development for a bit, especially anywhere near financial applications, you’ve probably heard the golden rule: don’t use double (or float) for money. It's common knowledge, and for good reason – floating-point arithmetic can lead to precision errors that are a nightmare in finance. The go-to solution is java.math.BigDecimal.

However, simply switching to BigDecimal isn't a magic bullet. There are nuances to using it correctly that can trip up even experienced developers. I've seen these issues pop up time and again, so let's dive into some crucial points that often get overlooked.

Initialize with Strings: The Precision & Scale Matter

You might be tempted to create a BigDecimal like this:

// Don't do this!
BigDecimal amount = new BigDecimal(0.1);
System.out.println(amount); // Might print something like 0.1000000000000000055511151231257827021181583404541015625

“Wait, what?” Yeah, that’s not exactly 0.1. The problem is that the double literal 0.1 itself cannot be perfectly represented in binary floating-point. When you pass it to the BigDecimal(double) constructor, you're essentially creating a BigDecimal from an already imprecise representation.

The correct way to initialize BigDecimal with a specific decimal value is to use the string constructor:

BigDecimal correctAmount = new BigDecimal("0.1");
System.out.println(correctAmount); // Prints 0.1

Why? Because the string “0.1” is an exact representation. BigDecimal uses concepts of precision (the total number of digits) and scale (the number of digits to the right of the decimal point). The string constructor allows BigDecimal to parse this representation accurately, preserving the intended precision and scale.

Got a Double? Use BigDecimal.valueOf()

Sometimes, you might receive a double value from a library or an external system, and you need to convert it to BigDecimal. If you're stuck with a double variable, avoid the new BigDecimal(double) constructor for the reasons mentioned above.

Instead, use the static factory method BigDecimal.valueOf():

double priceDouble = 0.1;
// BigDecimal stillNotIdeal = new BigDecimal(priceDouble); // Avoid if possible
BigDecimal betterPrice = BigDecimal.valueOf(priceDouble);
System.out.println(betterPrice); // Prints 0.1

BigDecimal.valueOf(double) is generally preferred over new BigDecimal(double) because it often gives a more predictable result. It uses the canonical string representation of the double (e.g., Double.toString(doubleVal)), which can help avoid some of the more egregious precision issues you see with the double constructor directly. However, remember the best practice is to start with strings or integers if you have control over the input.

Formatting Floats? BigDecimal is Your Friend, Not String.format()

When it comes to displaying floating-point numbers, especially currency, formatting is key. You might instinctively reach for String.format():

double value = 123.456;
// String formatted = String.format("%.2f", value); 
// Potential for rounding surprises

While String.format() works for basic cases, when dealing with the precision that BigDecimal offers, it's better to let BigDecimal handle its own formatting, often in conjunction with NumberFormat for locale-specific currency symbols and conventions.

For simple scale setting:

BigDecimal preciseValue = new BigDecimal("123.456789");
BigDecimal roundedValue = preciseValue.setScale(2, RoundingMode.HALF_UP); // Explicit rounding
System.out.println(roundedValue); // Prints 123.46

// For currency formatting:
NumberFormat currencyFormatter = NumberFormat.getCurrencyInstance(Locale.US);
System.out.println(currencyFormatter.format(roundedValue)); // Prints $123.46

By using BigDecimal's setScale() method with an explicit RoundingMode, you have full control over how rounding occurs, which is crucial in financial contexts.

Comparing BigDecimal: equals() vs. compareTo() – The Scale Trap!

This one bites a lot of people. You have two BigDecimal objects that represent the same numerical value, say $10.00 and $10.0.

BigDecimal val1 = new BigDecimal("10.0");  // scale = 1
BigDecimal val2 = new BigDecimal("10.00"); // scale = 2

System.out.println(val1.equals(val2)); // Prints false!
System.out.println(val1.hashCode() == val2.hashCode()); // Likely false!

Why false? Because BigDecimal.equals() considers both the value and the scale. Since "10.0" (scale 1) and "10.00" (scale 2) have different scales, equals() returns false. Similarly, their hashCode() values will likely differ.

If you want to check if two BigDecimal objects represent the same numerical value, regardless of their scale, you must use compareTo():

System.out.println(val1.compareTo(val2) == 0); // Prints true!

compareTo() returns:

0 if the values are numerically equal.
A negative integer if val1 is numerically less than val2.
A positive integer if val1 is numerically greater than val2.

So, for logical equality of monetary amounts, always use compareTo() == 0.

The Silent Killer: Numerical Overflow with Primitives

Beyond BigDecimal, let's touch on a general numerical gremlin: overflow. All primitive numeric types in Java (byte, short, int, long, and even char when used numerically) have a fixed range of values they can hold.

What happens when you exceed this range?

int maxIntValue = Integer.MAX_VALUE; // 2147483647
int result = maxIntValue + 1;
System.out.println(result); // Prints -2147483648 (Integer.MIN_VALUE)

long largeNumber = Long.MAX_VALUE;
long overflowed = largeNumber + 100; // Wraps around to a negative number
System.out.println(overflowed);

Notice something scary? No error! No exception! The calculation silently wraps around. This can lead to incredibly subtle and dangerous bugs, especially in calculations involving quantities, counts, or IDs.

The solution? Since Java 8, the Math class provides "exact" arithmetic methods that will throw an ArithmeticException on overflow:

try {
    int sum = Math.addExact(Integer.MAX_VALUE, 1);
    System.out.println(sum);
} catch (ArithmeticException e) {
    System.err.println("Overflow detected! " + e.getMessage());
}

try {
    long product = Math.multiplyExact(Long.MAX_VALUE / 2, 3); // This would overflow
    System.out.println(product);
} catch (ArithmeticException e) {
    System.err.println("Overflow detected during multiplication! " + e.getMessage());
}

Other useful methods include subtractExact(), multiplyExact(), incrementExact(), decrementExact(), and toIntExact() (for converting long to int safely). Using these methods makes your code more robust by failing fast when an overflow occurs.

Wrapping Up

Working with numbers in software, especially when money or critical quantities are involved, requires diligence. BigDecimal is a powerful tool, but like any tool, you need to understand its intricacies. And always be mindful of the limits of primitive types!

By keeping these points in mind:

Use string constructors for BigDecimal (new BigDecimal("0.1")).
Prefer BigDecimal.valueOf(double) if you have a double.
Format using BigDecimal's methods (setScale()) and NumberFormat.
Compare values with compareTo(), not equals().
Guard against primitive overflow with Math.xxxExact() methods.

You’ll write more accurate, reliable, and maintainable code. Happy coding!

The Subtle Pitfall of @RequiredArgsConstructor: A Lesson from Integration Testing2

Luke Tong — Thu, 15 May 2025 23:43:09 +0000

Introduction

Recently, I encountered a frustrating issue in our Spring Boot application test suite. One specific test kept failing with a 500 Internal Server Error while similar tests were succeeding. After hours of troubleshooting, the culprit turned out to be a single missing keyword - final. Let me walk you through the debugging journey and explain why this tiny oversight had such a significant impact.

The Problem

I had a test case shouldSuccessfullyCallMyService() that consistently failed with a SERVER_ERROR, while similar tests like shouldSuccessfullyCallCreateStopAccount() worked perfectly fine. Both tests used MockWebServer to simulate backend service responses, but only one was failing.

@Test
void shouldSuccessfullyCallMyService() {
    final String myServiceUrl = MY_SERVICE.replace("{resourceId}", RESOURCE_ID);
    final MyServiceResponse expectedMyServiceResponse = getStatus200MyServiceResponse();

    mockMyServiceServer.enqueue(
            new MockResponse()
                    .setResponseCode(200)
                    .setBody(convertObjectToJsonString(expectedMyServiceResponse))
                    .addHeader(CONTENT_TYPE, APPLICATION_JSON_VALUE));

    webTestClient.get().uri(myServiceUrl)
            // Headers and assertions omitted for brevity
            .expectStatus()
            .is2xxSuccessful();
}

The Investigation

My first instinct was to check the differences between the passing and failing tests:

HTTP Method: The failing test used GET while successful tests used POST
Response Structure: Perhaps issues in the response model?
Mock Server Configuration: Different configurations between tests?

I added debug logs to see what was happening:

System.out.println("Mock server URL: " + mockSapOrchServiceServer.url(myServiceUrl));
System.out.println("Response body: " + convertObjectToJsonString(expectedMyServiceResponse));

The logs showed the mock server was correctly configured, and the response body looked good. The most puzzling aspect was that the test was failing with a 500 error, suggesting an exception in our controller or service layer.

The Breakthrough

After ruling out issues with the test configuration, I shifted focus to comparing the controllers handling these endpoints. The YourController handled the successful endpoints, while MyController handled the failing endpoint.

Looking at both controllers side by side revealed the subtle but critical difference:

// YourController.java - working correctly
@RequiredArgsConstructor
public class YourController implements YourApi {
    private final YourService yourService;
    // Other services...
}

// MyController.java - failing
@RequiredArgsConstructor
public class MyController implements MyApi {
    private MyServiceService myServiceService; // Missing 'final' keyword!
    // ...
}

The final keyword was missing from the service field declaration in MtController!

Why This Matters: Lombok and Spring Dependency Injection

This tiny omission had massive consequences because of how Lombok's @RequiredArgsConstructor works:

@RequiredArgsConstructor generates a constructor only for fields marked as final
Spring uses this constructor for dependency injection
Without final, no constructor parameter is generated for the service
Spring can't inject the dependency, leaving the service as null
When the controller tries to use the service, it throws a NullPointerException
The exception bubbles up as a 500 Internal Server Error

The Fix

The solution was elegantly simple:

@RequiredArgsConstructor
public class MyController implements MyApi {
    private final MyServiceService myServiceService; // Added 'final'
    // ...
}

After adding the final keyword, Spring could properly inject the dependency, and the test passed successfully.

Lessons Learned

Be consistent with field declarations: When using Lombok's @RequiredArgsConstructor, always mark dependencies as final.
Understand your annotations: Know exactly how annotations like @RequiredArgsConstructor behave.
Compare working vs. non-working code: Sometimes the most subtle differences cause the biggest problems.
Look beyond test configuration: When tests fail with server errors, examine your application code carefully.

Conclusion

This debugging journey highlights how a single keyword can make or break a Spring application. It also demonstrates why understanding the frameworks and libraries we use is crucial - what seemed like a complex issue with mock servers or HTTP methods was actually a fundamental misunderstanding of how Lombok and Spring work together.

Next time you encounter a 500 error in your Spring Boot tests, remember to check if your dependencies are properly declared and configured for injection. Sometimes the smallest details make all the difference!

Annoying NullPointerException part1

Luke Tong — Sun, 11 May 2025 00:56:10 +0000

One day, I received a text message that said, “Dear null, hello, XXX.” I laughed at that moment because it’s a joke that programmers can easily get. The program didn’t retrieve my name and instead formatted the empty space as null. Clearly, null was not handled properly. Even if it was replaced with “guest” or “customer,” it wouldn’t have caused such a joke.

When a variable in a program is null, it means that it has no reference or pointer. Any operation performed on this variable will inevitably result in a null pointer exception, which is called a NullPointerException in Java. So, when and how does a null pointer exception occur, and how can it be fixed?

Although null pointer exceptions can be frustrating, they are relatively easy to identify. What’s more troublesome is understanding the meaning of null. For example, when a client sends null data to a server, what is their intention? Are they providing an empty value or not providing any value at all? Another example is the NULL value in database fields. Does it have any special meaning? When dealing with NULL values in a database, what should be taken into special consideration when writing SQL?

Today, let’s embark on a journey to explore the pitfalls of null with these questions in mind.

NullPointerException is the most common exception in Java code, and I categorize its most likely scenarios into the following five:

Parameter value is an Integer or other wrapper type, and a NullPointerException occurs due to auto-unboxing when used.
NullPointerException occurs during string comparison.
Containers like ConcurrentHashMap do not support null keys or values. Attempting to put a null key or value forcefully will result in a NullPointerException.
Object A contains object B. After obtaining B through a field of object A, a NullPointerException occurs when invoking a method on B without checking the field for null.
A List returned by a method or remote service is not empty but null. Invoking a method on the List without checking for null will result in a NullPointerException.

To demonstrate these five scenarios, I have written a method called wrongMethod and another method called wrong to invoke it. The wrong method takes an input parameter test, which is a string of length 4 consisting of 0s and 1s. Each position represents whether the corresponding parameter in wrongMethod is null (1) or not null (0), allowing us to simulate various null pointer situations.

private List<String> wrongMethod(FooService fooService, Integer i, String s, String t) {
    log.info("result {} {} {} {}", i + 1, s.equals("OK"), s.equals(t),
            new ConcurrentHashMap<String, String>().put(null, null));
    if (fooService.getBarService().bar().equals("OK"))
        log.info("OK");
    return null;
}
@GetMapping("wrong")
    public int wrong(@RequestParam(value = "test", defaultValue = "1111") String test) {
        return wrongMethod(test.charAt(0) == '1' ? null : new FooService(),
                test.charAt(1) == '1' ? null : 1,
                test.charAt(2) == '1' ? null : "OK",
                test.charAt(3) == '1' ? null : "OK").size();
    }
class FooService {
        @Getter
        private BarService barService;

    }

    class BarService {
        String bar() {
            return "OK";
        }
    }

It’s evident that this case encounters a NullPointerException because the variable is a null pointer. Trying to retrieve the value of the variable or access its members will result in a NullPointerException. However, pinpointing the exact location of this exception can be tricky.

In the wrongMethod test method, we simulate four instances of a NullPointerException in a single line of code, which we log for tracking purposes. These instances are as follows:

Performing the operation +1 on the input parameter Integer i.
Comparing the input parameter String s to check if its content is equal to “OK.”
Comparing the input parameters String s and String t to check if they are equal.
Performing a put operation on a newly created ConcurrentHashMap, setting both the Key and Value as null. The output of the exception information is as follows: java.lang.NullPointerException: null at com.foo.myblog.nullvalue.controller.NullValueController.wrongMethod(NullValueController.java:41) at com.foo.myblog.nullvalue.controller.NullValueController.wrong(NullValueController.java:23) Next, let’s take a look at how to fix the five null pointer exceptions mentioned earlier.

In fact, the most straightforward way to handle any null pointer exception is to check for null before performing any operations. However, this approach only prevents the exception from occurring again. We still need to determine whether the null pointer in the program logic originates from the input parameters or a bug:

If it originates from the input parameters, further analysis is needed to determine if the input parameters are reasonable, among other considerations.
If it originates from a bug, the null pointer may not be solely a programming bug but could also involve business attributes and interface invocation standards. In this case, since it’s a demo, we will focus on the pure null pointer check and fix approach. When considering checking for null before processing, many people may think of using if-else blocks. However, this approach increases code complexity and reduces readability. Instead, we can try using Java 8’s Optional class to eliminate such if-else logic, enabling null checks and processing in a single line of code.

Here is the approach to fixing these issues:

For checking null with Integer, you can use Optional.ofNullable to construct an Optional and then use orElse(0) to replace null with a default value before performing the +1 operation.
For comparing String with a literal value, you can place the literal value first, for example, "OK".equals(s). This way, even if s is null, it will not throw a NullPointerException. For comparing two nullable String variables, you can use Objects.equals, which handles null checks.
Regarding ConcurrentHashMap, since neither its Key nor Value supports null, the fix is to avoid storing null values in it. While HashMap allows null as Key and Value, ConcurrentHashMap, despite being a thread-safe version of HashMap, does not support null values for Key and Value. This can be a common misconception.
In the case of cascading calls like fooService.getBarService().bar().equals("OK"), there are multiple places where null checks are required, including fooService, the return value of getBarService(), and the String returned by the bar method. Using if-else statements for null checks may require several lines of code, but using Optional allows you to handle it in a single line.
For the List returned by rightMethod, since it’s uncertain whether it is null or not, you can also use Optional.ofNullable to wrap the return value and then use .orElse(Collections.emptyList()) to get an empty List if the original List is null. Finally, you can call the size method.

private List<String> rightMethod(FooService fooService, Integer i, String s, String t) {
        log.info("result {} {} {} {}", Optional.ofNullable(i).orElse(0) + 1, "OK".equals(s), Objects.equals(s, t), new HashMap<String, String>().put(null, null));
        Optional.ofNullable(fooService)
                .map(FooService::getBarService)
                .filter(barService -> "OK".equals(barService.bar()))
                .ifPresent(result -> log.info("OK"));
        return new ArrayList<>();
    }
@GetMapping("right")
    public int right(@RequestParam(value = "test", defaultValue = "1111") String test) {
        return Optional.ofNullable(rightMethod(test.charAt(0) == '1' ? null : new FooService(),
                test.charAt(1) == '1' ? null : 1,
                test.charAt(2) == '1' ? null : "OK",
                test.charAt(3) == '1' ? null : "OK"))
                .orElse(Collections.emptyList()).size();
    }

These approaches can help you fix the null pointer exceptions and enhance the robustness of your code.

This raises another question: using null checks or Optional to avoid null pointer exceptions may not always be the best solution, as the absence of null pointer exceptions may hide deeper bugs. Therefore, to effectively address null pointer exceptions, it’s crucial to analyze each case individually, identify the root cause, and then implement appropriate null checks. Handling null values is not just about checking for non-null values and proceeding with normal business flow. It also involves considering whether an exception should be thrown, setting default values, or logging relevant information when encountering null values.

Each scenario requires careful consideration of the specific requirements and behavior of your application. This case-by-case approach allows you to address the underlying issues and handle null values in a way that aligns with your application’s design and requirements.

source code can be found in here

The Subtle Pitfall of @RequiredArgsConstructor: A Lesson from Integration Testing

Luke Tong — Fri, 09 May 2025 01:00:58 +0000

As a senior software engineer, I’m constantly navigating the balance between code readability, framework conventions, and real-world maintainability. Recently, a minor code review comment turned into a subtle debugging session that reminded me once again: annotations are powerful, but their magic must be understood deeply to avoid surprises.

The Setup: Constructor Injection in a Spring Controller

In a typical Spring Boot project, I had the following straightforward controller implementation:

@RestController
public class MyController {

    private MyService myService;

    public MyController(MyService myService) {
        this.myService = myService;
    }

    public MyResponse createAccount() {
        myService.myMethod();
    }

    // ...
}

This is clean, explicit constructor injection — something I’ve used and trusted for years. I had also written a full integration test using WebTestClient to verify the entire workflow, and everything passed smoothly.

The Code Review: “Use@RequiredArgsConstructor”

During a code review, a team member pointed out that the company’s coding guideline encourages the use of Lombok’s @RequiredArgsConstructor to reduce boilerplate. I’m personally not a big fan of @RequiredArgsConstructor, mostly because its behavior isn’t always obvious at a glance. That said, I didn’t see any immediate harm and refactored the controller:

@RestController
@RequiredArgsConstructor
public class MyController {

    private MyService myService;

    public MyResponse createAccount() {
        myService.myMethod();
    }

    // ...
}

No constructor. Just Lombok magic.

The Surprise: NullPointerException in Integration Test

To my surprise, my integration test suddenly failed with a NullPointerException at myService.myMethod(). It was clear: myService was null. But why?

How@RequiredArgsConstructorReally Works
Here’s the catch: @RequiredArgsConstructor only generates a constructor for fields that are either: final, or annotated with @NonNull.

In my refactored code, myService was neither.

So although the annotation was present, no constructor was actually generated by Lombok. Spring Boot silently used the default no-args constructor — and since myService was never initialized, the result was a null pointer.

The Fix

After reviewing the Lombok documentation, I updated my field to be:

private final MyService myService;

Now @RequiredArgsConstructor kicked in, generated the proper constructor, and Spring injected myService as expected. My integration test passed again.

Key Takeaways

Annotations like @RequiredArgsConstructor can be deceptive if not used carefully. Understanding how and when they generate code is crucial — especially in dependency injection scenarios.
Constructor injection remains the most explicit and reliable form of wiring dependencies, particularly in Spring-based applications.
Final fields signal immutability and are necessary for Lombok to do its job with @RequiredArgsConstructor. Final Thoughts Lombok can reduce boilerplate, but it comes with trade-offs. In teams, especially larger ones, annotations like @RequiredArgsConstructor can improve consistency — but only if everyone understands the magic behind the scenes.

So next time you get a null pointer where you least expect it, don’t forget to check whether your “constructor” actually exists.