How satisfied are you with the code quality of your current project?

It's absolutely abysmal. It's an old Zend 1 project that has seen at least two attempts at a rewrite fail,and at one point went off to another agency for a year or two before coming back. Until I started on it, it had no tests, and the JavaScript was all spaghetti jQuery. Almost everything was crammed into fat controllers, and there was a huge amount of duplication (12% if you didn't include the view layer, according to PHPCPD). The models were used as both domain objects and repository-style classes, so to find an item by ID, you had to create a new object, then call find() on it to get that item.

But, it's teaching me a LOT about working with legacy code, refactoring and implementing design patterns.

I'm pretty much a novice.

My first real project is on GitHub here; I'm sure it's horrible...!

But I'm learning and am confident that I'm gonna be able to improve...

Any advice would be great though...

Thanks for the answers.
As I expected most of you is unsatisfied.
I wrote a short post about the topic:
dev.to/rlxdprogrammer/how-to-handl...

In the future I plan to write more about the topic if I find time.

It's by far the worst code I've ever seen in production. It's a huge legacy system started by college devs, then moved offshore, then back into the college devs team. They do not allow time to write tests, there are basically no tests at all, and almost every function is 100+ lines long of spaghetti with lots of shortened or single letter var names. There are bugs everywhere, unreachable statements, loops that immediately return, unsafe comparisons, the whole shebang. It's php 5.6 but written as if its php 3 or 4. I'm seriously thinking about jumping ship as I can't work on it since we are never given the chance to refactor or add tests. It's only getting worse and I don't want to be here when the ship sinks.

For me, happiness with (my) code-quality on a given project is inversely-proportional to the length of a given project. The longer the project, the greater the probability that I will have learned new techniques or improved on existing techniques. Further, if a project is longer, I'm more likely to have reason to revisit earlier code — even if I'm not accorded the time to fix said code. Thus, the longer a project goes on, the more-glaring the poorer quality of the earlier code becomes.

A real exacerbator of the preceeding is that the longer a program goes on, the more the project demands, change:

• Often, I'm the first thrown onto a given project because a project has a high (opening) urgency and I tend to be very quick to figure out how to get initial functionality worked out. On the plus side, being able to crank out functionality to meet the initial urgency is often the difference between a project receiving full-authorization rather than suffering from infant-death. On the minus side, a lot of that "quick" code is, objectively, "garbage" that needs to be refactored if not whole-sale replaced. Getting bounced from infant-saving to infant-saving project makes it often feel like the only coding I'm capable of is garbage-coding ...which is, for obvious reasons, kind of discouraging (not to mention, "how do you even put that on a résumé?").
• Related: early project-involvement often means you're dealing with a project that doesn't have a lot of specification behind it. So, you're writing to meet a nebulous end-stand. This isn't often a recipe for terribly "solid" code.

I don't think anyone is ever satisfied with the code on their project. There's always going to be technical debt, misalignment of the architecture with the present requirements, "old" code that should be replaced with more modern libraries or coding styles or whatever is popular with you today, more unit tests, etc.

I think the more important thing is to aim for the most cost effective code, not some arbitrary quality level. That gets you thinking about things in terms of dollars, which aligns you with your business.

Sometimes the most cost effective thing is to slow down a bit, do code reviews, and write tests for that new code. And sometimes the most cost effective thing is to "hack" something together and get your site back online now.

Getting things in dollar terms allows you to have intelligent conversations about the merits of various approaches to quality and schedule with the stakeholders of your software.

Could be better, but could be worse too.

Have a code base with a few minor (known) bugs.

Most of them are based on the fact that the back-end lies to me, haha.

I will inprove the API client next. No more trusting error codes.

In my next projects I'll also try stuff like TypeScript with strict null checks and Storybook. These tools seem to solve most of my refactoring problems.

I'm mainly working on maintaining legacy applications written in various flavors of the Microsoft stack from VB6 to WCF. It was written and patched by 20+ programmers over the past 22 years. It is a mess.

The good thing is that we are moving forward on replacing it with better quality code. It's just going to take a while because the "keep the lights on" maintenance takes up a lot of time.

To be honest, our code could ~should~ be a lot better. Architecture is just a monster and has changed twice since we started the project.

To clarify, "our" project is just a piece of a much bigger project, and things have changed a lot around here.

Also, can't deny that I have learned a lot about developing, code quality and javascript in general, so now I have more tools and knowledge to improve old code.

What keeps us from improving more, is probably IE support and the constant changes to the bigger project's structure.