This isn't the old days of FTP, Perl or PHP anymore. There are too much information I cant memorise every single bit of it. And I dont think you should either. Especially in the age of Google. My memory capacity has its limit, and there are things I just decide it is not important enough to memorise when I could easily search for it. ( Or if I am relying on Heroku )

I have long thought of Directing a video, where we have famous Developers, or developers from a pieces of software that normal people would have heard of, filming them doing work, looking up silly things in Google. Starring at the screen for hours and absolutely dont have a clue what the code is doing. Not typing any code for hours. Sort of like Reality TV shows for Programmers.

Hollywood Movies and Anime has made the perception that proper Software programmers should be super fast touch typist and typing code with insane speed. It makes people uneasy when they learn programming. It turns out they have to constantly look up some manual, googling, copy and pasting and for most of the time not typing anything. They thought they are just not any good at it and many simply gave up.

The reality is, hopefully the video would show, even top level programmers dont know everything. And it is perfectly normal to look things up.

I went one stint where I didn't start a new project for 5 years. Practicing new projects in that time period would have been a whole lot of wasted time.

Very similar to physical fitness. Sitting all day trains you to sit. And that’s making you more fragile

Most of the inner working is hidden

I guess I know now why every other website pegs my CPU to 100% to slowly display static text and break the browser's back button - professional software engineers are "bored to death" when doing their job so they have to make things "interesting" in order to entertain themselves.

We live together, I work from home, they school from home.

I manage to not get bored.

If I was allowed to look at what I already have on my machine I could even set up a build process for my site. If not allowed then no build process.

But it would probably be pretty slow to write this, depending on how basic the site was, and it would not be as good as if I could look things up when I needed to.

But I wouldn't be able to deploy without searching.

That’s cool if true but until you try it you could be fooling yourself. The other thing is that it’s not really a skill that’s valuable in such a connected age, except in contrived scenarios like closed book coding interviews, maybe.

However my confidence that I could do this slowly and of poor quality is that - I started making websites 20 years ago so making and index.html file and linking to each file by hand and I still do this every now and then when making little static sites (like if a site is 4-8 pages I might just do it by hand). And the stuff I look up for sites like that are generally - how do I do this cool thing in CSS.

Admittedly if I did it this way the site I am envisioning doesn't look much better than Berkshire Hathaway's https://www.berkshirehathaway.com/

on edit: also there is some question if one is just allowed to do what one can remember in one's head or if, without using an internet search engine, one can use the stuff one has on local computers and devices? In which case I have some complicated stuff here to reference going back a lot of years, a lot of ebooks, local hardcopy books. So in that case I think I can do just about anything that can be done with search (except for using newest CSS, es2019 features), but still significantly slower.

I don't see the value of memorizing somethings you just do once.

That said you're right, even the 99% of work still involves a lot of fiddling and sometimes research outside of writing code.

Using Google and GitHub I found RMUIF, which, like many available templates, is based on React's standard create-react-app

Maybe a “Big brother season 1” style. I’d watch that.

Things are more complex, but a lot of documentation is also now online instead of printed or distributed on floppies.

Granted, this assumes that the deployment target is ready to receive the deployment payload...

I'm pretty sure I could do it depending on our definition of basic web app. With something Rails it's not even really that hard. Rails g scaffold [Model] gets you 95% of the way there.

I can make a basic web app without googling.

On-line information? That's another question entirely. This would be a more interesting test: can you make a basic webapp (or other type of app representative of your experience) without Internet access?

If you're dealing with an older stack and toolkit, you probably have many books' worth of manuals already installed. Unless you're unlucky and didn't notice the documentation isn't installing along with your tools. Or you're on Windows[0]. You can use them to work out most of the problems you're facing.

Newer tools though? There's this annoying trend of under-documenting things, and relying on people on StackOverflow to fill in the gaps. Or even worse, setting up a Slack/Discord for the project, and getting people to help each other there.

Maybe I'm just old, but when I'm working with computer tools, I prefer to solve the issues myself, instead of chasing around the Internet and talking to people. I also like to be able to continue to work when my Internet dies, or I'm out of range, or the site hosting the docs dies (happens more often than one would expect).

And to answer my own question: yes, I can write basic apps of the type I work on (and bunch of others, including games) without Internet access, as long as you let me use my computer - where I have access to heaps of off-line documentation and lots of prior source code to supplement it.

--

[0] - Someone at MS had the bright idea to ship PowerShell without help for its commands by default, so that the first thing Get-Help tells you is to download the man pages...

> On-line information? That's another question entirely. This would be a more interesting test: can you make a basic webapp (or other type of app representative of your experience) without Internet access?

I would suggest that the type of information is important, rather than the medium. It is not that solving the issue yourself is better than talking to other people. It is a matter of ensuring the validity of the information as well as it's suitability to the task. That is more difficult to do without referencing language or library documentation, and I suspect that it is not being done at all by most of the people who rely upon searching the Internet.

While the quality of books is better (on average) than online information, one still has to be selective. The market is flooded with books that offer shallow explanations or are simply a rehash of what dozens of other books have discussed. Not only does the latter limit the breadth of knowledge, but the nuggets of insight offered by any given author are usually so deeply buried that they are easy to miss. Sometimes it is more productive to scour the Internet because of that.

I generally go directly to the API reference and do the search there because Google results might not even have it on the first few pages.

