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. 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. Failure is 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?


6. 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? Not just that, but once you’ve admitted that you will undoubtedly have errors in your software you can spend more time improving it and making better software.


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

Why Don’t Users Report Software Errors and Crashes?

Remember when you used to encounter those pop up messages each time your computer crashed? The ones synonymous with the Windows operating system were regularly popping up every time things imploded. You lost your work, smashed your keyboard and had a good cry. Just me?
67429-click-send-error-report 2

If I click to ‘send this error report’, what actually happens to it? I’m pretty sure it’ll go one of two ways.

What I think will happen when I click on ‘Send Error Report’

A friendly employee will get notified of my error and pass this information on to an eagerly awaiting development team who will take this problem extremely seriously. Next up I’ll get an email from these lovely people. They’ll apologize, tell me not to worry. I am important to them. They make me feel amazing. I’m awash with kind thoughts and positive things to say about their company and their customer service. I’ll never use anyone else, they care about me and I actually helped them make better software by reporting this issue!

What actually happens when I click on ‘Send Error Report’


This behaviour and expectation has become embedded in software user’s minds for many years. Usual responses from people when they encounter software errors and crashes are:

  • What’s the point of submitting a bug report? They never go anywhere.
  • That’s a hassle, I can’t be bothered. They don’t care.
  • I don’t have time to explain it all. They will just ignore it.

Usually this is the case for the developer too. Why should they spend their time going back and forth with customers over email to get screeenshots, operating systems, browsers, browsers versions all to end up with a bug they can’t replicate. Hassle!

office-space-computer-smash 2

What could happen in the future (right now actually)

By plugging a solution like Raygun into an application you don’t need the user to report the issue. Raygun monitors your software for problems and notifies you in real time. So without the need for the user to do anything you can see who was affected, what browser they were using, what operating system and even what line of code the error happened on! I mean really, are you a software developer and are not using this thing yet?

You can even reach out to the user from the Raygun app to say ‘Hey, I saw you had that issue yesterday, we just wanted to let you know that we’re sorry about that and have fixed the issue now.’ See, it’s the future, but right now.

Real world, real problems

So I’ll tell you a story, a real world example of this phenomenon. About six months ago the management at my partner’s school where she is a teacher implemented a new software system to create, collaborate and send out reports to parents.

It was designed to take the hassle out of report writing and showed great promise. The school was perhaps their tenth or so school to implement the system, so it was kind of in a Beta format and they were encouraged to give feedback. All was good until bugs started appearing. They encountered several big issues with the system ranging from photos disappearing, posts not saving, clicking save and things disappearing, inviting users to the account and no invitation emails showed up – you get the picture.

This went on for months and I was hearing of all these frustrations and problems with the system. Mainly in my left ear. I was driving home most of the time when these conversations occurred.

‘Have you reported these problems?”, I asked. “Well, no, actually. What’s the point?” It seemed amazing to me that these people were having all these problems yet never took the step to report the problems to the developer, and it turns out this is far more common than you’d think.

Hello? I'd like to report a software error....
Hello? I’d like to report a software error….

Here at Raygun we obviously get real time error reports from our own software. It’s this kind of weird inception type thing where if you think about it for too long it starts to hurt your brain. An error monitoring software system reporting errors on it’s own error reporting system which could be also reporting….anyway, we digress. We have found that only 1% of users actually report to us the errors that we know they experienced, and these poor teachers, and they can’t be the only ones who do this, had found novel ways to navigate around the errors from occurring rather than report them, by navigating to different screens to do the tasks or saving their writing to their clipboard before hitting the save button just incase it lost it all. Rather than report the problems and face the hassle.

The developer on the other hand had no idea that these problems were happening. Absolutely no clue. We found this out when we emailed him to see if he’d like to try Raygun to fix the issues the teachers were having. He was almost taken aback that someone was suggesting the software had errors, and in hindsight you can see how he would be. You won’t know about things that are happening in your software if you’re not told about them, and you certainly can’t expect your users to be the ones to tell you. They won’t.

Get notified of problems in your software applications with Raygun and become a better developer! Raygun reports errors that are affecting your users in real-time so you can fix software errors and crashes faster. Try it free – 30 days to see for yourself!

Share this post

Things to help you kick ass at marketing high tech

