I was a full stack Java developer. Then I joined Salesforce as a Technical Support Engineer.

For three years, my job was building things. At Riverstream Consultancy Services I built 100+ REST APIs and React frontends for enterprise clients. At Trust Fintech I built 20+ Spring Boot microservices for KYC, onboarding and loan processing. I measured success in features shipped, sprint deadlines met, and — the number I'm proudest of — zero post-release defects.

Then I joined Salesforce as a Technical Support Engineer. A few people asked whether that was a step away from development. It's the opposite. It's the other half of development — the half most developers never see.

What a Technical Support Engineer at Salesforce actually does

The title undersells the role. Salesforce's own job postings for Technical Support Engineers ask for proficiency in Java and hands-on experience debugging and troubleshooting Java applications. The work involves reproducing complex customer problems, isolating root cause, collaborating with product engineering on defects, and writing knowledge articles so the next person solves the same problem faster.

In other words, it's a seat built for developers — and I was hired into it because of my full stack Java background, not in spite of it.

Five things the other side of the table taught me

1. Nobody reads your code; everybody reads your errors. Customers never see the elegant service layer. They see the error message, the log line and the documentation. Those are the parts of the product that get tested hardest in real life — and they're usually written last, in a hurry.

2. "Works on my machine" is a statement about your machine. Real environments have proxies, firewalls, old client libraries, odd data and timeouts nobody configured. Reproducing an issue means rebuilding the customer's reality, not yours. Now, when I design an API, I ask what happens when the network is slow, the payload is huge or the client retries.

3. Every breaking change lands on someone's desk. Renaming a field, tightening a validation rule or changing a default feels harmless in a pull request. On the support side, it's an escalation from a team whose integration stopped working overnight. Backward compatibility is a kindness to people you'll never meet.

4. Root cause beats quick fixes — every time. I already worked this way: at Riverstream I resolved 30+ P1 bugs with an average root-cause-to-fix time under four hours. Support reinforces it daily. A workaround closes a ticket; a root cause closes a whole category of tickets.

5. Clear writing is an engineering skill. A precise bug report saves product engineering hours. A good knowledge article saves hundreds of customers from filing the same ticket. Writing clearly is how an engineer's impact scales beyond the problems they personally touch.

How this changes the way I write Java

These lessons show up directly in code. My APIs now return specific, consistent ProblemDetail errors instead of bare 500s. Every request carries a correlation ID through every log line. I treat performance problems that scale with data as bugs, not tuning. And I design for the failure paths first, because that is where real users spend their worst moments with software.

What this means for teams hiring Java developers

Most Java developers are evaluated on how well they build. Far fewer have spent real time on the receiving end of what they build. A developer with both perspectives writes code that produces fewer escalations, is faster to debug when something does go wrong, and can talk to customers, support and product in their own language.