Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This problem is a re-occuring one in my experiences. That of the ability to learn from other people's experiences, and being able to share what I have learned.

Part of the problem of this learning process, is the dependence on experience.

If for example, you've never had many jobs cleaning up other people's code for ease of readability, better written queries, and better logic, and validation practices, you might not have had developed the same practices and behaviors I have, in how I write my code.

This is what I call the "Experiental Gap".

It is very hard for people who haven't had the exact same experiences I have had to understand the reasoning why I have adopted the techniques and methods I have had.

Take as an example, source control, which is on the famous "Joel Test" as just one of the 12 items there.

Let's say you have worked with a wide variety of source control software/applications, not married to any of them, just want to use one that works. And have experienced a lot of the painful errors and problems that occur from not having source control.

Then how can you explain to someone who has never experienced those same problems, why source control is important and why they need to adapt it immediately.

This question is not about source control, that is just an example I am using to help illustrate the problem of communicating best practices or methods of any kind, when the reason we adopted them is mostly because of our personal work experiences.

Then when we meet someone that we see needs to adopt some of what we think is core, must have practices, and they have not had our experiences, it becomes nearly impossible to persuade or educate those people.

It's not because they are dumb or uneducated or stupid. It is because of the "Experiential Gap"

So now brings to the point of this question, because I want to be able to discuss and learn from other people how they have overcome this gap?

How do you teach or learn when you may not understand why you need to learn things or teach things.

Another example, I for years, have been anti-oo, anti-cfc's, (Used In ColdFusion). And then got into many flame wars because those people who have had the painful experiences could not persuade me of the importance of that.

And since i wasn't in a situation where I could experience what they had, this made for a very frustrating experience for both of us.

I didn't understand the need for the best practice.

And they couldn't understand why I didn't get it.

So how can we overcome this gap which is a key part of our learning process. Most of us, or a huge chunk of us, learn by self-teaching, reading, practicing.

This can be good and bad, but doesn't help us learn how to learn, or what to learn. Because then each of us have had different jobs with different skills and different experiences, then we each learn from those experiences, and can't really relate very well to people who haven't been what we've been through.

This is a very big but subtle problem, I think it needs to be addressed, if not by me, by someone more educated or experienced than I am.

I only want to help, us all learn more and learn from each other more easily..

Thanks...I hope this re-write is better.

Thank You.

share|improve this question
1  
From "Let's take for example the joel test..." to "... our ideas of what a best practice is" seems to be irrelevant to the actual question. Can you edit it in some way to focus on the actual question and avoid long war stories? –  S.Lott Jan 28 '11 at 14:59
1  
this is like the anti-thesis of my question the other day :-) programmers.stackexchange.com/questions/40508/… Good question though! –  jmo21 Jan 28 '11 at 15:12
    
To S.Lott, I just re-wrote the question, I hope this is clearer. Thank you for the compliment, this is important to me, I want to end the era of flaming over disagreements, that are really based on the Experience Gap. God I hope so :P –  crosenblum Jan 28 '11 at 15:16
    
@Developer - the other question is on Stack Overflow and will be migrated. We'll have to deal with the duplication when it arrives –  ChrisF Jan 28 '11 at 15:18
2  
No offense, I don't find those examples useless. They help me clarify a real world example of why the experience gap is a problem. But thank you for your concern. Oh I have a copy of that book "Coders at Work" I haven't had the time to finish reading it, I like that whole "at work" series. –  crosenblum Jan 28 '11 at 15:39

7 Answers 7

up vote 6 down vote accepted

As a lead I regularly face situations where I know a particular problem should approached or done (or not done) a particular way. I usually pick one of the following options to deal with the situation.

  • Dictate that we will/won't solve the problem a particular way.
  • Let them make the mistake, because the experience of the mistake is valuable. Iff it won't cost that much time/money.
  • Explain why there is a problem. Use examples to convince the other person.

I almost never dictate to a programmer. I think it's bad form, bad manners and indicative of other problems. If there is a break/fix situation we really don't have the time to talk about the issue, is about the only time I will override someone and tell them what to do (not do). I may also override someone if I can't convince them of the cost, and the cost is significant. I see those situations as my failings.

Occasionally I let programmers make their own mistakes. I've actually found as a learning experience it's the best teacher iff they see the consequences of what they did.

Usually I try and explain the problem using an example. I try and point out the cost or negative impact. Some will be concrete, while other costs may be soft (ie. team morale). I encourage dialectics; I want them to argue for their points as well. In those cases where the benefits out weigh the costs of the problem I will be swayed.

