There's one particular case where a look at a reference is warranted: when something doesn't behave as expected.
For example, the other day someone asked on stackoverflow why a particular Java class to calculate a difference between two dates was returning a weird result when they asked for the difference in days. Turns out, the class would calculate the difference in years AND months AND days, so if you asked for the difference between June 23 2018 and June 23 2019, the getDays method would return 0.
While this is something you would find in a tutorial on how to calculate a difference between dates in Java, it's much more expedited to just go and read the reference. Works wonders when you get inconsistent results in C for example, since you're probably invoking undefined behavior which is documented in the standard (i.e., the reference).
As a sort of counterpoint for this particular case, the documentation for that class didn't make how the class was meant to be used clear at all. But in the general case I think it applies.
I haven't worked with Java much, but have done enough to have a thorough dislike of its built-in date libs. Trying to parse dates, for example, "2019-01-40" is accepted, and actually returns February 9, 2019. I'm not aware of Any other date lib that would accept this. The behavior was certainly surprising to me. Only found out because my QA guy at the time tried it, was also surprised by the result and filed a bug against one of my releases of a web service. Closed it out as won't fix.
this complaint is almost as old as the Java language. you should use Jodatime if you can't upgrade to Java 8+ yet -- see https://www.joda.org/joda-time/
It also reminds of a quirk in DB2. I'm not sure if this is still the case, but in versions 6 and 7 circa 2003, '2019-06-24T24:00:00' and '2019-06-25T00:00:00' would never compare equal, yet they are the exact same point in time, excepting some rare leap seconds.
JavaScript on Chrome and Firefox will accept days up to 31, regardless of month--'9/31/2019' will be October 1. On the other hand, IE 11 really doesn't care how big the day is--100, 1000, it's all good. "new Date('6/1000/2019') is Feb 24 2022 as far as IE 11 is concerned.
wow - replace 'java' with 'mysql' and you've got one those decades-old go-to arguments against mysql. Except... the anti-mysql crowd would always point to it with the implication that somehow it was the only "wrong" behavior in the computing universe. I had no idea Java behaved that way too.
The problem with webdev is that JS has a lot less "standard" than other languages like Java, so a lot of times people either reinvent the wheel or import some package to deal with things that would be standard in a language like Java, and they implement things their own way.
The other problem is that you're not really fighting JS or CSS or HTML per se, but a browser implementation of interpreters for that. And you don't really have a say in the matter, because you're not picking what browsers are using your webapp, your users are. This is only really solvable using a combination of MDN, Stack Overflow, and Google-fu.
For example, the other day someone asked on stackoverflow why a particular Java class to calculate a difference between two dates was returning a weird result when they asked for the difference in days. Turns out, the class would calculate the difference in years AND months AND days, so if you asked for the difference between June 23 2018 and June 23 2019, the getDays method would return 0.
While this is something you would find in a tutorial on how to calculate a difference between dates in Java, it's much more expedited to just go and read the reference. Works wonders when you get inconsistent results in C for example, since you're probably invoking undefined behavior which is documented in the standard (i.e., the reference).
As a sort of counterpoint for this particular case, the documentation for that class didn't make how the class was meant to be used clear at all. But in the general case I think it applies.