There are few things more difficult than marketing a high-tech product.

Like, sneezing with your eyes open, licking your own elbow or writing the number 6 whilst moving your foot in a clockwise direction – it sometimes feels damn near impossible to have the most anti-advertising audience on earth check out your tech product.

Please try my devops tool, it's built with Node!
Please try my devops tool, it’s built with Node!

Because many of our Raygun users are also developers with their own businesses and struggles with marketing high tech, it would be selfish of me not to share my resources.

Marketing High Technology – William Davidow

First published in 1986, Marketing High Tech isn’t exactly a modern read, but if I were to recommend just one book to help with marketing your startup, it would be this. William Davidow is most well known for being the success behind Intel’s ‘micro processor explosion’, in the 70s and 80s and his experience can be transferred as words to live by for any tech company trying to market to a technical audience today. Everything I know about product placement and market share, I learned from this book. My main takeaway from reading it would be, you can’t please everybody. Find your strengths and focus on them.

Great companies are not just a little better in a few ways, they are significantly better in one or more ways that are important to the customer. – William Davidow


Kissmetrics is a really handy marketing tool that helps you wade through your massive swamp of user data and tells you all the important parts with reports, and leaves out what you can ignore. Their blog is one of the few I’m still subscribed to after the mass cull of my email subscriptions several weeks ago (thanks unroll.me). We’ve used the A/B testing reports many times, and let me tell you – having the data to back up something you suspect saves A LOT of time convincing your team to go with your idea. Always be testing.

Thank you Certified Knowledge, for this most excellent image.
Thank you Certified Knowledge, for this most excellent image.


If you do just ONE thing today to get you closer to successfully marketing your high tech product or service, all I ask of you dear reader is that you watch this 54.22 minute long talk on writing non-sucky copy for websites, marketing collateral and newsletters by Joanna Wiebe from CopyHackers.com. The words you use to talk about your tech product are CRUCIAL to how people feel about you, but if you take a look at nearly every tech landing page on the internet – they’re made up of a bunch of words and phrases that don’t really mean anything, let alone explain what the product does. Be different, be unexpected and be real.

Insane honesty

In staying with the theme of being real and being different, I absolutely loved this article on being ridiculously honest as part of your marketing strategy. Think about it, NO ONE is going about telling people why they shouldn’t use their service. In fact, they’re probably denying their weak points and exaggerating their good ones. But the truth is, people will trust you and respect you more if they feel you’re being honest with them. For example, a developer who shouldn’t use Raygun, is someone who’d rather be in the dark about their code once it’s in the wild.

The Intercom blog and The Buffer Blog

Ok so I was a bit dishonest about unsubscribing from ALL the newsletters and blogs before. I’m still an avid follower of both the Intercom blog and the Buffer blog, who are both companies that we use and love at Raygun. Otherwise, I’ve totally cut back on email subscriptions, I promise, I don’t have a problem…

So, take these resources and pass them on. Marketing high tech is hard, and if you can help one person improve just a little bit – you can be helping in a big way. Like this swimming horse, with a small dog riding to freedom on its back.


Share this post

Hello, is it me you’re looking for?

Hello! I’m Kate, the newest member of Raygun’s growth team here in Wellington. I’m really excited to be part of the gang and thought it was time to share a little about myself.

Where I’ve been:

I moved to Wellington for Uni in 2007 and studied Psychology and Media Studies, finishing up in 2010. From there, I was lucky enough to get a job at TradeMe (NZ’s e-bay) in a customer service role where me and my amazing colleagues listened to people complain alllll day, and hopefully fixed a few issues too. After a while I decided to get outta there and pursue a job in ad land. After a 2 year stint at an advertising agency:


18 months in an ad ops team, and 5 weeks exploring the world a little:

MPJump v2
On the Inca Trail to Machu Picchu. Fun fact: you’re not allowed to jump at Machu Picchu so I had to get it out of my system before hand.
Here I am, sitting politely.

I find myself here at Raygun!

Where I am:     

Here! Talking to my new BFF’s software developers! If the above didn’t give it away, this is all a bit new to me so please be gentle. It’s been 2 weeks and so far I love being here – it’s a completely new environment, oddly everywhere I’ve worked previously has had the exact opposite male:female ratio! Learning about what Raygun has to offer our users and getting that message out there into the world is a big task but I’m definitely up to the challenge. Watch this space, awesome things to come…

