I'm not old enough to be responsible for stuff like that but I am incompetent enough.

Now that is a great conversation starter! I assume you think you know more than the senior/lead/architect on the team. You might, but have fun with that mentality. It's not sure to last. :)

oh, oh! I'm doing one of those. Only, it's a modern, MVC version, so there's actually a couple of dozen controllers with a single function each, and all actions snake through The Great Maze of Ifelsedom to set their rightful values, before traversing it once more on the page view file

Manager: "Uhm, I thought you said changing that label would be a 5 minute task?"

  git commit -m "$(curl -s developerexcuses.com | sed -n '/<a.*>/{s/<[^>]*>//g;p}')"

  awk -F'>' -v RS='<' '/a href/{print$2}'

    lynx -dump -nolist developerexcuses.com

We need you to change it back because the system that scrapes that page is relying on the page load time.

That's pretty unfair to people coming from history or psychology who actually can write good code. Just because you don't have a degree in CS doesn't mean your code is shit. This is purely anecdotal, but my predecessor at my current job was a CS graduate and wrote code like in the OP.

One of the real issues has to do with the mentality of coding. There are people regardless of background who approach coding as a job, and those who approach it as a craft. You want the latter, not the former.

Here's my rule:

If you don't look back at code you wrote a decade ago with some degree of horror, you are either an extraordinarily good coder, or you aren't a good coder at all.

The question is:

Are you improving? Or are you beyond improvement?

But what this means is I rarely come in the next week and wonder what I was thinking (it does happen, but rarely). More often I look at things, over a few months figure out better solutions to coding problems and my style changes accordingly.

Then again I started learning ios programming then so I might have a bias/reason for it. >.<

At the time, the majority of incoming CS freshman did not even harbor the most basic ideas or curiosity about how a computer functioned. They had all heard they could make mounds of money. When I took elective CS classes in college, I had graduate CS students attempting to copy off of me.

It's possible CS students and programs have changed since the 90s, but based upon the CS graduates I encounter, I expect they haven't improved that much.

At one job, I judged coding ability by the number of times your SQL woke me up due to huge I/O usage[1]. Many a CS graduate cannot read a query plan.

1) if it looked like a reasonable query and it was just Sybase's crap optimizer, I gave them a pass. Although, after a while, you learned to force the indexes.

The two most common issues are inability to create sanely defined and decomposed schemas and clearly written queries, and poor ability to structure code in an organized way.

That said, I have known a couple very good coders without any kind of formal education. They just seem to be outliers.

When dealing with formally trained developers I've certainly encountered the incompetent also, but I'd say at an easy majority of trained coders I've worked with are competent enough to not be hard to work with.

Mind I you I do not claim to be a "superstar developer" or anything. The state of the art tends to change just a bit faster than I can keep up with these days.

Code which can be fixed easily isn't "legacy". Code where a replacement would need to be bug-for-bug compatible in order to avoid breaking things is "legacy".

You could be writing legacy code today.

But other things change. The library changed its interface. You coded your crypto lib when MAC-then-Ecrypt was all the rage. You aren't handling HTTP/1.0 headers. Windows 7 doesn't even have those 16-bit drivers any more.

I hate the "throw everything away and rewrite with the brand new frame work every two years" that some parts of the web development community seem to have (and then get angered when you ask about a version over six months old because it is what you installed everywhere). But sometimes software does rot if it's old and no one is trying to keep it up-to-date.

The great thing about this definition is that it doesn't matter how old the code is - if it can be changed without worry about introducing unwanted behaviour because of test coverage, then it's not legacy.

It also means that you can write new legacy code right now!

I once made the argument that a team within my organization was actively producing new legacy code. It wasn't my most diplomatic moment.

It's always the function that's been rewritten twenty times that gets labelled as legacy code.

Hooray for short term job security!