“Google” programmers. How one idiot hired a couple more idiots

I have a parallel term I use, jiggle programmers. They can jiggle code around until it works, often working off existing code. They may become obsessed with refactoring because it's the only kind of programming they really understand.

They usually cannot write code from scratch, or when they do it contains a huge amount of plumbing copied from other familiar codebases without any reason for its purpose. It's kind of like they can read a foreign language, but they cannot speak it. Or maybe a parrot who can produce the sounds without the meaning.

I do think Google has caused some of this. But the other secret, I think it's how most people program by default. Animals largely learn by copying. The deconstruction of concepts to primitives, and synthesis of these primitives into new ideas if a very academic way to approach things. Centuries have proven this approach is superior, but it takes a huge amount of effort, and many things are lost in this process. (Ever do a physics problem with spherical cows?) With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation.

So many interviewing red flags. The author does not seem to be interviewing critically – figuring out the skills to test and how to test them – but rather applying the techniques they have heard about or experienced themselves without consideration.

There's a difference between programmers-who-google, and programmers that can only google, and I don't think the author is on a path to identifying one from the other, but rather has decided that googling things is wrong.

I've conducted a lot of programming interviews, and I've always let candidates google and even encourage them to ask me for my thoughts and opinions. It's clear from what they ask, what they search for, and how they apply that information, how they go about solving problems and whether they truly understand the problem they are solving. Also by being present the whole time it's also obvious if the candidate works at the level of copy/pasting answers from the internet.

The best engineers know how to ask questions and search for things in order to boost their productivity, while knowing enough about the problem to not be limited.

This article has just enough ambiguity for the author to be seen as either an insufferable dickhead or a decent person in a bad situation

If he's complaining because his employees haven't memorized some niche part of documentation by heart and - gasp - need to look something up, then he's the former

But if he's complaining because employees don't understand basic fundamentals like scope, then he's entirely in the right

Actually edit:

> I started with offering my help. Can't solve a problem? Come get me. I will come over, sit on your chair, and finish your task. You'll sit next to me and memorize the way the work should be done.

I don't like this, It seems like bad management with subtle insecurity. imo it would be better to show the employee how to go about solving the problem themselves so that they can do it and feel confident in their own abilities, as opposed to just doing it for them

Can you imagine working somewhere and then, one day, some guy comes over to "re-interview" you :D Hilariously bad people management.

> I kept freaking out and yelling in chats

> The people could have lacked a kick in the butt

> remote work was to blame — it made it hard for me to use my charisma

Employer of the year award?

Can someone help me understand this copy-paste issue?

I heavily rely on StackOverflow like most devs but I’ve never been able to straight rip something from SO that didn’t fall under the following categories:

- Extremely simple, but I missed something causing me to have to Google the error

- One-liners to short functions that do some common tasks for me, and is faster for me to copy rather than write.

- Language specific syntax for when I’m switching to a language I’m not as familiar with.

I’ve never been able to copy paste any meaningful code off of the internet. As in, code that could reasonably be significant in the project I’m working on. How would you even find code that complex anywhere? Are people genuinely upset that someone would copy simple stuff off SO instead of writing it on their own?

This essay doesn't make its point well. There's no lesson in there about how knowing the fundamentals is helpful.

Here's how I would say it:

- You can only get so far with Googling. You can find an awful lot of solutions to little problems, that's for sure. But you need to understand how to integrate whatever you find, and that's not always trivial.

- There's no level at which Google isn't a necessary tool for coding. Top programmers will Google stuff, just like a top author might open a dictionary.

- The CS fundamentals, basically DS&A, sometimes surface in order to bite you, and if you haven't come across them, they will do so silently. You can't google it if you don't know what Big-O is.

- The engineering fundamentals (perhaps loose coupling? perhaps requirement scoping?) will certainly bite you, and they are also not something you can google.

- When you're interviewing, you can test for simple things that can be googled. You can chat about the other things without being able to test them.

The distinction between these 2 types of programmers predates Google by quite a bit. I worked in user research at Microsoft in their developer division in the lat 1990s and early 2000s, and we were well aware of the difference between "systematic", "pragmatic", and "opportunistic" programmers, and ensured that we had tools and offerings for each. The opportunistic programmers were most numerous, and preferred to copy and paste their way to success.

> I started with offering my help. Can't solve a problem? Come get me. I will come over, sit on your chair, and finish your task. You'll sit next to me and memorize the way the work should be done.

