Lessons Learned From Supporting Enterprise Applications

Starter draft. The observations below are generic; add your own experiences and remove anything that does not fit.

Building a new application and supporting an existing one are different skills. Greenfield work rewards decisiveness. Support work rewards caution, evidence and the ability to read code you did not write.

Some things that recur.

The code tells you what it does, not why#

Every established codebase contains decisions that look wrong and are not. The unusual null check, the retry that seems redundant, the column that duplicates another one. Frequently each exists because of an incident, an integration quirk, or a business rule that no longer has a written home.

"Clean this up" is the most expensive sentence in support work. Find out why it is there first. Commit history and issue trackers are documentation, even when nobody meant them to be.

Reproduction is most of the work#

The gap between "a user reports it fails sometimes" and "it fails when the payload exceeds 4 MB and the connection is slow" is where most of the effort goes. Once you can reproduce it reliably, the fix is often small.

That is also why vague bug reports are expensive: without a reproduction, you cannot know whether your change worked.

Logging is a feature you wish you had shipped#

The moment you need production diagnostics is the moment it is too late to add them. What actually helps:

• A correlation identifier flowing from the client through every service.
• Context in the message. Order 4821 rejected: customer 118 credit limit exceeded beats Validation failed.
• Enough to reconstruct the request, without logging anything sensitive.
• Consistent levels, so ERROR genuinely means something needs attention.

Small changes, understood changes#

In an unfamiliar codebase, the risk is not the fix — it is the code adjacent to it. A minimal change you fully understand beats a broader improvement you mostly understand.

Improvements are worth making. They belong in a separate change, with its own review and its own rollback.

Nobody remembers how to deploy#

Ask early: how does this get to production? Frequently the answer lives in one person's head, or in a document that is two releases out of date. Finding out during an incident is the wrong time.

Users describe symptoms, not causes#

"The report is wrong" might be a calculation error, a time zone problem, a caching issue, a permissions boundary, or a correct result the user did not expect. Get the specifics: which record, which value, what was expected, when.

Asking "what did you expect to see, and what did you see?" resolves an astonishing number of tickets before any code is opened.

Confidentiality is part of the job#

Enterprise work, particularly in regulated domains, involves data you must handle carefully — and cannot discuss afterwards. Internal architecture, business processes, customer information and screenshots stay inside. Knowing what you cannot say is a professional skill, not an obstacle.

It is also why the case studies on this site describe shapes of problems rather than clients.

What it teaches you#

Supporting production software changes how you build it. You start adding the log line before you need it, writing the error message for the person who will read it at 2am, and asking how a feature will be diagnosed when it misbehaves.

That is a habit greenfield work alone does not teach.