I actually get annoyed at being pointed at the StackOverflow question that shares a few keywords with my search, but is completely unrelated otherwise.

As for StackOverflow results, at least there is a chance that they will be more useful than most third-party information. I have found too many sites that attempt to rehash the documentation, perhaps in clearer terms but virtually always covering common knowledge and completely omitting everything else.

I guess it's time to start bookmarking those /usr/share/docs/... paths again :)

In my initial days of programming in school/college, I relied almost entirely on local MSDN library installation (during VB6 days, it used to come in three CDs), to learn VB6 and build apps. With that, I built a multi-lingual word processor, a screen reader and some other nice tools that got me hooked with coding. It was around 2003-2006 and I used to only search on internet whenever I needed to add something not supported out-of-the-box in VB6 like Win32 APIs etc.

0: https://ASPSecurityKit.net 1: https://www.youtube.com/watch?v=TmUO90JNlvs

Plus, these questions give me a great reference for next year when I am doing something similar but have forgotten the details.

This approach probably works well because I know how things work at a high level; I think it would be disastrous to do this without any real understanding.

I actually interview for this skill specifically. I stress to candidates that they can and should search the web in whatever way they would when tasked with code in real life.

The speed at which someone can process search results and stackoverflow responses to filter out crap and find the solution is the best proxy I've found for developer productivity.

Some people don't search for anything, even after prodding them 3 times that it's 100% fine to search and they definitely won't lose points. They still won't do it, because it's just not how they reason about problems.

Other candidates will immediately identify the problem, search with good queries, quickly navigate through a bunch of sites, find the relevant info, copy/paste, and solve the challenge.

I like to think about a problem at least a little bit before giving up and asking for help. I have to at least be able to understand the problem before I can effectively find a solution.

And hell, these days it's only a 50/50 shot whether searching will actually help with my problems or I'll just end up in a rabbit hole of SEO spam.

That's interesting. What is your experience with harder problems - ones that can't be just googled? Do you find that those same "googlers" still outperform the more "independent" developers?

And the other other thing to know is when not to do it, like for the core business logic, or for anything that needs to be really fast.

You’re being judged for your knowledge (in part at least), googling something fairly basic doesn’t feel great even if it’s completely normal to do that in normal development.

Sometimes my google queries are so entry-level that even I chuckle, but I do worry what my employer would think if they saw "how to create a date in java"

Also, eventually, what matters is how you connect the bits and pieces you take from online and integrate them into your software. How you design and shape your software so that's its scalable, optimized and reliable is in your hand and that's what matters the most!

