The more nauseous I got at the thought of teaching through a mundane semester of for loops and syntax the more I realized that these students deserved better; after all for many of these students my course would be the last programming course they took before they graduated and entered (or attempted to enter) the workforce.

I decided I had 1 semester to teach them all I could and maybe, just maybe turn them into junior programmers that I would want to hire myself.  I decided I was going to throw them into the ocean and see how many could learn to swim before drowning in the waves of semi colons and compiler warnings.  The results where exceptionally surprising:

• 25 – percentage of students who said WTF did I get myself into, gave up and just sunk
• 25 – percentage of students who realized they hadn’t been taught well up to this point but gritted their teeth and dug in to see what they could learn
• 50 – percentage of students who said, “Hell, yeah no more learning for loops! I actually want to come to this class. Can we learn how to do ___X___?”
• 3 – number of students who asked, “Can we build a networked XNA game for our class project?”  and then built it! http://codingquirks.com/projects/xna-tanks/

As the semester progressed several students began approaching me with ideas they had for software products or business they wanted to create but didn’t feel they had the technical expertise to start. At the same time I started hearing several senior level programmers talking about these great products they were going to write ‘someday’ and I began to see a possible convergence.

 

What if?

 

We stopped talking and actually built that product we’ve dreamed of and created more Software Craftsmen in the process?

 

 

What if, there was some way to bring together these students who are eager to learn and full of energy with these senior programmers who want to build something. Is it possible to create an informal setting where younger programmers can receive mentoring and code advice and also motivate the senior programmers to stop talking about that great product and actually build it?

Out of that idea was born something called the ‘Code Dojo’.  As aspiring Software Craftsmen I feel that one of our duties is to teach others our craft and as an aspiring software entrepreneur I feel that one of the greatest tools toward actually shipping a product is a healthy dose of peer pressure.

We had our first Code Dojo meeting last month at the Coding Inertia office in downtown Boise. We barbequed some burgers, almost set off the building’s smoke alarms, used up all the whiteboard space and shared some great product ideas.  The next Code Dojo meeting is set for Tuesday July 6th at 5:30. If you are in Boise and you are looking to help out some younger coders, hang out with some startups or just want to chill on the balcony for a while please stop by.

And where ever you are if you consider yourself an experienced programmer or a Software Craftsman then chances are that somebody helped you get there, now what are you doing to give back?

One more thing: I actually hired one of those students as an intern for the summer and he’s doing great.

Microsoft, doing what it knows how to do best, has once again copied a great tool – striving to make the tool Microsoft’s own.  Granted, a number of times this has gone badly (the first version of MSUnit is such a case), but I am very hopeful this time around.

They did a near full scale copy of FireBug for Firefox and called it Developer Tools for IE 8.  I couldn’t be happier.  Actually, I’m ecstatic!

Now, for IE 7 there were some tools that sort of competed with FireBug called the Developer Toolbar and Nikhil’s Web Development Helper.  And those are good tools, but just not as slick as FireBug.  FireBug’s ability to play with the html, css, and debug javascript were just unparalleled.   We had to wait for Visual Studio 2008 and those two tools just to get close.  The Developer Tools should change a lot of that for web developers.

For those of you who are saying, “There goes Microsoft and their anti-competitive practices again, sticking it to the little guy”, I say: GET REAL, it is an open source tool for crying out loud.  Plus, if John Resig is to be believed, Joe Hewitt (the creator of FireBug) is perfectly happy with this.  The reason is, the IE developer team was probably the only group that could create this tool for IE, so they did. 

Actually, go back and read John Resig’s blog and see all of the JavaScript enhancements to IE8.  Well worth a read.

The point is, as much as I like FireFox (it is my standard browser), it is still not the dominate browser on the market.  Most businesses and general users will continue to use IE for a long time.  What I hated was the difference in the quality of the debugging tools between FireFox and IE.  That has now leveled off a bit, and in the end that is better for everyone.

I am a strong believer in balanced teams (different levels of experience and diverse backgrounds) because I have fund that this tends to result in the best solutions. But why exactly does experience matter? For my purposes here I am going to ignore the technical aspects and focus on some “softer” benefits of having been there before:

1. Experienced people are not afraid to be wrong.

   They have been wrong before. They know that they are going to be wrong in the future. Every day you need to make decisions based upon imperfect information. When the decisions are big it’s easy to become paralyzed. However once you come to the realization that you can only do the best that you can with the inputs that you have things become a lot easier. And making these decisions with confidence (not arrogance) is important too.

2. Experienced people are not easily flustered.

   Let’s face it , once you’ve been round the block a few times it’s pretty much guaranteed that you’ve been in some horrible situations. And yet the world has not ended. So when life throws one of its infamous curve balls you simply compare the current disaster to those that you have survived before and think “I’ve seen much worse”.

3. Experienced people know when to push back…but equally they know when to stop pushing.
   
   We’ve all seen it before. “And when the user presses this button I need dancing penguins to materialize and…”. The ability to constructively question the “business value” is critical to any project’s success. Everyone is different and users and no different. Over time you’ll pick up a variety techniques that work for steering the different personality stereotypes in the right direction.

   But there is a second piece to this, knowing when to stop pushing. No matter how skilled your customer management skills there will always be things that you need to do that you don’t like or that don’t make sense. My advice is simple – get used to it!

   It difficult because every time anything happens that supports your previously ignored opinions it’s very easy to fall into the “we should have done it my way trap”. This can be very destructive because the negative energy can adversely affect not just you but the entire team. I’m not saying that you shouldn’t vent about the fact that you were right and everyone else was wrong…I would not want to deny you that pleasure. However vent and then quickly move on.