Where I’m going:

“To infinity, and beyond!”

In this situation I’m Buzz and you’re Jessie. Get excited.

Share this post

How does website performance affect user experience?

We all know that website performance is important. But how important is it and what can we do to improve it?

When your web page takes longer than one second to load

Many companies and researchers have spent a lot of time looking into performance. From all of this research, one thing is clear: a fast page does matter.  These are some of the things we can learn from them.

“A 1 second delay in page response decreases customer satisfaction by 16%”

“50% of people will tell others if they have a negative experience on your site”

“Facebook pages that are 500ms slower, result in a 3% drop-off in traffic”

“64% of smartphone users expect pages to load in less than 4 seconds”

“If Google increased page load by +500 ms, they get 25% fewer searches”

“52% of online shoppers claim that quick page loads are important for their loyalty to a site”

“73% of mobile users say they’ve encountered a site that was “too slow to load”

What? My page went slow overnight!

I have experienced this and I think many other companies have done the same too. Building (in our mind) the most awesome web page… until one day someone says, “Hey! why is the page so slow?”

 Small tips that makes a big difference

Compress images

Small images, big issues. It’s obvious to optimize big images, but every image makes a difference. It should be part of your routine or even better, your automatic workflow. I mostly use .png and for that I find tinypng.com the best image compressor for the following reasons.

  • Preserves the image quality
  • They have a drag and drop web page. Super handy
  • Photoshop plugin available
  • Works as well as a npm packages

The last thing I love. You can automate your image-compression-process, which will ensure that all images get compressed without wasting your time.

Check out the grunt-package or the gulp-package for installation guides.

External JavaScript are sometimes slow

On a modern website we can expect tons of JavaScript. This can really slow your site down. If you’d like to see your script performance in real-time, Ghostery is the tool.

Ghostery is a chrome extension that lets you disable external JavaScript files. This is also useful in the development environment, if you have scripts you don’t need while you develop. Such as analytics scripts or other tracking scripts.

Be alert before your site gets slow

Two great tools to find out what could make your site load faster is Google’s page speed and Yahoos Yslow. They both come with different choices of implementation. The one I would like to highlight is the npm implementation. Why? Cause you can add it to your build and it will warn you when you are in slow-site-risk-zone. The more code and files you add the higher risk for slow pages. Always keep track of your status while you develop.

This is a screen shot of the grunt plugin based on google page speed.

google page speed

Remove unused CSS

I know! Keeping track of the CSS is hard, what is used and what’s not? For a long time we’ve been lacking good tools to help us keep the CSS small. So far I have only found one tool that I think does the job. UnCSS, which is a npm package. It parses your CSS files and writes it to a new file if it finds a matching CSS rule in your markup. NO match NO output. What I found really good too, is the JavaScript support. If you dynamically inject a CSS-class or HTML element, it will take this into consideration as well.

Yahoo’s best practice

This is the best practice list from Yahoo’s Yslow page.

  1. Minimize HTTP Requests
  2. Use a Content Delivery Network
  3. Avoid empty src or href
  4. Add an Expires or a Cache-Control Header
  5. Gzip Components
  6. Put StyleSheets at the Top
  7. Put Scripts at the Bottom
  8. Avoid CSS Expressions
  9. Make JavaScript and CSS External
  10. Reduce DNS Lookups
  11. Minify JavaScript and CSS
  12. Avoid Redirects
  13. Remove Duplicate Scripts
  14. Configure ETags
  15. Make AJAX Cacheable
  16. Use GET for AJAX Requests
  17. Reduce the Number of DOM Elements
  18. No 404s
  19. Reduce Cookie Size
  20. Use Cookie-Free Domains for Components
  21. Avoid Filters
  22. Do Not Scale Images in HTML
  23. Make favicon.ico Small and Cacheable


Share this post

New Integration – Using Zendesk with Raygun


Good news Zendesk Users! We’ve gone live with our latest integration. You can connect Raygun error groups to issues in Zendesk, or create whole new issues in Zendesk from an error group. It’s super easy and by using Zendesk and Raygun together you’ll be squashing bugs faster than ever.

You’ll see this integration is already available in your Raygun.io dashboard.

