I am wondering are you using some external framework angular/react or just "only" js?
"Or even deeper, does an over-reliance on documentation indicate a lack of critical expertise that will ultimately result in considerably lower job performance?"
I don't think so, and I don't know why relying on documentation would be bad.
In a more general sense even for making a todo list app I'd imagine the fundamentals aren't changed even across frameworks e.g. of when adding a todo it needs to be added to some sort of a list.
So in my metaphor, that would be like perhaps a gardener assembling irrigation, or someone in a mechanical trade fixing the gasket. There's still a ton of specific knowledge to the job in question.
Of course, it shouldn't be that Google specifically is necessary - just some literature or reference source (i.e. consulting with someone).
> To be fair, I'm not a web developer so I'm not entirely shocked by this. I only have the itch (and time) to throw together a small web app about once every 6 months.
A better rebuttal is, do you make a [small] outdoor irrigation system or fix a [simple] head gasket "once every 6 months"? I added the adjectives to better compare to his stated "small web app".
I think it's reasonable to expect someone who "throw[s] together a small web app about once every 6 months" to be able to do it without googling, but it isn't how software development is taught. When studying something to master it you start with the basics and do them over and over until you understand them. We don't (tend to) do that in software development, I think for two primary reasons: 1) there's more "important, urgent" things to do and 2) things change so quickly that probably half of what you learn today will be unused in a year (of course if you learn the very basics those rarely change, but I'm talking about the things we all know change so frequently, but were good decisions at the time)
Does it actually matter if I can? Is using reference material a bad thing?
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.
It matters because SWE interviews rely on coding without googling. Maybe we need to change how interviews are done to test people on their Googling skills. For a given coding task, what do they search for? Do they Google for the right terms? Do they converge quickly on the right website to copy from?
Or just give them free reign to use whatever tools they would use in an actual work environment and see what the end results are. Sure makes more sense than seeing how many leetcode problems you memorized.
>It matters because SWE interviews rely on coding without googling.
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.
SWE interviews (at FAANGs at least) don’t care about library specifics though. As long as you know the syntax and how to write algos/data structures, you can make it through.
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.
> There is a strong argument that being good at that isn't required for most SWEs (including at FAANG)
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.
> Algos/data structures are used as a proxy for problem solving and how fast someone can learn.
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.)
> Of course, you should already know basic data structures
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.
> If you've never heard of dynamic programming there's absolutely no way you're going to come up with that in an hour.
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.
Fwiw... My go-to interview question has about four hard spots where people get stuck. I don't really care so much where you get stuck, so much as that you demonstrate good thinking and deploy strategies for getting unstuck once you hit your limit, wherever it might be. And, yeah, points are given for actually getting unstuck.
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...)
Are you explaining this to the interviewee. Otherwise it's a guessing game for what you want and creates unnecessary stress. If you planning to put people on-call (working under stress and time constraint) on their first day(no prior knowledge of the problem they may encounter) then its fine.
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).
I've coined a term for these FANGA interviews: Epiphany Lottery.
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.
> 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
> Algos/data structures are used as a proxy for problem solving and how fast someone can learn.
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.
A measure of a good developer is how they choose and utilize tools. I really don’t see the benefit of prohibiting developers from using tools that they’d otherwise have complete assess to on the job
Let's say Elon starts that colony on Mars and you think "Ima move there and write code for a living." You might have the internet, but its 15 minutes each direction. Nothing interactive works, and while they brought copies of Wikipedia, stack overflow didnt package so easily.
Or more simply, can you write a web app without internet access?
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.
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?
Anyone who has worked with a team in a time zone 8+ hours away from their own can already answer this question. It depends entirely on the technical and communication skills of all involved parties.
Vast majority of documentation and even the websites promoting most web related libraries are autogenerated from git. Run a bash script with a bunch of `git clone` on an Earth based server and and ship the disk image, latency be damned.
Dash [1] does package up StackOverflow and a bunch of library docs too.
And what if you wanted to go camping on the ocean floor? Can you start a camp fire underwater?
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.
> Or more simply, can you write a web app without internet access?
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.
I mostly agree, but I think there are situations where it does make a difference.
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.
That's the reason I do algorithmic whiteboard instead of full blown "real world" coding exercises.
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.
That really depends on how much management there is for hand holding. I expect a good developer to get a ticket to fix the size of a button and be able to follow up with stakeholders about the size of the button next to it.
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.
It's a symptom of a well organised org. The ticket doesn't need to have a lot of detail (unless your ticketing system is dysfunctional and forces you to input a lot of information, which is sadly more common than it needs to be), only enough to capture what needs to be done and where so it's not forgotten.
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.
Last interview I had, I was encouraged to google and afterwards, we talked about the resources I sought out and how I used that information. It was a good experience - if it's a part of my job, why not make it a part of the interview?
It's not a problem when you look up the spelling or the order of arguments in the reference.
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...
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.
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.
In the pre-web days I had a shelf full of O’Reilly books. Everyone did. But O’Reilly has gone down hill, and the popular tools have good on-line doc that is much fresher than a book can ever be.
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.
> It's a problem when you search for the solution to every problem with a search engine
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.
Code I've seen at an (at the time) very well known startup horrified me. It must have been written by people with exactly this mindset:
"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)
> 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.
I think I'd be able to do this, especially from my desktop where I have the code for many basic web apps to look at if I need to (which feels a bit like cheating). I am also not a professional web developer but I make random websites sometimes for fun.
I can, but it will be basic! I might have to use a JSON file for the backend because I probably can't remember any database libs well enough to use without documentation.
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 ^_^
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.
It's a good point, I take it to mean search for how to use or do something, even as google is becoming worse at finding things, it's still often waaay better than the search functionality available on the websites of many libraries and utilities.
So yeah, I guess I take it to also mean searching through local documentation, but I know that's maybe not what was meant.
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.
> 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.
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.
Something that has dramatically reduced my reliance on outside resources is an editor that can lookup symbol definitions.
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).
I'd argue that's just having Google-lite built into your IDE.
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).
Well, it's not really like having "Google-lite" built in because all of that information is available on your filesystem. It's more like knowing exactly where your site-packages are and being very skilled with grep or some other search tool.
If I really need that capability, I personally would download a LAMP/WAMP/MAMP setup with all the docs downloaded but needing to Google things isn't inherently bad.
I used to program with 6 thick reference books around me. Has memorizing SDKs, APIs, libraries ever been a thing? Or is this just the daily "everything is bad nowadays" post?
I had an online interview last year, and it was basically me coding up as they supplied the criteria (in PHP).
For the life of me, I couldn't remember how to use array_column, but I knew that was what I needed to use.
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.
Getting a simple application up and running shouldn't be that difficult without scouring reference guides if it is a thing you do.
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.
Back in the days of PHP, I could develop web apps without references for the most part, using a simple text editor. It's a pretty similar story with Python too, unless I'm using Pandas, I generally don't use reference material much.
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.
PHP in fact had one of the first large online dev & documentation communities. A huge chunk of the web was built with multiple tabs of php.net open looking up which string length function to use.
Back in the days i would open an editor and start with <?php...?><html><head>, and it would immediately show at least something in the browser. The rest was open to creativity. Adding libraries was only needed when adding features.
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.
I'm guessing you could use a .pdf reference manual for a specific language instead of googling, but it does feel like frameworks and workflows have gotten more complex overtime.
Yes, I definitely could do it without Googling(TM). There's plenty of search engines and little need to advertise one in particular by coining a word just for it.
Sorry about the snark and completely missing the point of the article.
Yeah, the googling point is kind of strange in that way.
My first thought was, OK I'd probably go back to some projects in my bookmarks db that seemed interesting last time I was looking into web apps. HTMX maybe. That project has some good examples in the docs.
Googling can help in some ways, but it's also casting way too wide a net in others, especially if you keep repeating that step. It's like walking out into the street and shouting, "I WANT TO BUILD AN APP" infrequently, and then wondering why you keep doing this instead of building apps.
Perhaps it would help the author to think more about creating their own process for selecting, refining, and testing methodologies first, then ramp up to building an app second.
Yes. I'm a mobile and web developer of 15+ years and I often will just hit File->New in Dreamweaver and proceed to create the JS, CSS, PHP; etc, on its own while prototyping quite often without the need to use anything but my own head.
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.
I think one of the questions beneath the question is how much would you be able to justify paying each month for a subscription-only Google? How about Internet access?
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.
The meaning of and technology needed to build a “basic web app” is in a continual state of evolution. Therefore, googling is not so much required due to a lack of knowledge but rather due to that this knowledge needs to be continually kept up to date.
Yes I can and I did after the enyojs framework went completely bye-bye and replaced with an entirely different framework called enact based not on enyo but on react! It reminded me of the time Qualcomm decided to one day purge all brew documents from their website. Google is fickle. The truth is in the source code of whatever you’re working with.
It obviously doesn't matter that much if you can or can't. We all google all day long.
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.
I love googling and stackoverflowing. I know a great deal, but I'm like Kelly Bundy; I can only hold so much in my pretty little head.
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.
As a sidenote on the availability of Google to look things up, how often do you find yourself stuck on a problem and locked into a result bubble where Google keeps on showing you the wrong results, usually spammy articles?
I would not be surprised if even Professional Web Developers cant do it. Especially if you include deployment.
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.
in the php world you usually have decent man pages for webservers handling php requests and generally speaking php frameworks and packages have good inline documentation. also there is a package for anything you may need and and ide will usually give hints based on that documentation.
most frameworks come either with examples or commands to get your started. symfony even had their docs available for local reading as well.
with python i always have to delve into reading obscure documentation that either makes no sense or is not up to date. and there are too few packages for what you normally need in a scalable app. so yeah you can write php code without googling, as long as you are not a complete noob in web development.
if its 2021 and you still write code using vim and niche languages then you are doing it wrong, and indeed google is your only hope.
There's nothing unique here. Virtually all libraries and languages have local version of docs. I think you're too biased to continue in good faith argument.
they all do, its just that some are better than others. i dont actually like php, but it has plenty of advantages when it comes to quick web app development even without googling.
had a client once where its workers were day dreaming of a job in the valley and ofc they were using python. they bashed php on a daily basis, and as they were doing it, the php api was sole codebase running in production (essentially the company’s product) and running reliably for a few years.
the python workers were still struggling with basics such as queues and isc, and digging through non existent or vaguely written documentation. was a fun experience watching them struggle as i basically cloned repos, read the code or entry points for that code and get things shipped.
since then i started loving python. development is slower and my invoices keep coming. love it. occasionally i write some lib thats already been implemented in plenty of php and nodejs packages.
oh same client had a ruby codebase that kept failing and couldnt find devs to work on it. fun times.
Please don't dismiss comments for grammar or spelling mistakes. These are not substantial criticisms of the argument being made, and are IMO a form of ad-hominem.
I would be grateful, if you could explain which of the guidelines I may have transgressed. I read them all and searched "grammar". Nothing comes to mind.
My own comment was precipitated by the sneering tone I read in (sic!)
Which itself points out a grammatical mistake unnecessarily. Then compounds this, by making a more egregious mistake.
Really my comment was making the same point. Don't point out grammatical mistakes, which is the precise purpose of (sic).
My last interview: the interviewers said I was the only candidate who didn't Google any syntax or articles after being given a small 60 min development task from scratch. I was applying for a senior dev role and if I couldn't deliver a tiny web app, I wouldn't hire me either. I could have just solved the task procedurally but I asked if they wanted to see a more OO solution to demo a bit more knowledge. I think back to that time and think how poor my env/tooling was back 5 years ago compared to today. I'm way more powerful now. Version control. Docker up an entire server architecture now with separated proxy, web, db server, env configs, & more. I routinely challenge myself to starting scratch projects to test myself because I rarely work on greenfield projects these days. When I encounter resistance in the workflow, I work to solve the roadblocks. I think this is an important dev exercise that brings alot of satisfaction. Constantly improve your tooling!
It’s impressive what you say, but I would hire someone that would need to google to develop something if they were to code it quickly enough and to code it well.
Personally I make no attempt to write code without googling. In my position as a robotics engineer my work covers such a breadth that I guess I just outsource my memory to Google. I don’t remember the syntax for many common Linux commands. I don’t remember how bash scripts work. I constantly look recommended ways of solving certain problems. Google is just integrated in to my process.
This applies to me as well. There are lots and lots of small things I do so rarely that I just can't keep the details in my memory. And I really would love to be able to type "man scp" and on the first lines of the man page to just get a couple of basic examples that I could basically copy-paste and change the server addresses to suit. But instead I get a ciphertext of all possible flags I can use, so in the end it is just faster to go directly to qwant.com and type "scp example"
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.
To make you less fragile to disorder. The things you do regularly are trained into you by repetition. You practice under developped skills to stay flexible and able to adapt.
Very similar to physical fitness. Sitting all day trains you to sit. And that’s making you more fragile
I think I would die from boredom if I had your job doing the same thing which I know how to do over and over again. Wouldn't you just automate something like that with a Factory in Java? Somehow my brain works the exact opposite if I already know how to do something without googling it then it's not interesting anymore and I move on to the next thing outside of my comfort zone.
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.
>I would not be surprised if even Professional Web Developers cant do it. Especially if you include deployment.
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.
Some developers already livestream on YouTube as they program up web apps or other software. George Hotz for example used to livestream on YouTube/twitch. You can find many others.
I'm reasonably sure I could write a basic site, make it look as good as I can make things look given my sense of design, without searching.
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.
> I'm reasonably sure I could write a basic site, make it look as good as I can make things look given my sense of design, 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.
I didn't say it's a valuable skill, in fact as I said it would be slower for me to do so (which maybe I should have said significantly slower) that's a pretty strong indicator of its lack of value. I should also say it would be worse quality - because if I needed to add some JavaScript functionality I would need to be able to use the syntax I remembered and not what I could look up.
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.
Yeah, so the big problem is every software project has some initial parts you only have to do once and then 99% of the project is just extending and improving the project using the same flow over and over.
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.
I have been a react developer for 3 years and I don't even know how you set up a react project from scratch since it was already done when I started the job. I assume its pretty easy with lots of info available online though.
331 comments
[ 3.0 ms ] story [ 277 ms ] threadKind of a non-article. Could I make an outdoor irrigation system, fix my head gasket, or anything else complicated without doing some research?
"Or even deeper, does an over-reliance on documentation indicate a lack of critical expertise that will ultimately result in considerably lower job performance?"
I don't think so, and I don't know why relying on documentation would be bad.
In a more general sense even for making a todo list app I'd imagine the fundamentals aren't changed even across frameworks e.g. of when adding a todo it needs to be added to some sort of a list.
Of course, it shouldn't be that Google specifically is necessary - just some literature or reference source (i.e. consulting with someone).
> To be fair, I'm not a web developer so I'm not entirely shocked by this. I only have the itch (and time) to throw together a small web app about once every 6 months.
A better rebuttal is, do you make a [small] outdoor irrigation system or fix a [simple] head gasket "once every 6 months"? I added the adjectives to better compare to his stated "small web app".
I think it's reasonable to expect someone who "throw[s] together a small web app about once every 6 months" to be able to do it without googling, but it isn't how software development is taught. When studying something to master it you start with the basics and do them over and over until you understand them. We don't (tend to) do that in software development, I think for two primary reasons: 1) there's more "important, urgent" things to do and 2) things change so quickly that probably half of what you learn today will be unused in a year (of course if you learn the very basics those rarely change, but I'm talking about the things we all know change so frequently, but were good decisions at the time)
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.
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.
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.)
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.
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.
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).
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.
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.
Or more simply, can you write a web app without internet access?
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?
Dash [1] does package up StackOverflow and a bunch of library docs too.
[1] https://kapeli.com/dash
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.
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.
Also, as if no internet access = no refernce.
Sounds wonderful :P
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.
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)
> 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.
I do a lot of webdevelopment and have zero issues.
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 ^_^
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.
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.
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).
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.
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.
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.
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.
Sorry about the snark and completely missing the point of the article.
My first thought was, OK I'd probably go back to some projects in my bookmarks db that seemed interesting last time I was looking into web apps. HTMX maybe. That project has some good examples in the docs.
Googling can help in some ways, but it's also casting way too wide a net in others, especially if you keep repeating that step. It's like walking out into the street and shouting, "I WANT TO BUILD AN APP" infrequently, and then wondering why you keep doing this instead of building apps.
Perhaps it would help the author to think more about creating their own process for selecting, refining, and testing methodologies first, then ramp up to building an app second.
[1] https://www.goodreads.com/list/show/96192.O_Reilly_s_Pocket_...
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.
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 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.
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.
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.
most frameworks come either with examples or commands to get your started. symfony even had their docs available for local reading as well.
with python i always have to delve into reading obscure documentation that either makes no sense or is not up to date. and there are too few packages for what you normally need in a scalable app. so yeah you can write php code without googling, as long as you are not a complete noob in web development.
if its 2021 and you still write code using vim and niche languages then you are doing it wrong, and indeed google is your only hope.
had a client once where its workers were day dreaming of a job in the valley and ofc they were using python. they bashed php on a daily basis, and as they were doing it, the php api was sole codebase running in production (essentially the company’s product) and running reliably for a few years.
the python workers were still struggling with basics such as queues and isc, and digging through non existent or vaguely written documentation. was a fun experience watching them struggle as i basically cloned repos, read the code or entry points for that code and get things shipped.
since then i started loving python. development is slower and my invoices keep coming. love it. occasionally i write some lib thats already been implemented in plenty of php and nodejs packages.
oh same client had a ruby codebase that kept failing and couldnt find devs to work on it. fun times.
That's literally what I keep hearing since 30 years lol (for vi proper not vim, that is).
This comment is only precipitated by your use of (sic).
If you are going to point out others' mistakes like that, it would be better not to make any yourself.
There are many ways to rewrite your grammatically incorrect sentence. Here's one:
That's literally what I have been hearing since 30 years ago lol
Or another: That's literally what I kept hearing for 30 years lol
For clarity, I have no problem with these grammatical errors and beg understanding for my own.
Please lay off pointing out others' mistakes unless they impede understanding.
Please don't dismiss comments for grammar or spelling mistakes. These are not substantial criticisms of the argument being made, and are IMO a form of ad-hominem.
My own comment was precipitated by the sneering tone I read in (sic!)
Which itself points out a grammatical mistake unnecessarily. Then compounds this, by making a more egregious mistake.
Really my comment was making the same point. Don't point out grammatical mistakes, which is the precise purpose of (sic).
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.
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.
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.
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.
Granted, this assumes that the deployment target is ready to receive the deployment payload...
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
I can make a basic web app without googling.