Tips, tricks and tools for switching from Windows to Mac



I’m more of a Windows user which I use a lot at home and most of the time at work. At Raygun, I maintain the Raygun4iOS provider and a few other projects that require a Mac. This is a list of a few tips, tricks and tools that I’ve come across since starting to work on a Mac that others may find useful.


As mentioned, I work on both a Windows machine and a Mac in the office, and sometimes switch between them frequently during the day. To help with this, it’s very useful to only require a single keyboard and mouse that you can slide from one machine monitor to another. There are several software and hardware options to achieve this. The solution I go with is Synergy which I’ve found to be easy to use and reliable. It even syncs the clipboard between all the machines which comes in handy. This used to be free a while ago, but will only cost you $10 to get it now.

Open a Terminal from Finder

Sometimes I need to run some commands in a Terminal within a folder that happens to be open in finder right in front of me. Rather than navigating through the directories in a Terminal window, it would be nice to jump straight from the folder in Finder to a Terminal window – like in Windows. Well, Mac does have this feature too, it’s just hidden by default. To enable this feature, open “System Preferences” and click the “Keyboard” item. Next, hit the “Shortcuts” tab at the top, then select “Services” from the left hand pane. Now, scroll through the list to find “New Terminal at Folder” and mark it as selected.

New Terminal at Folder

To use this feature, right click a folder in Finder and the “New Terminal at Folder” option should be at the bottom of the menu.

Take a screen shot

There isn’t a print-screen button on a Mac keyboard, and there doesn’t really need to be – Mac provides several shortcuts for taking screenshots in different ways.

Command + Shift + 3 will take a capture the entire screen and save the result to the desktop.
Command + Shift + 4 is a bit more useful, as you can then drag a crosshair on the screen to capture a rectangle. Releasing the mouse will take the screen shot, or press Esc or right-click to cancel.
Command + Shift + 4 and then press space will switch to window select mode. Click to create a screenshot of just that window (or even a context menu) including the surrounding shadow.

I used that last one to take the image displayed in the trick above! As I’m using Synergy and a Windows keyboard, I use the Start key in place of Command. Additionally, holding Ctrl while using any of these screenshot shortcuts will cause the result to be saved to the clipboard instead of the desktop.

Show the desktop

Is your desktop cluttered with windows? Probably not – I still don’t have Mac desktop management down. But if it is cluttered, and you just tried out the previous tip to save a screenshot to the desktop, then it’s probably hidden behind a sea of windows. Fastest way to access it now is to press F11 which animates all the windows to the edges of the screen to display the contents of your desktop. Pressing F11 again restores the windows back to their original locations.

Window snapping

When I’ve got two XCode windows open and want to compare or edit code in both, I put the windows side-by-side as surely anyone would do. As far as I can tell, there isn’t a Mac feature that lets you quickly snap windows to the left or right of the screen though, so I manually resize and position them instead. I’ve played around a little with a tool called Moom which is simple, cheap, easy to use and has a good set of options – such as snapping to a corner or custom grid positions. This is mainly used by hovering the mouse over the green zoom button of a window and selecting an option.

A good free option would be Spectacle which is even more simple if all you want to do is snap to half of the screen. When it comes to window snapping on a Mac, there are a lot of options. These just happen to be the two I’ve played around with.

Folder context menu

In Finder, if you right-click some empty space, you get a small context menu containing tasks such as “New Folder” and “Paste Item”. If the folder you have open in Finder is packed full of files, there isn’t any empty space to right-click. You can get around this by holding the Shift key while right-clicking to force this menu to be displayed. Note that this only seems to work when finder is in column-display mode.


iExplorer is an iOS device manager app that lets you manage files on an iOS device. I use this tool while doing iOS development to check that files are correctly being created on the device. I can then use iExplorer to transfer the files to the Mac for further examination or processing.

Quickly get your IP Address