I learned to write java code (structure, basic io (terminal, file, datastructures) blind like in word or notepad and it would run without errors for a google interview; It is not that much you need to know actually but when you learn it once, it lingers around for quite a long time and it gives you a different feeling of confidence that you actually know java (i was writing java code for 6? years before that already so i do know java).

Its very similiar to my personal experience with doing push ups: If you never have done them you don't have any muscles at certain areas; Now after going from 0 to 15 push ups over a few month, i gained a general better physiology on upper body strenge and it still lingers around.

Non of both are critical in a day to day scenario but both experiences were fun/interesting and this base is now here where it was not before.

It brings me, mentally speaking, closer to really get something like java.

Does education work in a similar fashion? does being very good at solving very specific timed algorithm problems at a whiteboard translate to being a good software engineer overall? If that's all you trained for, you will be just very good at that.

As to pushups and pulling things, back strength from supporting your body weight on your shoulders would help you pull things. Clearly practicing the motion you want to improve is optimal, but controlled motion generally involves a lot more skeletal muscles than just what’s being targeted.

I have a clear difference in my body structure after i ever did and made it to 15 push ups.

And now after 8 month of not doing it at all, it still lingers around.

This adds to my confidence.

Same with my java skills.

Disclaimer: I used to write code without internet access every day for years (was in a secured area where internet and phones are not allowed).

If I quickly need to know how to get the last item of a list in yet-another-language, Stack Overflow will provide me an answer in about 2 seconds.

The documentation will certainly provide the answer too, but I'll need to look at several places etc., since the format is just not optimized to answer exactly this question fast.

Edit: I know the article touches on that idea briefly but my argument would be "of course it doesn't matter".

Sure, I could develop slightly faster with a more encyclopedic memory but I really doubt it would make an observable difference in the long-term.

Most of my time isn't spent referencing libraries or syntax but instead I spend most of my time thinking out the logic and higher level relationships of my code. I suspect that is largely the case of any development even remotely non-trivial.

I don't care that someone memorized whatever command line syntax to create a new project in whatever framework. That's just rote. Even what we write on the whiteboard I don't expect it to compile. Is it ToString or toString? Can't recall either.

What I care about is that someone can ask the relevant questions, come up with a design and explain what and why they are doing something.

It'd be really weird if we sunk so much effort into ticket writing that everything really was just reduced to a task - at that point the ticket author should just go ahead and fix the thing.

If my requirements are that precise I'll farm that to offshored contractors.

It's no different to filing a ticket with the building management to replace a broken lightbulb - it's in your interest to know whether they replaced it already without having to stand up from your desk to check, and it's in their interest to know which individual problems are located where so that they can plan their weekly maintenance run through the building accordingly.

It's a problem when you search for the solution to every problem with a search engine.

So many answers on the internet are written by absolute beginners, who happened to have the same problem, and then blogged about the solution after spending 5 minutes of googling. Sometimes these answers are alright, but often they are shallow and miss context.

The problem is excacerbated by the fact that 1000s of sites try to get into the top results for programming questions. So you end up with crappy shallow answers, and never learn the underlying details.

And then there's the problem that the more experienced you get, the less you look up answers, so the less you are exposed to sites like Stack Overflow, and the less you contribute to Stack Overflow. So the result is that the least experienced contribute most to the answers on the web.

My preferred solution is to buy books. Find the best book on your topic and read a chapter, and you'll learn more than if you had googled 100 questions.

The downside of books is that it only works for "old" tech. If you want to learn about the hot new Swift UI Declarative Reactive Whatever, your out of luck and you need to scrape together any info you can find from random blog posts...

Books are also written by amateurs a lot of the time, especially if the topic is a bit niche. I've had people from publishers reach out to me to write a book about things based on a single blog post in the past.

Technical books have become a dumpster fire. Some publishers (I’m looking at you Packt) are so bad their books are not worth the space they take in a dumpster. Total waste of trees.

Why? I'd fire an engineer who took on problems and refused to spend 10 minutes googling around and looking for solutions first.

I have no interest in humoring someone who dismisses the entire internet because it is written by "dumb people." Buying and reading books is how you draw out a project you don't want to work on.

"Why spend time learning all this useless background information when I can just find the answer on google in 10 minutes".

It was obvious that people just cobbled together dirty workarounds that they must have found somewhere on the internet. They used runtime hacks to circumvent limitations in a library API, even though the library was developed by someone else at the same startup, and the runtime hacks were not necessary if the developer had any clue about what they were doing.

Sometimes you get stuck, and searching the web can help you get unstuck.

But the problem is when people just search for the solution to EVERY problem they encounter and never learn the basics because they don't want to "draw out the project".

(Addendum: I'm not dismissing the internet. You can find good information on the internet. But it takes time. The problem is that people take shortcuts, and instead of learning everything they need to know, they just google for the answer to their specific problem because it seems more productive in the short term. Buying and reading books will take longer than copying an answer from Stack Overflow, but it will not take longer than learning sufficiently in depth about a topic by reading blog posts, documentation, etc)

There is a strong argument that being good at that isn’t required for most SWEs (including at FAANG), but it is something that having library/framework references doesn’t really help with.

Algos/data structures are used as a proxy for problem solving and how fast someone can learn. Plus every decent CS program will have a few courses on it.

Also, internal codebases are, well, internal. You won't get a nicely formatted Stack Overflow response on how X works if X is deep in the Google Source tree.

Problem solving, yes. How fast someone can learn, absolutely not. If you've never heard of dynamic programming there's absolutely no way you're going to come up with that in an hour. If you've never heard of binary trees you aren't going to think that one up in an interview. (Of course, you should already know basic data structures, but my point is a lot of these things aren't something you'll come up with if you haven't heard of them before.)

I had a FAANG interview question applying statistics to a unbounded input. It took me a while to understand what the question was really asking, followed by some shock because it was something I'd never even imagined before (since I haven't needed to do much statistics in my line of work) and I didn't have the faintest idea where to start. With some hand-holding I figured out some basics, but I'm pretty sure that interview was part of the reason that "the hire signal was not strong enough". Now, let me take a walk for 15 or 30 minutes to consider solutions to something I've never imagined, and I'll probably come up with a reasonable solution on my own, and also be able to extend it for the rest of the interview. That might measure my ability to learn. But expect me to solve it in five minutes so we can go on to the deeper questions? Yeah, not really. So this interview didn't measure my ability to learn, it measured what happens when you give me something I've never imagined before and expect a solution in five minutes.

