I don’t know how it happened, but my local working copy got locked. This meant that every time I tried to commit, I got a ‘working copy is locked’ error.

The solution was easy, after I found a reference in the FAQ:

svn cleanup <directory>

I’m currently looking for contract work, and all of the usual places offer vague job descriptions that makes it hard to differentiate one from the other. This makes it hard to decide which ones to apply for, and almost always mean that you end up applying for jobs that are totally inappropriate.

Now there is JobReel.com.au – much along the lines of jobs.joelonsoftware.com, positions must display the employer.

I’m still looking for a site that lets me specify location, price range, responsibilities and technologies – but JobReel is closer than any of the others, and from what I’ve seen so far, the job descriptions are more useful and realistic.

It looks relatively new to the scene – good luck!

There is a good article here about the need to explain why you are coding. I’ve often found that with most projects or tasks people are reluctant to give you the high level picture – it wastes too much time and, “you don’t need to know”.

It reminded me of several situations where someone comes to me and says – “I want you to write a program that does this…”. I say “sure”, expecting that they have done the due diligence and arrived at the conclusion that this is the correct thing to do. (I’ve even had my knuckles wrapped several times for second-guessing these requests).

So, you proceed with development and somewhere along the line (at the watercooler, elevator or kitchen) you mention what you are doing, and they hit you with “There’s no need to do that because system XYZ is being replaced with ABC” or some other equally jaw-dropping statement.

I like to know the bigger picture of where a piece of work fits in, because then I can do a much better job. After all, I’m not just a monkey. And it’s not my job to just code. I am supposed to be building solutions. And without the bigger picture this is a lot harder.

Note: I am a advocate for ‘project induction’ where new team members are taken aside and explained how everything fits together, and how they fit in to the picture. For programmers, this is a technical session (NOT an HR or project management session) and should be run by the architects of the system. This is a good way to discover the talents of your team, and to make them feel involved. I’ve not had much buy-in though, anyone out there seen it being done effectively?