Patterns, learning on the job, and college graduates

Today’s post is on how new hires out of college seem to learn best at my firm. Keep in my that the following is purely my opinion and is based on my experience as a consultant working on custom software development projects with recent college graduates.

I work at a relatively small (sub 300 employee)  consulting. We offer a few different services, but for the most part they revolve around custom software development and integration. For a variety of reasons which I won’t go into my company prefers to promote from within and hire college graduates with computer science/engineering degrees. The end result is that we often have project teams with a couple experienced individuals and couple college graduates.

Let it suffice to say that there is a gap between theory based computer science education and the practice of professional software development. I have come to expect such a gap in individual’s skills, 4 year universities are not trade schools and I don’t expect them to fully teach the ins and outs of software development in a few years of classes. The question then is how to best teach new hires good practices and skills that will serve them well when they go to design and implement features for our clients. So far the method I have seen work best could be described as the sink-then-float-with-a-life-preserver-then-swim method.

Sink

[][1]

 Sinking in a sea of bits or floral pattern in this case is a daunting experience and can lead to many unwanted late nights at the office. From a client's perspective a sinking consultant (or worse teams) can lead to later than expected deliveries or lower finished quality (or both). Part of the issue is that a difficult subject like professional software development requires a number of different skills to be progressed ranging from interpersonal skills to design and coding habits. On top of the myriad of things a new college graduate has to learn is that sometimes it can be hard to [**even determine what to learn and from whom.**][4] On a difficult project (expanding requirements, tight deadlines, etc) a college graduate can figuratively drown in things to learn and do. There is one bright side however, a tough project forces an individual to recognize his or her individual limitations and to learn new habits from more experience teammates. Asking for help is one of the hardest things to learn for many of the self-contained, self-motivated individuals we hire (that have often done exceedingly well by themselves in college).

Float

[][5]

The goal at my company is to **not** burn people out which means that people cannot be allowed sink indefinitely. Like a pontoon holding up a bridge (or something like that) we give and encourage new hires to use a network of mentors and project buddies for guidance and help. Going back to something I mentioned previously, an individual has to know that he or she needs to grab onto the pontoon (or other related stretched analogy.) I have noticed that often the best and sometimes only motivation for someone to reach out is a _little failure_. A couple (minor, individually) missed deadlines may remind an individual to work on estimate, but (likely) won't harm the project as a whole. Similarly, a more experienced team member may point out the flaws in a design prompting the team as a whole to begin better review processes. Mixed teams of expert and inexpert individuals give opportunities for more inexperience teams members to fail a little, but at the same time not lose control of the project.

Swim

It doesn’t happen.

One of the annoying things about gaining expertise in a topic is that usually it just uncovers more things to learn and do. In some sense more expert individuals are just better at tying together pontoons, so much so that instead of hanging for dear life they’re building roads across rivers. For my perspective this means providing a lot pontoons or in less strained terms: developing classes on best practices, encouraging (but not preaching) the use of well known design patterns, and being involved with design reviews before features are implemented with application code. In short, the goal is to make a wealth of knowledge available when an inevitable little failure occurs so that the company’s consultants can learn and not let little failures snowball into an avalanche.