> I thought the remote work was to blame — it made it hard for me to use my charisma

Pure narcissism

Well, welcome to the Russian mentality. During my past life in Russia, I was interviewed many times for local companies, and it was not always a pleasant experience. Questions like "name all the IP packet fields with their lengths, in the right order" were not uncommon. For the past decade, I've been working outside of Russia. The interviews I had in Western companies were easier (even for faang), but deeper. I have a few theories that might explain this, but it's really hard without historical context. In a nutshell, most of these guys had Soviet parents, so they inherited the Soviet culture from them. Arrogance, humiliation, and rigidity are part and parcel of it. Still, I believe, that author has made some valid points, but the article itself is just difficult to digest for the unprepared audience.

Not only he didn’t imagine candidates would Google interview questions, but he also didn’t sit and watch they write code. It’s not an interview, it's a take home assignment, but in-person.

You get very few signals just looking at the finished result. You should let the candidate ask you questions and progressively improve the solution. And you should progressively make the task more complex, because it’s not a binary evaluation. A good code interview must rank candidates.

There there are chefs, people who understand chemistry and use their foundational knowledge to cook interesting things and make up new things, and there are cooks who take a recipe and follow it to produce a dish.

Really good cooks have experience around cooking dishes and know that they can substitute somethings, they can cut down on the butter and it will taste just fine, or that it needs a bit more ginger than the recipe asks for.

Really good chefs can be handed a recipe and transpose it to use different ingredients or meet different needs (Vegan? no problem! Gluten free? Gotcha!, Etc.) They know their transposition will work because they understand the chemistry that is creating the texture and flavor of the dish they are preparing.

I tend to think if software engineers as the folks who understand the principles behind computation, data structures, and languages which informs their choice of algorithm, or their effort to transpose an algorithm to meet the current need.

I think of coders as the folks who understand how the code they are looking at works and can adapt it to their needs, as long as those needs are not too far different than the original purpose the code was written for. In that case they go out and search for a different chunk of code to start from.

> I thought the remote work was to blame — it made it hard for me to use my charisma.

Big oof.

> I understand when you surf the net to figure out how a new technology works. Or when you need to use some exotic feature and not to bloat your head with unnecessary information. But basic things! How can you copy-paste basic things from the Internet?!

I'd say basic things are the unnecessary information that you shouldn't bloat your head with. You don't need to remember if it's "split()" or "splice()" or "slice()" because you can Google it in a second, but you do need to remember how advanced concepts work.

Lots of bad takes in this article.

If your Google programmers were delivering until the bloody pandemic, there's nothing wrong with them.

Sure, maybe they're not experts in every API - but they proved for months their productivity, in easy and hard tasks (by your admission).

As an engineering manager I've dealt with covid performance issues in three different companies (two of which were already remote pre pandemic).

Incidentally I've dealt with performance problems for depressed people a few times in my career and COVID performance issues felt exactly like those. It just happened to the majority of people.

Turns out that if you do everything possible to remove everything that's good out of people' lives, their performance suffer!

I really don't understand how you can go from what happened to you to "my engineers know to code only with Google" but you should really rethink that.

I wish you and your teams well.

This is a lot of words to double-down on a false dichotomy: that you either copy paste code from the internet or you write it painstakingly from scratch.

IMHO you don't pass junior level without the ability to efficiently google for solutions at the right zoom level. This starts with understanding what you are reading and the best way to use that information, whether it be integrating a library, integrating a small snippet, disregarding as inapplicable, or mixing and matching ideas from multiple sources.

The very specific conclusion that the author jumps to lacks nuance. It's hard to say based on this whether the programmers are as bad as the picture he paints, or if it's primarily a management failure.

In Portugal my younger brother was on the second year of software engineering at a university, I wanted to see his progress and how he programmed but was disappointed.

He did not know how to program at all.

The teachers were lazy and repeated the same exams and activities year after year. Too many students took the easy path and either copied the answers from previous years or would google some snippets.

Worst: teachers didn't care if the code would compile, they would grade the effort.

In the end students would pass the year with positive grades (public university) and my brother would graduate next year without knowing how to write code on his own.

I hope that not too many students follow that lazy path.

The writer never talked with the interviewees about their code? I’ve made the same mistake as him (seeing great code from a candidate and not pressing further), but it’s fixed pretty easily by asking them to walk you through it.

> I started with offering my help. Can't solve a problem? Come get me. I will come over, sit on your chair, and finish your task. You'll sit next to me and memorize the way the work should be done.

