Listen to colleagues, even or especially if they are not in your department as something useful may come out as a result.
This is more of a cultural phenomenon than a real development topic, but can be drilled down to a nice real-world example that’s currently taking place here at XING. It started with a small discussion (shortened of course) between a frontend developer (FE) and a quality assurance engineer (QA).
FE: Hi, how are you?
Ah, that sounds bad. We should definitely look into ways to improve this.
Wait a minute – I think we might be able to create something… in common browsers.
– Someone from QA would be immediately informed when an error occurs
– We can optimize the level of effort required for testing
– We could save time reproducing bugs
Yeah. We can even determine in which file and which line the error occurred.
So an engineer can see where bugs are? This would be a win-win situation for everyone! How about multiple errors? Would this work everywhere? What about mobile?
It just lists every error that occurs and works on both desktop and mobile browsers.
(We’ll leave the discussion there)
After that little chat we decided to take a previously used approach for collecting anonymous information about JS errors. window.onerror (which every major browser has implemented) is overwritten in a development environment by some native code that fetches the message, line number and path of the error object and prints it into a new element on the page. This “container” appears in a fixed position so that you can see it everywhere and not just when scrolled to the top (of course only in browsers that support this).
- Fast and easy to report
- You immediately see the bug without having to search for it… ;)
- More precise error reports
- Just one hour’s work results in:
– less time needed for bug searching
– less time needed for bug reproducing
– less time needed for bug reporting
– and even less time needed for bug fixing
- No access to the stack in window.onerror
- Requires additional handling
- May ONLY be delivered in development ;)
From a technical perspective this is a huge step although only a small piece of work is required, and therefore glues two departments together in cultural terms.
One week later: Déjà vu…
Well, I had a great weekend.
No annoying bugs found before the weekend? ;)
Now that I can find bugs really quickly it takes far less time for me to inform our developers.
So less time to fix bugs and more time for other stuff? That’s fantastic!
And how was your weekend?
Well… (that’s another story)