Getting setup

  1. In Zendesk, head over to the admin panel choose API under Channels
  2. Enable Token Access if it’s not already
  3. Click ‘add new token’
  4. Provide a label – we suggest Raygun so you know what the token is for
  5. Copy the token that was just generated for you
  6. In Raygun, click on Application Settings, then Plugins. Choose the Zendesk integration button
  7. Enter your subdomain, the email address you use to login to Zendesk and paste the token you got from Zendesk
  8. Press ‘Test Settings’ to make sure Raygun can talk to Zendesk properly
  9. Assuming the test worked, hit Save Changes
  10. Tick the Enabled box and press Save Changes when you’re ready to enable the plugin properly

Share this post

A quick look at ECharts – Javascript charting

I’ve been playing around with various Javascript charting libraries recently, and ECharts is one of my favourites. Overall I’ve found it very easy to use, and has a good balance between simplicity and flexibility. I personally think that ECharts is well documented, and has lots of good samples to work from. As it is Canvas based, and can’t be styled with css, its visual customizability is a little bit limited, though everything I’ve wanted to do has been possible. If you do find it meets 95% of your needs, you could always fork the source code.

While playing around with this, I’ve just been using the eCharts Javascript file in my project and referencing echarts directly, and hence my code below is based on this. Feel free to use require.js as the official docs do. Regardless, here’s the steps I use to start working on a new chart:

Step 1 – A host element

The first thing you’ll need is a DOM element to host the chart. I’ve read that this can be just about any type of element you want. I use div, because it just makes sense. Two things you’ll need on your element – first, some way to identify it in Javascript such as an id or a class name. Secondly, the element needs to have a width and height before rendering the chart, so make sure to set the size in some way such as in the Javascript, with css, or in my example below, with inline styles. (Hopefully our design team doesn’t read this blog).

Step 2 – The chart options

This step is where most of the work will be done. You need to create an object that will define what you want the chart to look like. Below is a reasonably minimal set up just to aid in getting started. Before going into any detail, lets move on to the final step so that you’ve got a chart to display and work with.

Step 3 – Initialize and apply options

