skip to content rich footer

stevenclark.com.au

subscibe to the StevenClark.com.au rss feed

Filching in Class is a Programming Sin

Before I proceed with this post it should be said that a lot of very high quality programmers have come out of the university system and having a degree doesn’t in any way degrade from anybody’s ability to do their job. But there are other factors which come into play in the university programming paradigm that I feel are sadly deficient. I’ve passed a few units that were extremely hard on a wing and a prayer too, so I know it isn’t easy.

Filching, by the way, is the stealing of code or design artifacts and using them as your own. Its a common university passtime in the grey area between quality and plagiarism. At South by South West there was an entertaining panel on Filching worth listening to as an MP3.

One very bad thing in the university system is that, while it provides an excellent jumping point for the interested, it fails the average with an acceptance of mediocrity at every step of the way. University, after all, should teach students the value of research and at every step enforce the highest quality of code. Instead, it basically works on a set regime - here is problem Olga, now fix. Good fix for pass, very good fix for distinction.

The problem with that approach is that often in the madness of doing four units I see students just ask their friends. They will state categorically they are great programmers but at every turn they ask friends (other students) or otherwise hunt up an already prepared solution on the web. Can anyone see the flaw in that? Software engineering of any sort is about process not solely about providing the end product. Define the problem, consider (research) solutions, develop an algorithm and then implement it. The weakness of the university process is that so many students just jump to the last step, hack line by line, and voila someone provides the answer. This is partly driven by time deficit in students.

Note to forums: read the manual just makes you sound like an arrogant prick, give advice or shut up or go home and ask yourself why you’re there. Demonstration is alright and good advice is always valuable. Note to everyone else in the world: giving someone the code, or a critical part of the code, is the worst thing you could do. It causes students brains to stop thinking about the problem.

The number of graduates who claim to be great programmers by far exceeds the number who really can program. Those people were activated enough to do their own projects during uni in their own time, they read books and articles and sat down to understand what was happening with their code (or someone else’s). And even when it worked they didn’t just drop it and move to the next step. The difference between these two groups of graduates by the end of a degree are absolutely huge. Me? I sit somewhere in the not so brilliant middle of that continuum. I’m not a natural smart cookie but a hard worker.

I’ll be the first to admit that I’m not a programmer’s old tennis shoe and being a web guy in a world where the web plays second to software programming puts me even further behind. I’m far from the best at any of it, in fact.

But I read and research and understand a lot of the principles and fundamentals of the work that I do. I’m activated and interested. My university world has always consisted of real clients and private projects and books outside the curriculum. But I’m the exception rather than the rule.

My advice to anyone hiring a programmer remains the same - at the interview hand them a piece of paper and a simple programming assignment with a tough ten minute time limit. If someone hands you a blank sheet at the end of that (or just scribbles) then pat them on the shoulder and tell them very clearly they have a great future in management.

Articles are licenced under a Creative Commons Licence but copyright of images is retained by © Steven Clark 2007 - 2008

Leave a Reply

NOTE: fields marked with an asterisk * are required.





skip to top of page

Currently Reading

Information and Data Modelling (Second Edition) by David Benyon (Cover)With an eye toward implementing another web interface database solution from the ground up I'm casually revisiting David Benyon's Information and Data Modelling (Second Edition). Its critical to have a solid understanding of conceptual data modelling and knowing how to identify various things like fan traps and three way traps very early in the process. To that end, while its fine to have a basic understanding of third normal form and general ideas about relations (that which relational databases rely on), its also a great idea to spend time exploring the theory and case studies that lead to a higher understanding.

Often people I deal with just snuff their nose and say they can design a database - but often its a very naive approach. Having read this book about four years ago its time for a quick refresher over my holiday period. No, I doubt few will envy me.