> I thought the remote work was to blame — it made it hard for me to use my charisma

And other "gold" hidden in this article.

The premise is also ridiculous. Everything went amazing for 6 months, then the pandemic hit, people worked from home, and suddenly couldn't google anymore? Or does the author have a linear scale in mind, where the longer the project goes, the more understanding it requires?

Come on. As a 20 year software professional, whose software the vast majority of Americans interact with daily, I still google the most basic stuff. Daily.

I don't think this is the right takeaway. Yeah, it's a problem if programmers have to copy-paste solutions from Google in order to do anything. However, sometimes people just search it because it's helpful and quick. Does not necessarily mean they don't understand it. Could be something as simple as clipping something out of Go slice tricks, or as advanced as "JS debounce function."

For a novice who is struggling, they might literally just copy-paste the solution, but for someone more advanced, I expect they will read it, try to gather the bits of nuance (some of it may be realizations like "oh, I need to use len-1 here because this bound is inclusive", or maybe something more practical, like, "oh, I need to decide if my debounce function should fire on the leading or trailing edge of the debounce.")

If they're literally copy-pasting the whole solution nearly verbatim, without really knowing what's going on, then maybe it's just not a very good interview question.

"monotonous, similar tasks. I kept freaking out and yelling in chats.

I thought the remote work was to blame — it made it hard for me to use my charisma."

What now?

Many commenters here seem to miss the humor and self-irony. I find the article well written and it has an unexpected turn.

And we all know that everything is true. The amount of programmers who write things from scratch is tiny, and ironically it is usually a thankless task.

Often, you get ahead by stealing or churning around other people's code and being a ruthless politician.

The author is extremely naieve if he never considered that candidates would Google the solution. How did they make it through the rest of the interview process, let alone years of working there, without him noticing that they actually couldn't code?

I see this a lot. Usually these programmers are capable of much more, but the system they're working on is too convoluted and they've given up on understanding it, instead they rely on people like the author of this article, the one person who understands the entire system. Problem is, usually that one person doesn't understand the entire system. I'm experienced enough to know that when you see a complicated system, and a wise old guru claims to understand it, that guru is probably an idiot or a liar, and you should seek to understand the system yourself from first principles.

My rule as a professor (who had actually worked as a dev in the past) was simple: I don’t care if you use code samples, but I will ask very specific questions on how it works and I really care if you don’t know.

There is a perfectly reasonable, fair, simple, and drama/angst-free way to dispatch this problem.

"Can I just google it?"

"Sure. That's just not worth very much to me that's all."

Now if they don't like that, which of course they may not, at least you don't have to struggle with the changing norms or fairness or anything like that.

Put that way it's very cut & dried and up to them, as long as you're at least willing to help them succeed if any decide they want to take up the challenge.

Mean time you can still get some product out of them, and they can still just google if that's all they want to do, but there is no reason to pay them like rock stars if they're not. And that's your answer to your bosses too.

And you can keep an eye out for better developers at the same time with some budget available to pay them, or maybe identify at least one potential for training up from within your existing team. There probably is at least one who would take to it even if they aren't impressive today.

Copy-paste interviewer hires a batch of copy-paste programmers & lives to regret it. There, I just saved you 5-10 minutes.

Simply put, you're a bad interviewer and a terrible boss.

> An old man who is also a deputy dean and associate professor told us: "The university does not give you knowledge. It teaches you how to get knowledge on your own."

This is laughably untrue and, oddly enough, the part of this post that left me most bothered.

I’m not sure what was the type of problem that he asked the engineers, for which they could simply copy and paste “perfectly optimized” answers from the internet… I suspect they were just some common algorithm questions, supposed to be answered in a very popular programming language. Then of course this is what he would get as a result. Still can’t deduce from this that paper-based interviewing is the answer. For a customized coding challenge with moderate complexity, I can’t foresee this kind of issue easily arising.

Author seems to have struck a nerve with many such programmers in this comments section.

We all jiggle bits of code around to some extent. I doubt everyone here is writing their own lang/interpreter/compiler/std library/network stack. I think the offending part is not understanding what the hell you're jiggling around.

BTW as bad as the "jiggle programmer" there's the "superenterprise software engineer" who can't ship code because they spend way too much time writing stuff from scratch, making sure it follows all the good principles and software patterns, and that the code is super optimal and covers all edge cases.

I am a bit skeptical about this article.