In the Mac menu bar is a Wi-Fi button which looks like a signal icon. Holding Option while clicking the Wi-Fi button will display additional information in the menu. (Hold the Start key if you have a Windows keyboard). Under the name of the network you’re connected to will be a list of greyed items – the first one being your IP Address. Other ways to find your IP address is to open “System Preferences” and go to the “Network” section, or run something like ‘ipconfig getifaddr en1′ in the terminal.

I hope that at least one the items above is new and helpful to you. I’d love to hear any other tips, tricks or tools that you’ve found useful in the comments below.

Share this post

Using OAuth For More Secure JIRA Integrations

We’ve listened to customers who were wary about sharing JIRA authentication details with third party tools and today have delivered a great update that solves this problem for users using (or wanting to use) JIRA + Raygun to keep on top of errors in their JIRA accounts.

First things first this feature allows users to authenticate with JIRA through OAuth tokenisation, meaning you don’t have to share any of your JIRA account details with us under this set up.

Instead, when you view our integrations list under your application settings you’ll find two JIRA options. The original set up remains but we have added the OAuth option.

JIRA setup

Setting this up with OAuth will take a little longer than the standard set up but the process is fairly straightforward, just follow the steps and you’ll be blasting error reports over to JIRA in minutes. Click on the Set Up tab to access the configuration details. Enter your JIRA URL in Step 6 and click go. You’ll be sent off to JIRA to authenticate with your account.

Screen Shot 2015-09-29 at 1.57.48 pm

So that’s it, pretty simple huh? We hope this provides you with a better way to manage your JIRA integration set up and is another great addition to Raygun!

Use JIRA already but don’t use Raygun? Why not give things a try today! 

Share this post

Test Driven JavaScript Development: An Introduction

Test Driven JavaScript Development

The Raygun team is made up of a bunch of nerdy folk just like yourself. Occasionally they write about tools they like and thoughts they have about dev-type topics. This week we’ve got Rick, our longboarding-freediving-Swedish speaking front-end dev talking about test driven JavaScript development. 

Test driven development has been around for a long time in the world of software development. The last few years JavaScript has been growing bigger and websites have become more JavaScript heavy and complex. If you you haven’t done JavaScript testing but are curious, it can be a bit of a jungle to get started. This will be a brief guide to get you started.

Why and when should I test my app?

Writing tests should not be a big project itself. It should be part of your workflow for cases that make sense. What makes sense is hard to say but a rule of thumb could be:

  • Is the functionality complex?
  • Is it an important functionality for the app?
  • Is it easy to write a test?

If you answered yes on all three you should definitely write a test.

There are many reasons why we should be writing tests. Quite often we write code before we are 100% sure of what it should do. We write, learn, rewrite, learn more and rewrite again. Writing a test before the actual development can give you a deeper understanding of the code you are about to write.  It will now be easy to step by step write the code you need and you will be sure it does the right thing throughout the process.

Things you can test

A test could answer the following questions. If you implement it to your build processes you will be sure it always works.


  • Can I create a new user?
  • Can I create a new user with different user types?
  • Does this user type have access to all features and pages they should?
  • Is this user type blocked from features and pages they shouldn’t have access to?
  • Does the user get notified before their credit card expires?
  • Can the new user log in?

Did my CSS changes break anything?

It’s easy to break CSS but sometimes hard to find the broken parts. Testing is a great thing to do.

Build in screen shots to your test, compare them with working images and get a warning if they differ.

Asynchronous requests

  • Does the server return the right data?
  • Does the app behave as expected on slow ajax request?

Links and buttons

  • Do my links and form submits behave as expected?
  • Does my form get the right messages for invalid fields.

As you can tell there are many things that can be worth to test. Now it’s up to you what you want to do with it.

Different test styles

  • TDD (Test Driven Development)
  • BDD (Behavior Driven Development)

