Computer Science in the Workplace
Useful or redundant? How much do we really need geeks?

by Heather Nagey

I read this article recently and found it interesting. It explores whether its worthwhile getting a computer science degree these days, or if its better to learn on the job. The existence of high level tools such as Rev possibly make it unnecessary to learn binary, assembler or even a higher level but still fairly obscure tool like C++ for many tasks. Perhaps that three years at university would be better spent in the work place, finding out how real life coding works and interfacing with the end users.

Of course, I can only give my own opinion on this, as a not particularly technical person working in a highly technical environment. Your Mileage May Vary. Clearly, for a company such as ourselves, actually creating a high level software programming environment, we do have a need for programmers with a firm grasp on lower level languages such as C++, which Rev itself is written in, and an understanding of fundamental programming principles. We have an outstanding team of extremely expert programmers, most of whom have been to university and studied computer science in one form or another. But not all. We also employ people to work with Rev, who really do not need this kind of qualification. In fact, in some ways, it can be better to have someone without preconceived ideas to start working with Rev. A smart lad with some basic knowledge and the right attitude can pick up enough in a matter of weeks to be a valuable member of the team. Our CEO is of course a great illustration of the idea that you don't need to go to university to be a programmer. Instead of going to university he spent his time after leaving school becoming expert in the precursors of the Rev programming language, and set up the company which eventually became RunRev Ltd.

There is a vast gulf between theoretical, "best practice" programming, as taught on many degree courses, and actual programming in the workplace. You may be taught that a certain thing should be done in such a way, or you should never use method xyz, but in practice you may be given a deadline of a week to produce something that "should" take three weeks, and you have to find a way to produce it. Quick and dirty hacks become more explicable in these circumstances. Then there is the difference between producing something satisfying to mind of a programmer, and something that an end user can actually use and understand. It may be the smart and logical way to do it, but if the end user can't grasp it, its not especially valuable. It can take some time for the lower level programmer to grasp that if it is possible for an end user to click something in the "wrong" order, or enter the "wrong" kind of data, or misunderstand what seem to be perfectly plain instructions, they will. Not only to grasp this fact, but to rethink how they view it, not as the user doing something "wrong" but as the program itself needing work. Many such programmers undervalue the user interface. Its something they will tend to "bolt on" afterwards, instead of designing the functionality around it. But a program is only as useful as the users ability to use it, and interfaces are critical to this.

Another aspect of "pure" programming vs "everyday" programming, is maintainability. The best and brightest brains are capable of producing the best software code. They are also capable of producing the most convoluted solutions which no-one but themselves can understand. This becomes a problem in the workplace, when another person has to work with and maintain the code. Time taken to add notes is time well spent! Rev lends itself to this in particular, as much of the code you write is self-commenting. The appearance of simplicity is the true mark of excellent code.

Really, it depends on what you want to do. Most people just drive cars. A few take apart the engine, make their own repairs, and add extra exhausts. Some are needed in the factory to design the next engine and incorporate new technology. In the future, I suspect most people will just use a high level language such as Rev to get the job done, fast and efficiently. A few will still be needed to handle the underlying 1's and 0's, but thankfully for most of us, this can remain as great a mystery as what, exactly, a carburetor is for.

About the Author Heather Nagey is Customer Services Manager for RunRev Ltd.