(What's a little frustrating is that I'm not really sure how to expose myself to the problems I've never imagined but which FAANG interviewers are likely to ask. I'm not sure that leetcode would do it, although obviously it'd be a place to start.)

Dynamic programming problems are really terrible for interview signal though.

Firstly, it's mostly an aha moment or two trying to realize the relationship between the elements. Not really lots of signal there.

Secondly, the code is trivial in 99% of cases. Just set up an initial (likely multidimensional) array, some for loops to iterate in the right order and then apply the formula. Returning the right array element at the end.

Also terrible signal, since the initial fizzbuzz question during phone screens or whatever should've caught an inability to code.

That said, yeah, the algorithms bit of interviews are the bits that are scary to me, since they're the biggest dice rolls. Everything else just has normal levels of unexpected events that you learn to deal with during your job. However, I write proper algorithms once or twice year and, even then, just trivial ones.

You need to come up with the correct answer in less than 2 minutes, twice, within 45 minutes. Because it runs twice, you will only have 15 minutes to write up the code to handle all the edge cases your solution can't cover for. There is simply no time, nor expectation, for the candidate to reason about a problem and actually work out a solution.

And that's for a single interview slot.

Strategies I want to see are along the lines of 'draw a picture' or 'work a small example, carefully, in full detail.' People who do these kinds of things /usually/ solve the 'hard part' they got to, and I give them a good review, wherever that was. People who don't manage to get unstuck tend to either a) not use simple problem solving strategies and/or b) get overly attached to an initial wrong idea.

(and I totally agree: taking a walk is totally a valid problem solving strategy, though it isn't easy to incorporate into a time boxed interview...)

While I'm a decent programer, I perform terrible under these situations. When I get stuck I need to take two steps back (go for a walk, explain it to a coworker/rubber duck).

That's partly what the whiteboards are screening for. Any decent CS program should teach them.

> I had a FAANG interview question applying statistics to a unbounded input. It took me a while to understand what the question was really asking, followed by some shock because it was something I'd never even imagined before (since I haven't needed to do much statistics in my line of work) and I didn't have the faintest idea where to start. With some hand-holding I figured out some basics, but I'm pretty sure that interview was part of the reason that "the hire signal was not strong enough".

Yeah, if you are asking something weird (as an interviewer) you should be expected to explain it.

It sounds to me you had the right approach (figuring out what the problem is and getting help from the interviewer). Ultimately, it's completely possible you simply stumbled upon a bad interviewer who assumed his specialty question was well known.

Leetcode

A piss poor one if you ask me. The truth is that it’s a skill where you need to internalize what various low level data structures buy you to know when to reach for them.

Most of the code I saw at Google was boring ass proto transforms based on business logic. Knowing when to use a map vs an array was about as complex as it got for 95% of the positions.

Additionally, knowing the algorithms/ds (as all Googlers are supposed to) did not help for that normal work. A bunch of folks I worked with in the open source world produced better structured, better tested, and more performant code than many of the internal folks but they couldn’t join Google because of the algo/ds bar.

Some (probably most) SWE interviews rely on coding without Googling. However I have been through plenty of interviews in which that wasn't the case. Coincidentally I also find this type of honesty in the interview process is a good indicator of how much I would enjoy working at the company.

I had a position working on a pretty complicated 3d application in Angular. At times, it felt like I was fighting a war on two fronts, one dealing with Angular complexities and the other dealing with ___domain complexities. A better understanding of Angular in general would have greatly increased my productivity.

Now, whether or not an increase in team productivity would have really mattered is hard to gauge.

> Does an over-reliance on documentation indicate a lack of critical expertise that will ultimately result in considerably lower job performance?

Technical research is a skill. I love working with teammates who understand how to find, evaluate, and apply proven solutions. Most projects can spare the time to do a reuse trade study before writing something from scratch.

Use (and authoring) of documentation is also a skill. Professionals use documentation to communicate with teammates so projects can scale efficiently.

That you can imagine some convoluted scenario where a skill could be employed does not mean it is an efficient use of your time to develop that skill, particularly when that scenario is easily avoidable.

You just need some copy of something like: the way back machine, google cache or archive.is and then do asynchronous mirroring and you are not so far behind.

Zoom meetings might be a problem though.

If it prompted the meeting organiser to put their one point into an email, thereby saving 6 people a 45 minute meeting, would it be a problem or a feature?

I understand what you are trying to say - but what would be the point of that ?

If we were to prepare an essential list of documents that are required to write web applications without access to the net, we would probably be able to cobble it together and make it available offline.

I mean MDN, CanIuse and CssTricks.com would already get you like 90% there.

Dash [1] does package up StackOverflow and a bunch of library docs too.

[1] https://kapeli.com/dash

Also, as if no internet access = no refernce.

Sounds wonderful :P

I took 50GB of wiki resources mirrored in my pocket.

https://kapeli.com/dash

https://zealdocs.org/

[1] http://wiki.ros.org/Mirrors [2] https://docs.python.org/3/download.html

The whole idea was to have a page I could load from a laptop attached to the pi via a ethernet cable for quick debugging and interaction. No external internet needed, and did the job decently.

I’m using Django and I used to use Sublime Text without any plugins which meant (at the time) it couldn’t automatically show me the definition of a function or object from a library, forcing me to search around for its documentation.

Switching to PyCharm/IntelliJ meant I could now just Command-Click (Ctrl-Click for Linux & Windows I believe) and see the actual definition and logic of the underlying function without having to rely on the online documentation. This of course works recursively, so I can repeat this process again and again up until I eventually reach the core standard library which is in C and isn’t introspective (at this point I can rely on my knowledge or some trial and error to figure out its behavior).

Personally I think that focusing on how you solve the problem loses sight of the fact that the only important thing is that you can accomplish the mission. If you can't build a basic web app on your own, but you can while salsa dancing w/ a mountain gorilla, I'll pay for your subscription to Spotify so you can stream Havana Kings while tearing up the dance floor w/ a Silverback (must provide own gorilla).

I enjoy to develop without Googling; really enjoy!

I tried some other amazing things:

- developing without using touchpad or mouse.

- debugging without running code until the end.

- developing with turn offed WiFi.

In general, I'm always trying to reduce my needs.

I think this practices would help me to be more accurate, more independent, and become able to live in a post-apocalypse situation as a geek.

I said post-apocalypse, I remembered lcamtuf article "Disaster planning for less crazy folk": https://lcamtuf.coredump.cx/prep/

When I'm running I periodically close my eyes and it helps me breathe a lot.

When I'm programming I often close my eyes if I know what's the current state and what operations I'm going to do for several following steps, until I lose track of them. It helps me to concentrate and recover my sanity.

p.s. Even occasionally I'm walking closed eyes.

So not googling is a time saver here.

Today on day one i would go: wtf is this Babel thing and how do i configure it so that Angular work together with SASS and is npm compatible with this version of Typescript? Which reactor pattern is flavor of the month and what stupid parameter was needed to make the router work? I hardly even know which files are shipped to the browser anymore after all Webpack preprocessing.

But once you actually have the setup in place, i have to admit the modern experience is a lot more productive and powerful. It's just that every time you have to start a new project or touch anything related to the build-process your soul dies inside. There are too much gunk just built on top and on top of each other, instead of replacing the whole stack, and thanks to leaky abstractions you have to understand at least something throughout every layer of the rotten cake.

There are a lot of scaffolding-scripts available, like Vue-cli, helping you to do all of this but imo they just add even more to the problem, now you got yet another layer of crap to crawl through and it prevents you from actually learning the real layer underneath.

Today with node/angular, I'm generally leaning on Google (well DDG) pretty heavily throughout the day. Web platforms seem substantially more complicated today than they used to be. Then again, maybe the mid-aughts was the golden age of programming.

The number of times I google how to do the thing I'm supposed to do is relatively low, but the number of times I have to google how to fix something that has come up AFTER I did the thing I was doing is probably 90+% of my googling.

They basically said "errr, you could just look it up?" - like, it was obvious that the interview was more about what you knew, and how to do things, rather than can you remember every little thing from ever about your job that you don't use day in day out.

Can I knock up a site with some PHP/HTML/CSS without references - sure.

Can I knock up a standard server side app - sure, but I'm gonna want to look up certain functions and what arguments they take.

Can I put together an SPA without? Probably not. I know what I need to do, but I'm not going to remember which packages I need to install, or how they are configured, or if package x works with webpack4 or if I have to have Vue2 because a certain thing I want to use doesn't support 3 yet etc.

There are so many moving parts now for an 'app' that it is not feasible to keep it all in your head. Thats why there are so many starter-packages for things, because people forget what they did the first time around, so just create a new git repo with the skeleton to get going again ... only to be replaced in 6 months.

It was perl and flat file site counters when I started, and now I have to google how to make webpack work nicely :D

I’d much rather have someone find the best page showing a specific tree algorithm, than describing it on a white board.

Bonus points if the searching test requires knowing the termninology. Having a broad-but-shallow set of knowledge is a key skill for developers in general, for this reason (information finding).

E.g knowing that a bounded cache can be a “LRU cache” will help you find information or implementations.

But it is kinda like a specialized version of a fun party question, "With what you know now, if you were sent back in time, how far could you go and usefully employ your knowledge of the future?" (E.g. I know chemical fertilizer is a big deal, but I definitely do not know how to make it. I studied heat engines in a physics class, but could not spark the industrial revolution a century earlier.)

Maybe the midway point between these is something like, "if you were sent back to an earlier era in computing, how far back could you go while usefully applying your current knowledge?" E.g. I work with the jvm constantly and I know that it was a big deal for a popular language to have an actually described memory model, but I couldn't build it myself in the 80s. Maybe I could build MapReduce or Spark in the 90s?

It's _hard_ working without the informational resources you're used to, but there are so many more fun ways to explore that gradient than web apps.

One "out" that can make the exercise more inclusive depending on the group is germ theory. Any modern person could save a bunch of lives in almost any period if they can convince people to wash their hands, boil suspect water, separate wells and sewage by a wide margin, etc. And yes, definitely still relevant today.

The hard part here is probably convincing people. Something to prepare for before you go back in time or post-apocolyptic.

However, lots of programming is much closer to plumming than to.. programming.. any time you're using a lib or api, you're just looking up what kind of fittings that comes with and what length of pipe to attach to it.. So don't worry about not being able to do anything really useful without looking in the docs :)

Now, if you have to look up basic language syntax for the language you use every day, I'd say its bad and you probably need to practice a bit ^_^

You should be able to learn at least one language deeply enough that, given sufficient time, you could do just about anything without libraries or external dependencies, and therefore without needing additional documentation. Aspiring to and eventually developing that level of language mastery is, IMO, one of the core signs of maturity for a Software Engineer.

However, that would be wildly impractical in our day to day work, which is more about connecting pieces together in the right way, and hence is a lot about reading the manual for those pieces, understanding what it is they do and how they should be assembled together, and then actually assembling them together and testing that it all worked as expected. "Googling things" is an essential step in that process, but you could substitute Google for "read the manual" in an earlier era and it would be the same thing.

Perhaps what is sad is how many things these days ship without good manuals, because Google makes it easy enough for people to stitch together scanty release notes, comments in the source code, blog posts, Stack Overflow questions, etc. that you can actually get away with not having a manual.

I don't understand why so much emphasis is put on being able to do this without consulting the docs. Sure, it's nice to be able to pound out the most basic valid HTML page without googling it, but that's hardly a web app. If you need a backend component, I suspect the ecosystems where you can make anything practical using only built-in functions (no libs) are in the minority. You'd end up doing ridiculous stuff like using the filesystem as a database, plain javascript on the client side, node's builtin http in the backend. People with years of expertise may be able to do this, but it's just a side effect of having been steeped in the tech stacks for so long. I don't agree that being able to do this is something worth aspiring to. Rather, people should aspire to moving efficiently within their ecosystems and conserving mental space by knowing where to find things quickly.

Of course people’s projects can be unique, and my work may not be representative of the readers work, but I guess this raises the question: what does “using Google” mean? I frequently use “lots of things” on my computer: man pages, other installed documentation, will browse source code of libraries I’m using, or indeed my own previous work. I can do this if, say, I have no Internet connection, but that doesn’t mean I’ve got a fully-formed bug-free implementation of my goal floating around in my photographic memory.

So yeah, I guess I take it to also mean searching through local documentation, but I know that's maybe not what was meant.

For the things I've mastered I hardly use google anymore, and even that is mostly to check if things have changed since the last time I used them and if there's a new way I didn't know about.

But my emacs with ctags only does local method lookups, so that's not really my case.

I don't know whether he really said or thought anything like that, and I also don't actually agree with the literal meaning. There are some things that it pays to memorize, in my opinion. As I keep reminding my daughters: times tables (or math facts as they seem to be known nowadays) are important forever.

The principal behind the quote, however, I'm fully behind. I live in the docs. Even if it's something that I know pretty well, I often like to check to make sure I understand exactly what's going down. There are too many little details that are easy to forget. If it's important and you aren't sure, look it up!

Finally, I could probably claim to be able to write build a simple web app without using google, but I'm sure I would lean heavily on my editor to remind me of argument order, syntax, etc. Maybe there is a little bit of difference there: if my editor/IDE can tell me what I need to know, it's probably just that bit faster than searching for it in a browser.

Shoutout to lsp-mode.

But there is no productivity booster as large as knowing exactly how to do something without needing to look it up. This is almost by definition the level of mastery that comes from significant practice / experience.

I've noticed that some of the very smart people I've worked with for years did not ever really achieve mastery of their language or tools, and I think that's at least partially because they didn't care to take the time to try and figure things out without looking them up, and thus the inner workings of things remained inscrutable to them.

I know for a lot of people coding is all about fun and lifestyle, but at some point it becomes a job and you just need to get shit done without being fancy, cool, hardcore, eXtreme, 1337, agile, lean, mean, whatever.

Or maybe I'm just becoming grumpy and old.

But then cheap and ubiquitous calculators changed all that, and what it meant to be a good mathematician was solving complex chains of problems.

But then cheap computers changed that, and what it means to be a good mathematician now was just setting up the right equation.

Now it’s about filtering out the “noise” facts and figuring out which facts or dates are relevant.

I made a conscious decision to fix this.

I have switched from Java to Go, effectively lowering the level of abstraction. Then from IDE to Vim, getting rid of autocomplete. I turned off syntax highlighting, allowing my brain to parse and interpret code more effectively. Last but not least was starting to use embedded documentation `go doc {{ package }}` via terminal and reading language sources to learn how internals work.

It was hard at the beginning, and my productivity dropped for some time. Later, when new neural connections were created in my brain, things started to improve.

Some of the benefits that I enjoy now are a better understanding of the code, improved knowledge of language libraries and interfaces.

I have tested this approach by coding in planes and trains without access to the Internet, and it works well.

Did it fix my problem with whiteboards? I do not know, but I am happy with the new skills.

People like Mike Acton and Jonathan Blow give incredibly condescending speeches about "practice" like you should be able to just make a Win32 API app that calls DirectX (or some other comically absurdly bad API) from memory. Blow in particular loves harping on this and loves saying that web developers are incompetent and wasting their time creating awful products.

How much time do you spend making new apps on long-lived projects? At many companies, the answer is zero. These same companies may think you suck shit at programming if you can't remember command line options you never have to use in day-to-day work.

I like doing that as an exercise. It trains you well for a very common situation for professional developers. You have to work on a project, poorly documented, the original developers left long ago and no one really knows how it works, except maybe for one guy who don't have time to answer your questions. Of course it is internal stuff, so the internet is no help. It is a valuable skill, literally, companies are ready to pay good money to people who can do that.

I totally agree that it's a very valuable skill, but just wondering, how would you demonstrate that skill in an interview? I personally find it pretty hard to demonstrate these "soft" skills, and even when I act as an interviewer in those rare cases, I find it hard to tell if a person is equipped with such skills.

So yeah, I might be able to get a basic page going, but I am sure I would need it for the postgres integration.

Only with Pycharm, so I can scroll through and search code easily as an alternative to Google.

If your job is to make and fix/tweak the style of a web page, and you do it practically everyday, you probably can make a pretty decent css file without even looking away from the editor. But if you then need to make a basic html page, you will probably search.

If you use an ide with autocompletion, you probably won't remember the correct camelCase of even common functions (is it instaceof or instaceOf?) but if you work on an embedded system with a plain console editor you probably remember them all (or at least the most used ones).

I remember when I was actively using Lightning Launcher (an android launcher with JavaScript capabilities) that I could make full scripts almost without pressing delete, when its editor was simply a big textarea (no autocompletion, no colors, not even automatic indentation). I did need to check the docs from time to time, but their limited (and logical) set of basic functions made it easy for me to remember. Nowadays I need to check everything again, because I simply forgot due to not using it much.

Answering the question: yes, yes I can, a very basic but working one, simply because I like making small tool pages for myself, coding directly from my phone (in a basic text editor). But when I need to do something not so basic, like checking if the user has scrolled to the bottom of the page, I search it.

There's some pedagogical theory around this. (I learned this through the FAA's instructor training.) Sort of common sense stuff, but it's helpful for structuring learning. Basically you'll remember things that you use a lot, have used recently, experienced intensely (e.g. actually used rather than just read about), and had fun learning. In addition, the first way you learn to do something tends to stick.

