brianwillis

It sort of does, but it's not as obvious as it should be. Mouse over the green zoom button in the top-left corner of a window, hold the option key on your keyboard, and then "move window left" and "move window right" options appear.

I mean, it's impressive from a technical standpoint; but still, worrying.

> val notPositive = not {it > 0}

This idiom took me by surprise. It's really quite lovely, and now I'm disappointed C# doesn't include it.

In the end, it never really went anywhere because it became another inbox to check, and we already have too many of those. A chicken-and-egg problem also presented itself, where people only checked the site when they got a notification saying they'd received feedback, which led to no-one visiting the site to give feedback.

If you're on the Microsoft stack then Xero and Trade Me are the most obvious choices. Mobile development and Ruby on Rails are somewhat popular. Wellington is a government town, so there's a fair amount of work maintaining legacy platforms if that's your thing.

Quality of life is decent. Good weather most of the time, better traffic management and city planning than Auckland, good food and coffee. The place feels like it has a personality.

You will not be paid well compared to Australians and Americans. The cost of living is lower than in those places, but still high relative to salaries. Food is expensive, housing is expensive, broadband is expensive and somewhat slow, anything you want to import will have to travel a long way which raises the price, and all purchases have 15% GST.

1. Change jobs more often. The only way to be paid market rates is to change jobs when your market value increases. Your employer has a strong financial incentive to keep you working as long as possible at your current rate.

2. Move into management quickly. I've heard it's different in other parts of the world, but where I am being a developer limits your career. In every software company the people who are the most influential, and the best paid, are in management or sales.

3. Be more aggressive about getting side projects finished and getting them out into the world. Like many developers, I've got a bunch of half baked ideas on my hard drive that could make decent open source contributions, side businesses, and there might even be a worthwhile startup buried in there somewhere. When all your publicly visible code is your employer's intellectual property, it makes it harder to sell yourself.

It doesn't have to be this way. There are free software projects out there that have beautiful, thoughtful, iconic logos. Firefox is the first that comes to mind. The Linux penguin (while a bit odd) has grown on me too.

It was the early days of SOAP, and I had been assigned the task of integrating my employer's software with a third party's, so that the applications could share data. This third party org was a wealthy, powerful mega-corporation; and my employer was, well, not. The third party produced a spec for the interface, expected us to follow it, and offered no help from there.

I built a solution. It worked on my machine. Solved the problem. All was right in the world.

I moved it to the test environment. It worked again. Demoed it for one of our customers, and everyone was pleased.

Deployed it to our first beta tester. One lonely employee working accounts receivable, tucked away in the corner of our customer's office.

It crashed.

I checked everything. I mean everything. There are still particulars of that little Windows 2000 workstation that I can describe vividly. Which programs were installed, which patches were installed, how Windows had been configured, how the firewall worked, I even got permission to install a packet analyzer. My employer only had a handful of customers, and the beta test machine was near our offices, so I was over there personally a lot over the following weeks.

We brought in the customer's network support people. They found nothing. They could see the packets leaving, and an error coming back, but couldn't offer more than that.

We brought in the best networking engineer in my company. He was stumped.

What really shook my confidence was knowing that competitors mine had gotten this interface working. This wasn't some half baked project that I could blame on someone else. Others had succeeded where I'd failed.

I practically had to walk across broken glass to get on the phone with the third party's development team, but with enough pestering I pulled it off.

The phone call involved me sitting at the beta test workstation and firing off a request so that they could view it hitting their servers live. The developer who I spoke with immediately spotted the problem.

You see, when you send a SOAP request, you send the date and time that you're making the request along with it. The clocks on the client and the server were too far out of sync, my requests appeared to be coming from the future, and so the server disregarded them with a blunt error. Interestingly, the workstation clocks at my company's office weren't too far out of sync, which is why it worked in one place and not another.

Stuff I learnt:

1. Third party interfaces require a point of contact at both organisations who can talk with one another. This is non-negotiable.

2. If you send an error message that reads "Error", you're a bad developer and should return your computer science degree to your university and demand a refund.

3. No matter how well written the spec is, something always gets left out.

4. Persistence maters more than anything.

I completely missed the value of having decent moderator tools (which no site had back in the early 2000's), and a passionate group of moderators who cared very deeply about the integrity of the site.