They can appear to be quite similar but some key differences are worth mentioning. BDD puts focus on the syntax to achieve a more readable structure. The idea is to write tests in the way you would normally read. It’s also more focused on the team rather than just the developers.  That doesn’t mean BDD is always better, even if some would claim that. Before you choose you should learn more about the differences and also take in account what your team is most familiar with. This is a good explanatory video about BDD and TDD.

Different Frameworks For Test Driven Develpment

I will cover npm test packages since that works for everyone no matter what language or server you work on/with. Make sure you have Node.js installed first.

Here’s a  list of 46 frameworks from

Yes it’s hard to get an overview of what to use. A good indicator is what other developers are using. Let’s have a look at’s download history.

Last month download history from npm

  • Mocha 2,009,678 downloads
  • Jasmine 415,922 downloads
  • QUnit 17,479 downloads
  • Buster.JS 9,833 downloads
  • Casper 663 downloads

I will focus on Mocha (since it’s the most common) test suite.

Hook it up to Chai to control assertions

And a browser framwork phantomjs to test browser specific behaviors.

What is Mocha?

Mocha js

Mocha is a well used test framework. It runs on Node.js and is great for asynchronous testing.

What is Chai?

Chai js

Chai is a BDD / TDD assertion library for node. In my later examples I will show how Mocha uses Chai’s set of assertion styles and how to switch between them. Here’s some test examples to different assertion styles. They’re all testing the same things.





What is PhantomJS?

Screen Shot 2015-09-28 at 10.32.44 am

PhantomJS is a console based browser. It runs on the webkit engine and allows you to do everything you can in a browser but controlled from your console. It comes in handy when we do user behaviour tests. If you want to test it with Firefox Gecko engine try

Install Mocha, Chai and Phantom

First we need to make sure we have node.js installed. Then we can install…

Mocha.  Since it’s a global installation you might need to sudo before npm.

Then Chai

And PhantomJS

Or mocha-phantom that I use. It does some background work for easier implementation. 


Set up the first test

What we will test is initialization of the single app library Marionette.

  • Is Marionette defined ?
  • Can I create an instance of my marionette object?
  • Does my marionette object have a model attached?

First we need to import libraries, frameworks and npm packages that we need in our test. We will create an HTML file to where we will point the test to. I call mine testrunner.html and it looks like this.

Note that it has a stylesheet. It’s because you can run this file in a regular browser as well. We are also embedding Mocha and Chai for the test functionality. Then the scripts we use in our app e.g jQuery, Underscore, Backbone, Marionette and of course our app scripts (my-app.js).

The next step is the settings. Note that this is where we choose what assert style we want. In this case we are using Chai’s expect style.

My Marionette Application looks like following.

My test spec

It should be pretty self explanatory what the code does. So lets run it.

And my console output looks like this.

Outputted mocha test

We’re now getting a clean list of things that work in our app. If something fails we’ll get more detailed information about it.


I hope this brief guide gave you a good start and made you curious.  As mentioned, there’s a fair bit of libraries and you often end up chaining a few of them to get the features you need.

Have a think about what value you can get and use the internet to become a pro. You, your work mates and users will soon find great value in test driven development.

For more insights into your code, try Raygun and be alerted of errors before your users walk away in frustration.

Share this post

JavaScript error handling best practices

When creating large web applications in JavaScript it is critical to implement a robust error handling process, whether coding on the server or in the browser. The latter environment is a wild west of differing specs and legacy versions under which your code must run, and unless you have unlimited resources for QA, you won’t be able to test and find all the edge cases. As ECMAScript is a null and exception-based language, error handlers should be present at the top levels of your code paths, in order to catch bugs which aren’t caught or handled in their scope. Browsers, being as delightful as they are, add a few gotchas to a task that should be bread and butter. In this post I’ll highlight a few of these so you can ensure you’re picking up every error possible that occurs while your users are running your client-side web app or site.

window.onerror: the global handler

