Throwing away assumptions and trusting nothing, where it makes sense to do so. I've been burnt too many times by library bugs, framework issues and the other layers between me and what I'm actually doing. When I first started out I used to think that browsers such as Chrome were infallible and any problems had to be with my code.
As a result of being burnt, I'm happy to give up on logging and trawling through code in favour of just taking a PCAP and finding out what's actually going on over the wire. Or stracing my app written in a high-level language which runs in a VM. Sometimes you just want to see the syscalls.
I'm also happy to go digging in the browser's source code. I think my favourite bug to diagnose manifested as a visual issue with menus in a frontend framework. The menus were styled with some CSS, nested inside a media query:
@media (hover: hover) {
These styles were only supposed to apply on desktop devices with a mouse pointer capable of hovering over HTML elements.
The rules seemed to apply on some OnePlus devices though, with just a touch screen as an input device.
Getting to the bottom of this involved creating a test page to reproduce the problem, reproducing it in multiple browsers, digging into Firefox for Android's source code (yay FOSS) to find out how it implemented the media query, writing an Android app to reproduce the underlying data problem and eventually working out that it was a problem in the phone's operating system.
To be honest, for me the point where you discover "this media query does not behave correctly on this device that I need to support" is where you stop digging and find a different solution for detecting pointing devices.
It's very clever that you managed to discover a bug in OnePlus's version of Android but then what?
> To be honest, for me the point where you discover "this media query does not behave correctly on this device that I need to support" is where you stop digging and find a different solution for detecting pointing devices.
It enabled me to go back to the customer and explain the problem and make the informed decision to not continue work on the problem. The fact is that the broken OnePlus devices (not all of them, and not all the time) represent a very small proportion of the devices we need to support.
I guess maybe this is a bad example because the web is stuffed full of "this mobile device a lot of people use is inexplicably broken" situations (hello Mobile Safari) that I would never consider digging deeper.
Yes, exactly! If I gave up on my language's debugger or compiler every time I was troubleshooting something because I didn't trust it, I'd waste an absolute ton of time. I think finding a balance is important, but also not being afraid to consider the possibility that libraries, browsers and tools that you generally don't consider flawed might have their own issues.
As a result of being burnt, I'm happy to give up on logging and trawling through code in favour of just taking a PCAP and finding out what's actually going on over the wire. Or stracing my app written in a high-level language which runs in a VM. Sometimes you just want to see the syscalls.
I'm also happy to go digging in the browser's source code. I think my favourite bug to diagnose manifested as a visual issue with menus in a frontend framework. The menus were styled with some CSS, nested inside a media query:
These styles were only supposed to apply on desktop devices with a mouse pointer capable of hovering over HTML elements. The rules seemed to apply on some OnePlus devices though, with just a touch screen as an input device.Getting to the bottom of this involved creating a test page to reproduce the problem, reproducing it in multiple browsers, digging into Firefox for Android's source code (yay FOSS) to find out how it implemented the media query, writing an Android app to reproduce the underlying data problem and eventually working out that it was a problem in the phone's operating system.