Cite: https://en.wikipedia.org/wiki/Principles_of_learning

So here's my attempts. I store some annotated snippets in Joplin (could probably use org-mode or similar). I also collect programming ebooks and PDF'ed docs: sometimes you can still find them, sometimes you can 'print to PDF'. No idea how one would do it with javadoc for example.

The problem is interface for searching this stuff locally and reading. I use recoll for full text search and qpdfview for PDF viewing (the main reason is that it has tabs). Admittedly, this is not completely satisfying. Simple text search doesn't have the sophistication, PDF's feel less pleasant than web pages. Maybe something I could get used to if I went fully that route, but for now I don't feel compelled to do that (besides some experimentation).

My guess is that if you use a small language/libraries, or have a self-contained codebase, or do fairly rote things, it's possible to go without searching documentation. Otherwise... no?

[1] Or you could use bookmarks, but then, why not archive.

But through my career at various times I've been able to say yes, usually after spending multiple years on a project and the platform/tech its built with.

Speaks to the really enjoyable side effect of productivity and unencumbered expressiveness that comes with being immersed in a platform or technology for a longer period or time.

Thing is, you don't start apps every day. In some jobs, not even every year.

Whatever's initial setup and not related to the actual functionality you're working on will fade from your mind, and that's good. You can concentrate on the thing you're trying to do then.