It is true that with modern browsers, hooking window.onerror for errors that bubble all the way to the top along with adding jQuery event handlers for Ajax errors will catch practically all Error objects thrown in your client code. If you’re manually setting up a handler for window.onerror, in modern browsers this is done with window.addEventListener('error', callback), while in IE8 you need to call window.attachEvent('onerror', callback).

Note that you should then consider the environment in which these errors are being handled, and the reason for doing so. It is one thing to catch as many errors as possible with their stacktraces, but the advent of modern F12 dev tools solves this use case when implementing and debugging locally. Breakpoints etc will give you more data than is available from the handlers, especially for errors thrown by third-party libraries which were loaded from CORS requests. You need to take additional steps to instruct the browser to provide this data.

The key issue is providing this data in production, as your users are guaranteed to run a far wider array of browsers and versions than you can possibly test, and your site/app will break in unexpected ways, no matter how much QA you throw at it.

To handle this, you need a production error tracker which picks up every error thrown in your user’s browsers, as they use your code, and sends them to an endpoint where the data can be viewed by you and used to fix the bugs as they happen. At Raygun we’ve put a bunch of effort into providing a great experience for this, as there’s many pitfalls and issues to consider that a naive implementation will miss.

Dealing with minification and source mapping

For instance, chances are you’ll be bundling and minifying your JS assets, which means that errors thrown from minified code will have junk stacktraces with mangled variable names. For this, you need your build tool to generate source maps (we recommend UglifyJS2 for this part of the pipeline), and your error tracker to accept and process these, turning the mangled stacktraces back into human-readable ones. Raygun does all this out of the box, and includes an API endpoint to accept source maps as they are generated by your build process. This is key as they need to be kept non-public, otherwise anyone could unminify your code, negating its purpose.

The raygun4js client library also comes with window.onerror for both modern and legacy browsers, as well as jQuery hooks out-of-the-box, so to set this up you only need to add:

Third party scripts (CORS)

There’s also a bunch of functionality built-in including the ability to mutate the error payload before it is sent, adding tags and custom data, metadata on the user who saw the error. It also takes the pain out of getting good stack traces from the above-mentioned third-party CORS scripts, which solves the dreaded ‘Script Error’ (which contains no error message, and no stack trace).

A more crucial issue is that due to the huge audience on the web, your site will generate many thousands of duplicate instances of each error. An error tracking service like Raygun has smarts to roll these up into error groups so you don’t drown in a flood of notifications, and lets you see each actual error ready to be fixed.

Ready to implement these JavaScript error handling best practices? Sign up for your free 30-day trial here. Or if you’ve got questions about JavaScript error handling let us know in the comments below.

Share this post

Does Raygun work on iOS 9.0?

You bet it does!

iOS9 and Raygun_BlogCover_720x300px

So as you all must know, iOS 9.0 was released a little while ago and we’re pleased to let you know that all your apps containing Raygun will continue to work as expected.

For those that don’t know – Raygun provides an exception reporting solution which can be set up in a couple of minutes by integrating a Raygun provider into your app. The provider can detect and report exceptions to the Raygun exception tracking service where they are grouped together, send out notifications to the devs, and display lots of useful information to help track down and solve the problem. Raygun supports a multitude of languages and frameworks including native iOS (Obj-C and Swift) and managed Xamarin.iOS apps.

App Transport Security support

If you played around with the iOS 9.0 beta and your app has Raygun4iOS integrated, then you may have noticed errors occurring in your app when attempting to send an exception report. This would have been due to the new ATS feature of iOS 9.0 that encourages you to only use secure connections when talking to the web – only connect to servers that support TLSv1.2 and a few other requirements. The Raygun service now supports all of these ATS requirements meaning Raygun will continue to work fine in your apps without needing to update the Raygun4iOS provider. This also means that if you had marked Raygun as an exception to ATS in your apps info.plist in some way, then you no longer need to do this.

dSYM support

