Every other project I worked on was a "greenfield" project--a blank sheet of paper.
It took a while to adjust.
I'd always thought of legacy code as something that dull people maintained in the basements of banks.
I was an idiot.
In fact, legacy code is important code. If it wasn't important, a company would simply decommission it, but instead a company continues to fund its development (or at least its maintenance), despite all the problems the programmers who work on the code complain about.
Legacy code is virtually bug-free code, at least on the happy path. If it wasn't virtually bug-free, end users would complain and/or the code would crash. But it doesn't do that. Instead, it hums merrily away, the bugs having been dispatched years ago.
Working on legacy code, you don't have to worry about the project getting cancelled, the start-up running out of money, etc. You already have customers, and you already have revenue.
Legacy code pays well. A company can find millions of programmers who can write hello world, but not many programmers can do things like:
- Migrate a legacy database to a non-backward-compatible schema without impacting end users
- Revamp a legacy user interface to use Flex
- Convert a legacy build system to Maven
- Replace homegrown legacy infrastructure components with open-source libraries
- Refactor unstructured legacy code into layers
Besides, new code is just legacy code in waiting. Assuming some new code proves useful and survives, it eventually turns into legacy code. Yesterday's spiffy greenfield project is today's legacy codebase.
In most contexts, the word "legacy" has a positive connotation: freedom is the Founding Fathers' legacy; the National Park System is Teddy Roosevelt's legacy; prudent saving and investing leaves a legacy for one's children to inherit. This should be true for legacy code as well.
Consider yourself lucky if you get an opportunity to work on legacy code!