There are no technical details on language/framework/problem domain. No code examples.

Surely those "Google" (or jiggle as another post said) programmers had some understanding of coding.

Otherwise they would get the wrong Stack Overflow answer and things would inevitably go horribly wrong.

They were doing the right thing for the business for many months. They might not have been able to program from scratch but that is not required most of the time these days.

That is if it is stupid and it works it is not stupid.

Programming is mostly copy/pasting from stack overflow and example codes. (if you write documentation make sure to have great examples). Then there are software libraries for about everything, and compilers do the optimization for us.

You only learn stuff (become a good programmer) if you are forced to. Examples when you learn is when debugging, or working with constrained resources, you are forced to optimize or scale up, your service goes down, data gets corrupted, you are getting hacked, etc.

I participated in the interview process at work for a number of candidates.

One of them was clearly glancing at code from the internet on video as they worked through the problem. The other produced a lovely recursive solution (when recursion was not called for); but googling for solutions to the problem produced nearly verbatim code as the first hit. Neither of them could discuss their solutions at a high level.

This is bad advice. It sounds like the dynamics of a dysfunctional, low performing organization.

In general, please don't blindly follow the advice of random people on the internet (including me!). There is plenty of advice around from reputable people with experience building and scaling high performing teams. My latest favorite is "An Elegant Puzzle" from Will Larson.

A friend of mine was just telling me about how the programmers at his job fix bugs by adding special cases at the top layer instead of by digging down and finding the root cause.

But my friend is old school and can't bring himself to be so hacky... But this means his co-workers close more tickets and it looks bad for him.

Unless it's trivial or fresh in my mind I will Google the problem in the hopes of finding a library or an interesting discussion in the first page. If I can't find anything I implement it to the best of my ability. If later I find a similar problem I will grep and copy my own code. There's no shame in being curious and lazy.

I spent a lot of time on a project run by people like him. The leads kept trying to figure out why the coders were lazy idiots while they constantly reshuffled requirements, switched around the organizational structure, pulled them between projects, heaped on unclear requirements, yelled in sprint reviews, etc.

Copy paste is good if you understand the code, bad if you don't. Not sure why it needed so elaborate blog post. As a developer you have to understand the problem domain, the tools and solution. That is basic requirement.

I wonder if the author of this article has an existential crisis when typing `#include <stdio.h>` in a C file, since they didn't hand-craft the formatting and printing capabilities of the standard library.

Interesting how the author never considered re-training their programmers instead of "re-interviewing" them, after all they were not far from understanding the basis as he claims.

Imagine the productivity levels as people are preparing for their quarterly re-interviews.

And then productivity and moral levels after you let go your good devs that suck at interviewing.

This article needs a name and a company name on it, so that I can avoid ever applying to a job that would involve working with this arrogant reductionist egomaniac.

There might be some substance to his gripes (I doubt it), but his method of interacting with other humans sounds frightfully flawed.

And it's just more of the pompous assumption that somehow the actual mechanical writing of code is the hard part of this job. It's not. The hard part is business requirements, task management, figuring out what the next and right thing to do is. Very rarely is our job a simple matter of writing code, the actual programming is often only a small part and most people's productivity issues tend to boil down to handling and understanding ambiguity or conflict in the business requirements, or motivation around them, or dealing with piles of legacy crap that needs to be cleaned and managed before moving on... not the coding itself.

A bunch of junior or new hires get sent home to do remote work combined with a guy who admits he "yells in chat", yes that sounds like a disaster.

And honestly it wouldn't surprise me if that's where the whole thing was falling down, not the competence of the programmers he hired.

"Look you missed a semicolon on line:x, column:y"

v/s

"Don't you know, you missed something? look again!"

Honestly I think we need to face the hard truth: the majority of humans do not deserve life, they do not work hard enough, they are lazy. They are being propped up by our over abundance. We should aim to replicate an impoverished condition for them so that they can see why they need to work. It’s not optional

"I kept freaking out and yelling in chats"

I think the interviewer is the problem....

> I kept freaking out and yelling in chats.

Sounds like a joy to work with.

Doesn't mean you need to watch over people's shoulders as they complete interview problems though. It's plenty to just discuss their solutions with them afterwards. Quickly becomes obvious who actually understands the issues at hand.

i didn't learn anything here but i was amused :)

I would be very interested to hear viewpoints from the supposed 'Google' programmers on his team. The fact that he didn't gather feedback from the team makes the whole thing rather suspect.