If you use Raygun4iOS, then you probably know that we can symbolicate your exception reports to produce readable stacktraces if you upload your apps dSYMs. What you may not know is that every time a new iOS version is released (major or otherwise) we upload all the iOS symbols for you so that lines in the stacktrace that originate from iOS standard libraries will also show up in the symbolicated stacktraces. So with the release of iOS 9.0, we have of course uploaded all the iOS 9.0 symbols ready for all the native iOS exception reports you throw at Raygun.

Xamarin.iOS support

And we certainly didn’t forget to test our Xamarin.iOS provider on an iOS 9.0 device. There were some known issues with certain features of Xamarin.iOS not working on iOS 9.0. These were more directed towards apps, rather than components such as Raygun4Net, but we still wanted to make sure that everything was in working order. We tested a couple of apps with Raygun4Net integrated on a couple of iOS devices running iOS 9.0 and found that nothing needed to be fixed. Both classic and unified APIs are supported, and both managed and native exception reports are sent to Raygun.

Give it a try

Don’t have exception reporting in your native or managed iOS apps? Try out the free trial of Raygun now.

Share this post

Amazon Web Services Partnership

We’re excited to announce that we’ve been selected as an inaugural Amazon Web Services’ (AWS) Technology Partner. The Amazon Partner Network (APN) Competency Program highlights companies who have demonstrated technical expertise and customer success across specialised solutions and industries, including security, digital media, big data, and many others. The new AWS SaaS Partner Program provides APN Technology Partners with support as they build, launch, and grow SaaS solutions on AWS.

Technology Partner Logo

Together with AWS, Raygun makes it easier for developers to focus their time on developing high quality apps.

To get started, check out the AWS partner network.

Start your Free Trial with Raygun Today.

Share this post

How we use Raygun to support Raygun

The Auckland Software Craftsmanship team asked us to give a presentation at their most recent meetup, so I went along and gave a talk on how we use Raygun internally when working on Raygun (I’m not going to make that yo dawg joke again, don’t worry). The talk’s up on Youtube if you’d like to watch it – if you just want the cliff notes, then this blog post is for you!

Continue reading

Share this post

NodeJS 4.0.0 is 8% faster – we tested it!

NodeJS and iojs have met in the middle and become one project again – whoop! No more trying to decide which one to use. They have also announced their release plans which are exciting. Two big releases per year and to top it off, there will be a LTS version of Node which will hopefully make the use case easier in environments where life cycles are longer.

As you know, we’re big fans of Node here at Raygun, so I thought I’d take Node 4.0.0 for a spin through my benchmark process and see how much quicker, if at all, it goes!

How I tested

  • NodeJS and io.js running on Mac OS X Yosemite, fully up to date on a 2.5ghz i7 Macbook Pro with 16gm of ram
  • Ubuntu VM using wrk, 12 threads, 400 concurrent connections over 30 seconds posting a small Raygun styled payload to a tiny ExpressJS site that returns what’s posted to it

Each test was run 5 times and then averaged to get the numbers below. As with all benchmarks, these can only be compared to the results in this set.

With that done, let’s get cracking

If you’ve been following the Node/io.js thing for a while now, you’ll know that the latest version is using a recent version of V8 which includes heaps of new ECMA 6 features. It should also be quicker, being newer and all.

From the very quick test here, Node 4.0.0 is around 8% quicker than Node 0.12.7 when dealing with the same load. That’s not bad for a simple upgrade, especially if you multiply it over multiple servers!

I was a tad surprised to see that io.js 3.3.0 was slightly slower than Node 0.12.7 based on previous results – but the Node guys did work hard to catch up and it looks like their work paid off.

So should you upgrade today? Probably. There are a few breaking changes though, so probably best to test it on your dev environments first to make sure you don’t end up having a very late night – been there, done that, wouldn’t recommend it 😉

Share this post

5 stages of debugging

