We are saying ‘farewell’ to my proudest video game project. After four years, Coinland has closed.
Most Australians at my age would have fond memories of Commonwealth Bank initiatives that were offered to them in primary school (elementary school) such as a free ‘Dollarmites’ savings account that encouraged making small, weekly deposits during class. For four years Coinland has taken this to the next level, teaching children the importance of saving (virtual) money, earning interest, finding jobs, using ATM cards and even donating money for a selfless cause - all through a browser based video game.
For over 160,000 Aussie children, Coinland was almost certainly their first MMORPG experience, and our support team receives streams of fan-mail from parents praising Coinland, and from children who are having a ball.
When Coinland was announced to close, we received offers from parents who believed that their children have learnt so much from Coinland, that they were willing to pay a fee to keep the free game running. A child sent us an email saying how upset they were about Coinland’s closure, and how it was cruelly coinciding with their sister’s Coinland-themed birthday party.
Coinland was a winner of several Australian industry awards at launch, and just before the decision to axe Coinland, a port of the game for iOS and Android was ready for submission, which I’m certain would have been a hugely successful evolution of the game.
I’m proud to have been part of Coinland, and I wish that you could have experienced it too.
See Coinland being played by an expert here!
If you've done any amount of programming, you would eventually, inevitably, feel the urge to rebuild everything.
The reason programmers feel this way, is that reading someone else's code is always harder than writing your own from scratch. There are some good situations where doing a full re-write is a good idea, but the vast majority of situations, it is a terrible, terrible idea.
Every developer who has spoken to any other developer would notice that there is always the feeling that a code re-write will solve all the issues of an old project; people swear that the new version will be well-planned, documented, etc but you know what it won't have? The 90% of the time that was spent to fix the last 10% of unexpected issues. That is, all the effort that the previous developer spent to debug, test, and hack their way through bugs.
That is why I like to approach existing code like a surgeon, and the application is my patient. A surgeon theoretically knows how a patient's body and organs should work, but sometimes she'll start surgery, and the patient's innards are a mess. Maybe they had a bone breakage in their youth that repaired badly, or their liver isn't quite positioned the right way.
Now if the surgeon's original task is to remove a kidney stone, would she take out and re-organise the rest of the innards to match her textbook? Of course not, the patient's only complaint was the kidney stone, and was perfectly healthy in every other way. The body would have adapted and hacked its way to function like normal.
There are some instances where a code rewrite is warranted, and likewise we can use the surgery approach. If the patient above not only had kidney stones, but also exhibited other convulsing and or other symptoms due to the bad positioning of the badly-healed bone or upturned liver, then sure - it would be a good idea to explore fixing the rest of the organs.
I'm so gross. What's for lunch?
Check out my post on the Google Glass learnathon on my company website.
I'm pleased to announce the launch of my new mobile game, Rise of Gladiators!
After a month's worth of work between me and Brendan of www.jabberworks.com.au, the game is now free to download for both Apple and Android users.
Rise of Gladiators for iPhone/iPad:
Rise of Gladiators for Android:
Oh no, it’s that feeling. You could be in a meeting, or a workshop; when all of a sudden, someone throws you a supposedly simple, work-related question:
“Hey Garry, what framework would you use for XYZ?”
“Hey Garry, how do you type-set in XYScript?”
“Hey Garry, can you summarise the SLC in your technical spec?”
SLC? What does it mean? Do I wing the answer now, or Google it up later? Do I shrug and say “I dunno”? It’s moments like these when I start to doubt myself.
Not long ago, I felt like an imposter. I felt extremely lucky to do what I do because there’s no other excuse for me to not know the acronym for Software Life Cycle.
Psychologists call this Imposter Syndrome, and it can affect anyone from the uni-graduate, to the boss. Symptoms can be mild, or downright debilitating. Imposter Syndrome sufferers can feel depressed, defensive or worse! There has been a lot written about this very modern disorder, but to avoid feeling like an imposter you can follow some simple steps:
1- Celebrate your achievements
2- Remember, you’re not the only one feeling like this
3- Find a mentor
4- Swot up on the symptoms
*Psychologies Magazine, February 2013
Thankfully, I did find myself some great mentors in the last few years who were able to celebrate my achievements with me. It is incredibly helpful to have someone guide you, who has been there themselves.
After all, you probably deserve to be where you are; you can’t be that good at faking it… right?