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

Comments are closed.

skip to top of page

Currently Reading

Mental Models by Indi Young (cover)Developing software from the user's perspective as opposed the organisational one is a critical area we need to work on as designers. I'm reading Mental Models by Indi Young, a book about understanding users' reasons for doing things and one system for understanding and designing for those reasons.

It's important to understand that when people visit your website they bring with them their own world view, motivations, experience and expectations. And, by working with those factors, we can improve our game significantly by providing them with what they want and need.