1. Denial

 5cca270514ac148388541b818adec89da) “It works on my computer – you must be doing something wrong” – this is the classic attempt at trying to remove the blame from yourself and put it onto someone or something else, be that a co-worker working on the same branch or the internet that must have dropped its connection right when your code tried to access it. It’s a basic survival reaction that serves to preserve our sense of self and self-belief. As long as you don’t overreact or draw out this process it’s perfectly fine to go through.
b) “Oh look, another project I forgot that I needed to work on” – otherwise referred to as productive procrastination. As tempting as it is to work on another project that you are almost guaranteed to succeed at, you run the risk of either having this distraction project break as well (in which case you have two broken projects)  or the previous broken project goes stale, you loose the mindset you were in at the time of coding and all of the code you wrote becomes dormant and that much harder to sink back into and consequently fix.
c) “Oh look…cat!” – this is just unproductive procrastination that is far too easy to fall into on the internet. While some may not think of this as direct denial, and they would be right, indirect denial can be just as bad if not worse, because you may not be consciously aware that you’re in denial – in your brain you’re just taking a 5 hour break to look at cats that leap in time to dubstep.
d) “Time to pursue my life long dream of being a woodland ranger” – this is just full on avoidance and should probably be stopped in it’s [hiking] tracks.

2. Anger


Ever had that feeling of utter rage that you just want to flip the desk and walk out? This massive urge to hulk out is not uncommon among developers – especially when it comes to debugging.

You’re too angry to be sad that your project isn’t working and what’s worse is that you probably have no one but yourself to blame. Whether it was past you being a lazy hacker or present you just not having the knowledge base to know how to approach the situation – experience being what you get after you most needed it and all…

Personally, I recommend letting the anger release in some shape or form – ideally not by raging at your work mates but perhaps a lunchtime martial arts class? After which your body may be so shaky that you literally have no energy to be angry anymore.

3. Bargaining

bargainingHere, you begin to reason with yourself – maybe you decide that no one will encounter the bug when you push it live and that’s the end of that – only future you has to deal with those repercussions by which time of course you’ll have the knowledge to deal with it (bad juju).

We’ve all had those conversations with ourselves of “just how necessary is [x] feature?” or “how much of my code can I strip back so that the error is gone but the functionality is still there?”

I must confess I don’t have any recommendations as to how to deal with this stage – just recognise that it is a phase and make sure you have a backup of the current project just in case you do start acting on these irrational bargaining conversations.

4. Depression

At this point, you start second-guessing every aspect that can be second guessed. Why didn’t you foresee this being an issue when you were originally coding? Why did you even start5cfccac8e766403ffd0d91a029b0a47f9d8a3b7245649d3adfac5922806db3c7 on this project? Why didn’t you wear your world-conquering Batman tee that could have prevented this whole fiasco from being so deflating?

This also isn’t helped by the waterfall nature of debugging, where what seems to be one error (big or small) is actually caused by a sequence of other hidden errors that constantly deflate your debugging efforts.

You’re also dealing with the emotional drain of your creative project not working how it does in your head. This is quite a blow – you don’t know if it’s a fault in your skill or what, you just know that something that you’ve been pouring all your efforts is just ungratefully flipping you off and that’s hard to handle.

Recommendation? And no I’m not proposing a cure to all depression, just debugging depression…Step away from the project and take a minute (or several) to change your mental state, maybe play some video games (if you’re desperate to stay computer bound) or play with some puppies.

5. Acceptance

tumblr_n39tffHOEd1sej561o1_500After a long journey through all sorts of emotional turmoil, you come to the final stage.

It is only once you have reached this final stage that you can truly acknowledge that yes, this error is being a pain, and yes you will probably find a great deal more logic flaws or errors once you’ve fixed the current one.

But you know what? You are going to debug the hell out of it.

Share this post

Reasons to love errors in software and life

