Over the summer between my senior year in high school and freshman year in college I had the unique experience of interning at a software consulting firm. Leading up to the experience I was most worried about the breadth and depth of my software knowledge (I would be doing mostly software development projects with the company). I spent the weeks leading up to the experience reviewing the languages I had heard I might be working with and fretting over if what I was doing would be enough.
As it turned out my technical knowledge as it related to languages needed very little practice. Most of the projects I was doing required very little skill with one specific language or another. What would have been most useful going into the internship experience is a more in depth knowledge of the companies software development practices and specific tools they used. While syntax and language theory never came in to play, the ability to understand and label the workings of specific development environments and what rules to follow would have been immensely useful.
The question becomes then how do we better prepare students to label and solve the problems they encounter as they head in to industry. The easiest answer to this is to simply require more experience closer to industry than what is already mandated. However this is more of a throw things at the wall and see what sticks type of approach. I believe that learning to label problems and parts of a system is useful, but what really allows you to do this is the ability to ask the correct questions about a system.
A good amount of the back of the napkin deals with recognizing problems, and determining possible solutions. This sort of methodology is very powerful and simple to combine with labeling, if we can successfully break down each problem or lack of understanding we have within a system, we are infinitely more likely to be able to correctly label each part or at least know what solutions we are looking for. For me personally, labeling seems to be most useful when looking at a system we don’t understand. It, combined with the other missing basics we have learned so far, gives us a running start at understanding systems we are at first unsure of.