Last of all, you need to initialize the chart object with the host element, and then apply the chart options. I’ve been using Backbone and Marionette while playing around with charting libraries, so here’s what my code looks like (Where chartHost is an ItemView ui selector ‘#chart’).

If you’re not using Backbone, there are of course other ways to get the host element, such as this simple example:

And here’s what the minimal chart looks like:

Basic Chart

A bit about axes and series

As seen in the simple chart options example above, the fundamental components of building a chart are the axes (X and Y) and series. All of these are arrays, as you can have however many you need, and they all have a ‘type’ property which will affect their behavior, display and what further properties you can use.

The valid axis types are:

  • value – which I’ve used in the above example – a simple axis for plotting numeric values.
  • category – probably the most commonly used axis type – this requires you to set the ‘data’ property of the axis which is an array of objects. These objects will be used as the context of the axis labels, and will be evenly spaced along the axis in the order you provided them.
  • time – a date time scale – best used when you have irregularly spaced datetime data. If some points are separated by a week, but others separated by a day, you’ll probably want the spacing of the data in the chart to reflect this, in which case a time axis is what you’ll want. If your datetime data is already evenly spaced (e.g. a data point for each hour of a day), I find it easier just to use a category axis.
  • log – logarithmic scale – used for specialized scenarios where you need to plot data along a log scale to improve readability.

As I think the category axis is very useful and commonly used, here is in example for you to get started with. Note that I’m now setting the data property of the xAxis, and the values in the series data are single values, rather than pairs of X/Y values. Another thing to note is that you’ll want the length of the axis and series data arrays to be equal.

ECharts provides a huge range of different chart types – whatever chart you need, you’ll probably find it here:

  • line – Includes basic line charts, filled areas, splines and stacked data. All of these also support displaying symbols at each plot point.
  • bar – Can be displayed vertically or horizontally, supports combinations of stacked and side-by-side arrangements, and can be used to create tornado or waterfall charts.
  • scatter – Simple symbol plots, bubble charts (symbols with different size to display 3rd dimension of data) and supports massive amounts of points.
  • pie – Also used to create Doughnut charts, Rose diagrams and some trippy spirals
  • radar – Polar charts with lines, areas or wormholes
  • map – Comes with geographical data that can display a world map or be broken down into country views. Animated pings and jump lines can create some nice effects. Also supports providing your own map data.
  • And lots more – Also included are Candlestick, Chord, Force-directed diagram, Gauge, Funnel, Heatmap, Event-river, venn-diagram, Treemap, Tree diagram and Word cloud

Want to give it a go?

This has been a very short introduction to get you started with ECharts. If you want to try it out, the next step would be to start playing around with the available chart options. Here is the documentation regarding the chart options. The colored table displays the top level chart option properties you can work with. Click the links to see what customizations you can make.

Share this post

See exceptions in your Slack integrations channel, annihilate them like a champ

We were stoked to see this tweet recently from @gnat who stumbled upon one of the killer features of Raygun:

Like all good software tools, Raygun is dogfooded internally to ensure the service nails the use cases for everyday software development. I can confirm that the Slack integration is pretty sweet, and is a critical part of our workflow. If you haven’t heard of it, Slack is a popular team chat service with rich support for messaging and team collaboration, which importantly allows third-party services your team uses (like Raygun) to post messages directly into your chat channels.

In this post I’ll be highlighting how we use this to streamline our development workflow and ensure the entire team is aware of exceptions when they occur, immediately.

A wild exception appears

Say you’re in the implementation phase, debugging locally. An exception is no big deal as you’ve got your debugger attached and the stack appears right in front of you:


The same applies during staging and testing, where your web server or mobile apps can output the stacktrace for your team to use. This completely falls down in production though, when exceptions like the one above fall into a black hole in a log file somewhere. You might have notifications set up using another service (which is also invaluable as a failsafe), but someone still has to find the offending machine or VM, remote in, diagnose the error, and begin work on a fix.

Tough call at 1am. And even when the heroic late-night fix is applied and your system is stable again, the cause and knowledge of the incident may remain with the one who had to triage it.

‘Raygun-Driven Development’

A much safer and more scalable approach is to have notifications sent to a team chat service like Slack, where exceptions are immediately visible to all. With all key services your devs, DBAs and QA integrated into one app, such as build servers, deployment services etc, team members have one centralized places they know to visit to get a constant stream of live updates for what actions are being applied to the system.

We’ve also got our source control (GitHub), build server (TeamCity) and deployment app (Octopus) all sending webhooks into Slack whenever someone takes an action. It winds up looking something like this:





Those are all from our development channel, where work-in-progress actions are recorded. With the ability to assign different webhooks to different channels, you can have your staging/beta environments send their events to a separate place from the mission-critical Production rooms. That way, if a message occurs in there, anyone watching knows it’s critical and to immediately click through to check out the stack trace, and alert the person with the most knowledge and chance of fixing it.

All of this takes place alongside discussions about the notifications as they occur – for instance, someone can @mention the person responsible, have a convo to decide on the best course of action, add a comment in Raygun, perhaps create an issue in GitHub, then develop, test, merge and deploy a fix, all while the whole team watches. Instant feedback, quality control and context for the entire team.

The real-time stream of webhooks as presented in the Slack channels becomes an invaluable timeline of events, which members can use to catch up on things they missed if they were away for a few hours/days while work continued.

Get started with Raygun and Slack

You only need two things to get the above slack integration working – a Slack account and a Raygun account. You can start your free 30-day Raygun trial here, and then link it with your Slack channels using the easy integration inside the app. Documentation for this is available here, but there’s only a couple of steps involved so it should Just Work.

Got any questions about how Raygun and Slack can work together to help your team build great software? Let us know in the comment form below!

Share this post

Programming is hard. Is there a problem with my brain?


“Now, navigate to a small folder in Terminal that you want your program to open with. Good, now it’s time to create your symbolic link in your PATH folder, BUT, before we do, let’s check your profile file by using nano ~/.bash_profile.”

My mind flicks through the catalogue of these words in my brain, I know I’ve learned them at some point, but I can’t piece them together into coherent instructions to myself before the teacher has moved on to the next topic.

‘What keyboard shortcut opens Terminal again? Command and Space – no wait that’s on a Mac’.

I grit my teeth and try not to think about how far behind the Treehouse instructor I am, as I scramble to open up Google and look up keyboard commands for the hundredth time. 

“I’m just not good at this”, I think to myself. “It must be my brain, I’m just not good with logic.”

This was meant to be an intro course – so why was I finding it so hard?

This scenario is not uncommon for me, whether I’m doing an online course, attending one IRL or having a colleague or friend teach me programming concepts. I always wind up feeling dumb, frustrated, and angry with myself and whatever poor soul is giving up their time to help me.

Most sessions end abruptly with a tight feeling in my throat and a rising swell building up in the back of my eyes before I declare that I’m not doing it anymore, and quit for the day. Sadly, most of the time I’m just a few stages away from completing a module, or making my app thing work, or having a break through – but it’s too late. The damage is done.

So I’ve been wondering, why is this? Why is learning to code so hard?

I think this is a not a straight forward question, with straight forward answers but I have several ideas as to why I am not finding coding an easy skill to acquire. I also asked the Twitter community for their thoughts, and received an overwhelming response:

So, with these gems of wisdom, these are my tops points for why I think programming is hard:

The ‘it’s so easy – I can’t believe you didn’t know that’ attitude

You know that thing where you just don’t get something – a maths equation, a programming problem, grammar in a foreign language, the political regime in South-East Asia…

And then some smarty pants comes along and glances over your shoulder, or interrupts you mid-sentence to say:

“Oh, but that’s easy”

Yeah that. That is why we can’t have nice things. Now you have to struggle through understanding the task at hand knowing that it should be easy, and everyone thinks so but you.

Possibly even worse though is:

“I can’t believe you didn’t know about the figure element in HTML – not that HTML is a real programming language anyway”

Seriously, it doesn’t matter that it’s not considered a ‘real’ programming language – it’s still a new skill that needs to be learnt. Trying new things is scary. It’s about being brave enough to be in the vulnerable position of not knowing and there’s nothing wrong with failure or uncertainty – in fact, it’s an important part of success.

And what’s the deal with that ‘I can’t believe you didn’t know that’ attitude in the tech industry? It’s impossible that someone can know every single idiosyncrasy about a programming language – they’re very complicated beasts. When did it become OK for us to belittle each other like this? Perhaps we’re just afraid we’ll get ‘found out’ for not knowing something.

It’s normal to find a new skill hard at first. As Jake the Dog once said, “Sucking is the first step to being sorta good at something”. And he is so right.



The ‘Left Brain/Right Brain’ argument

My favourite excuse to use when maths and programming problems are over my head:

“I don’t get it because I have a creative mind. Programming is logical and my brain just doesn’t work like that”

And while I so love to cling to this notion that I’m good at writing and painting because I’m a creative left-brained thinker, and I struggle with maths and programming type disciplines because they are primarily right brain based activities – there’s a lot of evidence to suggest that this is an outdated way of thinking.

The article ‘Debunking The Myths About The Programmer’s Brain‘ by Belle Beth Cooper investigates some of these common myths about how programmer’s minds work, and points out that “Our brain hemispheres are inextricably connected. Both sides are co-dependent and each takes a part in most thought processes”.

So, could it be that I’m just better at creative things because I’ve simply had more practise at them, due to believing I am naturally good at them? The saying comes to mind: ‘whether you think you can, or think you can’t – you’re right’.

Programming Is just hard, full stop

“Don’t believe anyone who tells you that learning to code is easy”

Probably summed up perfectly in this Tech Crunch article, while the recent push that ‘anyone can learn to code’ is doing amazing things for encouraging more people to join a previously seemingly unreachable industry, we could be going about it the wrong way by insisting that it’s an easy skill to learn.

As Kate Ray puts it in her article, ‘as a programmer, there is a limitless amount of stuff to learn’ – and a constant sense of inadequacy is sadly not uncommon for even those considered specialists in the field.

I think a better message to those who are just starting out might be that there is a LOT to learn, it might be challenging, but you CAN do – step by step. The following video about ‘How To Get Good At Anything’ explains that rather than trying to learn it all at once, and setting unclear goals like ‘I want to learn how to code’ – you need to be more specific about what you want to achieve, and break the tasks down into smaller tasks.

So maybe, instead of feeling sad that I can’t understand JavaScript yet – I’ll focus on just learning enough to make one part of my static blog interactive. Then, move onto the next step. And be prepared that I’ll probably be terrible at first, but that Jake the dog said that is totally OK.


Share this post