Update: This job has been filled. Thanks so much for all your applications!
At Shifty Jelly we’ve always gone to great lengths to make sure our customers receive the best support that we can possibly give. We’re one of the few companies our size that hire dedicated people for this role and we now have an opening for just such a person.
If you’re adept at Twitter and Email, if you get along well with people, if you have outstanding written and verbal communication skills then this could be the role for you! You’ll be responsible for managing our Twitter accounts, answering customer emails and helping out in other tasks that go with releasing and managing successful products like Pocket Casts and Pocket Weather.
This is a full time role, preferably based in Adelaide, Australia. If you’re interested, please email us!
We’ve had a lot of email recently. Probably because some genius thought it would be a good idea to start putting email us buttons into all of our applications. While it has increased our workload a bit, we’d prefer that to people just getting frustrated, deleting our application then telling all their friends how bad it is. The emails vary from ones that are quite funny to ones that are quite angry. I’d estimate that 9 times out of 10 the answer is very simple, and people normally walk away (assuming that’s what you do after reading an email) very happy. It’s funny, sometimes it almost seems that people are happier to get a buggy application that you then fix (after they find the bug) than to receive a perfect, bug free application. In quite possibly the longest segue in ever, that’s what I want to talk about: Quality, Features and how shiftyjelly applications are made. Possibly unicorns and rainbows too, I haven’t decided.
Most people assume that we’re some large-ish corporation, which I’d like to put down to the amazing quality of our applications, and the fact that ‘shiftyjelly’ is a very serious business like company name. I can see the latest IBM board meeting: “Who did we outsource all our IT work this year Bob?”. “Why shiftyjelly Frank, who else? Dependable chaps the lot of them.”. In truth a typical day in the life of a shiftyjelly goes something like this (there are 3-4 of us btw, depending on who’s counting and how, you can read more about that here):
- Wake up
- Eat breakfast
- Go to our full time jobs (which have nothing to do with shiftjelly)
- Come home
- Eat dinner
- Be social
- Put the kids/wife/dogs to bed
- Decide whether to code like a mad monkey or just crash into bed
There’s a point here right? If you’re still reading my guess is that’s what you’re wondering. Well the point is this: we’re just 3-4 part timers working in the wee hours from our couches. It might sound more glamorous if I told you my couch is leather, but really, sometimes it’s just hard work. We make a little money, ’tis true. When split 3-4 ways it’s not a lot though, which you can probably guess by the fact that we still all work full time elsewhere. But we don’t do this for the money. If we did we would have been much better off working the graveyard shift at a service station (gas station for the Americans out there). It would pay more, and I hear the employee discounts are really awesome. No we do this because we love it. Not always, not every day, but we really do love it. Some days we hate it, we chase down excruciating painful bugs for hours on end, sometimes in circles. Some nights you end up giving up and just reverting all the changes you made (thank goodness for source control). But most times it just seems cool. We’re making applications that people use every day. Roofers, tradies, fishermen, office workers, cyclists…even grandma. We’re also motivated by our competitors, perhaps because we’re all alpha males, but every time one of them creeps above us in the charts the coding nights become more frantic, the features get more elaborate, the whole virtual office (we’re separated by many kilometres) hums. All this just for the pure fact that we refuse to be beaten.
So on to the point (yes I know I promised it paragraphs ago): we love you guys, we really do. We love hearing from you. It pains us that we cannot add features faster than we do, but we’re trying. Some days we feel like we’re working 2 jobs. So yes we’re upgrading all our apps to support that fancy new iPhone 4 display, yes we’ll keep adding features to our new iPad versions, yes we’ll never forget about the old iPhone apps, yes we’ll fix all those little annoying bugs that slip through our 2am testing…but it will take time. And until someone comes along and hands us a million dollars (I know, we’re cheap, right?) we’ll probably stay at our day jobs, and it will always take time.
In the last two posts, we’ve told you all about who designs our graphics and ruby magic. There is of course a third part being the iPhone Application itself. That’s where Russell Ivanovic comes in. Russell loves many things (like writing in the third person about himself and gratuitous use of brackets), but chief among them is building iPhone applications. The literary types among you will have to excuse him, because he’s about to go from the third to the first person, all while breaking the fourth-wall that separates yourselves from him.
Let’s start with a history lesson. When the iPhone first came out I, like many mac geeks around the world, watched the video stream with a childlike sense of wonder. I had dismissed all the rumours of an Apple phone as wishful thinking by the Cult of Mac, rather than anything to do with a real product. Then Steve got on stage and did his stuff, and introduced us all to a new phone a new iPod and a groundbreaking internet device. Needless to say I had to have one. Only a few months later I got my very own iPhone, courtesy of the wonderful people who invented forwarding addresses, and the nice people at FedEx. Then in June of the next year the iPhone SDK was announced, I was excited, but too busy to do anything about it. I like many people I signed up, downloaded the SDK, ran a sample app and then never opened Xcode again.
Fast forward to later that month, I was playing indoor soccer when someone kicked me really hard in the calf. As I turned around to give them a piece of mind, I realised that no one was there. Being the genius that I am, it took me a few hours to realise that I had actually snapped my achilles tendon (don’t try this at home kids). A few days later I had surgery and was told I wouldn’t be able to walk for two months! After a few weeks of sick leave, my work shipped out my iMac and all my other equipment and I started working from home. As I soon discovered without the distraction of meetings, coworkers and walking I was working a lot faster from home than I normally would from work. I also spent a lot of time waiting for people to respond to critical emails before I could do anything productive. This left me with a lot of downtime. Long story short, I started investing an hour or so a day of this downtime into Objective-C and the iPhone SDK.
Giddy from all my success I began planning Pocket Weather AU, recruiting Nathan & Philip on the way. The rest as they say, is history.
To summarise our little trilogy of posts:
- Shifty Jelly is made up of 3 people, each with complimentary and awesome skills in all the areas required for a good application (design – Nathan, back end – Phil, front end – Russell).
- We work for love, not money (though to be fair my wife loves her new kitchen, which was payed for by money, ironic, I know)
- As a general rule, no we won’t build your World Changing Application unless you are realistic about what these things cost, and are willing to wait the amount of time required for us to build it. Even then 99 times out of 100 we’ll still knock you back (see the above point). We certainly won’t share your revenue any more than we’ll share your risk.
- Buy Pocket Weather AU so that my wife stays happy, no really I mean it, I need to do the floors in my house next, and at the current level of sales that’s going to take a while 😉
In our previous post we talked about Nathan, the sole designer in our trio of iPhone monkeys. We figured that we may as well complete the picture, and release part two of this three part trilogy, this time looking at Philip Simpson.
Philip and I both work at Groundhog Software during the day, a company that develops custom applications and web sites for many different clients (be sure to check them out, they’re one of the few companies I’ve ever come across that really value quality and innovation rather than just talking about them). They are also highly supportive of our iPhone efforts, and trust us to maintain a separation between our work and personal developments, a trust I think we’ve always done the right thing by. That’s where I first came across Philip, when he started there as a Software Developer about 2 years ago. It quickly became obvious that Philip was smart, and highly motivated and also that he did a lot of development in his spare time (at the time mainly for charity). In his day job Philip mainly works with Java and large J2EE applications for our clients.
It came as no surprise then that when Ruby on Rails started gaining traction Philip fell in love with it. It was the anti-java in a lot of ways, fast, flexible, highly extendable and very light weight. While Java servers generally need at least 512MB of RAM to run, Rails runs quite happily on a tenth of that. Meaning that you could set up a ten server Rails cluster in the same space you could put one Java server. Rails is also a lot cheaper to host than Java. It was a fairly logical step then that it was the language of choice for the back end of Pocket Weather, and even more logical that Philip should be the man to do it.
The back end of Pocket Weather is what I call the ‘invisible’ side. Most of you probably don’t even know it’s there or what it does. Coded exclusively by Philip the back end polls the various FTP and HTTP sites from the BOM at various intervals during the day, and parses out all the data that Pocket Weather needs. This is no small feat, and is why we refer to Philip as our ‘Ruby Magician’ because all I see of it is a nice clean API that the iPhone App talks to. When you open Pocket Weather it contacts our server, and asks it for the weather for all the locations you have set up. This data is all sent back in one tiny chunk. This is good from a speed and data point of view on your iPhone, and also very good for the BOM, because it’s only our server talking to it, not tens of thousands of individual iPhones.
The running joke in the early days of Pocket Weather development between myself and Philip was always ‘Yes, but can it scale?’. You see Rails has an (undeserved) reputation for not being able to scale when it comes to handling large amounts of traffic. We were able to test that first hand when, in the early days of Pocket Weather, 800 new people a day were downloading our application. There were some nervous times when Philip had to keep a daily eye on things as our shared hosting groaned under the strain. Philip was always on the case though, and has been tweaking the code and architecture since day one. This has meant that Pocket Weather has experienced no downtime due to our code, though we have had some minor outages thanks to the double-edged sword that is shared hosting.
Philip is also a great friend and a very handy developer to have in our trio. I find that working solo it’s hard to get motivated and produce quality work, but when you have someone else you can draw immense motivation from each other, and you end up with a much better end product. Just like all of us, Philip is in the development for the fun, not the money, so much so that I often have to force him to accept payments and end up arguing with him because I think he needs a higher share of the profits, while he’s always pushing for a smaller one. I can think of many employers who would kill to have that problem 🙂
So what is Philip currently working on at the moment? Well he’s bringing the extended forecasts we promised for version 1.4 (so you can stop emailing us residents of Cape Byron, Wollongong, etc), as well as moving all of our code to a private server, so that we will never have to suffer the indignity of the downtime and problems you get on a shared host. He’s also working on two other projects that are very close to being released, but that we are maintaining Apple(TM) levels of secrecy about.