Article: Speaking another language: how to communicate with web developers

Author: Katie Silvester
Date: Katie Silvester

If you have ever been exasperated with a website that worked yesterday, but not today. Or a URL that loaded with one web browser, but not another – you’re not alone.

For KISS’s Senior Web Developer Baz Calver, getting to the bottom of issues like this are a big part of his job.

“We all enjoy problem solving,” he says of KISS’s web team. “But sometimes it can be frustrating debugging things. It can even be something as simple as a comma in the wrong place in the code. That would be at the extreme level, but it can often be slight syntax errors that cause issues down the line. That’s how it always is with coding - once you find the problem, it’s nearly always a very simple solution.”

The importance of correct spelling
Baz recounts a cautionary tale that, ironically, revolved around the misspelling of dyslexia.

“A colleague was setting up a site about dyslexia, so the word ‘dyslexia’ featured quite heavily in the code. A bug was discovered during the later stages of the build. In his code he’d set up strings – which are just variables, short programming bits of text – and it turned out to be one misspelling of the word ‘dyslexia’ that was the route of the issue. That really made us laugh.”

A common issue for web developers is trying to get new sites to work with older technology. Old versions of Internet Explorer, for example, are still commonly used, but are incompatible with some technologies used in modern web browsers.

“I was setting up this cookie that was fine with every other browser, but not with Internet Explorer,” recalls Baz. “And it turned out that Internet Explorer demanded the attributes be in a certain order, but this was only discovered by comparing implementations of similar code.

“We call them ‘gotchas’ – little quirks that you need to look out for that aren’t always written in the documentation.”

Lost in translation
A day-to-day concern for developers is getting the right information from clients, or users, when a problem is being reported. There is often what could almost be called a language barrier between developers and the rest of us. Let’s face it, most of us don’t know our APIs from our AOPs, let alone our polymorphisms from our prototyping!

“It’s hard to report problems in the right manner,” Baz admits. “Some people will try to be overly precise with what they’re describing, but because they don’t know the lingo – or jargon, you could say – they can lead you down the wrong path. On the other hand, some people give you so little information, it’s hard to know where to start.”

Baz’s top tips for talking to developers:

  1. Explain what you were attempting to do.
  2. Supply URLs, where relevant.
  3. Give plenty of detail – there are so many things that can go wrong on a website or with an application, the developer will need to know exactly what you were trying to do when the problem occurred and what happened next.
  4. Don’t forget to mention which operating system and browser or application you are using.
  5. If there is an error message, paste it into your report as will give the developer a lot of information, and that can often lead to a quick solution.

At KISS our in-house team place great emphasis on utilising best practice, modern techniques and tools in a robust development and testing process. Our diligence in this area ensures that what we build will perform. Find out more about our work here…or just give Baz a bell!

 


Click here to view the online publication