[gedrap]

From both my own experience and witnessing others, one major factor that sets apart from beginner and expert is working with legacy code. And by legacy I mean legacy from previous developer, previous team, whatever, not necessarily a decade old code base.

Beginners are keen to get rid of all the legacy code. It's tightly coupled, it's hard to read, hard to maintain, yada yada yada. And then they tend to make a way too optimistic estimate on how long it will take. While it might look like nothing fancy from outside, under the hood it often handles loads of edge cases etc. Been there, almost done that (didn't fit in the budget which was way too optimistic already). Eh.

Experienced programmers understand that it's not perfect, but they just live with that. Surely there are some cases when maintaining the codebase would be waste of money because the previous coder was a disaster, and sooner or later it will have to be scrapped away. But it's more tempting to do that than actually needed.

[collyw]

I had a nightmare of VB6 code to work on. Something like 3/4 of a million lines, and lots of deadlines to meet. No consideration given to quality - just have it working by friday. It was in the financial industry.

On more than one occasion you would write a subroutine to do something, then a month or two later, you would see someone had already written that same functionality.

[nollidge]

Also I'd argue one shouldn't be considered an expert programmer until they've been forced to maintain lots of legacy code. It's an incredible lesson in what not to do, knowing when to comment and when not, proper naming, which things to optimize "prematurely" based on your experience-based predictions of how your application will scale, how to organize code in support of a growing codebase, etc.

[nikster]

Experienced programmers refuse to take the job.

We once tried to contract this really fancy team to take over some code. They asked if we had unit tests. "No". "Then we can't do it, sorry, bye."

And I agree with them.

[ufmace]

Really fancy, hmm... They strike me as being not very useful if they aren't willing to touch the code unless it meets some quality standard. I can understand turning down a contract if the code is total mess and the client wants major work done in an unrealistic amount of time or for too little money. In this case, why not reply more like "We're going to have to do some refactoring before we do X. If your budget allows for that, then we'll take the job."

[gregimba]

On the other side if all possible edge cases break it may be time to rewrite your code.