(Dev Tales is part of a Heart Internet blog series showing that web developers are humans too. Any resemblance to any duck themed imagery, fictional or non-fictional, is pure coincidence. Honest guv.

If you missed the previous episodes, check out Demystifying code sorcery and How I became a developer).

As a developer who was promoted from the Heart Internet support team, I still maintain a social relationship with many of the people I used to work with, and as time goes on I realise that they have absolutely no idea what we do beyond “making the website”. This episode of Dev Tales gives you an insight into my typical day as a developer, and hopefully give you an idea of the magic that we perform.

The first priority of the day is to prepare for the current release, which can at times be terrifying. Just imagine that you’ve spent an entire week working on a particularly complex piece of code that you are 100% happy will work in the live environment. Then the dreaded message from the QA team comes in and it’s almost always one of two things:

• It doesn’t work at all.
• It doesn’t work if I click this, enter this, move that, stand on my head, whistle three times, spin around and then try to do it in Firefox.

As a developer it’s hard for me to pick which of these situations is more frightening – the former usually means I’ve forgotten to do something really basic and it is easy to resolve in nine out of ten cases, while the latter becomes a nightmare to track down, a nightmare to debug and usually means I’ve forgotten to do something really basic and it is easy to resolve.

All jokes aside, I have a massive amount of respect for QA Engineers. To understand what they do in a nutshell, I present to you a tweet I saw recently from Bill Sempf:

QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.

— Bill Sempf (@sempf) September 23, 2014

Without the input of our QA team, I dread to think how many mistakes would be live due to us not immediately considering an esoteric niche edge case we wouldn’t come across naturally in our own testing. They do a fantastic job of keeping us in line and making sure our sites are running the best that they can.

We recently as a company adopted the Scrum methodology of Agile development, therefore the next order of business is the ‘Daily Stand Up’. In simple terms, this is a meeting we have every day to review the previous day’s work, decide what we’re doing today and discuss any problems or ‘blockers’ we are experiencing. The Scrum methodology fosters better communication between a team and breaking down larger tasks into smaller ‘stories’ that describe the outcome rather than the nitty gritty details of the implementation. Even if you or your company have no plan to adopt an Agile methodology, it is worth researching for your own use as it can help you anyway by learning the abstract concepts that go into organising a project.

Once the morning meeting is over, the day becomes completely free-form. Usually this will involve working on the latest major project but can also be one off changes, marketing campaigns or behind the scenes improvements for performance or generally making our own lives easier.

Making a project happen is far more work than it may seem. Many people think we write some code and it works. If only! The majority of projects require:

• Writing automated tests to make sure the code itself works as expected.
• Manual Testing and pretending to be a user to make sure the experience is as expected.
• Reviewing other developer’s code, especially on security sensitive projects to make sure the code is safe and durable.
• Talking to and assisting the back end developers to make sure the communication between the website and the back end is flawless.
• Communicating with the design and marketing team to implement SEO techniques.

The key to fitting all that into a single day is very good time management – a skill that I have improved considerably in the last six months. The biggest help in my experience has been breaking down projects into small digestible chunks and documenting the progress made. A great (and more importantly free!) tool for organising your thoughts and time is Trello. As an example, you can break down projects into “boards” and then create various lists of tasks that you can move in to a “complete” list once they’re done. Having a visual representation of work done versus work still to do can make estimating and completing a whole lot easier to do.

The moral of the story boils down to not biting off more than you can chew, have a plan and then stick to it. Learning to cope with unexpected interruptions is the key to delivering on time, and it is a hard skill to get to grips with. My personal method is by introducing a small amount of slack on to any project that I estimate, allowing me to use that time for the emergency “oh my god the world is falling apart!” bugs. There is no “one true way” to accomplish good time management but good practice and the right tools will make it a whole lot easier.