One of the things I don't like about webdev (among many) is that I even have to Google in the first place. Manpages are so much more immediate and accessible.
I also think that anything js-adjacent has a real culture problem. Trying to dredge an answer out of a Medium tutorial written in a cloying tone and interspersed with pointless gifs can be such a groan enducing experience. I'm hoping that the community will mature alongside its technology.
Speaking as someone who writes blog posts littered with irrelevant pictures (but never on Medium!), I acknowledge your experience trying to solve a problem based on a blog post.
Manpages and documentation are written to be references. Blog posts are written to be tutorials. They have different affordances, and as a result it is very hard to learn how to use something purely from a reference, and very different to solve a problem purely from a tutorial.
That’s why really decent reference sites have both step by-step tutorials AND references designed to answer questions quickly and to be easily searchable.
If there is an opportunity here, it is for search to understand the difference and know how to present the two kinds of results differently.
That way, if you question is, “How does this thing work?” You should get tutorials. If your question is much more specific, like “what parameters does this take?” You should get a reference.
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.
What is nearly always missing is some sort of overview that explains you which parts are there, what are they good for, and how they work together.
Either these are very rare, or there are hard to google because they are drowned out by the many tutorials.
When you follow a tutorial, you are shown a very specific way of doing things (which often isn't up to date, with no indication that in the meantime this way has been replaced by another way).
And while that's very helpful for a beginner, it isn't as helpful for an experienced programmer, especially if he or she is having a problem that needs a slightly different way of doing things, and the missing information is just "instead of X, you can also do Y here".
And references don't answer these questions, unless you work through them from top to bottom (which usually takes more time than you have).
For js and js-adjacent technologies or libraries, there sometimes aren't any references to speak of, unfortunately. You're supposed to divine the information you need from task-oriented texts and code snippets.
When I work with most stuff that isn't web dev, life is good. I can figure most stuff out painlessly. It's mostly feels like working on a space that has been designed and documented by someone sane.
When I'm forced to do Web dev type stuff... I want to jump off the roof. It always makes me question my life choices that led to me being exposed to js. I hate it, it's a logically incoherent disaster that feels like its been deigned by people who are all just winging it and sorely lacking a good CS degree. It all just feels immature and feels like it's a field trying to develop methadologies while ignoring lessons of the past and as a result making mistakes they shouldn't be.
Once you get into this npm / node nonsense it feels like proper wild west madness.
I'm sure it will mature some day. I'll probably be retired by then though. Then again maybe the entire eco system is doomed to a future of just constant nonsensical churn and the solution is just therapy or install nets on the tall buildings to catch devs, who after spending another day hating js, decide to junp off the roof!
Another problem is I don't see many Web developers wanting to learn when they encounter something they don't understand, instead they just want some code they can copy and paste that had the illusion of solving their problem. Understanding be damned. Or even better a library, and hey if it has a million dependencies... Well.. That's life right?
Someone is speaking the truth here. But we (as a web dev I'll try to speak for us) are learning: React and Vue (and all the other great libraries) use optimized vdoms, React teaches functional programming paradigms with immutable data structures (redux) and we've already learnt from Ember what components we'll need in a project.
Most people will simply follow blindly. After the base stops moving (breaking changes in the APIs - Vue is currently doing the last big ones), we will write the best practices. Every half-decently educated developer already understands that those ideas are not new. They are the same ones they've already had in the 60s.
They will try to do it better - maybe they really are more clever, right? - but after the third or fourth try they'll understand that their own half-baked solution doesn't stand a chance. And then they will realize that life is too short to lose some data because your file-based DB implementation isn't ACID.
Look, Sturgeon's Revelation is that "90% of everything s CRUD." That's true of almost every technology I've encountered in 45 years of programming.
It's especially true when you lower the bar to entry. There's lots of CRUD because anybody can make something. It also means there are lots of things.
If you want well-documented stuff, vote for it by not using things that are poorly documented. Or figure it out and write the documentation. That's how open source works (or doesn't work), and JS/Webdev is not unique in this regard.
Microcomputers were poorly documented way back in the 70s. I'll be there were people complaining how shoddy they were on that basis, but that low barrier to entry led directly to us having this discussion on Hacker News today.
Of course you will, as do I. But it's no good moaning about the fact that they let just about anybody buy a computer and write software.
That's literally why we're all here, because they let anybody buy a computer and write software, even people who can't be bothered to write documentation, or people who are too busy optimizing advertising click-through to give us good search results from a web browser.
My thesis is that this is not limited to JS and WebDev, it's everything! It's just very visible with JS and WebDev.
If there's anything in particular to focus on, I'd focus on package management. You pick something that seems well-documented, and next thing you know you have dozens or hundreds of other things baked into your app.
If you go off the beaten path and need to break the abstraction of the thing you chose, you find yourself wrestling with the things that author chose.
This doesn't change the fact that irrelevant pictures (like memes and cheap popcultural references) belong neither in references nor blogposts, they're just a waste of time and bandwidth.
Tone is a different matter, tutorials sure can be more lighthearted. But I'd still take a dry tutorial instead of forced, stillborn humor any day. (I'm not sure if the latter kind is all that common in the wild, could be an illusion of frequency on my part).
As an author, that’s my decision to make about my blog posts. My choice of pictures belong in my blog posts, much as my choice of chords belong in my musical compositions.
It’s a perfectly valid choice to write essays that are hyper-focused on just teaching the facts as efficiently as possible, but that isn’t some kind of universal rule that must be applied to all essays.
I personally don’t care for the popular “American Folksy” style of essay that is heavy on the author’s journey to learn the thing it purports to teach, but I wouldn’t dictate that nobody should write in that style.
There are no gatekeepers to writing words, just as there are no gatekeepers to writing code. That has its benefits, aand its hazards.
This seems orthogonal to the complaint: the person you are responding to is assuming you aren't just doing this because you think it is a worthy art form for your audience of people who enjoy it, but that you are attempting to write something that provides strong value to the reader. You are welcome to write whatever you want, but you are fooling yourself if you think it is helping. If you want a music analogy, you are welcome to make a movie score that has loud and clear lyrics while actors are talking... but I would still say to you that lyrics "have no place" in a movie score during a dialog scene--the audience is trying (and now failing) to hear the dialogue--even if there are some people who seem to enjoy that. So: you are welcome to write those tutorials in that style if you personally must--no one is saying they should be banned and censored and deleted from the web--and also you really should know that you are actively making a decision to be less useful.
"Useful" is very much context-dependent. A post that does not catch the reader's attention is not useful. If you write in a style that is indistinguishable from a thousand other authors writing about the same topic, your writing is equally useless.
It is a mistake to think that an "audience" is one uniform set of people with identical needs, tastes, and interests. And therefore it is a mistake to suggest that there is something inherently "less useful" about one style of writing over another.
Less useful for whom? Under what circumstances?
I agree 100% that if you define your audience as "person trying to solve a problem and googling for help," my writing is terribly useless.
But I don't write for that person under those circumstances, and I assure you that the pictures in my blog posts do not bleed over to obscure any of the text.
I personally think that analogy doesn't really fit. A different take might be to consider Raymond Smullyan writing about combinatory logic.
If you just want to solve a homework problem, reading "To Mock a Mockingbird" is going to be an exercise in frustration. What's all this faffing about with birds and forests? Or locks and vaults?
Nevertheless, a great many people have found the book both useful and entertaining, which is a kind of useful in its own right. Smullyan also knew that there were other ways to write, and he wrote textbooks that eschewed the metaphors and entertainment while focusing on the utility.
---
I am not fooling myself that my writing is helping some people, some of the time. I know that it does, and I have the data to prove it. But, I am also not fooling myself that what I write is the best thing for all people under all circumstances.
I regularly endorse buying books like Eloquent JavaScript or You Don't Know JavaScript precisely because they are written in a manner that is useful in a different way than my own writing is useful.
But getting back to the subject of the post... I think that ultimately, search should be sure to highlight StackOverflow and MDN results or similar. Reference works designed to answer questions simply and directly are what you need when you're in the middle of a problem.
Blog posts serve a different purpose, such as motivating you to want to solve the problem in the first place.
>As an author, that’s my decision to make about my blog posts. My choice of pictures belong in my blog posts, much as my choice of chords belong in my musical compositions.
Of course, just like anyone's free to say "it's a generic 4:4 I–V–vi–IV pop song, nothing to write home about" or "it's yet another ISO standard blogpost, don't bother clicking through the popup". Though I think a better equivalent of a meme-laden blogpost would be a sea-shanty with changing time signatures and atonal riffs with a rabid scene kid at the vocals - kind of bizzare, kind of crass, fully useless for pulling a rope on a galleon.
>It’s a perfectly valid choice to write essays that are hyper-focused on just teaching the facts as efficiently as possible, but that isn’t some kind of universal rule that must be applied to all essays.
I wasn't arguing that every blogpost should be hyper-focused, just that it would be kind of nice if more people took the route of "uncreative but solid" rather than "trying to create an illusion of creativity with randomness".
> "trying to create an illusion of creativity with randomness"
I doubt that's why authors use this technique, though. I think it's part humble-brag ("hey I'm so smart I don't take complexity seriously!") and part an expression of nervousness ("it's scary to write things and publish on the internet, because haters"). A less serious style also allows you to take criticism more easily, perhaps.
That's an explanation, not an excuse! I like dense, solid prose more.
Hmm you're right, on a related note patching holes in my understanding of a topic with "distance" and sarcasm is something I'm personally guilty of. I'm grateful of HN for being much less conductive for that style than, say, Reddit.
I think a better equivalent of a meme-laden blogpost would be a sea-shanty with changing time signatures and atonal riffs with a rabid scene kid at the vocals - kind of bizzare, kind of crass, fully useless for pulling a rope on a galleon.
To my great delight, this phrase illustrates the value of writing with feeling and metaphor. It captures my imagination and motivates me to think about your argument carefully.
I've never argued that metaphors make for worse technical writing. It's just that you've started the discussion defending putting random pics into a blog post, and now you're trying to paint opposition to these as an opposition to creative technical writing (vide the sibling post about Raymond Smullyan). I think we might be in a violent agreement here, actually.
Why don't they belong in blog posts? They belong anywhere the author had made the creative decision to include them, and if you don't like it, that's fine, but if the author wants to use their time and bandwidth in the article to post irrelevant memes then that's their call. To you it might be a waste of time, but in general people can and should do whatever they want.
> If there is an opportunity here, it is for search to understand the difference and know how to present the two kinds of results differently.
Tag documents into categories (using ML diceroll, up to one category per document), with a strong bias towards "none" when in doubt. When a search term's results include some categories more frequently than the global average, offer them as filters.
Would its utility survive the resulting wave of SEO innovations?
> One of the things I don't like about webdev (among many) is that I even have to Google in the first place. Manpages are so much more immediate and accessible.
I don't really get this response. First there's the notion that "webdev" is the discipline where information is so fractured that you need to go googling around to figure out how to do everything. All the other disciplines have a magic thing called a man page that just gives you the answers. This is obviously not true, right?
The second thing is the idea that a man page for any one component, or even a set of components, could possibly contain enough information to allow you to build a complex system without consulting the experience of peers, colleagues and past practitioners, which is at least what we intend to do when we search google.
> All the other disciplines have a magic thing called a man page that just gives you the answers. This is obviously not true, right?
It is true to some extent. The less dependencies you have the less you need Google. Have thousands of dependencies in node? You will likely google their different error messages a lot. Write low level C libraries where not having dependencies is a key feature? Then Google wont help you much at all, the few times I try I almost never find anything useful for my work.
So the thing about web dev is that you automatically have all browsers as dependencies, not to mention all the libraries, frameworks and api's people are using in modern webdev workflows. Most other fields tend to have much simpler dependencies than that.
Reading web specs at least once will save you a lot of time. You don’t need to memorize the things, but it helps learning about capabilities that are easy to miss and keywords that’s make searching far more efficient.
Man pages rarely are enough in my experience. When I encounter an issue with grub-install not writing to my EFI system partition, good luck finding much about it in its very short man page. You’ll have better luck using the ArchWiki, which is like a much better man page, but a simple Google search (or another search engine) will show a forum post with an easy solution as the very first result.
Piping six man pages through grep to find what I’m looking for is simply not as fast as Googling an error message.
I think there’s also a sort of cultural difference between languages and tools frequented by newer and older programmers: more experienced people look for documentation and then get working on their project, whereas less experienced programmers look for tutorials and very specific “soft” documentation.
Transitioning from modifying tutorials (the type-in-the-code-in-the-magazine of the 21st century) to glancing at the documentation is probably the surest sign of maturity. Still, you can get a ton done by copypasta.
This might have to do with learning to code with or without the Internet, I’m not sure. I’m personally very envious of people who can take a look at the docs and just get chopping without the assistance of the GIF-covered Medium posts.
> When I encounter an issue with grub-install not writing to my EFI system partition, good luck finding much about it in its very short man page
This says more about the man pages for grub2 (and grub2 itself, to be honest) EDIT: than about manpages /EDIT.
Compare them with the man pages for grub1. There's a sea of difference.
If you really want to be blown away by a manpage, look for the one for mplayer, which is difficult to find information in for different reasons, i.e., lots of options and lots of options and flags that depend on other flags and options.
Yet another reason to prefer the BSD family of OSes over the GNU/Linux family.
In the BSDs, self-contained, complete, and correct documentation is a cultural value. Not one that’s always achieved, but a value nonetheless. Information missing from the man pages is a reportable bug.
And if the man page doesn’t document something, its code is right there in /usr/src for you to dig into.
Agreed. Even in Linux, complete documentation for userland tools is usually a given.
Not so with webdev. That said, the source code is there for all of us to read. I'm a frontend developer and spend more time looking at source code when I need to figure out an issue than digging through Medium posts. Particularly when something is behaving in an unexpected manner.
I'd urge everyone who hates webdev to try this approach the next time they struggle with an issue. JavaScript, for all its sins, is fairly easy to read. And once you've understood the ~30 most common gotchas in JS, reading the source is highly beneficial (and here's a good intro to those gotchas, including an accompanying video: https://github.com/denysdovhan/wtfjs)
Or better yet, work in one of the statically-typed compile-to-JS languages such as Typescript, ReasonML, Elm, ScalaJS, or Purescript and worry about those gotchas much less (and only when wrapping external libraries).
I find manpages to be mostly useless because they ignore the common case to explain every single possible function. For example I use the tar command 99% of the time for extracting files and 1% of the time compressing files. When I open the manual I want to be able to quickly work out how to extract a file but the first bit of non intro text on the man page is
>Options to GNU tar can be given in three different styles. In traditional style, the first argument is a cluster of option letters and all subsequent arguments supply arguments to those options that require them. The arguments are read in the same order as the option letters. Any command line words that remain after all options has been processed are treated as non-optional arguments: file or archive member names. For example, the c option requires creating the archive, the v option requests the verbose operation, and the f option takes an argument that sets the name of the archive to operate upon. The following command, written in the traditional style, instructs tar to store all files from the directory /etc into the archive file etc.tar verbosely listing the files being archived:
Scanning through the manpage a fair way down and I can't see the one bit info that covers almost all of my use cases for tar.
And for anything more complex than a tiny cli tool the manpage is far too large to use usefully.
but there is a dozen ways to compress files, and only one way to extract them (for each compression format). i need the tar manpage much more when i compress, and rarely when i decompress.
I’d honestly love to know what people are comparing to javascript when they complain about rate of change / having to learn, unless it’s just a mental bias on learning something new vs something they’re comfortable with. I’m in a new position working on python and spring APIs and it’s effectively the same deal — researching means filtering through bitrotted methods and advice over a 4-5 year period, new methods & libraries or api usage patterns, etc.
Anyone could divine some reasons for why javascript / “web dev” is so different but I’m seeing shades of the same thing mixed with personal biases towards trade offs and design decisions.
I've been programming mostly in Java for 20 years, and in the past whenever I picked up web development it always felt like a kludge. JavaScript was inferior to Java, CSS was frustratingly difficulty to lay out components, and HTML forced me to treat my application like a printable document. Tools and libraries weren't as efficient or robust. Then I had to test on 5 different OS/browser combinations and implement ugly workarounds to fix the inevitable discrepancies between platforms.
Recently I've been developing in Flutter/Dart, and it's so enjoyable. The Dart language is an improvement on Java, the Flutter documentation and online support is great, apps look and behave the same on different devices, the API and underlying code is well designed. Plus the tooling and IDE integration is first-class.
In general it seems like most native C++ software has far fewer external dependencies than JS software does. Not zero, of course, but culturally people are much more reticent to take a third-party dependency than they are with JS.
Perhaps this is because it is just so much less of a hassle to do so in a world with things like NPM.
This is what I’m talking about with this argument being a proxy against learning vs a legitimate difference. I just replaced a big chunk of a 20 year old C system this year. There was nothing even researchable in there because the vast majority was homegrown, or libraries were pulled in and source-modified after going stagnant on the 20 year journey. Same exact symptoms I’ve seen in every other ecosystem.
What you're mentioning is all just a side effect of something being extremely accessible. Webdev is very easy to start and get into, but on the deep end, it's just as deep and difficult as coding a backend of your application in Java or Go.
You don't have to search the internet for web dev any more than you have to do so for any other dev job.
Man page: find the man page, search for terms you hope might be related to what you want, read through a lot of dense paragraphs to maybe find something relevant.
Google: just type in a quick description of your issue and get a stackoverflow post with an answer as the first result.
For me the issue is not really whether I access the docs through `man` or through the browser. It’s comprehensive, accurate docs provided in one place by the vendor of the tool I’m using, versus wading through a crowdsourced resource like SO which might be incomplete, out of date, or inaccurate.
If a library vendor provides good docs on their website, that’s just as good as man pages, but in my experience they usually don’t.
There is a staggering amount of misinformation or non-existent information on Stack Overflow. For one simple example: try to figure out how to use the GPS on iPhone. It’s simply impossible. 99% of people on SO think “GPS” is synonymous with “Location APIs” in general. Of the 1% of people who understand the several different data sources used by CoreLocation, nobody can tell you which accuracy settings will cause it to use GPS specifically. If you bother asking, you’ll get a bunch of “middle-brow dismissals” asking why you want to know such a thing, telling you to just use whatever accuracy setting you semantically need, smugly claiming you’re guilty of posing an A-B question, and so on. This is the type of dead simple basic information I would have expected to be present in Apple’s documentation, instead of having to crowdsource it from internet trolls.
Stack Overflow has a problem of outdated answers written ten years ago by people wanting to collect experience points.
Technology moves on and those early answers are simply no good. Recently I decided to learn a few things from first principles - reading the specs. If I then try to put a half decent answer on SO then it will be answer 97, 3563 upvotes behind the 'right answer'.
New person who comes along isn't going to get to my detailed answer on page 5, the one that points out how technology has moved on and why the winning answers are not what you needed. They just need to deliver the deliverables and the first answer will suffice. They will take it and add another plus to the upvotes.
You can't win, the odds are stacked in favour of the mediocre. This wasn't always the way with Stack Overflow, in fact it replaced forums where the same problem existed but only to stall the nonsense for a few years, we are back to peak nonsense again.
I think time is ripe for Stack Overflow to be usurped, nothing against the site which I have so loved over the years, but even mySpace had to be replaced by Facebook.
Stack overflow doesn't need to be replaced they just need to find a way of filtering out answers that are no good anymore which is actually a bit of a hard task because many ancient answers about vim and git are still perfectly valid.
Maybe some kind of super downvote for outdated questions that is strictly moderated so it isn't abused.
I completely agree that this is a serious problem. But I’m not sure how it could be solved, and I still think vendors providing docs, and easily readable source code for when the docs fail, is a necessary complement to any crowd-sourced model, be it forums, SO, or anything you might imagine replacing SO with.
This is basically never been the case for me. Once or twice I got an answer that suggested a deprecated API call, which I could then just google the replacement for and use that. I don't have any complaint about StackOverflow personally.
If you are on the bleeding edge of the new shiny then you won't have this problem that I am seeing. But the guy supporting your code in five years time might.
To some extent the problem depends on how new and shiny your stuff is.
Do you personally have recs for how to parse manpages? In my experience, I've found them far more difficult to grok than e.g. the MDN JavaScript docs. Particularly if I'm trying to look up a tool that I don't already have familiarity with, as opposed to e.g. just trying to look up the correct syntax for a flag.
Yeah, manpages feel like the equivalent of being served a book on a subject where I just want to know a quick incantation. Like reading the entire wikipedia entry on cats just to settle a dispute on how many toes they have (18 btw).
I think manpages are a popular thing to worship here for nerd points but people don't use them nearly as much as they say they do because nobody actually wants to read a manual when they are trying to Get Things Done. Also, some things are just incredibly hard to figure out, like ffmpeg arguments.
> Yeah, manpages feel like the equivalent of being served a book on a subject where I just want to know a quick incantation.
Because manpages are from a time when reading the manual was expected behavior, searching for a quick incantation more often than not results in learned helplessness because you don't actually learn anything, just the specific spell for the specific situation.
I'm as guilty as anyone of trying to solve the immediate problem with a magic spell at times, but bropages embrace this willful ignorance.
not to make fun of my old roommate, but I had to give him line by line instructions for him to use a scientific calculator, which he dutifully copied, instead of taking the time to learn calculator principles. know your tools.
Except for being an online resource, the MDN docs are much more like man pages than what the parent is talking about.
Btw if you find the MDN search unsatisfactory (as I do) try mdn.io/search term. It's just a proxy for site:developer.mozilla.org search term + I'm Feeling Lucky.
The MDN is a pretty good reference complete with availability tables for browsers.
The problem with a reference is that a lot of times browsers do quirky things and things that are essentially browser-specific bugs aren’t documented in a reference.
(I'm aware that Polymer insists it isn't a 'framework'. But it is. If their breaking changes cause incompatibilities between components using different Polymer versions, that's what I call a 'framework'.)
This really just isn't true about the javascript scene anymore, and hasn't been for a little while now. React and Angular alone make up the vast majority of framework usage and they've been out for years.
Honestly, a lot of javascript criticism I see nowadays is a little outdated.
A big part of it is that imho technology has gotten more powerful, but still no easy to use. Like, I'm imagining in 20 years the API for Amazon's drone fleet will be here and we'll still be like "wait, the address parameter is for an IP address? And the library isn't thread-safe but also doesn't connection pool so I have to maintain one dronecloud client per thread? And what's this cryptic "rotor invert" error?
It feels like half my job is googling how to do common things in popular libraries and finding completely counter-intuitive pain-points.
A great example of this is AWS. I'm not a power user but I dabble. You have to go back and forth through user docs that all have some % of the correct steps, but no single doc has all of the correct steps. Some reference deprecated api, some just never seemed to work in the first place and you wonder how it even got there.
I get that these ecosystems evolve over time but I'm not convinced that that evolution requires inability to use the underlying features effectively.
Oh I can relate to this a lot as well, it is really hard to get some services on AWS working together. There is documentation but its always not enough. I find stackoverflow + trial and error the best way to resolve issues but it is quite a painful dev experience
Hah! Worse is over a day you open a dozen or so pages about a topic lets say SES and scan through them then later youre back to looking for some thing which you know exists on one of the pages and now you have to trawl over everything again trying to find it seemingly at random.
It's like you need to keep an index of things in your head when reading AWS docs as you know the information is dispersed across multiple different places.
Using search engines sometimes feel like a lost art if you spend any time in Facebook groups, where people will ask mundande, simple, and easily Googleable questions.
Sometimes I wonder if people do it to fill some sort of social need, and don't particularly care for the answer.
HN seriously overestimates the technical capabilities of the average person.
Facebook now has enough reach that it includes many people who don't know how to use technology properly. Finding an answer through Google takes a little bit of skill to frame the question and pick the result that will give you the answer.
Roughly 70% of adult Americans use Facebook [1]. This study [2] is from 2015, but it says that only a third of America adults are capable of medium-difficulty technical tasks, such as tasks where you need to '[evaluate] the relevance of a set of items to discard distractors'.
Remember, 20% of American adults have below basic or no literacy skills [3], which means they are not capable of tasks such as:
- "using a television guide to find out what programs are on at a specific time"
- "comparing the ticket prices for two events" [4]
How is googling something not the lazy option though? Personally, I think it's far more work to ask someone and wait for the answer over immediately getting the answer from searching and finding a 4 year old forum post with the same question.
Tell that to my dad. He just picks up the phone and asks me why the printer is not working. On an OS I don't even know how to use, for that matter.
Also remember, I can find a vastly greater breath of information cause I can search in English. He can't. Now that I think of it, this may even be a counterpoint to "just Google it".
Don't worry, my parents still call me for things like that, and they don't even have the excuse of being non-english speakers. I will say, if you have the time, set your folks up with something like Linux mint: my step-dad somehow mahaged to get malware on a Mac, and it's much easier for me to keep an identical Mint VM around so I can walk him through everything screen-by-screen. Honestly, setting up their new printer was harder on my mom's Win10 machine, which greatly surprised me.
Asking someone skips the tedious work of filtering applicable solutions from 20+ years of forum posts, memes and SEO shitfarms in exchange for an actual-but-delayed answer.
As I get older I have less time or patience for it myself. The effort required increases with the amount of content available on the internet. Some people just aren't good at research in the first place.
Important to note that most of us have had years of practice searching for stuff online, and we're very good at identifying this garbage. You can't reasonably expect someone to just hop on to Google and know what to type, which links/sites to avoid, how to spot trolling, and so on.
Before the age of the internet, when someone didn’t know something they would first ask their family or friends for the meaning and if nobody would know or weren’t really sure, they then would open the encyclopedia, or move on to the next thing. It feels more naturels to ask someone first than googling for it, maybe it’s the social aspect of humans, but it could also be laziness, but googling things is definitely a skill that can be improved upon
I can be both. I arrested myself typing out a “let me google that for you” reply on a small social network years ago. I realized doing that stops a conversation dead in its tracks. And sometimes people just want to have a conversation.
Imagine never meeting a wife because you used a self-checkout, pumped your own gas, drove a car instead of taking an Uber, read a FAQ instead of calling customer support, watched TV instead attending local theater, played Minesweeper instead of Fortnite, or commented on Hacker News instead of going speed-dating.
In some cases they may feel it's whether they are asking the right question - but I agree that people searching for themselves is often a better practice
Many times I've asked google a specific question and only got results in the form of "Top 10 vaguely related unhelpful bullshit" clickbait. So yeah, actually, it is a lot like a really big version of my own nigh-useless human memory.
The other times you get stack overflow or github repos with licenses that are typically not friendly to your project
For example, how many code bases have things ripped straight from StackOverflow in their code? Are any of them attributing the author based on CC-sharealike license? Nope.
How many snippets from GPL code has been used because it was found in GitHub?
So asking google is great, but it could very well taint your code. The next question is if this ticking time bomb will explode now or later
So many people missed the point of this post that I ended up replying to it instead of them.
"Memory upgrade" means not relying entirely on your own memory and previous knowledge. That doesn't exclude internalizing the language, nor coming up with new solutions. It probably changes a lot depending on what you do, but I've found it imperative to keep up to date with an ever-changing engine, and it would have been malpractice to just rely on memory, and a great waste of my employer's time.
Not entirely related but I think its a good practice.
Anytime I learn something new, I create a simple project using that new thing as a way to memorize it better but also be able after few years revisit it and either remind myself about it or improve it.
Since one's brain is not able to translate a thought into a search engine query which leads straight to the answer, that virtual memory analogy doesn't work at all.
No one said it’s not still valuable, but less so on it’s own with the advent of the internet and Google. The same thing can be said with taking notes in school: you’re less effective using human memory alone without the augment of note taking.
Yes, you need both. I think it's even more important today with the massive amount of information that's available. And in addition you need the skill to look up stuff.
I agree; human memory is good at keeping indexes, which is augmented by the internet to retrieve the full content. You only need to store enough in your mind to know what to Google for. Memorization as a skill is less valuable now than it used to be.
I've been thinking about this topic a few months ago when considering how I go about finding out information on how various things are implemented in the Linux kernel, as someone that's not a kernel developer:
* option A is that I start by reviewing the literature (most books are quite old, but I might get lucky) to get a general idea about the topic e.g. memory management under memory pressure. Then I search the kernel docs. Then I use any references that I found to e.g. LWN or similar websites. Message groups search. Finally I would do general internet search, SO, etc. In between these steps I might look at sources, although that's hit or miss, depending on the specific topic.
At the end of this adventure, I will probably have a vague or middling understanding of what I was looking for.
* option B is that I ask our kernel expert and he tells me what I want to know, because he's continuously read all of the above resources for the past couple of decades.
So not only is the human memory not obsolete, it is daft to think that Google - which is getting amnesia to boot - could "upgrade" it.
Most of the value you create is done by your subconscious and it can't just google things, so getting things into your head is still required and the more you have there the better.
Software is not so complicated that you have to Google search everything every time. If you are not internalizing new knowledge, you are performing poorly.
There is definitely a point in a framework with strong structure where it becomes easier to read the code than google the problem. But if you aren't working on a single codebase for a while you are definitely better off with google on your side.
Some frameworks are written in a way that makes reading the code a pain in the ass too, with generation, magic methods, annotations and other meta coding techniques that turn conventions into code. In those cases even if you have a really niche problem google may still be faster than delving into the dark depths of non-code.
I am a good back-end developer, I'm good at Googling things.
The things I tend to be Googling are typically either superficial, like syntax, or specific as in I know exactly what I want, how do I construct it in x language or y framework? It's quite rare that I have a problem and don't know how to approach it and they're the most fun. Sadly, it's also rare to need to look for algorithms. Just avoiding the run-of-the-mill complexity problems using common patterns or data-structures is sufficient. When they're not (e.g. performance or scale constraints), also fun times.
What do you do about license tainting in your code base? Stack overflow provides all of its answers under a Creative Commons license. An example may have been lifted from a GPL source, do you care that you have contributed this to your community project or corporate employers code? If the answer is no, then why care if you google or not
I'm not sure you can licence how to do x in language or y with framework in a license as the code is not being copy/pasted but rather used as documentation on how to do things.
I worked at a place where I was working on a feature that had to integrate with some code that a consulting group had developed for us. As I looked at their code, I knew that it had been developed by a single developer in their group, but it was odd in how completely disjointed the code was... even in individual source files; it was like it was developed by a team that didn't talk or plan together: no consistency in naming, functional boundaries, code style, etc.
This had raised some red flags for me... so I took some snippets and googled them. Sure enough, the code was largely an assembly of cut/paste code units from various blogs, Stack Overflow, etc. that had been glued together with only small changes made to get the disparate bits to talk to each other.
The applications we were building were IP sensitive and the developer and consulting group had represented this as original work. No indication of where the code originated came in any form or communication. Truth is that enough of this copied code was sufficiently verbatim that there would have been no question as to copyright ownership (not us or the consulting group) and with many questions regarding as to if we had copyleft license terms, permissive terms... or had no license at all to use the works.
Naturally this led to much unhappiness on our part and had both sides going for their contract terms. It also didn't help that our company's products were substantially business legal services and close to half of the employees at that time were attorneys.
This isn't to say we didn't use many of the same resources in our internally developed code: but we did so as you suggested... as documentation and knowledge sharing. We also were fairly scrupulous about stating where ideas and techniques we learned this way originated via code comments including links to the source we relied on.
This is one thing that I make sure to tell any new developer. Don’t be embarrassed to google things. Understanding how to figure out the best way to solve the problem is the objective, not showing everyone that you’ve got all your tools memorized perfectly.
We have close to the summation of human knowledge at our fingertips. Why would we be embarrassed to harness that power?
I want to question this.
Sure there are many things where a google search brings up a better solution than the own spontaneous one (for example path finding algorithms for games).
But every problem beyond a trivial ‘getting started’ needs more thought than an algorithm one can copy and paste from google. Even if it’s only the glue code to bring all parts together or transferring the knowledge to the problem trying to solve.
Also what others already mentioned about noisy search results: Deciding which of the (hundreds of) possible solutions might bring the desired outcome is an engineering skill.
Another thing: When googling the same issue for the third time one should question why he has not memorized it by now (e.g. syntax of commonly used bash commandos etc.). And by internalizing one gets better as engineer every day without relying on google.
Yeah for some reason software engineers love self depreciation. It's like we've internalized management's desire to make us low status cogs
Doctors google things, captial E Engineers google things, chefs google things, everyone googles things. Yet you don't hear them talking like this to the extent we do.
Like you said it's knowing what to type into Google, knowing how to filter the results, and knowing how to apply the information you that's the hard part.
for getting started guides, it's great, although even there i'd exercise a lot of caution. there's a lot of info from people who are not experience that people just replicate in their code/setup which isn't really a good idea.
for complex issues you never drown in information. and usually when you find something it probably doesn't apply to your setup. that doesn't mean you can't, at least, get some idea or a pointer to the right solution.
however, just googling or stackoverflowing, i'd be wary of implementing any solution without any thought just because someone else solved it before me.
There are tons of getting started guides for everything but beyond that, one will find a wasteland of information most of the time or it is scattered around in different locations. So in this case the engineer is working hard to figure out which pieces of the puzzle belong in which place. Not to mention that nobody knows how the finished puzzle has to look like.
This is not just for webdev roles. We used to joke about this in my sysadmin days - when hiring new staff, the only test should be how effectively they could Google for a particular solution. And in all seriousness, understanding how Google works and how to use the search operators effectively, is a crucial skill in an IT career.
Edit: relevant XKCD - https://xkcd.com/979/
(and the only thing worse than that comic, is finding someone who had the same problem as you and they followed up with a simple "I solved this" with no additional details!)
Rate of change is the biggest driver for this, at least for me. It's rare that I'm covering the same territory twice, so it's novel research all the time.
That said, the search output wouldn't be of any use without being able to relate it to past experience and accepted practices.
This has not been my experience. I never take notes, almost never go to StackOverflow, and can find anything I don't know from MDN and W3 docs. Maybe it's because the things I work on are really simple, but I like to think it's because I've developed a deep enough understanding of JS/React/Redux and design my code in such a way that I'm easily able to reason through any task and resolve any bug.
This. Op has either been very, very lucky in his tenure -- or, he has never had to build a site with compatibility requirements targeting >= IE9, Blackberry's browser, or Safari iOS (which is basically mobile IE).
I feel that over the years of doing things related to web development I actually have to Google less.
Frameworks change, idioms change, but the web itself has largely remained stable (it's still HTTP, even if we now sometimes use HTTP/2). The same security concepts apply.
I feel like I can authoratively answer on more subjects than I could 10 years ago.
Maybe this is mostly related to front-end frameworks? We've only really had one big shakeup in the backend and that's that for the past decade or so we've all moved towards preferring async code (yay Python3k).
I would agree. Frontend ecosystems and idioms have changed frequently, each time adding a new layer of concepts. Backend architecture has progressed but the concepts are pretty stable. Caching, authentication, roles, models, interpolated templates and so on. Same toolkit but more refined.
I think it's like a chemist needing to reference the periodic table less as they inherently memorize more of it. That's not the hard part of chemistry. Looking up call signatures, APIs and common patterns is not the hard part of software development.
I'm a college professor. I try to teach my students enough that they know what to Google, and that they can understand and use the result. I can't teach nearly everything they might need in the future, but I can give them the foundation.
Of course. Even MDs, despite all their years of study don't have all the procedures and possible diagnoses in their heads all the time and need to read literature and consult with other physicians to reach conclusions.
I'm not sure why people think software development (and computers in general) is somehow different. We don't know everything. We basically can't.
What we (and all other professions) have is knowledge on how to apply new information to what we already know.
So yes, you're right. You have to teach the basics, how to put them together and how to add new pieces once you inevitably hit something you don't know.
I allergic to Amoxicillin and always get irritated looks when I tell this a doctor. They usually have to search for an alternative in books, because they don't know them from the top of their heads.
This is also partly why specialists exist. An infectious disease DO/MD would know both what the alternative would be and possibly even the appropriate dose calculation off the top of their head because antibiotic management is their bread and butter.
If the physician you were at felt unable to make the right call, he could have referred you to or consulted with someone who could. An 'irritated look' might instead be a flurry of such treatment paths going through their mind.
'Can I figure this out on my own? Should I consult? Should I refer out? Should I just check UpToDate? What does the latest literature I read say to do? What was done for the last patient who had this? Has the literature changed since then? What is the hospital policy on this (if any?)? What did my microbiology class say to do for this? What do the boards think is right to do in this instance?'
I wonder if the irritated look isn't from "damn, the thing I know from experience works well won't work for this patient" rather than "damn, now I have to crack open a book".
Consulting with other specialists or reading specialist literature is in a wholly different class of information quality compared to using a search engine.
The problem is there is too much noise in Google. Its highly unlikely you can google your way to being a competent software designer
I think relying on Google, at least in the initial days of development is bad. I rather developers struggle their way through relevant documentation than google.
I agree, and often wish there was a central repository of collected tribal knowledge not about how to do things but about to do them right. Google's resources for developers provide a bit if this, but not nearly enough.
Yes exactly.
The future of schools will have to integrate "knowing how to find something quickly and efficiently"
into it's core along side "doubt anything you find online".
I know folks who've gotten pushback from clients of "I'm not paying you to just Google things, fix my problem!"
My recommended response is "Nope, you're paying me to understand what's happening, look for possibly relevant information about why, understand what results are and are not relevant, and apply what I've looked up."
I'd rather they be searching in UpToDate.com, but one of the most important things in diagnosis is the ability to filter available information and determine relevance. If you have identifiable symptoms that don't fit with the "hoofbeats means a horse" common diagnosis then someone able to take that starting point and get other possibilities to evaluate is good to have.
This is my life. Apparently it is what sets me apart from most people; somehow I'm blessed with this ability to read things, highlight them, hit CTRL-C, open a web browser, hit CTRL-V, and hit enter. Most people, according to my empirical studies, are simply not capable of doing this...
I wish I was being snarky, but this is literally true
I think this guy wrote a great article. However I don’t know if I agree with his conclusion of him not being a good web developer.
I would bet that most great developers have googled often enough. In their defense googling is a more efficient tool than pouring through manpages all the time that have poor search indexes.
Also, in this developer’s blog, there is no reference to the fact that his code is buggy or less maintainable, or plethora of other reasons that categorically make him a bad developer.
I think it’s ok, to use help from google or stack overflow to do a good job at your task and that doesn’t make you a bad programmer.
I suspect Google Search can no longer function as well as it once did without being informed by everything Google knows about you (malicious use of SEO might very well be the reason). You could try fiddling with the privacy settings in your account, especially if you blocked anything (edit: or remove privacy protections from your web browser), and see if that makes it better. I just use DDG for most things these days.
Even with all the personalized knowledge Google has, often they still serve worse results than DDG. At this point, I think Google is relying far too much on their historical knowledge about me, since i almost always see results related to previous searches, which clutter the relevant results for my specific search string.
I have indeed asked this question to several candidates, yes. They were faced with a debugging challenge and some of them weren't sure what .repeat() (JavaScript) did/what the argument meant.
I literally said "What would google for?" and then proceeded to invite them to show me in a browser. It gave us a good impression of how good they are at finding answers to coding problems.
You might just be my new hero. I find it both sad (but also interesting) how little the current IT interview process actually has to do with what job candidates will do once they get the job, and predicting their performance.
There’s a lot of people commenting and supporting the author of the article and in his practice of googling and how normalized that is.
This leads me to a hypothesis. I would argue a large percentage of software developers are average, the bell curve for extremely brilliant engineers and extremely idiotic engineers must be be low for each end.
So what is considered average work?
I would working on mundane issues which involves a lot of googling. It would also reason that if you are googling a lot you aren’t doing anything that’s breakthrough or exciting since if the rate of your googling is high that would indicate that the problem you are solving is quite common.
There is a large difference between building things with React and learning how React works and trying to create your own.
I’m not sure why the “re-inventing the wheel” I dread the day we stop innovating and resign our career lives to “well someone else solved this problem so it must be the best solution - no need for me to innovate.”
Just do some work in a dead framework for a couple years and then you'll be good to go. Even something as recent as Ember has little to no information on places like StackOverflow for the last 3-4 years, so you actually have to look at docs and source code instead.
Love this article. THe programmer is honest and teaches us, some handy things.
The ability to work well with a good search-engine is vital, esp when you need to spew out good code.
Re-inventing the wheel is out.
Standing on the shoulders of giants is in, just like Isaac Newton did it centuries ago
So one of the things that the author should Google is “salesmanship“. Everybody uses Google as a reference, no shame in that. Everyone uses spell check also. But would you go into an interview and proclaim your a lousy typist dependent on spellcheck? Putting your full real name on a blog and announcing to the world that your a lousy developer, that is just as bad. Much like cops posting racists rants, people on disability pay posting their jet ski antics, and criminals showing off their latest score. I’m sure every one of those people thought it was a good idea at the time, but it’s not, and the internet never forgets. Author should also Google “MacGregor the brick layer”.
The interviewer who expects me to have every little detail about every single technology I've used in the past stacked up in my mind, won't be worth my time, not to mention joining their company. The comparison to spelling prowess is apples and...melons. Use your favorite search engine to look up "what is the difference between insight and information?"
There are absolutely people out there who expect that — and they are usually the ones who can’t figure out why they can’t find anyone to fill their position. A lot of times a manager won’t interview someone until their people have, and it’s those front line people that are always the worst because they are fresh out of college and just like school they expect you to answer random questions from memory, obscure questions to make sure you didn’t just study up, and if your % correct is too low then goodbye. A lot of times they are the gate keepers to otherwise good positions, so helps to be prepared for them. Once your hired you can go turn down the brightness on their monitors to mess with them.
I think this is true for most technical jobs. What makes us good is that we understand how to search, which leads us to the corners of the internet where other technically minded people seek help and answer questions.
I've seen friends and family search for errors or 'how do I...', and their searches mostly yield youtube videos and scraper sites. For me its mostly SE, reddit, and product specific forums.
Knowing how to ask the right questions and understanding jargon is often the greatest asset.
"The power of the unaided mind is greatly exaggerated. It is 'things' that make us smart, the cognitive artifacts that allow human beings to overcome the limitations of human memory and conscious reasoning." - Donald A. Norman, Things That Make Us Smart
Knowing how to find the answer is an often underestimated trait of successful developers.
When I interview someone I often ask them what they will do if I'm out-of-the-office, no other senior devs are around, and they need to find the answer to continue to be product - what do you do? You would be surprised how many times I hear 'wait for you to return', versus 'I'd fire up duck-duck-go or search stack overflow'.
There's nothing wrong with referencing documentation, but I do see it reasonable to look down on those who can't program without asking a malicious corporation questions. So, I pride myself on not needing to do this, I suppose.
Of course, I also pride myself on using good tools. My observation of Stack Overflow is that it's an excellent resource if you don't know what you're doing and don't want to learn what you're doing. Unfortunately, that's the only real way to operate some things. The only times I ever really need to use the Internet for such a problem is when it involves some baroque WWW nonsense some idiot caused however many years ago that's still echoing today or it involves some baroque UNIX nonsense some idiot caused however many years ago that's still echoing today.
If you use good languages and good tools, with real standards, (Common Lisp is an example.) you'll find yourself seemingly magically free from all of this stupid and pointless drudgery. Consider giving it a try some time. Imagine not needing to rewrite code constantly because something updated or some external ''API'' changed or other nonsense.
As a closing aside, it's laughable that people are pointing to man pages as examples of good documentation. GNU Info isn't perfect, but it's leagues better than man pages will ever be, if only because it's segmented and hypertextual.
it's true that in the current "move fast break everything" climate developer knowledge expires at an alarming rate and everything needs to be rechecked constantly trough internet sources to fix integration issues between ever changing libraries
it's also true that searching sources without a solid knowledge base derived from theory and practice quickly devolves into cargo-cult programming.
I too sometimes feel like my skill differential often comes only from being very fast at googling stuff, however this is a gross oversimplification on what happens after the specific knowledge piece is acquired: whether the solution is taken to solve the problem at hand or if it results in a change in one own understanding of the problem domain makes all the difference.
This just shows how shallow web programming is in intellectual content. If your expertise consists of stuff that can be looked up on the fly, all you need to join the field is a high enough IQ to comprehend those ideas at all. There’s no need for deep thinking or mastery.
In what other technical field can you simply google everything? And is that because other fields are merely more obscure, or because they’re actually harder? Could one be a mathematician or physicist by googling things?
As someone who works on math intensive back-end stuff, and routinely can't google things, I'll defend web-devs:
Most occupations are not intellectual in the slightest, nor do they require a high IQ. They do require other talents, though, such as a sense of aesthetics or technical ability, in this case.
Not being intellectually rigorous doesn't mean they don't require careful thought or mastery.
I could absolutely perform any of the individual steps required to design a website, and have done this. But I either rely on somebody else's template or my designs tend to look like shit. Mostly, I think, the sheer patience to tweak CSS, let alone testing it on a dozen browsers and mobile devices, is often beyond me. Or (Christ, be my shield) dealing with end users.
The simple act of repetitively designing many hundreds of websites and then getting feedback from actual people as to how they work with those sites, that is mastery and it does take careful thought. So, yes, they're constantly looking up "recipes" to combine into code.
Speaking as someone who is on the "tool-making" side of the house, that's the point. I want to make tools that other people can use and combine into new things; if I write a compiler, the goal is that someone can use it without having to learn compiler theory.
I understand the point you’re making here, but having done webdev for about five years now this has just not been the experience of me or anyone I know. Admittedly, limited sample size and all.
The simple act of repetitively designing many hundreds of websites and then getting feedback from actual people as to how they work with those sites, that is mastery and it does take careful thought. So, yes, they're constantly looking up "recipes" to combine into code.
If I were at a party I would appreciate my job being described this way, but the reality is that webdev is mostly applied common sense + having a lot of the kind of knowledge that is googlable. Like, I’m successful career wise and I’m regarded as being quite good at my job, yet I don’t feel like I’ve mastered anything per se.
Whereas for my side project, an IDE for Golang, I feel I’ve actually had to learn difficult concepts that couldn’t be re-learned from a blog post.
I take back what I said about webdev not requiring thought, which was an exaggeration.
Maybe referring to Physicists and Mathematicians googling is a bit glib but almost certainly they do a whole lot of "Googling" by way of being familiar with what others have done...it is the only way to be effective.
Knowing how to quickly find what you need is not in conflict with mastery...besides, we are talking about web apps here, most dev teams wont have much patient with a developer spending a ton of time reinventing wheels when there are ready-made solutions.
>This just shows how shallow web programming is in intellectual content.
Not really, the same rule applies for a hell of alot of other things.
>And is that because other fields are merely more obscure, or because they’re actually harder?
It's simply because other fields don't have the same knowledge sharing culture and you end up having to use SciHub and doing the knowledge sharing yourself.
>Could one be a mathematician or physicist by googling things?
I think a number of fundamental cultural problems with mathematics needs to be fixed before this is viable for the broader population, but I do think it may become the case over time.
I found for web development that to google is simply the fastest way to a solution I'm trying to solve immediately. It is all about rushing to fix the next problem in code. Need to do something new? You can enter a few keywords and the solution pops up. For most folks this search then copy/paste is the extent of programming nowadays. The deeper stuff where we all get enjoyment from programming done without google may be a thing of the past.
Also knowing when you have found the answer. An experienced developer doesn't just paste the first thing they find. They read it and think "Ah yes, this will do what I need"
Because somehow the search function on SE mostly sucks. I tried a couple of times (especially when flagging duplicates) and it's really hard. I usually just revert to Google or ddg.
I also think that anything js-adjacent has a real culture problem. Trying to dredge an answer out of a Medium tutorial written in a cloying tone and interspersed with pointless gifs can be such a groan enducing experience. I'm hoping that the community will mature alongside its technology.