Characterizing the problem can be the hard part. Most problems are a problem because they have a negative impact or cost. Some are easy to point out and therefore usually easy to convince people that they are a problem. Some problems have a slight ongoing negative impact or cost and may be difficult see. Still others you may know are a problem, but you may not be able to explain why.

I've had great success teaching other programmers when I have a good example that shows the cost of the problem. Even with small ongoing costs, an example goes a long way towards at least helping others understand what you are looking at and why. Not being able to explain why something is a problem is bad. Sometimes it will turn out that it's not really a problem, other times it is. Either way the onus is on the programmer to make a convincing argument.

share|improve this answer
    
Very well said, I am not sure how that answer helps me, but it very well written and said. Thank You. –  crosenblum Jan 28 '11 at 16:33
    
@crosenblum I think it's all about the ongoing dialectics. Don't just sit their with your headphones on. Have technical discussions, argue your points, etc. –  dietbuddha Jan 28 '11 at 17:35

There are many reasons why best practices are not always followed:

Not Life Or Death

The unfortunate truth of web development is that in many cases, the products we develop don't involve life or death. Therefore, some of the best practices that are intended to produce quality, maintainable products that are 100% rock solid are not always adhered to.

Technology Changes Fast

Technology changes at an incredible rate. What is a best practice today may not be a best practice in six months. Best practices is about continuously asking yourself as an organization what you can do better.

Business Goals

Many times, the design goals of a project may dictate that speed is a necessity in order to break into a new market. In some cases, the difference between stopping to smell the roses and make sure all your hypothetical t's are crossed and i's are dotted can mean your competitors are innovating.

Meanwhile, you have a product that you think is right for the market, but you don't know because you haven't released it yet.

Although releasing that product early may mean costly maintenance, sometimes the question is about which is more costly, losing a contract or market opportunity, or dealing with cleaning up some messes later.

Company Culture

This sometimes coincides with business goals. Some companies, like startups, make it a point to be the first to enter a market. This involves a level of ruthlessness as a developer, because the goal kept in your mind must always be speed, speed, speed.

In summary, you are asking what our best practices are, but you also seem to be asking, indirectly, what others do to maintain best practices.

The bottom line is that if business goals are involved, you are best not rocking the boat. But if it's laziness or lack of awareness, or if it's just simply time to update to the newest best practice, then the best you can do is to continue to educate others and use your skills of persuasion to build support.

One of the most important skills for a developer is the ability to communicate his or her ideas and be a technical leader. Without great communication, moving forward with your agenda will be more of a challenge than it already is.

Good luck!

share|improve this answer
    
This question isn't about why they aren't followed, but about how the experiental gap, makes it much harder to explain or teach them. Does that make sense? –  crosenblum Jan 28 '11 at 15:35
    
@crosenblum - The experience shouldn't matter. In the Army they tell you to treat an unloaded weapon as if it's loaded. I don't need to understand why. The "Show them the pain" methodology here isn't even an option. In some industries, there is no room to allow people to learn from their mistakes. I don't need to understand that a weapon could be loaded even though I know (or think) that it's unloaded. I just follow the rules because that's what I'm expected to do, whether I understand it or not. If the Web involved more life and death situations, we wouldn't be having this conversation. –  jmort253 Jan 30 '11 at 7:30
1  
@crosenblum - Basically, if a person doesn't understand why a best practice is important, that doesn't give them full authority to ignore that best practice. Instead, it means that they better catch up or move onto another career... at least that would be the methodology once the Web is advanced enough to handle tactical targeting systems and medical monitoring equipment. –  jmort253 Jan 30 '11 at 7:32

Pair programming is a technique specifically designed to make transfer of this kind of information much easier.

In a pair programming setting, the more experienced of the two programmers has direct access to a live system, and can point out mistakes and problems as they arise - giving opportunity to highlight the negative consequences and more easily communicate what has been learned through experience.

share|improve this answer
    
Interesting approach that I have never experienced personally. And that's the problem, how can I know your answer is the right one, if i have never done it that way to understand if it is correct for me or not? Thank you though. –  crosenblum Jan 28 '11 at 15:20
1  
Pair program with me, and I'll show you. –  blueberryfields Jan 28 '11 at 15:22
    
