It isn't unheard of...

It is not uncommon, see laputan.org/mud

It can happen. But it must be said that in our branch some people can accumulate 30 years of bad practice and other who stick to outdated practice without questioning themselves and without taking any opportunity to improve. It might be linked to overconfidence and fear of leaving the comfort zone. In some rare cases the choices can be justified. In most of the cases you just have less maintenance because the product has less evolutions and some happy users who prefer the status quo. The principles you've learnt are great. Practice them as much as you can and be a vector of change.

Those developers might be as well just demotivated. They seem to be assigned to maintaining a rather mundane business application after having spent 30 years in game development.

I've opened a discussion on the title in chat: chat.stackexchange.com/transcript/message/40126879#40126879 Please join me.

Yes, it is common. That's why we have places like thedailywtf.com.

A game developer might be more justified in using massive methods to avoid the cost of a method call (itself something that varies from non-existent to appreciable in different contexts) than someone writing a code-behind for a web form. What's a justifiable departure from good practice (almost to the point of actually being good practice) in one context, may not be in another.

I've seen my share of bad software. They often start as a pilot, proof of concept, the developer do it quickly and when it goes live, there's no time to do the code properly.

Anecdotal... I write code for a state government. Bad coding practices are often the norm. Some people are aware that there's better ways to do things, and some just don't know/care. And some people in charge enforce that we do things the old ways for "legacy reasons."

Are you familiar with Sturgeon's Law?

I've never seen a house that didn't have some kind of patch job done to it somewhere (whether during construction or maintenance). Similarly, I've never seen a codebase without any arguable SOLID violations either. Implementing SOLID can often lead you down a rabbit hole of refactoring; and when that rabbithole is considerably larger than the fallout from avoiding a pedantically accurate SOLID implementation, many (if not all) developers will stop SOLIDifying the code base, as it ends up wasting time for little to no benefits.

Define bad. Then do it again when you have maintained your own code in production. You might be surprised.

They use ... - afraid you already declared yourself as outsider for their company, not a good sign :)

This is exactly why the book "Code Simplicity" was written. Highly recommended. A taste of the author's take on things: Refactoring is About Features

There are best practices and there is the real world. In the real world you often need code that works and that can be shipped, not code that can be verified to work by tests. So when you need to finish feature X, will you write unit tests or work on feature X? There are companies doing proper software engineering, but many are just doing programming work. And often it works just fine. You need to find the point when you need to use best practices because your code bases grows so big that nobody has the overview anymore. This should not advocate this practice, but just state that it's there.

The problem with every human endeavor is that most people doing it are average or below. Damn you, bell curves!

@T.E.D. so, raise the average. If the average gets to 100%, problem solved.

In 20+ years of professional development, I have seen way more poorly written code than well written code. You'll hear all sorts of lame excuses for why it's OK. Don't believe them. They all boil down to what Larry Wall called false laziness. Well written, properly factored code almost never needs to be touched again.

It's a lot easier for a college professor to see a new paradigm and change his course around it than for an application development team to see one and change their entire program and methodology around it.

They don't do units tests of any sort...everything is manual....any testing is done at a high level through what they call a system test bed.

I told one of them that I was going to learn haskell next year. Told them it was a goal of mine and that I wanted to. He didn't know what haskell was. I told him it is a pure functional programming language. Told him I wanted to learn a language that was in the functional paradigm. He didn't know what the functional paradigm or even procedural or imperative. Small things like this is why I question there methods of development. I try to be humble because I know that I am entry level and just started. That is why I asked the community the question I did.

You may want to look for a different job if these practices are important to you. I would think that generally, a bigger company with a good reputation has higher chance of using some better practices, even if they aren't cutting edge.

Well I want to work with the best so that way I can soak up as much knowledge from them as I can. I want to be an above average developer.

Ill will stay with them for 2 or 3 years and practice heavily in my spare time.

Said "they" because I am someone new looking from the outside in. I will be a part of the team and support there decisions until I leave. They have alot more experience than I do and as others have stated there are several factors involved into solving problems and its mainly based on requirements, scope of the project, time of delivery, problem size, technologies used, complexity etc...

I would wager at least half of all programmers at half of all jobs suck. That's only 25% so I'm not being cynical!

@grimlek If they have no formal education in programming, they may never have run across the different paradigms. That doesn't mean there's nothing to learn from them. Nor does the fact that don't do automated testing. Stay humble. They have years of experience you don't, and while their code isn't the best, your early years will not be spent producing good code, either. (Trust me. College does not prepare you for writing good code. I can tell you're not ready just by all the acronyms you list. ;) ) Just make sure you learn about what works well and what doesn't from the experience you gain.

I know im not ready yet, it will take years but along that path I want to be sure on im on the right track and not straying left somewhere

You might find this interesting: joelonsoftware.com/2001/12/25/…

Ah, I see that the powers that be eventually noticed the question and put it on hold. Of course, nothing here fits in the "on topic", "objective", blah blah blah framework of thought that is supposed to make this site better. Congratulations! We're officially morons.