Hold down the option key. Hover your mouse pointer over the green zoom button in the top-left corner of the window. A "move window to the left/right side of the screen" option appears.
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.
My employer tried and failed using a similar system with Salesforce Work.com. It all seemed a bit pointless and forced to me. In the early days of using it while it was still a novelty, managers were giving feedback to people so that they could demonstrate to HR that they were being good little soldiers by using the tool, rather than because they wanted to praise good performance. This insincere praise was worse than no feedback at all.
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.
It exists, and demand for talented people outstrips supply. I find recruiting new people for my team to be tough. Literally had a candidate fail at FizzBuzz yesterday.
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.
10 years as a Software Developer here. Based in Wellington, New Zealand.
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.
Logos aren't mindless fluff or artsy wallpaper that you slap on a project before sending it out the door. They're often the first impression someone gets of your work, and using a thoughtless design says nothing good about what you value.
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.
This might not be the hardest bug I've tackled, but it certainly took the longest to solve.
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.
Not really a start up, but I thought Wikipedia was an extraordinarily dumb idea at first. An encyclopedia that anyone can edit - what could possibly go wrong?
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.
This doesn't seem to work right for negative numbers. The article says the rule is "each number must be larger than the one before it", but if you try -2 -4 -6 it says that pattern doesn't match the rule.
Maybe I'm just being pedantic here, but last I checked -6 was larger than -4.
I like these more for their aesthetic properties than for any technical or sales-focussed reason. I really have no idea how well any of these would convert.
I spent five years working for McDonald's, and I'll say that I've never worked for a company before or since that was so easily distracted and unfocused. The general philosophy from head office seemed to be "everything is always a priority all the time". There was never any sense of what truly mattered, and there wasn't a clear vision for the future of the company.
I'd speculate the reason for this is that when you're insulated by the sheer volume of money that McDonald's was back in the 80's and early 90's, you're effectively living in a world without scarcity. As a company, they've never really been forced to make difficult choices, and haven't developed the ability to do so. Instead, they just choose everything, and hope that if they throw enough mud maybe some of it will stick.
I'm really pleased to see Apple getting away from the "events" concept that iPhoto introduced. It was a good idea in theory - all your photos would be automatically grouped into albums based on the date they were taken - but in practice requiring that every photo in your library belong to exactly one event meant that you had a bunch of awkward single-photo events. Photostream ended up making this worse with special photostream-only events that completely broke the model of how photos should be organised.
I'm reading through the sample on my Kindle now. His similes are a little forced ("battles like this one raged across Beijing like a multitude of CPUs working in parallel, their combined output, the Cultural Revolution"), but he does know how to tell a story. By the end of the second chapter I was sold.