One of my favourite weblogs is
Joel on Software and
I have often linked to his site. Although updated relatively infrequently it's well worth the wait for the latest news and opinions. Case in point is
Joel's latest article [no longer a valild link - check out the
Joel on Software - Archive (in fact
Joel on Software - Archive for February 2001)] :
...Human Task Switches Considered Harmful, explains why you should be careful that each programmer is only working on one thing at a time.
I am often to be found nodding my head in silent agreement as I read Joel's weblog entries and I agree entirely with his latest thesis that human task-switching is to be avoided whereever possible. The problem is that it is often difficult to avoid distractions. One of the reasons there are gaps in my weblog calendar is that the dates coincide with periods of activity where I will mask out all other interrupts. Processing of applications and marking exams are prime exams of very high priority tasks that once started often run to completion. (Aside: isn't it weird how computer scientists sometimes do the opposite of anthropomorphisation and talk about life in terms of algorithms and programming, but let me RTS - Return To the Subject ;-))
Evidence that it is a small world made even smaller by e-mail and the web was the fact that I was contacted by Michael Pryor as a result of my link to his answers to technical interview questions weblog [Update: Michael ran the 'Bad King' puzzle today]. I hadn't realised at the time I made that link that Michael worked for Joel's company - Fog Creek Software, Inc. but now of course it all makes perfect sense - the puzzles are the sort of questions that wannabe Fog Creek programmers get asked. I've forwarded to Michael a copy of the Departmental Friday Afternoon Puzzles so some of these may appear on his site in due course. Good luck to Joel and Michael for the success of Fog Creek Software. It's the sort of outfit I would've liked to work for when in my twenties. [1]
Even more evidence of uncanny coincidences is the e-mail I received this morning from one of my students. Basically the student was asking me how he could become a better programmer - I teach C and low-level programming for my sins - so that he'd be in line for one of those really well paid jobs I rant about. [Fellow academics will know the reason for the rant - new graduates getting paid a starting salary in excess of what we earn after 20 years. Not that I'm bitter ;-)]. All credit to the student for admitting that he wasn't happy with his programming skills and that he still had a lot to learn. Where to start with such advice?
First off, I'm still of the old school that believes that good programmers are born with that gift. Whilst not necessarily an advocate of 'programming as an art form' I have taught enough students C and low-level programming over the years - probably in excess of 2000 students - to conclude that some have a natural ability in programming and some don't. Plain and simple. Same of course goes for most other aspects of human endeavour. I'll have to dig out the quote but I think it was Bill Joy who said that there was at least an order of magnitude difference (in productivity) between the best programmers and the programmers of average ability.
So what advice do I have for the student. Well, first off I would check out the The Art Of Unix Programming by Eric Raymond that I linked to last week. One of the phrases that struck home to me is that a good programmer must be passionate about their craft. I paraphrase this as the 'Can Do' versus 'That Will Do' mentality. I am passionate about my programming. I suppose I am fortunate that as an academic I can pursue perfection in my programming and not necessarily be subject to the normal commercial pressures of marketing-driven ship dates and 'that will have to do' attitudes. I know students have deadlines too but I believe they can, and should, make the time to practise their craft without undue external pressures. Alas, years of lecturing suggests that the opposite view prevails amongst most students. But I digress...
The next thing I would recommend is to read some of the classic texts about programming techniques in general and C programming in particular. By classic I probably mean books that I already own so I'll dig these out and cite them later ;-) When I was student Ethernet had not even been invented (must check my dates!) and of course the web wasn't even on the event horizon.
More later. In the meantime, my students might like to check out last tuesday's technical interview question ;-)
Apropos the implementation of an atoi() function, the current cohort of students that took LLP last semester will no doubt be reminded of the pain of their attempts at my 'conversion utility to convert numbers into different bases' practical and I'm sure many kicked themselves at the elegance of the http://www.cs.strath.ac.uk/%7Eduncan/teaching/llp/solutions/s05.html">solution. Although not strictly an implementation of the atoi() to the specification given in the technical interview question, my version has the advantage of being unique insofar as trying to find a copy on the web and the fact that it copes with arithmetic overflow so is fairly bulletproof.
A wee programming exercise for budding C programmers is to modify the conversion utility to cope with numbers up to base 36. [Hint: only two lines need to changed. The sample solution already incorporates the changes so no cheating by checking that out first ;-)]
[1] Some students may doubt that I was ever employable B-}. I was a graduate of 1977 which were halycon days for graduate employment - much like the current situation - and every first interview I attended in my final year turned into a second interview and every second interview - bar one - turned into a job offer. Thirteen job offers out of fourteen interviews. The company that didn't offer me a job would have had it not been for a hiring freeze. A bit like Cisco currently. The name of the company - Hewlett Packard. Guess which company I wanted to work for!? I believe that I still hold the departmental record for the most job offers made to an undergraduate ;-)
[Updated 11/1/2001 to link to the new location of the answers to technical interview questions website.]