Likely you don’t have time to read this then… but in case this is pre-emptive and not reactionary – heres some tips for when you inevitably find yourself at the wrong end of the shovel trying to work your way back to breathing space…
Firstly: Stay calm!
Your a web developer. Yeah people get frustrated, and there’ll be a bit of puffery, but think through what is the worst that could happen. 99% of the time it’ll just be some sites are unavailable for a bit, there may be some reputation damage, or if theres been a mistake with some calculations – there may be some financial repercussions. This is not ideal at all – totally, but getting stuck on this will not help get the problem solved.
Secondly: Start from the top.
In my spare time I enjoy being an audio tech around the place. Troubleshooting is very similar in that world – a mic or speaker or something isn’t working, you work out how to fix it. And the process is the same. Start at the top of the signal chain (ie from the microphone), and check you have signal at each point in the chain from there right on through to the speakers. In development land, The input into the system is the end user – what does their browser hit first. Throw in some logging at that point and make sure the browser gets there. For many PHP frameworks that means starting at the index.php file and then following through a series of includes narrowing down till you find the culprit code / system / resource failure. Don’t be afraid to throw exit statements around – the system is already broken right? If you can be doing this in a development environment – ideal – else do what you can.
Thirdly: Bring your toolbox.
A tradesperson is no good without their tools. Ours is a bit more virtual than most, but the theory is the same. Know how to get log information, get familiar with linux tools like:grep -rnw ./ -e "text to find" //recursively find text
tail -n50 filename //show last 50 lines of a file
tail -n1000 filename | grep "text to find" //find text in the last 1000 lines of a file
For php – learn how to turn debugging on:ini_set('display_errors',1);
error_reporting(E_ALL);
for production environments investigate silently logging to a file – many frameworks support this, so it has minimal client impact. Otherwise send error information via email when it happens, or use services like rollbar or sentry to track issues.
Don’t be afraid to echo and exit. dump what data you do have to the browser so you know your script is on the right track. break your code down into components in order to rule out chunks of code from being the issue. Once you know what isn’t broken, you can quickly hone in on what is.
Lastly: Communicate.
Tell people what is going on. Often talking through a problem is a key to solving it – whether the person understands what you are on about or not. Just by replaying it in your head trying to package the problem for others to understand, you will think through potential areas you have missed checking. Have great communication with the key stakeholders. If people understand what is going on and what you are doing to try to fix the problems, they are likely to be more lenient, but also they are likely to feel part of the team and with a bit of control, rather than on the outside questioning what on earth is going on. Open and honest is the best policy. Don’t hide things. If you’ve cocked up – own it. If a member of your team has dropped the ball – don’t throw them under the bus, but the whole team wears the responsibility of getting things solved and communicating to the client / stakeholders what is going on.
We’re all human. Crap happens. Its how you approach it that makes the difference.