I’m going to use the example of children in this blog post from time to time. Why? Because when advising children who have experienced their first taste of failure we try to frame it as a good experience to prevent them from losing faith in the world. So why should this reframing of negativity change when we grow up?

As with raising children, when developing your own software you’re never quite done. Even if you think you are. Equally, as with children, software has a fantastic ability to embarrass the heck out of you if you don’t keep an eye on it. Children and software also have the ability to change the world, so long as they don’t get disheartened or given up on when they fail.

Here are 6 reasons we love failure, and why you should too:

1. Errors in life are simply growth opportunities. Here at Raygun we like to point out your “growth opportunities” not only so that you can make better software but also to save the Face Palmembarrassment of someone else – be they a customer or peer, pointing out a flaw in your software.

Not only does this preserve precious brain cells from those inevitable face palms as you discover the obvious and avoidable errors, but it also encourages re-evaluation once you have shipped your code. If you never had a software error or spotted a lapse in judgment about what you thought was good UI or UX, how can you be sure that what you are producing or maintaining is in fact the best that you can present to the world?

Those growth opportunities allow iterative cycles from which bigger and better ideas can be generated which may not have been planted had you not been assigned to fix a null pointer exception that caused you to re-evaluate dormant code.

Jon Snow2. You don’t know everything.
Don’t “well, actually…” me. You don’t. The sooner you realise that there is always going to be something that you don’t know or that you need to improve on, the better the world will be for you and those around you.

Let’s face it, no one likes hanging out with the person that thinks they know everything and argues overtly to cover up the fact that they just don’t know.
Once you’ve done this you can open yourself up to new and exciting things that you can learn about. Learning is a wonderful and positive exchange, people share knowledge with you and you share knowledge with them and life is good.

3. Failure keeps your britches fitting nicelyBig Britches.

In case you’re not familiar with the phrase “too big for your britches” this refers to someone who is conceited and feels that they have more importance than they actually do.

Let’s pause for a second and imagine being in the position whereby we have an exaggerated sense of importance – how destroying is it going to be when we realise that we’re not as important as we think? Failure helps us maintain a healthy perception of how important or intelligent we actually are and prevents that horrendous bump down to earth – because we’re already grounded in our own perceptions.

This realistic perception of importance and intelligence is also ridiculously helpful in terms of team cohesion and work-mate relationships as you’re not that [insert moderate expletive here] that thinks they are x amount better than the rest of the team.


4. Failure keeps you on your toes.

What would you do if everything you touched succeeded? Sure we’d all like to think that we would create a cure for cancer and solve world poverty or finally finish that game we’ve been working on developing for so many years we’ve forgotten why we started. But where’s the challenge? Where is the sense of accomplishment and that feeling of overcoming numerous obstacles and failed prototypes and experiments? These are all elements that contribute to the joys (and at times misery) of being in a creative industry that undoubtedly attracts creative people.

And then what? If you achieved everything at the drop of a hat, what would be left to do? And what would be the point in teaching anyone else if you knew that they would have no trial and tribulation that you as a mentor could guide them through? A world without failure in this respect sounds rather menial to me…


5. It’s all in your head.

We constantly associate failure as a bad thing, something to be avoided and feel shameful about. But imagine if you set out on a project without the fear of failure, perhaps even embraced the idea. What could you achieve with a new and positive perception of failure?

pete-burns-16. Failure encourages iterative improvements

Once you’ve admitted that you will undoubtedly have errors in your software you can spend more time improving it and making better software. Although do be careful of making too many “improvements”…

And where would we be without your errors? By making errors, you’re keeping us happy and feeling like we’re needed. And let’s be honest, who doesn’t like to feel needed?

So what are you waiting for? Kick that old failure notion out of the front door and embrace everything else that the experience has to offer.

p.s. Don’t feel bad if it takes more than 5 minutes after reading this blog to rewire your brain into thinking failure is awesome – it’ll take a little while.

Share this post