I agree with you that consulting with others is essential–on several different levels. First and last, you need to consult with your customer at length before setting down to write the code. Then there are other programmers with whom you are working. You have to craft a plan to work together and optimize any areas of expertise (e.g., the guy’s who’s good at SQL, the gal who’s a great UI developer) and organize around a plan. Finally, if you’re working in a big shop, coordinate with administration so that your resources don’t dry up before the project is done—or you don’t hog resources that are not used.

So on the issue of communication, we’re in total agreement. The other issue is (as you so well put it) a matter of social etiquette. If you see something in another’s program that you believe could be improved, you need to be delicate for two reasons. On the one hand, you don’t want to sound like a jerk. That can be handled by the way you put it to the programmer. On the other hand, you may not understand the program and your suggestions are flat out wrong. So tread lightly. I can’t tell you how many times I’ve had some well-meaning comment suggest that I could “save” programming code by removing an interface!

As for your comments about “elite” programming, you wouldn’t be looking at this blog if you weren’t interested in elite programming. Let’s face it, there’s no such thing as elite programming; so let’s just drop that term here and now. We can distinguish about four types of programming:

• Sequential
• Procedural
• Object Oriented
• Agile (including Design Patterns)

You might say that both agile programming and design patterns are just extensions of OOP, and you’d get no argument from me. Here our focus is on good Design Pattern programming in ActionScript 3.0 using OOP. It is difficult to learn and implement. Does that mean you’re too dumb to learn it? Of course not. It means that while the transition from Sequential to Procedural programming is pretty easy, and from Procedural to OOP is a little more difficult, the transition to Design Patterns is more difficult still.

At this point there are two directions you can take: 1) I’m too busy; 2) I want to climb Mt. Everest. In terms of practicality, Design Patterns were developed for the practical work of getting programs done effectively and efficiently for businesses. An early sponsor was IBM, and they didn’t do it because they’re nice guys. They saw this kind of programming as practical; so I don’t want to hear anything about Design Patterns being impractical. What’s impractical is re-inventing the wheel every time you sit down to program.

I guess the title “Since the ’80’s” indicates you’ve programmed since the 1980’s. That reminds me of a cop who would boast about having “20 years experience” and so he knew how to be a good police officer. One of the higher ranking officers pointed out that,

the guy really has 1 year experience 20 times

I know a programmer who was just like that. Instead of improving his programming skills by learning new programming techniques and approaches, he just learned more programming languages. So instead of growing taller, he just got fatter. That programmer was me. Now, I’m glad I learned several different programming languages from machine language to PHP; but I really needed to become a better programmer. I was fortunate to run into the right people at the right time several years ago, and I migrated first to State Machines and then to Design Patterns. I attended several OOPSLA meetings (where design patterns were introduced) and got to know people who were a lot smarter about programming that I. I learned from them. Sure, I was the dumbest guy in the room; but after several years, I’m not any more. Design patterns went from being hard to the only thing that is challenging enough to be interesting.

Cheers,
Bill

The only real ‘mistake’ being done, especially when dealing with DP is not to consult others before undertaking the development cycle. More is less, think more, code less.

I and many other non elitist programmers have also come to see that most of the time, a pattern, even though well thought of, becomes restrictive and actually hinders the development process, in essence, it all comes down to polymorphism.

Being that programming is still in an infant stage (believe me) we fail to see while we standardize and regiment our methods the errors of other disciplines that have come across similar bottle necks in their evolution. One could look at symbolic logic for example in order to see where thought and practicality are logically demonstrated not to meet in a reasonable manner.

Theory is theory, and practice rarely resembles what the books say.

As for people with no social etiquette, well, thats the world we live in and its not about to change soon. Change yourself and the world will change with you. :)

I agree with you. Readers of this blog know the language and algorithms inside-out. It’s always difficult to move from a functional understanding of a computer language to an understanding of OOP principles that are used together in design patterns. If anyone thinks they understand all of this the first time they look at it; they probably don’t.

Thanks for your insights,
Bill

Lots of ways to skin a cat, and that’s why it’s important to differentiate the TNTWIDI from useful information. I suppose a better way of putting it is:

By which criteria do we best judge our code?

If we can look for good criteria and communicate those ideas; then we’re dealing with people who are sincerely interested in collectively moving ahead with understanding. However, when someone spouts out a TNTWIDI whenever they look at your code; then it’s not too helpful.

Bill

We’re going to be going over all of the basic relationships in design patterns, and that should add to a firm DP foundation.

Kindest regards,
Bill

As for the original question for 2010 and beyond I am going to continue learning and using Design Patterns for my little educational applications. DPs have a sort of poison that make you want more and more.

And they are fun!

Best wishes

Curro

I think that all of us would agree with you when it comes to really wanting good ideas and better ways of coding. That was how I got into Design Patterns in the first place. When Jonathan Kaye first introduced me to the concept of a State Machine, I was blown out of my socks and am very grateful to Jonathan for taking the time to explain it to me.

The kind of comment I am talking about is the thoughtless TNTWIDI that is based on “See how smart I am,” rather than, “Let’s look at it this way because it follows Design Pattern Principle A and OOP Principle B.”

I’m with you 100% when it comes to being open to ideas and learning something new about programming virtually all the time. Danny’s point seems to hit the nail on the head when he points out that TNTWIDI comments are more likely to cause other problems because the comments really aren’t about programming—they’re about the programmer’s ego.

Great hearing from you and hope to hear more.

Kindest regards,
Bill

That’s right! It can waste a huge amount of time and you have to undo it all and go back to your original starting point.

Kindest regards,
Bill