1. If you use R# remember that it does necessarily run tests in the same order as NUnit. So running the tests in NUnit is a good starting point, Obviously the order in which tests are run should not be important. That brings us to #2…
2. The problem is not always caused by the test or even test fixture that fails. If the test runs individually but fails as part of the entire suite then look to the previous test. In my case the previous test’s class did not inherit from AbstractRepositoryTest (a bases class which is similar to Roy’s Abstract Utility Class) and hence some previous work was not being cleaned up properly.

However, using a typesafe Generic DAO implementation, you can have one class support all of your CRUD operations, and use named queries to support finder methods. But this approach requires that your service/manager layer know your named queries to submit to your generic finder method. To me this smells bad, I don’t want my service layer knowing about my DAO named queries, even if its only by name.

Here is my Generic DAO Interface:

 1: public interface GenericDao<T, PK extends Serializable> {

 2: // ... state methods (persist, save, remove)

 3:  

 4: public T findByPk(PK pk);

 5: public List<T> findAll();

 6:  

 7: public T findInstanceByNamedQueryPositionalParameter(

 8: String queryName, QueryParameter... args);

 9:  

 10: // .. Other named query methods supporting multiple 

 11: // and named parameters 

 12: }

The implementation of my GenericDao uses simple JPA calls so I won’t include it here.

Here is my User model object with JPA annotations that the Generic DAO can work on:

 1: @Entity

 2: @Table(name = "USER")

 3: @NamedQueries( { @NamedQuery(name = "user.findByName",

 4: query = "select u from User u where u.username like ?1") })

 5: public class User extends BaseObject implements Serializable {

 6: @Column(name = "USERNAME", nullable = false, unique = true)

 7: private String username;

 8:

 9: // … other properties

 10: }

The primary key Long ID is defined on the BaseObject. The number of named queries in a real model object will likely be larger.

I can then create a Spring User DAO bean using my Generic DAO implementation, telling it which model class it will be typed as.

 1: <bean id="userDao"

 2: class="dao.jpa.GenericDaoJpa">

 3: <constructor-arg>

 4: <value>model.User</value>

 5: </constructor-arg>

 6: </bean>

I can use this bean in my service layer like this:

 1: User user = userDao.findInstanceByNamedQueryPositionalParameter(

 2: "user.findByName", new QueryParameter("user"));

Of course I want to have my cake and eat it too, because I want to say userDao.findByUserName(“user”)

Which means I either need a User DAO class definition (which sadly means a DAO for every model that needs finders) or an elegant AOP solution. Per Mellqvist has a solution to provide this using Spring AOP introductions which is slick as snot, but I fear that this approach will confuse the heck out of my junior developers, and they will likely spend an entire day searching for the definition of userDao.findByUserName which doesn’t exists. Since my developers don’t have the luxury of walking down to my desk to ask for clarification, I think I’m stuck having an explosions of DAO classes. At least the implementation of the finder methods will be simple

Here is my User DAO interface with the finder method:

 1: public interface UserDao extends GenericDao<User, Long> {

 2: public User findByUserName(String userName);

 3: }

User DAO implementation

 1: public class UserDaoJpa extends GenericDaoJpa<User, Long> implements UserDao {

 2: public User findByUserName(String userName) {

 3: return findInstanceByNamedQueryPositionalParameter("user.findByName",

 4: new QueryParameter(userName));

 5: }

 6: }

And the Spring bean definition would change to:

 1: <bean id="userDao"

 2: class="dao.jpa.UserDaoJpa"/>

Now my code can all the friendly findByUserName method on the User DAO:

User user= userDao.findByUserName(userName);

I know that I’m working against the “Don’t repeat the DAO” movement, but my feeling is that my team will be more productive even though they end up creating more boilerplate code. As AOP gains adoption, I think the introductions approach will be a better choice, maybe I can submit curriculum guidance to Indian engineering colleges. I do have hope though, now that C# 3.0 has introduced extension methods, developers from Java and C# will slowly become comfortable not seeing the definition of the methods they call in the class definition.

References

• “Don’t repeat the DAO!” http://www.ibm.com/developerworks/java/library/j-genericdao.html (Per Mellqvist , developerWorks, May 2006): Presents a Spring AOP generic DAO implementation using Hibernate
• “Defining Your Object Model with JPA” http://www.theserverside.com/tt/articles/article.tss?l=JPAObjectModel (Chris Maki, TheServerSide.com, September 2007) Generic DAO implementation using JPA

I am becoming more and more a fan of Esther Derby.  I heard her speak several times at Agile 2006 with Diana Larson and knew then that I would be seeking out more of their collective wisdom, despite their admission that they create scrapbooks like other Midwestern women.  

Esther has a very plain spoken, but effective communication style with which she imparts the secrets of the softer side of software development.  Esther does a great job of drawing our attention to the soft skills that we will don’t want to admit to needing in our technology jobs. 

Her Pragmatic Programmers book, Behind Closed Doors is  a wonderful example of this.  Her fictional Director level manager, Sam, joins ABC Company and finds his way through the first seven weeks on the job, dealing with the issues of his direct reports, peers, and supervisors.

While the examples and discussions may be somewhat remedial for hardened long-term managers with years of experience behind them, this is the kind of book all of us needed at one time or another.  Regardless of your experience, there is almost certainly something you will learn as Sam works his team through the Storming, Forming, Norming, and Performing phases.

The last half of the book is a quick reference guide for running meetings, coaching, giving feedback, and 1000 other things that I wish I had read 7-8 years ago.

Thank you, Esther.