You would think that this kind of message would be a thing of the past, but apparently not. Or at least not when buying tickets to major exhibitions in Melbourne.

I’m back at university, in an effort to force myself to knuckle down and get through the pain of learning Java. It’s been 16 years since I was last there, and here are a few of the things I’ve learned so far -

I’ve learned about the syllabus
Despite the move to Java, very little has changed in the overall teaching approach in 16 years. I’ve heard from another source that someone in my position 15 years ago may have been saying the same thing.

I’ve learned something about gold-plating
University seems to reward you for adding extra features. This doesn’t seem to happen in the business world.

A couple of years ago, I had a graduate developer assigned to my test team to help extend a test tool that I had written. He seemed overly focused on wanting to build a GUI for my tool, when a simple command-line interface was all that was needed to solve our problem. Similarly, with a user base of three, robust error handling was something we could live without. After a couple of semesters of university assignments, I think I understand why this was the case.

I’ve learned something about testing
Lecturers are mostly not embracing some of the not-so-recent trends. I’ve found JUnit tests a boon on assignments where we are incrementally adding new features. Having these tests as I implement existing functions using newly-learned language features, or to add new functionality for new assignments makes things much less stressful. Implement a test per requirement also helps to make sure I get all the marks for the assignment as well. When I suggested a student learn JUnit rather than passing parameters to their classes manually via a GUI interface, lecturers seemed against it, despite the many practical (and career) benefits.

I’ve learned something about learning
University seems really keen to have students build GUIs on everything. Now, GUI building seems like a reasonably complex thing, object-wise. As a beginner, figuring out how to model the domain is hard enough without being forced to put a hacky user interface on top of it.

Learning to model a domain doesn’t start with modelling the user interface.

I’m sure there are more progressive courses out there. I’m just surprised that the take-up of things that are of much benefit to beginning programmers is coming along so slowly. But then we are always making a tradeoff between what we can easily teach and what’s worth teaching. Just look at tester certification.

I thought I was done with ranting about automation tools for a while, but I couldn’t resist this quote from my former boss’ blog:

“Tools that let programmers create software by manipulating icons and graphics shapes on screen have a long and sometimes successful history… But these have generally served as layers of shortcuts on top of the same old text0based code, and sooner or later, to fix any really hard problems, the programmer would end up elbow-deep in that code anyway.”

There’s more good software-development food for thought in his full post, so why not check it out here?

I have been riding the ups and downs as I transfer my previous test automation framework learnings to one of the big vendor automation tools. I’d resisted criticism, but today I have to say, loudly, it sucks.

Rather than waste my energy, I simply direct you to read this (http://adamv.com/dev/articles/hatevbs/) (make sure you follow the link at the end). It refers to ASP, but I found almost all of this applies.

The joy of unproductivity tools…