I do miss offline documentation though.

Mac: Dash (https://kapeli.com/dash)

Mac/Linux/Windows: Zeal (https://zealdocs.org/)

Windows: Velocity (https://velocity.silverlakesoftware.com/)

all support a healthy amount of documentation that you can download and most importantly a very healthy amount of integrations from Vim (https://github.com/KabbAmine/zeavim.vim) to VSCode (https://github.com/deerawan/vscode-dash) - note that on Windows all these apps write to the registry as "Zeal" so remember to uninstall the previous one if you're switching between them and using an integration.

If you just need a searchable docset that can be made available offline, there's also DevDocs (https://devdocs.io/) - just note that downloaded documentation can disappear if you regularly use the same browser for normal internet use - I'd do things like grab a copy of ungoogled chromium and just use it for this site before traveling if you're gonna be offline for a while (alternatively, there's some electron versions out there and you could package it that way for yourself too)

I am not a (frontend) web developer by career. I did LAMP webdev work as a college job 12+ years ago and, like the author of this article, do small personal web projects perhaps once or twice a year. I did one of them earlier this week.

Yes, I went to Google for basic things like "Javascript map lambda" or even "Javascript foreach syntax", but I refreshed myself on those exactly once and was then able to keep it in my short term memory through the completion of the project a few days later. I switch around so many similar-but-not-identical languages (Java, Go, Python, C++, etc.) in a year that it's often not worth it for me to memorize the minutae of each one. I know how to conceptually do something in whatever language, and use search engines and stack overflow to remind myself where to put the semicolons and the brackets.

Are you asking if I can make a web app from memory? Probably not.

I have ebooks, I have my Dash app which downloads documentation.

So while, I could technically do it without Googling, I can't do it without documentation. If I can't Google then I'd have to look at documentation and my ebooks.

Why?

Well, I work with a lot of languages and frameworks. I can't commit all these technologies to memory.

Few could.

    npm i express
    node -e ‘require(“express”)().get(“/“, (req, res) => res.end(“hello world!”)).listen(3000)’

I actually did this twice - once using a Mac, xCode, swift, and spritekit. Then the exact same app again using a Linux machine, text editor, C, and SDL2.

Doing things in C was far better - I just opened up the relevant SDL header files when I needed information, and was able to get basically everything non-iOS specific up and running without any internet.

I definitely drew on a fair bit of experience and hunches (e.g. writing audio synthesizers from scratch often involves picking a bunch of magic numbers, and if you pick them wrong it can sound completely awful).

Now I have a mac laptop again, I still would lean towards C+SDL2 over swift+SpriteKit (though I do continue to experiment).

When ever I hit doldrums, I'd pull out the laptop and work on the app to pass time. Luckily I had a good collection of gems locally that I used for reference.

Wasn't a web app, but I'm quite proud of it.

I was one of the original employees of k12.com, working as a Sun/Solaris sysadmin and late one night the "web team" had a next-day deadline to make a registration system work.

There were press releases and print materials being released the next morning with addresses and registration forms that needed to work and their big bloated "stack" was not producing anything workable for any of them.

I ftp'd over an old, personal copy of cgi-lib.pl and hacked up a little web page that dumped to a flat file and cc'd an email address with every registration.

It took about 45 minutes and they used it for a year.

Wow this sounds terrible. But it's actually an awesome place to work at!

Granted, that knowledge came from, originally, reading a ton of books, which; as the Internet can be much, much more up-to-date with ever-changing APIs and technologies, I am happy to have as a replacement to heavy and quickly out-of-date books - and also came from 15 or so years of practice.

YMMV.

  mkdir example-1
  cd example-1
  yarn init -y
  yarn add next react react-dom
  mkdir pages
  cat <<EOF > pages/index.js
  const Page = () => "Hello world!";
  export default Page;
  EOF
  yarn dev

I can't do it with an arbitrary set of tools either, but that's why good tools matter and that's why you should use Next.js.

* Ask coworkers

* Look at documentation

* Try things out

Things don't seem way different today; we've just replaced the first two items with a search engine.

There is one difference I've noticed, though: an instant-access search engine makes it easier to 'fake' your way through something with less skill and knowledge. In the long run, this seems detrimental to professional growth and development.

Trying to reverse-engineer some crazy DHTML javascript algorithm used by one site so we can reproduce it in ours (for their members portal).

Coworker came to me asking if I could help her deconstruct the hair ball javascript code into something meaningful. It used variable names like “a, z, t1” etc.

While you can quickly google something and get back a barrage of answers, usually on the same solution, this is software we are talking about - there isn’t a One True Way and there never will be. The more we try to make a “right way to do things” we invent a new way.

Do I google when coding, sometimes. Do I need to? No. Does it make me faster to put my thinking cap on the wall and just go with #1 SO answer? Unfortunately yes.

The real skill is understanding what you're making. What are the constraints, and of those which are hard to satisfy? Which choices are binding once committed? Everything else is fill-in-gaps, or choose a sane default: "Page needs my corporate background color, can't remember the CSS for it. I need a DB, let's go with pg. I need to make sure passwords are done sanely, let's double check the django docs. For some reason I keep getting an error with the page, let's google it."

It's also a skill to recognize when you have to backtrack on your choices. Maybe you missed the bit where it says "don't use this lib multithreaded" and you have to find another. With some experience your backtracking won't take you all the way back to square zero.

This post, along with the talk of interviewing and webapp development in this thread, is giving so much anxiety that it's really galvanizing my desire to leave this industry and never look back.

Create new project -> web site -> you get a template filled in with auth and minimal database.

No need to google function arguments, because in statically typed language autocomplete provides nearly 100% discovery.

CI style deployment would be a problem, but manually you can deploy from the project menu.

It is not only great for technical knowledge but also for project know how. Also it does not require know how to be introduced to the source code, it is stored separately.

It increased my productivity by 30% because I am not distracted by googling answers again and again.

It is a free extension, so try it out:

https://marketplace.visualstudio.com/items?itemName=tomasz-s...

I know without even thinking precisely how I would assemble a simple web app - I do not need help to understand what needs to be done in turns of building blocks. I.e. architecture, how it all hangs together, how data is stored and transmitted etc.

But do I need to search specific arguments for a library function call, some DSL syntax, or other reference material? You bet I do - time is too short to memorise that sort of thing, and totally not worth it IMO (especially since tech moves fast - what is relevant today, is obsolete and dead next year)

Of course you can't build an app without consulting documentation. Why do you think references even exist? Nobody can store all the knowledge in their head.

But doing it without the very specific questions (ie. Stackoverflow), that's a different question. This should be possible imo. But in my experience it is increasingly not possible. Many, many so-called engineers reach for this as their primary source of information these days.

As soon as I use JavaScript/TypeScript and Vue, no way.

React on the other hand never got there for me. I suspect that it’s the many libraries awkwardly glued together (ugh react-redux), with often complex APIs that makes it difficult.

- snippets/usage:

This was done in the past by books. But those days when I’m writing and many languages where some of them aren’t my dailies. This can save me a lot of time.

- cleaner/modernize:

This is equivalent to asking a colleague that’s more seasoned. At least with C++ you discover there’s a brand new std that does that cleaner.

- issues:

We live in a package / deps manager days. Sometimes tiny change breaks your tools. Many times the web searching could save you day(s) of hunting issues that broke due to some dependency or package update.

While the same was also in the old days. You’d naturally had less web deps and less frequent updates.

[1]: https://www.youtube.com/watch?v=Q3XuFr7rw84

Without documentation and autocompletion tho it would be a messy process of trial and error, I wouldn't even call it programming, albeit I've done it in the past, with the PHP toolchain of old. Hated every minute of it tho.

Another example: the setTimeout(a,b) in Javascript has two parameters: the time delay and the function to call. I never remember which one is the first, so I look it up every time.

I can type without looking at the keyboard. But I believe there can be great programmers, who need to look at the keyboard when they type.

I generally forget stuff a week after last using it, and am googling even the most basic things.

In a few days, I'm gonna have to put my Swift code aside for a week or two, while I modify my backend (PHP). I guarantee that I'll be like duuu-uhhh for the first couple of days, with serious Google-Jistu katas.

Then, the same thing will happen again, when I switch back to the Swift frontend.

I tend to avoid using dependencies, so I write a lot of code.

If I had a book on each framework I use with their docs reference material I could do without Google.

It's a fun question but can it really happen realistically? I mean if there is still a demand for web apps then there is most likely some sort of way to index the existing web and search it. Even if that isn't google anymore.

I used to commute on a ferry, and was offline for that commute. Often I would do some coding (more often I was writing), and a tool like Dash that put reference docs offline was essential.

Professionals use the tools at their disposal. Instant access to the sum of all human knowledge is an incredibly powerful tool, and you don't get any bonus points for leaving it in your toolbox.

What I care about is having good foundations that help me to undestand what exactly I need to look for and that's by itself and invaluable skill.

I remember I used the X11 manuals, an encyclopedia sized serie. Plus the manual of every language I used. Plus the Unix man pages, especially section 2 for system calls.

Plus books about basic algorithms.

All those resources moved online and we use far more libraries now. I don't expect to be able to do anything without an internet connection.

Many contemporary frameworks come with a project generator, because setting up a basic project is so tedious that it has to be automated.

All these files are configurable, and likely the default configuration is insufficient for your goals. You're starting out with a bunch of technical debt.

It's no wonder if we have to consult online resources to get anywhere.

I'm personally a fan of fzf. ctrl-r has saved me many google searches. If you're just getting into software development it's a lifesaver.

[1]: https://kapeli.com/dash