Why do some teachers often consider bad practice things that are not? [closed]

Question

In college, teachers often say that some things are bad practices while they are not. I'm referring to the recent Why is naming a table's Primary Key column “Id” considered bad practice? question, or to the fact that my teacher told us that early returns are bad practice and must never be used. There are plenty of other examples everyone who have been in college remembers.

Once learned, those things are hard to unlearn. When you deal with an intern who learned something wrong from her teacher, it's not always obvious to explain that the thing the teacher told is either not totally true or sometimes completely wrong.

What makes those teachers mistakenly believe that things are bad practices, while in programming industry, most people would disagree with them? Don't they read programming books we, developers, read? Don't they talk frequently to developers?

Answer 1

First of all, I don't think it's valid to apply this argument to teachers. It happens to everyone. 10 year programming veteran or teacher with zero practical experience.

That said, there's a couple reasons I've seen:

• Something used to be a bad practice, for specific technical reasons, but no-longer is.
• The think/assume that a bad practice in one language applies to another similar one.
• They don't know any better and/or they lack experience.

The difference, that applies to teachers and senior devs, is that they are in a position of intellectual authority and are expected to know more/everything. So when confronted with something that they think is right (or even don't), some will fall into the trap of stating absolutes because they need to appear to know it all.

You've probably seen it already: Consider a teacher who doesn't know the answer to a particular question asked by a student, the teacher may fear that responding "I don't know" will make the student lose all trust/respect for the him/her. "Well, if he/she doesn't know that then why should I believe them at all?"

Answer 2

Well, it is possible that they don't communicate with "real-world" developers, they don't have much/any practical experience; it's possible they don't keep up with the industry and state-of-the-art and current standards, or that they just aren't very good at programming, and maybe there are some that really shouldn't be teaching it.

It's also possible that what they say is a "bad practice" is really more of a "not very good practice unless you use it sparingly and correctly and in the right situation and you won't really understand which is the right situation until you experience it and unfortunately there's just not enough time in the lesson to go into the gritty gory details".

Answer 3

A few reasons:

• Some teachers are bad programmers.
• Everyone tends to mix up "best practice" with "the way I do it is..." (same difference, right?)
• Most professors do not work in the industry, and many have not in years, so how would they be expected to know industry best practices.
• Most best practices still have quite a bit of room for argument. For example, everyone knows you need to test; does everyone agree that you must always use TDD and write tests before code? Cleary, no. Not everyone even seemed to agree on the issue of PK naming in the question you referenced. How can you really say your professor was wrong?
• Best practices are sometimes wrong. In the case of the PK naming, I have heard that naming system described as a best practice many times. The methodology that would come to be called Waterfall, was best practice a couple decades ago.
• There are limits to everyone's knowledge, including professors. Many professors use their brain cells up focussing on extremely specialized issues. Questions like "In general, should I use Linq query syntax or expression syntax?" do not come up when you have been studying theoretical quantum computing for 10 years.

Answer 4

Affinity to Theory

There is a compelling reason against the use of 'id' columns in every single table, the way that for example ActiveRecord does it. You are essentially duplicating information, a lot of tables could be modeled without (ab)using 'id' as a unique identifier. Most the things you learn at university have a strong foundation in theory (relational algebra in this case). Early returns also fall into that category. In theory they are making it harder to figure out where your method exits and causes headaches when you are trying to determine the code coverage. After all, most of the time universities are teaching Computer Science, not programming.

Teaching Beginners

When teaching SQL to a student you want to make sure he understood the theory behind it, if he later goes on and slaps id columns everywhere that is ok with me, because after understanding the theory he should know the repercussions. It is easier for a student to later not follow the approaches he learnt that rigorously, than relearning the theory.

Answer 5

Because in a textbook scenario, there's usually only one or two answers and the wrong approach is apparent. However, in a real-world scenario there are other factors and when weighed up, they may not be as bad as they are made out in academia. Do you have other examples than "don't use Id for Primary Key names"?

Answer 6

First, the concepts of "best practice" and "bad practice" are vague. There are three things to regard when it comes to best practices. The first is that best practices only apply to most projects most of the time. They don't necessarily apply to every project all of the time, and in some cases, a "best practice" might actually be detrimental to the project. The second is that best practices evolve over time. What was considered a best practice a couple of years ago might have fallen out of favor or a better practice has come along. Finally, projects can establish their own practices, and for the sake of consistency and ease of communication, maintain these practices even though they might have fallen out of favor.

Given the fact that what is considered "best practices" or "bad practices" change, coupled with the rapid changes in the computing field, it's not surprising that most teachers are out of date. Most people who teach, sadly, are not in touch with the latest developments in industry. I was very fortunate that all of my professors had industry experience, remained in close contact with people still working in industry, and worked to stay up-to-date. Some even took sabaticals to spend time working to stay fresh. However, not all people who teach do this, and continue to teach either what they were taught or teach what they learned in industry, which is often significantly out-of-date.

If you have someone on your team who has learned practices that are not appropriate for your environment, you need to teach them two things - what they should be doing and why they should be doing it that way. However, you also need to learn from them as some of their practices might actually be beneficial to the team, project, or organization. Allow them to learn from you to add to their knowledge, but also contribute back. If they aren't willing to learn or share their knowledge, then it becomes time to reevalute your hiring processes - going back to the rapid changes in the field, you need people who are always willing to learn, share, and adapt.

However, you should also look at becoming more involved with Industrial Advisory Boards at universities. At the university that I went to, the department's Industrial Advisory Board was a group of people who do work in that field, for companies that would hire graduates. Their goal is to ensure that graduates of the program have the skills and knowledge to make them hireable. They review the curriculum, propose changes, and if they have graduates (especially recent graduates) or co-ops/interns working for them, discuss the strengths and weaknesses they see in the program.

Answer 7

1. Not all they say is true and not all that is true they say, but still: there is truth in what they say.
2. There is a difference between "this is bad practice" and "never ever do this". You can expand them to "in most cases there is a better solution" and "in all cases, it is a bad solution".
3. University is hardly the right place to teach you about all the exceptional cases, where resorting to things considered harmful is the best solution. Your work experience will teach you that. And also most of these cases highly depend on the language employed.
4. When first learning something, you should adhere to a small set of simple rules and seek understanding of why they are in place. As your understanding grows, you will be able to refine your ruleset both in breadth and depth. From The Tao of Programming:

   There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.''

Answer 8

Much of it is because they don't evolve once they get set in academia. Someone who grew up on long procedural C routines would be correct in saying early returns are horrible.

However, fast forward to today and if you have are using an object oriented language like C# and keeping your methods concise, an early return is fine.

Some things just arise out of hubris, since there's really nothing keeping them from declaring their own preference as best practice. Naming conventions etc typically fall into this category.

Answer 9

What makes those teachers mistakenly believe that things are bad practices, while in programming industry, most people would disagree with them? Don't they read programming books we, developers, read? Don't they talk frequently to developers?

What makes you think this solely applies to teachers/professors? You said yourself that when somebody learns something it can be hard to unlearn. I've seen on this site alone that there are many people here who work with people who don't follow standards or believe in bad practices.

What makes those teachers mistakenly believe that things are bad practices, while in programming industry, most people would disagree with them? Don't they read programming books we, developers, read? Don't they talk frequently to developers?

Talking to a developer who follows bad practices can just enforce, in the teachers mind that the teacher isn't doing anything wrong. Also, depending on the school the teachers main job may not be teaching but research, in which case the "best practices of the real world" aren't at the top of the list for the teacher.

Answer 10

The key is why. Don't do it this way because it will make your app 1ms slower. 99% of anyone paying for software development probably won't care.

Consider the reasons and decide for yourself, but be careful. You may be ignoring issues that will become problems. Bad experiences can be great teachers, but avoid them if you can. Refactoring or upgrading databases to handle new features

Answer 11

Quick Short Answer:

There are different ways to solve a problem, wheter is Collegue or Full-Time-Job.

Things like "Best Practices" are very useful, but, as many things, should be applied in a practical manner, meanning many times you applied, a few times, not.

Long Boring Descriptive Answer

One real world case, I had. I worked in a company where the business application had some legacy code, and the chief of developers, old guy, didn't care about "Best Pratices". Some of that code, was working so bad, that really need a full start from scratch.

There where also new modules, done or supervised by the second main developer, a young person that just finished school, that want everybody to use "Software Patterns". And you may know there are several software patterns, not just one. And he insisted on using the patterns, even if it was the wrong one.

Example of different "Best Practices"

In your example of "ID" in databases tables, some people use:

Example 1 (Same fieldname can be used for different keys & fields):

SaleItem = {
  int Id,
  int Product,
  int Qty,
  double Price,
}

ProductItem = {
  int Id,
  int Name,
  double UnitPrice,
}

/* has to rename a lot of fields, */
/* "WHERE" sentence fields are different for the same concept */

SELECT 
  SaleItem.Id AS SaleId,
  Product.Id AS ProductId,
  Product.Name AS ProductName,
  SaleItem.Qty,
  SaleItem.Price
FROM
  SaleItem INNER JOIN Product
ON
  (SaleItem.Product = Product_Id)

Others:

Example 2 (Same field concept still has different names):

SaleItem = {
  int SaleId,
  int Product,
  int Qty,
  double Price,
}

ProductItem = {
  int ProductId,
  int Name,
  double UnitPrice,
}

/* "WHERE" sentence fields are different for the same concept */

SELECT 
  SaleItem.SaleId,
  Product.ProductId,
  SaleItem.Qty,
  Product.ProductName,
  SaleItem.Price
FROM
  SaleItem INNER JOIN Product
ON
  (SaleItem.Product = Product_Id)

Me:

Example 3 (Verbose, but, same field concept uses the same across tables):

SaleItem = {
  int SaleId,
  int ProductId,
  int SaleQty,
  double SalePrice,
}

ProductItem = {
  int ProductId,
  int ProductName,
  double ProductUnitPrice,
}

/* (with "redneck" voice) */
/* "Look ma', no aliases and the keys have the same name !!! " */

SELECT 
  SaleItem.SaleId,
  Product.ProductId,
  SaleItem.SaleQty,
  Product.ProductName,
  SaleItem.SalePrice
FROM
  SaleItem INNER JOIN Product
ON
  (SaleItem.Product_Id = Product_Id)

---

This example shows that "Best Practices", altought very useful, must be well supported by facts, and cannot be applied to all cases. And in some cases, is subjective to the people who use them.

Answer 12

As a novice many things are bad practices, or too difficult to use properly even if they are the right tool for the job.

It's the same reason we have safety scissors, training wheels, and forbid the use of goto to novice programmers.

Answer 13

Because a lot of "bad practice" are faster to teach as "X is a bad practice" than "Y is a bad practice in Z kind of languages because bla".

The exact same problem is present everywhere a rule is given without spelling the reasons it has been written: after 5 or 10 years, the reasons have disappeared but the rule stays.

Answer 14

I have been working both as a teacher at university (for 3 years) and as a developer (for more than 10 years altogether).

In (Computer) Science you always look for the best solution possible for a problem. In my opinion it is good that students be taught what is the best known way of doing things: I would never say "Hey, I know this very good way of optimizing tables but I will not teach it to you because in mainstream software it is rarely used."

In practice, you look for a solution that is good enough wrt to the time you have at your disposal. Probably you could remove most of the id columns from tables or program without early returns (like in Pascal). But it is faster to use id columns and early returns as long as you know what you are doing. E.g. you should know that using one early return in a method is normally OK whereas using twenty of them is probably bad. Knowing that you do not really need an early return can be a motivation to remove a few if your code contains too many of them.

So I find no contraddiction between the fact that university teaches you good principles and practice teaches you to to find good compromises and decide when to follow them and when not. IMHO it is always better to know the best practice (even it is way too good for most practical applications) and then choose not to use it than not to know it at all.

Answer 15

Simple Economics

Teaching programming generally doesn't pay as well as actually programming.

What makes those teachers mistakenly believe that things are bad practices, while in programming industry, most people would disagree with them? Don't they read programming books we, developers, read? Don't they talk frequently to developers?

Some definitely do not. I once interviewed a C++ instructor at a UT branch campus for a job as a C++ programmer. He knew nothing beyond the horrible textbook they were using. I felt sorry for his students, who would get a pat on the head and a diploma and not much else.

Answer 16

Good answers.

Let me add, I was a CS professor for 4 years, so I understand the difficulty of teaching nuances to students. You tend to be a little over-specific, because it's like herding kittens on a diving board. If there's a way to fall off, they will find it.

But, my undergraduate degree was in Mechanical Engineering, and that included physics, chemistry, math, and some electrical engineering, plus a lot of lab and shop work.

I don't recall false certainties being taught in those other engineering and science disciplines. I do recall that the engineering professors and instructors seemed to have a pretty good familiarity with industrial applications. It seemed that industry was a fountain of interesting unexplored problems. It didn't seem they were prone to solving problems nobody actually had.

Why that appears to be a problem sometimes in CS, I don't know.

Answer 17

Academia and real life are nearly complete opposites in many ways.

When you're writing real code, you need to balance a number of competing ideals to produce a product that's good enough in many different respects. In academia, you're generally much more free to pursue one specific goal, and can sacrifice nearly everything else to get closer to that one ideal.

In real code, you generally need to restrict yourself to techniques that have already been developed and you're reasonably certain will work right here, right now, for this specific code. In academia, you're much more free to pursue ideas that may take years or even decades before they're developed to the point that they have any chance of showing real benefit.

Bottom line: what a professor treats as an absolute fact of utmost importance, the rest of the world will often see as one factor among many, and quite possibly of such minor importance that it can be ignored a good deal of the time. Even if they agree that the idea is right in itself, others may be so much more important that it's completely ignored most of the time.