Posts
 |
| Equipped with skills |
When taking a course in algorithms, you might need to demonstrate some type degree of learning through programming a lab assignment. Its a decent bet that languages the student may not be the best choice to highlight the various algorithms being taught. The student then finds himself learning a new language for the sake of submitting a lab assignment. This is usually done with zero training or exposure and very little support outside of asking classmates or asking for help from the instructor who is eternally busy with other things.
Version control is another topic that shows the rift between the two worlds. Most IT shops require the use of some version control system. Most developers learn enough to get the job done but never really understand it enough to make it an equal partner in the development process. The administrative function is usually lacking. big IT shops can afford to hire VCS admins also have so many repositories that the admin's time is spread too thin unless you happen to be working on the 800-lb gorilla project. Smaller shops muddle through and usually someone takes the admin role upon themselves because they are tired of the situation and are the first to hit their frustration threshold. Not unlike the newlywed dilemma, "If the full sink of dishes bothers you, you wash them."
Since starting grad school, I figured I'd apply my own coding lessons and use version control for my assignments. What an eye-opening experience! Some tools with which I'm familiar already have enough version history. Eclipse has a nice feature where it automatically saves the change history of a file every time you save it. This works for solo Java projects but doesn't for other languages or group projects.
There are two main obstacles to using version control in academia; having to be your own VCS admin/trainer, and the lack of consistency from the university. You have to have the discipline to keep your VCS configured and working but also extend it to whatever environment that might be required. It does you little good if you have your personal repository setup on your own PC when the professor requires assignments to be done on the campus Unix box. The same holds true when a lab is required to be done in a language that your IDE doesn't support. Eclipse has 'C' support through the CDT but if you aren't going to be using it next semester, the time it takes to get it configured and working becomes that much time away from getting the assignment done or studying for the next test. When working on a group project, it also means having to teach your teammates how to use the tool and then hope that they actually use it.
This leads to the second obstacle. Without a departmental policy or professorial dictate, version control usage by students will be as rare has hen's teeth. The university or at least CS department would need to support VCS tools for campus computing environments, at least for administrivia. The professors and instructors would need to make VCS part of the lab requirements.
Don't hold your breath.
There is no impetus by the faculty to standardize on a VCS tool. The sheer number of languages and environments make it unlikely for any consensus to appear. This is odd because CS classes constantly have issues with turning in code and checking for plagiarism/cheating. Looking through the check-in history would be a simple way to verify a student's progress. Code diff tools would make it almost effortless to check for "borrowed" code. There are enough cross-platform tools that it is not a technology problem, it's a human problem.
The fundamental problem is the two worlds are trying to 'train' for different things. In school, technology is a means to an end. Students are being trained to understand how to approach and solve problems. They are being prepared for unknown situations so they can recognize when an approach is guaranteed to fail or maybe has been solved before and a stock algorithm exists. Employers, on the other hand, want people who are trained in the tools they are using to solve their problems. New hires aren't the ones who get to analyze a business problem not to mention prioritizing which problem to address. Managers still like to think of coding like a factory floor, the workers don't get to design the manufacturing process or choose the tools.
 |
| Trained to repeat a process |
For those of you that like analogies, here is how I'd put this conundrum. College is training blacksmiths that don't make the same thing repeatedly. They can be given a strange piece of hardware and figure out how to fix it. They can be asked to create something new based on ambiguous requests. Business wants someone who is trained to make swords. The enemy is already defined by the leaders, the strategies already determined by the generals.
The problem isn't training sword-smiths, it's wanting nothing but sword-smiths and then discovering you need a telescope, or horseshoes. Technology is still changing at an unheard of pace. Training in the current technology is a recipe for obsolesce. The window of current technology is getting smaller and smaller. COBOL was king-of-the-mountain for 20 years, C/C++ for maybe 15, Java is already on the downhill slope with C# and JavaScipt taking the spotlight and other languages in the wings (Ruby, Python, Scala) or working backstage (Perl, PHP, SQL).
Pick your tools well and train for anything. You'll have your fate in your own hands and not be surprised by the winds of change.