What about situations where everyone is a peer? Without a "master slave" relationship how can one effectivly review the code of another? More experienced in terms of what? Should a 10 year progger with no .NET knowledge train a 3 year .NET guy on a .NET project? I prefer the term "peer review"... –  P.Brian.Mackey Jan 28 '11 at 15:33
    
Actually that does sound cool and interesting. Okay I want to do that, but how? And what programming languages? This sounds like an interesting challenge, and I accept! :) –  crosenblum Jan 28 '11 at 15:36
1  
I've actually found pair programming to work poorly when used to try and teach. It works best with 2 people of near equivalent experience and skill level, or at least deferral and trust in the teammate. –  dietbuddha Jan 28 '11 at 15:51

Show Them The Pain

You learned from experience. Experience comes from the pain of mistakes. Show me the pain points and chances are I will learn the same lessons.

good luck!

share|improve this answer
    
Interesting idea and approach. –  crosenblum Jan 28 '11 at 15:54
    
Which incidentially works better when you have practiced your communication skills ón SO... –  user1249 Mar 21 '11 at 8:15

I don't think it is an experience gap as much it is someone's unwillingness to learn or accept new things.

The flip side of that is that the person "teaching" is really bad at communicating and can't effectively demonstrate why one methodology is better than another.

share|improve this answer
    
Yes, but after having been in that situation so long, seeing the need for some adopting, but not able to get through, because the listener hasn't had the same experiences which forced me to certain conclusions. And that's my big point how can we share them better? –  crosenblum Jan 28 '11 at 15:37
    
you still claim that experience is the dividing factor...I am claiming that is not true. The person is either willing to listen or they are not. You are not going to change that short of threating their job. –  Pemdas Jan 28 '11 at 15:45
    
I see your point, but to me it's clear, that because they haven't seen and felt what you've experienced, that made you more interested in learning hasn't happened to them. So they see no point to learning anything more unless a specific assignment requires it. Where as, me, like you, always want to learn something more. –  crosenblum Jan 28 '11 at 15:56

I realize this is pretty long so I'll do a tl;dr version. We need to stop hand-waving, and use concrete examples.

So I can relate to what you said. I got into an unintended flame war and was actually accused of being a troll when I asked on the Alt.NET mailing list for someone to explain to me what made nHibernate in their experience a better O/RM than the original Entity Framework. No one could give an answer that was better than "it just is".

After EF introduced code-first, I saw the difference. This was what nHibernate users have been used to for quite a while now. Once you don't have to perform tricks to get the O/RM out of the way, code flows a lot better.

I'm currently writing a book on MVVM because I see the same problem. There are many people who look at it and say "I just don't get it, why would I go through all that trouble?" There are others who go full hog on MVVM without fully understanding why they're doing it (and in many cases I've seen end up doing it wrong). My goal is to provide them with the experience of "discovering" MVVM for themselves.

I used this approach to help introduce patterns to junior developers. I started them with a core template for implementing features and let them get to coding. Eventually, someone would say "You know I'm getting really tired of doing [X]." And I took the opportunity to introduce them to a pattern that solved their problem.

It's hard to discuss benefits of a particular approach to development without having a concrete example to pore over. Code is already abstract enough without doing a lot of hand-waving in the process.

If you look at the Dreyfus Model of Skills Acquisition there is a vast difference between a Novice and an Expert. Regardless of how much experience you have in software, there is always something that you are a Novice at. When you (or I) as a Novice approach someone who is an Expert at that specific skill and ask for them to explain why they do things the way they do, it can be difficult for the Expert to understand where you are coming from. The expert has probably long forgotten what it was like before he started doing things the way he does it. The discussion can be frustrating at best. At worst (as we both have seen) it turns into a flame war.

The way to address the problem is for more of us to realize that there is a quantum leap from novice to expert and assume a less antagonistic posture when discussing ideas. The best way to solidify your knowledge is to help someone else attain it.

share|improve this answer
    
Very interesting response, and I agree about the kind of responses you get. –  crosenblum Jan 28 '11 at 17:37
    
I hope you at least define MVVM in your book about it. –  user1249 Mar 21 '11 at 8:20
    
I see what you did there ;) MVVM==Model-View-ViewModel –  Mike Brown Mar 21 '11 at 15:31

I've always preferred using "Consider the following" moments. That is, ask them a question that demonstrates how/when practice X breaks. Then, give them some time to think of how to fix it, before offering up better practice Y. I find it also helps to point out some of the limitations of Y, but still show that it makes it easier to do more.

All models and methods have their breaking points at which they are no longer useful--some break sooner than others (causing more grief sooner).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.