> 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.
I suspect that the author would argue that more competent programmers would use their IDE's statement completion functionality to quickly determine the function name, or which of the functions to use, what arguments to pass, and what return value type to expect and how to use it. That their knowledge of the language would allow them to write the code faster and better which such tools, rather than copying something from the internet.
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.
The original author is Ivan Belokamentsev (as mentioned) and judging from his Habr profile you won't meet him unless you are willing to move to Russia and learn 1C (https://en.wikipedia.org/wiki/1C:Enterprise)
Wow, well said. It is so true that effective programming really requires a lot more support, especially around the product/business/project side. The smaller clear the chunks of work, probably the easier it is to reason about and complete.
I remember this personality being common among programmers from eastern Europe. By no means universal. If you work with these types you just have to have a thick skin. I think they generally mean well.
Maybe the internet is creating a situation where the workplace is no longer populated by a Dickensian cast of oddballs, but I feel like super polite workspaces where nobody ever calls people out and everyone is given pats on the back lack something as well. And under the surface is often disdain that is never voiced, just acted upon.
> I remember this personality being common among programmers from eastern Europe
This is HN and I do not want to make a personal attack or anything against you. But this comment is clearly discriminatory and, frankly, what ever a light version of "racism" is. Please stop generalising millions of people based on some anecdote and spread it online. Eastern Europeans are already marginalized in the Western software world, and English is a non-native language to them. They are as diverse as you and me
As someone from Eastern Europe I can relate the comment of @projektfu to myself and I do not think the comment is derogatory. There is some work ethic in Warsaw pact countries that is totally absent elsewhere. A topic for a PhD in anthropology, for sure.
The Dutch, the Israelis and everyone east and North of Germany. It's pretty refreshing in some respects, but the friction between these blunter and less blunt cultures can be massive.
The funny thing with Dutch is that Dutch speakers from Flanders are as much snowflake as everyone else.You really have to have this North Hollander protestant past to stand out.
You should read more about what racism is before you go around accusing other people. Or perhaps better, stop reading so much about racism that it makes you confuse a personality trait with a race. Such a personality is common among young white left men, please stop spreading that online. It does not contribute to diversity, but only divides.
Why? Nobody said one is better than the other. Are you going to pretend all cultures are the same? if you've ever traveled or lived abroad, you will quickly come to the conclusion that there are major differences in how (say) Eastern Europeans approach communication vs people from the US. And that's okay. Nobody needs to be offended.
I live in Eastern Europe (Bulgaria). I have lived all my life in Bulgaria. OP has it spot on. Stop being "offended" on my behalf. I would much rather be stereotyped, offended, called names, discriminated against, etc. rather than have one of your ilk try to come to my defence.
* it is true we are more blunt than a lot of our Western colleagues
* blunt does not mean impolite -- I always try to say what I mean with plenty of layers of courtesy, but I do not mince what I mean
* the guy in the article seems like an asshole by Eastern European standards too (mentioning "my charisma" is pretty egoistical no matter how you spin it)
> Eastern Europeans are already marginalized in the Western software world
Not completely wrong but I'd say the software industry is the place I have felt the least marginalized. I left Eastern Europe and finding a job in the software industry was very painless for me, while other places would wish for perfect command of the local language, or discriminated against me almost explicitly. Which leads me to your next point..
> English is a non-native language to them
While true, it is rather annoying to have people hold this over your head when you speak and think in English for decades. I'm more well-read than half my native English colleagues who haven't picked up a literature book since high school, yet being "non-native" means that I constantly have people doubting my ability to speak English. At least I no longer have to hand in TOEFL exams to prove I can speak the language that I think in 24/7, including when I'm talking with my workmates, girlfriend, showering, taking a shit etc..
Reminds me once trying to get an answer to a noob question about some Cisco equipment. Want to talk toxic culture, Cisco networking services, totally toxic. Couple of forums where someone asked the same question just received smug non answers in response.
Finally found a Russian lang forum where it seemed someone asked and a long response. I used to google translate. Half the response was the author insulting the guys mother followed by a detailed profanity laden answer.
Your comment reminds me of Jeff Goldblum’s character in the movie The Fly, when the reporter asks him how he could have built the teleportation system by himself and he says:
“I don’t work alone. There’s a lot of stuff in here that I don’t even understand. I’m really a systems management guy, I farm bits and pieces out to people who are much more brilliant than I am. But none of them really knows what the project is. I say build me a laser this, or a molecular analyzer that - and they do, I just stick them all together.”
I recently had to build an e-commerce portal for our customers to be able to order 3D printed parts on-demand. Did I write my own algorithms for rendering 3MF files and calculating the volume of a mesh? Nope, I just used three.js and a mesh volume algorithm I found on Stack Overflow and problem solved.
Eh; I encountered one of these "Google" programmers before. It was exactly as the author described. Fortunately, they did something unrelated that gave us no choice but to fire them.
Most of the skills you mention (business requirements, task management, spelunking legacy crap, etc) only really matter in large organizations, where human coordination costs and tech debt management dwarf actual development costs.
In a well-run small org, ICs can get by without them by having an occasional coffee/lunch/beer with the CEO/CTO/Sales head.
I've worked in both kinds of companies and plenty inbetween and I have to disagree. In small companies having a good handle on the business requirements is even more important, and it's frankly even more the case that it's not a simple matter of "how" you program but "what."
In a small company a frankly larger percentage of company revenue can be wasted through crappy project and product management. Coding it poorly is often the least concern at places like this. It's getting the right thing to market.
Come on man, junior or mid level engineers are suposed to do well defined tasks, or projects. It is part of the Team Lead, Lead/Staff engineers to reduce the business requirements to a relatively well defined project.
That's how most mid level, and large companies work. You are not hiring an engineer with 2yoe to 'coordinate business values', unless you work at some scrappy startup.
The original article has a good point: Young engineers are so used to google for everything, that they often don't understand the code, or framework they are working with.
Back in the day (prior to StackOverflow), we called them "Framework, Glue and Paste Engineers". Basically people that used frameworks without understanding what they did. It was fine for basic stuff, until the point you crash servers because you have no clue what did Hibernate do under the hood with those queries.
Anyway.... the article is clearly aimed at more junior hires.
I am in the opposite camp. I want to work for the author of the article because he gets it and he has humility, a trait that top level commenter (who informs us unironically in his profile that he likes grapes and other plants) needs some work on.
Indeed. The author just wrote yelling. Given the Russian culture I suspect he was yelling in chats about the situation, not blaming a particular person or team. Something like “Why the hell have we stuck?” perhaps even with f-words. Boss expressing himself in such way is rather common in Russia. If such yelling is followed by reasonable suggestions, it is not even perceived as offensive, but as the way to emphasize the gravity of the situation.
Sure, re-reading it I do pick up that the author was perhaps attempting humour and self-criticism throughout. But there's still boatloads of red flags starting with the interview process (toss them in a room and get them to write some code as the measurer of the value of the candidate) and ending with the whole concept of "re-interviewing" people.
It doesn't matter how humorous or humble the author might be, these alone worry me. Y'know, me, that arrogant guy who likes grapes.
In any case it's clear the original author does not live in a tech job market anything like North America, where a request to "re-interview" someone would be met with a confused stare followed by a middle finger.
This is only true if you're a beta bucks provider doing CRUD to support a family. There are plenty of real programmers out there working on their own projects and the hard part in these WORTHWHILE projects is certainly the programming :)
I have my own personal projects and on them, yes, the programming is the hardest part.
Leading a team or joining a new one? It's translating what the company needs into the set of instructions. Ambiguity in that process leads to stalled juniors, even if they're excellent coders. I've been there, both as the frustrated demoralized junior and, later in my career, as the team lead trying to make that process work.
Yes, I'd be concerned if someone literally cannot write compilable code in the programming language you're working in. But usually if someone makes it far enough to be employed there's something else going on if they're producing serious garbage. Skill, attitude, motivation, team morale, or bad instructions and bad leadership. Honestly, my experience in seeing teams dysfunction is that it's best to start from the end of that list and move backwards.
Honestly, having done everything you listed above over couple decades: no, not really. Developing code is still the hardest part. It's a lot harder to get a good programmer with consistent output you can rely on your estimates than an ass to warm a seat in Big Picture meetings.
I am so glad this is the top comment. The author of this post sounds like a horrible person to work for.
Also, we need to deliver a swift kick in the nuts to this unlimited growth philosophy. People under you NEED to plateau, that is their comfortable level of productivity. You don't force growth, that is something that comes naturally and at an unpredictable pace.
The issue isn't that they plateaued, the issue is WHERE they plateaued. If you get most of your code output by googling, you're going to plateau pretty early.
If you're also getting thrown into dealing with COVID lockdowns and WFH-related organizational overhauls, and then get yanked back into the office months after that, that's going to do a number on your productivity, too.
Leaving them in the room to complete the tasks was an early red flag here. If you have no insight into how people think about and complete tasks then you are testing the product of their time, not their approach to problem solving. You then shouldn’t be surprised by the lack of what you didn’t test for after the fact.
Because the "engineering" part is literally all that other stuff which is actually quite hard. Just like a civil engineer doesn't pour concrete for a living, we don't write sort or string search algorithms for a living, we build solutions that solve company problems. Usually using someone else's well-built sort or search algorithm. When I need to write the latter, I reach for my Knuth books.
That said, I still bridle at the term "software engineer"; I mostly accord with Alan Kay's quote "Software engineering hasn't happened yet."
I am the OP, and I don't think I've ever had a project or product manager who gave me sufficient detail such that all I had to do was walk away and "write code."
Problem solving skills required and a bunch of questions. What really do you need, how important is each part of it, and who are the other people I need to talk to help make this happen? Being able to ask those questions and produce code from the answers is what we get paid the big bucks for.
I'm not seeing a good reason to assume these people were any better at business requirements etc - if only because Google is going to be even less help with those.
We've had this before on HN. Student and work culture is changing from "Work it out for yourself because you're a skilled professional who understands how to solve real problems" to "Copy it from someone else without understanding anything about it because that's what you did to get your expensive degree."
It's not so much Google programming as Lego programming. And it's a terrible way to approach any kind of engineering, at any level.
Of course it's fine to import good existing solutions if you know what you're doing with them. But Lego programming is not that.
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 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.
Jiggle programmers isn't a type of person, it's a phase juniors go through. There's a lot of stuff to cram into your brain as a junior, and when you don't have a complete model of how things work it can be basically impossible to come up with an approach that has a chance of working on the first try.
In my opinion the way to get them through it is loads of pair programming and stopping them and reminding them they haven't stopped to think about the entire context when you catch them doing it (or when they come to ask for help in the ideal case).
I'm not sure if I ever went through this phase, but not everyone has the luxury of developing their programming skills at a leisurely pace from highschool all the way through college.
Strong junior programmers usually fail by rewriting everything from scratch, having no concept of DRY, libraries, or how to effectively break logic into methods. But inability to generate their own code is not a common failure mode!
It's only weak junior programmers (that is, people who simply are not going to become strong developers) who approach a problem and, in the absence of the ability to write code from scratch, try to find something to copy-paste.
> But inability to generate their own code is not a common failure mode!
This has been my experience too. It's also common (maybe even nearly universal) for devs to go thru a stage where "rewiting" feels like the path of least resistance. This is usually (not always) wrong, but until you've ramped up in several very different codebases it's difficult to see how something so foreign can end up being as productive as what you're used to.
From my experience that's the "final" phase of being a junior. Where you're perfectly capable of coming up with architectures, considering functional constraints and relationships to hardware. Maybe such a junior is fresh out of university, or has spent 3-5 years working programming jobs after high school. They'll have their head full of fresh strong opinions on what's good, and have had some experience with what happens when things go wrong, and maybe mistake code they don't understand or find hard to follow for bad practices.
I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.
I've done it. For me it is when I don't actually understand the thing someone else wrote.
It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something.
So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes.
But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code.
My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc.
I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.
But isn't this stage supposed to be over after school? I mean, i was pushed towards rewriting everything during my school days. We even had a graphic library with 3 functions: create windows, erase windows and paint this pixel. Rewrote printf, malloc and consorts. Once i was allowed to use glibc trees, map and hashtables, i never wrote an already existing function (maybe a ring buffer and a weird linked list)(and rewrote a scikit image filter because I was too dumb at that time to read changelogs and GitHub issues)
Strong/weak is definitely another axis. I'm not sure they could never be strong developers. I'm not saying they couldn't generate code at all, just that the first couple approaches they write miss fundamental constraints causing the code to either not work or have horrendous properties, and they sort of jiggle their way into something that works. Sometimes the initial tries come from a Google result, sometimes they came up with it themselves, the important part is they don't fully understand the code in its context.
Anyway, regardless of whether they're really strong or not, the couple I've mentored have become tremendously valuable to my company, with performance outstripping my own (I think because of the higher tolerance to shitty repetitive frontend work).
I wouldn't necessarily attribute it to juniors, it's the same if you're using a language you're not familiar with or haven't used in years.
Sure, technically you are a Junior again if you use a new technology, but assuming the MO of the language is not completely unlike one you're familiar with (for example OOP vs functional vs whatever).
I mean, at least that's what I need to do - but maybe "how was this syntax again?" paired with "I don't like these docs" might only superficially be copy/pasting from SO, because you know what you're writing, but you don't have the words of the language...
As someone who has kicked off multiple "from 0" projects, including a startup and been on the initial team doing an entire embedded runtime,
Blank source files are scary yo.
There are a near infinite number of choices that can be made when confronted with a blank file. And the ramifications of those initial choices will live on, possibly for decades! (I spent 10 years at Microsoft where it wasn't uncommon to come across 20+ year old code still in use.)
More than once I've initialized a new project, started at my blank folder structure, and spent a few minutes thinking "here we go again".
Sometimes I call this the “tyranny of choice”, tyranny is probably the wrong word but it sounds nice.
It’s pervasive in lots of aspects of my life beyond programming, where I get anxious having to make decisions. I will drag my feet to have to make a final decision, even if it’s a restaurant choice. I’d much rather have the obvious right choice in my face than have to pick between multiple good choices.
I face this same anxiety when staring at a blank source file too.
(Yes, I’m working on finding a therapist, but even picking one gives me the same anxiety)
It can be experienced in a lot of situations. Buying a burrito from Chipotle means you have to make lot of choices before you get your burrito.
This means you become partly responsible for the quality of the product you pay for. If the burrito is bad, you are to blame because you chose the ingredients. I think that makes me anxious when in Chipotle's.
In programming it does slow your progress if you have to frequently spend time deciding which choice is the best. Not only anxiety but also plain lost time.
Similar term although with a slightly different meaning that I use "analysis paralysis", when you get so caught up in trying to figure out the "correct" answer that you get stuck.
I so much hate those project generators. First thing I do when I generate some create react app is going through it and delete stuff. Everything. To start from absolute minimum.
I can accept some project generators being an option. But I never understood people who make it default way to go.
As a kid I had a multitude of "from zero" projects. There was no Internet. No SO. There were reference books and manuals but none of those really let you just copy paste your project. Later on I worked in environments with many smaller projects that again I took on from zero and worked on for years.
Boy do I miss those days now that I work for larger companies and with larger teams where the opportunity to do that is pretty rare. Give me a blank slate all day for any project.
I remember typing in programs from books and magazines. Although this is theoretically no different from copy-paste, I wonder if the slowness of the process gave me time to think about what I was typing. "Why is this bit here? What happens if I leave it out? Could I replace this with something else?" That's something you don't get today, when moving code from one place to another takes a couple of key-presses.
They are. But the more programs you write, the better you get at it.
It also helps to devise a personal architecture or two for different projects. I have some that I lean on, and that means I can bootstrap myself fairly quickly. It took a while to get there though.
I think I would identify as a jiggle programmer.
I was raised on a REPL, and in that case I find it pretty efficient, time-wise, to scribble something in the terminal, jiggle things around it until it works, and insert the working prototype into the program I'm working on.
Programming isn't my day job, but I do frequently write code from scratch (and refactor it, heh). I interviewed for one entry-level programming position; they did not appreciate my technique.
I think this approach is really common for programmers who aren't programmers first. REPL and Excel both really encourage this style due to their near instant feedback loops.
On the other hand, a generation of world-class programmers were raised on the REPL and interactivity (e.g., Lisp and Smalltalk programmers from the 70s-80s).
And interactivity can be an extremely effective way of experimenting and learning how things work and fit together so that you can rapidly develop a mental model of your core primitives and how to put them together in different ways.
It's also part of the appeal of TDD. Small iterative loops with rapid feedback.
This is a simplistic reduction of what many senior programmers do. In my experience these so-called "jiggle programmers" are ones who actually ship code and meet business needs. Sometimes that's what we're looking for. We don't always want a fresh grad who is keen on implementing a completely useless system from scratch. We need people who ship.
I think the big differentiating factor will probably be that "jiggle programmers" don't really know what they're copying or why something works. I'd hope senior programmers do.
This is why it's important to figure out what your core expertise is.
If you're copying and pasting your core expertise from stack overflow, then, I hate to break it to you, but you'll never successfully differentiate your product.
I'd wager that 90%+ of "tech" companies are hiring software engineers to "solve" technical problems that have already been solved in order to solve business problems that have not yet been solved.
Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.
> Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.
If this was true, it would bring a significant economic advantage to a startup if it would not use leetcode style questions for job interviews, but instead ask hard questions about these textbook architectures.
But someone might be able to answer the questions but not be able to build stuff. The coding portion of an interview is supposed to answer the question "can they code". If they can't code I don't think they can work in either domains (reapplying an existing technical solution or inventing one that doesn't exist). I'm not a fan of some styles of coding interviews but writing code needs to be part of any interview for a software developer (+ a lot more).
Writing code in an interview is not the same as the "leetcode" riddle questions that the parent poster was talking about. It's usually esoteric language and computer science concepts that are not very relevant to the job role.
May be true, but there is a lot of work for people that know how to cross t's and dot i's and don't need to differentiate anything, just successfully implement known solutions for known problems for N+1'th time without reinventing the wheel and messing anything up. It's not a glamorous work and probably won't make you neither a billionaire nor a CEO of a trillion-dollar unicorn startup, but there's no use denying it exists and somebody has to do it too. And if that someone won't mess up too often, they can earn their living very well.
I solve problems with software and I do both. If I can copy something it is most often smarter to do just that. There is not only copying code or writing it yourself.
Find the most readable color of a font for a given background on most displays. You could do extensive research on colors for something that on the first look sounds rather trivial or find a very thoroughly worked out solution on stack exchange.
It is difficult enough to advertise self-made software when many people are looking for off-the-self solutions. So being fast and therefore affordable is quite important.
I mostly develop for embedded systems on custom hardware so ready to use solutions are rare. But if I want to visualize process data in a browser? Please give me all your thousands of dependencies Javascript.
An algorithm I implement from scratch? Very rare. This takes time and thorough testing compared to something that is already solved.
Green-field projects help a lot for getting over this mindset. Having to figure out the right patterns and approaches by myself then live with those decisions and have to improve them down the line taught me much more than extending existing patterns in a mature codebase.
I think it a lot of it is the frameworks and people constantly trying to shortcut the method of building something with code. We have so many frameworks, tools, plugins and other stuff that it makes it easier NOT to learn anything deeply any more. Pick a JS Framework and I'll give you a dozen plugins or tools that have already been built to write your code for you. All you, as a developer have to do is string them together.
By building all of these shortcuts, no one really needs to learn Angular, you have their site as a reference and tons of material to help you. Developers actually learn in the absence of knowledge where they have to sit down and learn it without knowing there is a crutch or fallback if they get stuck. I think today's developers just get as far as they can and then start googling for a solution because they know that someone has already built a date picker in ten different languages, thousands times already. Why go back and reinvent the wheel when you don't have to?
Because it creates lazy developers.
An entirely other issue is why learn some framework inside and out if its going to be obsolete in a few years? Remember when everybody loved Backbone and Express? You tell someone in the Dev community today you use either of those and you'll get laughed right out of the bar.
I think its just a lot of things that work against developers learning more than then they really need in any given situation.
I jiggle code around until it works. But I am also very smart. If it doesn’t work by jiggling, I learn or invent a way to make it work.
I am a self-taught programmer. I copy, but I also innovate. I don’t follow at all the academic approach (I never studied CS or was very good in school). But I don’t paralyze when I can’t find anything to copy from like a Roomba stuck on a rug.
That’s fair. But I also know a lot about what I can’t do. I don’t have the knowledge (and maybe the capacity to acquire the knowledge) to work on really complex stuff. Like, solutions that work well on the scale of hundreds of millions of user (I work on web development for context). I also wouldn’t be capable of working on embedded systems or any system which just can’t fail.
Also, academic research on computer science, as I lack much of the basics.
I am happy building websites and web apps.
But I am confident enough to know I can innovate and create complex solutions for the kinds of problems I face.
I'm guessing the reality in your case isn't quite as severe but that's sort of where some "jigglers" sit.
When I hear "I don't follow at all the academic approach" what I'm hearing is you don't even know what is actually taught in a CS degree. Might be wrong but that's what I'm hearing. A lot of it isn't really that academic but sure some of it is. I'm self-taught and I worked as a programmer before I got my CS degree (as a teenager) but my self studies included CS topics (algorithms and data structures etc.) and I never copied any code or "jiggled" anything when I got started, everything was written from zero. What I did occasionally do is implement algorithms (i.e. the algorithm is known, write the code, which I guess is a form of copying).
On the plus side you've obviously acquired some good skills doing all this and you are likely smart. If you're happy with where you are (let's call this a "Software Integrator" maybe) that's fine. If you want to become better you probably should put in the time and learn some of the things you've been avoiding either formally or on your own (unlike when I was a kid there's endless resources now).
> ”what I'm hearing is you don't even know what is actually taught in a CS degree”
This is accurate. I don’t. My impression is “algorithms and data structures”, which is fuzzy for me. I don’t care at all about algorithms. Data structures I think I should know more about at some point.
I considered studying CS after starting working with software development, but decided I don’t want to. Kind of related, but I also decided that I don’t want to study leetcode too, even though there is a financial incentive to do it.
I am happy being someone that some arrogant developers like to call “web developer”, “programmer” or, at most, “software developer” as opposed to what a “software engineer” is. I understand the difference that those people try to point out. And I agree there is a difference and I don’t care to be on the side of line that I am. It does bother me that every time I see someone making a point of showing where the line is, it’s from a point of arrogance, entitlement. This does bother me, and I felt that tone in the comment I replied to.
I'm a designer who codes in this way. I can mock out a bells and whistles prototype that appears to work splendidly enough to test with users, but in reality I'm just hooking together libraries and pasted code. I have been doing this for 10 years, enough debugging savvy to "learn" React in 2 weeks but do I actually know how any of it works on a deeper level? Heck no.
Jiggling is much easier. I could probably jiggle code in any reasonable programming language within a week or two, without knowing it beforehand. Less if it resembles any mainstream language I know. Building a project from scratch requires much more deep experience and understanding.
And yes, I learn most effectively by copying too. Showing me a couple of working project and letting me implement a bunch of simple tasks by jiggling existing ones usually works for me way faster than throwing manuals and tutorials at me. Manuals have its place - when I know enough to know what to look up - and so do tutorials, but "learn by copying" is the most optimal way of getting bootstrapped for many people, including me. There's nothing wrong with that, if you don't stop at that stage but continue learning.
I mean, why on earth would you not use existing infrastructure and always keep writing code from scratch ?
If I see an engineer constantly do this, I would think that they are insecure and are constantly attempting to prove that they are "real" programmers (whatever that means).
The way I see it, we are here to solve business problems and the chances of your problem being so unique that similar solutions don't already exist is rather low.
Let's face it, the majority of software work is pluming work and wiring APIs these days. Very few people are tasked with implementing their own sorting algorithm and even if they are, you can bet that they will scaffold from another algorithm to get started..
Yes, one should not blindly copy and paste from Stackoverflow but researching, refactoring, thinking about the task at hand and using existing tools and libraries are all part of the process.
Arg. I think I'm the opposite, but worse. I cannot finish a project. I took a 6 month sabbatical, started 5 projects, didn't finish even one. My last project i tried to use tracking/productivity tools, it doesn't change anything. I have the 'well, good enough' mentality with my own projects, and once i stop having fun coding i just stop. And start another project.
My current project is boring (especially since i finished the code logic like 9 months ago), but since I'm paid to upgrade/deploy the stuff I'm not that disfranchised. (I won't lie and say I'm as productive, I'm clearly not)
I don't think I'm really able to work alone or unpaid. Which is weird, because I really, really enjoyed the two dozen school projects I've done, especially those who took 2+months
From my observation, we programmers are supposed to have two non-discrete modes of programming: 1.) the trial&error (or jiggle) mode and 2.) the literate mode.
Trial&error mode works well when working with randoms, e.g. exploration, research, acquiring information, identifying unknowns. Literate mode works well when working with exacts. Identifications for example produce exacts from unknowns. Enough facts enables you to build stuffs out of it like Lego. This is where literate mode works well.
Jiggle programmers that does not quite grow out of their jiggling mode is because they stay in trial&error mode and does not slide slowly into the literate end of the spectrum. After acquiring some facts, they don't deduct or intuit from them. They don't attempt to philosophize a bit.
A problem as simple as "how to do X after the window loads" for example, some programmer can find `window.addEventListener("load", X);` in stack overflow, but the main differentiator lies whether after fixing the issue, they care enough to at least wonder about what's the meaning of `window`, `addEventListener`, `load`, "why is the call shaped that way", "what is Event and what is Listener". Those who do slide slowly into their literate mode.
It is also not less dangerous to be stuck in the literate mode. Although this happens rarer, often to more experienced people.
Where are these jobs where you can write things from scratch? I do that on the weekends for free to recover from all the "jiggle" tickets I get in Jira.
My impression is that a trend started in the 90s which has taken over the industry where programmers that are capable of building things from scratch and keeping everything in their heads are much less valuable compared to those who are "weaker" but much more capable of communicating and cooperating.
> I have a parallel term I use, jiggle programmers. They can jiggle code around until it works, often working off existing code.
We're all jiggle programmers then. Once the applications architecture is established, we hang new feature on it by following that architecture.
Very very few of us get to only write code from scratch every day. Most of the time, when I'm writing from 0, I'm working on a R&D PoC. If I'm not doing that, I'm jiggle programming a new feature into an existing architecture.
> With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation.
I was self-taught before university. I learned on a C=64 and then an early x86 back in the day. If you didn't figure it out on your own, you hoped you would see it in a magazine or book some place. I learned a lot about how computers worked at a fundamental level from the C=64. I don't think self-taught is the issue. I think it's how much the person really wants to know about computers and CS.
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?
A few jobs ago the IT Manager put out feelers to the engineering team asking if any of us knew anyone interested in a junior IT Admin role.
I knew someone looking for work at the time and asked for a link to the job description so I could forward it along.
In the description included the phrase “without Googling” for a majority of tasks. It’s not as if the role was especially demanding or contained a ridiculous amount of esoteric knowledge; it was the equivalent of a help desk position. I can’t imagine ever doing help desk, much less ever again (fuck that stress) or for someone who thinks it’s a role where you will never need to Google anything.
I pointed this out to my friend with a frown on my face, but left it up to him if he wanted to apply. He read the job description and said “yeah no. That boss sounds miserable to work with”. My interactions with that manager were quite minimal, but judging but the attrition we noticed on the help desk team, I think he was right.
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.
Right? It's like administering a driver's license test by saying: "Bring me back a Big Mac, a Whopper, and a Chalupa within 30 minutes" then tossing them the car keys and judging them based on how many items they successfully bring back.
Of course they're going to Google - it saves time, and the interviewer clearly doesn't give a shit about how you arrived at the solution because he literally just left the room.
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.
A lot of other people have flagged the remarks about "yelling in chat" and the like, and those are certainly red flags, but I think what you're pointing out here is the biggest problem. "Write code on paper" and "write code unattended" are not the two only available options. Worse, from the description of it as "a very simple change", it kind of sounds like he was giving them the same type of problem to solve in both cases.
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.
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.
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.
> In addition, our superiors did me a disservice — they asked me questions like the following: " Has productivity growth stagnated because of remote work?" Of course, I was saying yes.
The author took no responsibility in the situation.
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
I'm trying to imagine this teaching method being used in other disciplines.
Don't know how to drive? Watch me and memorize what I do.
Don't know how to play chess? Watch me and memorize what I do.
Don't know how to swim... etc.
Though there are some jobs where you absolutely must watch someone before you even attempt to do it yourself (e.g surgery), it's not typical and probably not needed for something like programming where you can view the source. And it'll certainly prolong the learning process compared to having people do it themselves.
But isn't that exactly the first step in how humans learn? I mean, first you watch someone drive, then you get shown diagrams and explanations on how to control the car, then you get into a teaching vehicle with an instructor - one that has a steering wheel and pedals for the instructor that can override yours in case you make a mistake on the road, finally once you're proficient enough, you take an exam and (hopefully) get your driver's license. Similarly for chess - a big part of learning chess is reading analyses of games that already happened, i.e. watching people play the game with some explanation. Swimming (or any sport) as well - the instructor shows you the motions, then you do it slowly until you get the hang of it, then get let in the deep end of the swimming pool, etc.
But these are people who already "know how to drive" in principle, they are presumably just not driving well.
The solution to that isn't to have the instructor drive them to the store and back. The right way to approach that is to have the instructor watch them drive and give them tips and feedback in real time. Observe and correct. With programming then they're running the keyboard themselves and they're the ones actually doing the work, which is going to reinforce the learning in a way that just watching isn't going to (similar to how note-taking helps to reinforce memory and learning in lectures).
This takes a whole lot more patience though since you can't just sit down at the computer and start bashing keys yourself but have to "use your words" and requires some ability to instruct.
And I've done quite a lot of this kind of mentoring at my last job and this was the approach I've most often taken.
Where I found it more useful to drive the keyboard myself was in sessions where I was working on solving problems that were at my level where I didn't know the solution. That way they could watch my entire thinking process as I figured it out in "real time" and see where I went down avenues that didn't work out and how I thought about finding the right solution, along with the workflow that I used.
I wouldn't expect anyone to be able to replicate that after they were done watching me, that is more to show where there's more room to climb.
He complains that those guys didn't perform as well as he expected. Google is not an issue, performance is an issue. It's hard to judge whether he was right without delving into specifics which were not exposed.
In the absence of any specifics about how this person was measuring "performance" or "productivity", it's not unreasonable to extrapolate from the details he does provide which reflect poorly on his management ability.
> 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?
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.
We wrote and published about it quite a lot, but none of that content seems to be indexed or available anymore. Here's some content referring to it, though:
> 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 use zero knowledge from my University. Everything I was taught, I either knew before or it was stuff that I don't use. I use 100% of my ability to learn acquired when I was there. I attended one of the best Russian Universities. So I can only confirm this phrase.
Whether that's a good way to spend 5 years - I don't know. But in practice it turned out that way.
Sounds like you got very lucky. To clarify: the (reasonably well regarded) university I attended most certainly didn’t teach me how to learn properly. It taught me how to cram to answer a contrived set of questions and then promptly forget everything. I’ve learned more about how to learn from a few short books than I did across the sum total of my university education.
> 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
The author is conceited. Sure, he might have hired some copy paste coders, but he's on the opposite end of the spectrum thinking he's royalty, blitting 1s and 0s of shellcode through his 11th finger.
It's self-deprecating humor. He knows it sounds narcissistic and expects it to be interpreted as ironic i.e. making the statement demonstrates that it isn't true. He's aware that he isn't charismatic and is letting you know that he knows it. It's like a weak person flexing their muscles to show you how strong they aren't.
(Although, there could be another level of irony, i.e. he is narcissistic, and worries you might think so, so he deploys irony to persuade you that he isn't by making a narcissistic-seeming comment in a self-undermining fashion—but I doubt it in this case).
In my experience, much British humor tends to follow a similar model (and Russian too perhaps), but I've observed that it's common for people who don't share that type of humor to misinterpret it.
I'm not so sure, and I'm a native Russian speaker, who had read the original Russian language post just to make sure of this. That guy genuinely sounds unironically arrogant to me.
It's much harsher in Russian than the English translation. Compare:
> You'll sit next to me and memorize the way the work should be done.
and
> А ты, бездарь, сиди рядом и запоминай, как работать надо.
which literally translates to "And you, bungler, sit and watch how the work is done [right]."
And I utterly fail to see any self-deprecating piece that would turn this into a joke. If anything, author treats those "Google"-programmers as trash.
Even as a joke, I would say it's very poor and distasteful one, especially for a public blog post.
To the extent there's self-deprecation, it's that he believes he made the "mistake" of assuming that these "Google programmers" could be taught to do better.
Nothing in the article content, however suggests the author had the competency to teach or lead. Everything in the article does suggest the author thought they were hiring experienced programmers on new programmer salaries and were amazed and probably credited nicely by their management team initially.
The author makes it clear that he was the problem. That he was the “idiot” that caused the problem in the first place. That is the opposite of narcissism. So I think the rest of the article should be read while keeping that in mind.
See, if I'd say that I'm an idiot for not realizing someone is trash (or some stronger expletive) - yes, that would be ironic, but all the irony would be in the invisible quotes around the "idiot", with none around the "trash". A totally opposite effect.
And the author talks about "Google" programmers in a clearly derogatory manner. It is not just in the title (which would've been okay on its own because it uses "idiot" for both sides).
I am an enjoyer of sarcasm and irony. One principle of sarcasm in the written language is that there needs to be a bit of a 'tell' to reinforce that it is sarcasm. You need to write it in such a way that it just doesn't make sense if you take it literally.
For example, I'm fond of pointing out that I'm aware that American scientists have mathematically proven that it is not possible to determine sarcasm from the written word.
That is clearly sarcastic because thinking that you could mathematically prove that is just not grounded in reality and nothing anyone would seriously suggest, so it provides a 'tell' that it is sarcastic. Read sarcastically it is self-referential and makes perfect sense.
Another classic example is _A Modest Proposal_ where its so over the top that it has to be sarcastic.
Just posting something "edgy" without any kind of a "tell" isn't really sarcasm.
I can't really find much of a 'tell' in this whole article. The whole article is consistent with him being a total narcissist. And the way that goes around "correcting" people by forcing them to watch him solve their problem the "right" way is something a narcissist would do that someone who was actually instructing and teaching someone else wouldn't do. So if I read it like he's just a narcissist then its all consistent. If I try to read it like he's being ironic, then he's at a minimum both really bad at sarcasm and irony and still really bad as an instructor.
Not when the rest of the piece was describing his mistake as, essentially, trusting that other programmers were as good as him. He goes on to suggest that the training of these other programmers makes it impossible for them to perform up to his standards.
> They only followed the laws of their own world. And I was the fool for not seeing these laws — I did not understand them, did not realize their seriousness. The seriousness of superficiality.
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.
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.
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.
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.
201 comments
[ 3.1 ms ] story [ 264 ms ] threadBig 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.
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.
Maybe the internet is creating a situation where the workplace is no longer populated by a Dickensian cast of oddballs, but I feel like super polite workspaces where nobody ever calls people out and everyone is given pats on the back lack something as well. And under the surface is often disdain that is never voiced, just acted upon.
This is HN and I do not want to make a personal attack or anything against you. But this comment is clearly discriminatory and, frankly, what ever a light version of "racism" is. Please stop generalising millions of people based on some anecdote and spread it online. Eastern Europeans are already marginalized in the Western software world, and English is a non-native language to them. They are as diverse as you and me
OTOH, Dutch are notoriously blunt as well.
* it is true we are more blunt than a lot of our Western colleagues
* blunt does not mean impolite -- I always try to say what I mean with plenty of layers of courtesy, but I do not mince what I mean
* the guy in the article seems like an asshole by Eastern European standards too (mentioning "my charisma" is pretty egoistical no matter how you spin it)
> Eastern Europeans are already marginalized in the Western software world
Not completely wrong but I'd say the software industry is the place I have felt the least marginalized. I left Eastern Europe and finding a job in the software industry was very painless for me, while other places would wish for perfect command of the local language, or discriminated against me almost explicitly. Which leads me to your next point..
> English is a non-native language to them
While true, it is rather annoying to have people hold this over your head when you speak and think in English for decades. I'm more well-read than half my native English colleagues who haven't picked up a literature book since high school, yet being "non-native" means that I constantly have people doubting my ability to speak English. At least I no longer have to hand in TOEFL exams to prove I can speak the language that I think in 24/7, including when I'm talking with my workmates, girlfriend, showering, taking a shit etc..
Finally found a Russian lang forum where it seemed someone asked and a long response. I used to google translate. Half the response was the author insulting the guys mother followed by a detailed profanity laden answer.
“I don’t work alone. There’s a lot of stuff in here that I don’t even understand. I’m really a systems management guy, I farm bits and pieces out to people who are much more brilliant than I am. But none of them really knows what the project is. I say build me a laser this, or a molecular analyzer that - and they do, I just stick them all together.”
I recently had to build an e-commerce portal for our customers to be able to order 3D printed parts on-demand. Did I write my own algorithms for rendering 3MF files and calculating the volume of a mesh? Nope, I just used three.js and a mesh volume algorithm I found on Stack Overflow and problem solved.
Most of the skills you mention (business requirements, task management, spelunking legacy crap, etc) only really matter in large organizations, where human coordination costs and tech debt management dwarf actual development costs.
In a well-run small org, ICs can get by without them by having an occasional coffee/lunch/beer with the CEO/CTO/Sales head.
In a small company a frankly larger percentage of company revenue can be wasted through crappy project and product management. Coding it poorly is often the least concern at places like this. It's getting the right thing to market.
That's how most mid level, and large companies work. You are not hiring an engineer with 2yoe to 'coordinate business values', unless you work at some scrappy startup.
The original article has a good point: Young engineers are so used to google for everything, that they often don't understand the code, or framework they are working with.
Back in the day (prior to StackOverflow), we called them "Framework, Glue and Paste Engineers". Basically people that used frameworks without understanding what they did. It was fine for basic stuff, until the point you crash servers because you have no clue what did Hibernate do under the hood with those queries.
Anyway.... the article is clearly aimed at more junior hires.
Out of curiosity(from lack of experience working for a company), what are some things that lead to this situation?
It doesn't matter how humorous or humble the author might be, these alone worry me. Y'know, me, that arrogant guy who likes grapes.
In any case it's clear the original author does not live in a tech job market anything like North America, where a request to "re-interview" someone would be met with a confused stare followed by a middle finger.
Leading a team or joining a new one? It's translating what the company needs into the set of instructions. Ambiguity in that process leads to stalled juniors, even if they're excellent coders. I've been there, both as the frustrated demoralized junior and, later in my career, as the team lead trying to make that process work.
Yes, I'd be concerned if someone literally cannot write compilable code in the programming language you're working in. But usually if someone makes it far enough to be employed there's something else going on if they're producing serious garbage. Skill, attitude, motivation, team morale, or bad instructions and bad leadership. Honestly, my experience in seeing teams dysfunction is that it's best to start from the end of that list and move backwards.
Also, we need to deliver a swift kick in the nuts to this unlimited growth philosophy. People under you NEED to plateau, that is their comfortable level of productivity. You don't force growth, that is something that comes naturally and at an unpredictable pace.
That said, I still bridle at the term "software engineer"; I mostly accord with Alan Kay's quote "Software engineering hasn't happened yet."
Problem solving skills required and a bunch of questions. What really do you need, how important is each part of it, and who are the other people I need to talk to help make this happen? Being able to ask those questions and produce code from the answers is what we get paid the big bucks for.
At least for now.
We've had this before on HN. Student and work culture is changing from "Work it out for yourself because you're a skilled professional who understands how to solve real problems" to "Copy it from someone else without understanding anything about it because that's what you did to get your expensive degree."
It's not so much Google programming as Lego programming. And it's a terrible way to approach any kind of engineering, at any level.
Of course it's fine to import good existing solutions if you know what you're doing with them. But Lego programming is not that.
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.
In my opinion the way to get them through it is loads of pair programming and stopping them and reminding them they haven't stopped to think about the entire context when you catch them doing it (or when they come to ask for help in the ideal case).
I'm not sure if I ever went through this phase, but not everyone has the luxury of developing their programming skills at a leisurely pace from highschool all the way through college.
Strong junior programmers usually fail by rewriting everything from scratch, having no concept of DRY, libraries, or how to effectively break logic into methods. But inability to generate their own code is not a common failure mode!
It's only weak junior programmers (that is, people who simply are not going to become strong developers) who approach a problem and, in the absence of the ability to write code from scratch, try to find something to copy-paste.
This has been my experience too. It's also common (maybe even nearly universal) for devs to go thru a stage where "rewiting" feels like the path of least resistance. This is usually (not always) wrong, but until you've ramped up in several very different codebases it's difficult to see how something so foreign can end up being as productive as what you're used to.
I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.
It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something.
So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes.
But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code.
My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc.
I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.
Anyway, regardless of whether they're really strong or not, the couple I've mentored have become tremendously valuable to my company, with performance outstripping my own (I think because of the higher tolerance to shitty repetitive frontend work).
Sure, technically you are a Junior again if you use a new technology, but assuming the MO of the language is not completely unlike one you're familiar with (for example OOP vs functional vs whatever).
I mean, at least that's what I need to do - but maybe "how was this syntax again?" paired with "I don't like these docs" might only superficially be copy/pasting from SO, because you know what you're writing, but you don't have the words of the language...
Blank source files are scary yo.
There are a near infinite number of choices that can be made when confronted with a blank file. And the ramifications of those initial choices will live on, possibly for decades! (I spent 10 years at Microsoft where it wasn't uncommon to come across 20+ year old code still in use.)
More than once I've initialized a new project, started at my blank folder structure, and spent a few minutes thinking "here we go again".
It’s pervasive in lots of aspects of my life beyond programming, where I get anxious having to make decisions. I will drag my feet to have to make a final decision, even if it’s a restaurant choice. I’d much rather have the obvious right choice in my face than have to pick between multiple good choices.
I face this same anxiety when staring at a blank source file too.
(Yes, I’m working on finding a therapist, but even picking one gives me the same anxiety)
This means you become partly responsible for the quality of the product you pay for. If the burrito is bad, you are to blame because you chose the ingredients. I think that makes me anxious when in Chipotle's.
In programming it does slow your progress if you have to frequently spend time deciding which choice is the best. Not only anxiety but also plain lost time.
Barry Schwartz, is that you?
I so much hate those project generators. First thing I do when I generate some create react app is going through it and delete stuff. Everything. To start from absolute minimum.
I can accept some project generators being an option. But I never understood people who make it default way to go.
Your post was kind of eye opener for me.
I hate deciding where the ubiquitous "utils" folder should go in any given project!
Boy do I miss those days now that I work for larger companies and with larger teams where the opportunity to do that is pretty rare. Give me a blank slate all day for any project.
They are. But the more programs you write, the better you get at it.
It also helps to devise a personal architecture or two for different projects. I have some that I lean on, and that means I can bootstrap myself fairly quickly. It took a while to get there though.
Programming isn't my day job, but I do frequently write code from scratch (and refactor it, heh). I interviewed for one entry-level programming position; they did not appreciate my technique.
And interactivity can be an extremely effective way of experimenting and learning how things work and fit together so that you can rapidly develop a mental model of your core primitives and how to put them together in different ways.
It's also part of the appeal of TDD. Small iterative loops with rapid feedback.
Though I'd agree that no engineers should be copying code without understanding its intent and interfaces.
If you're copying and pasting your core expertise from stack overflow, then, I hate to break it to you, but you'll never successfully differentiate your product.
Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.
If this was true, it would bring a significant economic advantage to a startup if it would not use leetcode style questions for job interviews, but instead ask hard questions about these textbook architectures.
Find the most readable color of a font for a given background on most displays. You could do extensive research on colors for something that on the first look sounds rather trivial or find a very thoroughly worked out solution on stack exchange.
It is difficult enough to advertise self-made software when many people are looking for off-the-self solutions. So being fast and therefore affordable is quite important.
I mostly develop for embedded systems on custom hardware so ready to use solutions are rare. But if I want to visualize process data in a browser? Please give me all your thousands of dependencies Javascript.
An algorithm I implement from scratch? Very rare. This takes time and thorough testing compared to something that is already solved.
True
> I do think Google has caused some of this.
I think it a lot of it is the frameworks and people constantly trying to shortcut the method of building something with code. We have so many frameworks, tools, plugins and other stuff that it makes it easier NOT to learn anything deeply any more. Pick a JS Framework and I'll give you a dozen plugins or tools that have already been built to write your code for you. All you, as a developer have to do is string them together.
By building all of these shortcuts, no one really needs to learn Angular, you have their site as a reference and tons of material to help you. Developers actually learn in the absence of knowledge where they have to sit down and learn it without knowing there is a crutch or fallback if they get stuck. I think today's developers just get as far as they can and then start googling for a solution because they know that someone has already built a date picker in ten different languages, thousands times already. Why go back and reinvent the wheel when you don't have to?
Because it creates lazy developers.
An entirely other issue is why learn some framework inside and out if its going to be obsolete in a few years? Remember when everybody loved Backbone and Express? You tell someone in the Dev community today you use either of those and you'll get laughed right out of the bar.
I think its just a lot of things that work against developers learning more than then they really need in any given situation.
I am a self-taught programmer. I copy, but I also innovate. I don’t follow at all the academic approach (I never studied CS or was very good in school). But I don’t paralyze when I can’t find anything to copy from like a Roomba stuck on a rug.
Do you have a term for me?
Also, academic research on computer science, as I lack much of the basics.
I am happy building websites and web apps.
But I am confident enough to know I can innovate and create complex solutions for the kinds of problems I face.
I'm guessing the reality in your case isn't quite as severe but that's sort of where some "jigglers" sit.
When I hear "I don't follow at all the academic approach" what I'm hearing is you don't even know what is actually taught in a CS degree. Might be wrong but that's what I'm hearing. A lot of it isn't really that academic but sure some of it is. I'm self-taught and I worked as a programmer before I got my CS degree (as a teenager) but my self studies included CS topics (algorithms and data structures etc.) and I never copied any code or "jiggled" anything when I got started, everything was written from zero. What I did occasionally do is implement algorithms (i.e. the algorithm is known, write the code, which I guess is a form of copying).
On the plus side you've obviously acquired some good skills doing all this and you are likely smart. If you're happy with where you are (let's call this a "Software Integrator" maybe) that's fine. If you want to become better you probably should put in the time and learn some of the things you've been avoiding either formally or on your own (unlike when I was a kid there's endless resources now).
This is accurate. I don’t. My impression is “algorithms and data structures”, which is fuzzy for me. I don’t care at all about algorithms. Data structures I think I should know more about at some point.
I considered studying CS after starting working with software development, but decided I don’t want to. Kind of related, but I also decided that I don’t want to study leetcode too, even though there is a financial incentive to do it.
I am happy being someone that some arrogant developers like to call “web developer”, “programmer” or, at most, “software developer” as opposed to what a “software engineer” is. I understand the difference that those people try to point out. And I agree there is a difference and I don’t care to be on the side of line that I am. It does bother me that every time I see someone making a point of showing where the line is, it’s from a point of arrogance, entitlement. This does bother me, and I felt that tone in the comment I replied to.
And yes, I learn most effectively by copying too. Showing me a couple of working project and letting me implement a bunch of simple tasks by jiggling existing ones usually works for me way faster than throwing manuals and tutorials at me. Manuals have its place - when I know enough to know what to look up - and so do tutorials, but "learn by copying" is the most optimal way of getting bootstrapped for many people, including me. There's nothing wrong with that, if you don't stop at that stage but continue learning.
If I see an engineer constantly do this, I would think that they are insecure and are constantly attempting to prove that they are "real" programmers (whatever that means).
The way I see it, we are here to solve business problems and the chances of your problem being so unique that similar solutions don't already exist is rather low.
Let's face it, the majority of software work is pluming work and wiring APIs these days. Very few people are tasked with implementing their own sorting algorithm and even if they are, you can bet that they will scaffold from another algorithm to get started..
Yes, one should not blindly copy and paste from Stackoverflow but researching, refactoring, thinking about the task at hand and using existing tools and libraries are all part of the process.
My current project is boring (especially since i finished the code logic like 9 months ago), but since I'm paid to upgrade/deploy the stuff I'm not that disfranchised. (I won't lie and say I'm as productive, I'm clearly not)
I don't think I'm really able to work alone or unpaid. Which is weird, because I really, really enjoyed the two dozen school projects I've done, especially those who took 2+months
Trial&error mode works well when working with randoms, e.g. exploration, research, acquiring information, identifying unknowns. Literate mode works well when working with exacts. Identifications for example produce exacts from unknowns. Enough facts enables you to build stuffs out of it like Lego. This is where literate mode works well.
Jiggle programmers that does not quite grow out of their jiggling mode is because they stay in trial&error mode and does not slide slowly into the literate end of the spectrum. After acquiring some facts, they don't deduct or intuit from them. They don't attempt to philosophize a bit.
A problem as simple as "how to do X after the window loads" for example, some programmer can find `window.addEventListener("load", X);` in stack overflow, but the main differentiator lies whether after fixing the issue, they care enough to at least wonder about what's the meaning of `window`, `addEventListener`, `load`, "why is the call shaped that way", "what is Event and what is Listener". Those who do slide slowly into their literate mode.
It is also not less dangerous to be stuck in the literate mode. Although this happens rarer, often to more experienced people.
My impression is that a trend started in the 90s which has taken over the industry where programmers that are capable of building things from scratch and keeping everything in their heads are much less valuable compared to those who are "weaker" but much more capable of communicating and cooperating.
We're all jiggle programmers then. Once the applications architecture is established, we hang new feature on it by following that architecture.
Very very few of us get to only write code from scratch every day. Most of the time, when I'm writing from 0, I'm working on a R&D PoC. If I'm not doing that, I'm jiggle programming a new feature into an existing architecture.
> With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation.
I was self-taught before university. I learned on a C=64 and then an early x86 back in the day. If you didn't figure it out on your own, you hoped you would see it in a magazine or book some place. I learned a lot about how computers worked at a fundamental level from the C=64. I don't think self-taught is the issue. I think it's how much the person really wants to know about computers and CS.
I knew someone looking for work at the time and asked for a link to the job description so I could forward it along.
In the description included the phrase “without Googling” for a majority of tasks. It’s not as if the role was especially demanding or contained a ridiculous amount of esoteric knowledge; it was the equivalent of a help desk position. I can’t imagine ever doing help desk, much less ever again (fuck that stress) or for someone who thinks it’s a role where you will never need to Google anything.
I pointed this out to my friend with a frown on my face, but left it up to him if he wanted to apply. He read the job description and said “yeah no. That boss sounds miserable to work with”. My interactions with that manager were quite minimal, but judging but the attrition we noticed on the help desk team, I think he was right.
Sounds like a joy to work with.
> 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?
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.
> I gave tasks and a computer to a candidate and left them for half an hour to an hour.
Of course they're going to Google - it saves time, and the interviewer clearly doesn't give a shit about how you arrived at the solution because he literally just left the room.
And then productivity and moral levels after you let go your good devs that suck at interviewing.
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.
I thought the remote work was to blame — it made it hard for me to use my charisma."
What now?
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.
> In addition, our superiors did me a disservice — they asked me questions like the following: " Has productivity growth stagnated because of remote work?" Of course, I was saying yes.
The author took no responsibility in the 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
Don't know how to drive? Watch me and memorize what I do.
Don't know how to play chess? Watch me and memorize what I do.
Don't know how to swim... etc.
Though there are some jobs where you absolutely must watch someone before you even attempt to do it yourself (e.g surgery), it's not typical and probably not needed for something like programming where you can view the source. And it'll certainly prolong the learning process compared to having people do it themselves.
The solution to that isn't to have the instructor drive them to the store and back. The right way to approach that is to have the instructor watch them drive and give them tips and feedback in real time. Observe and correct. With programming then they're running the keyboard themselves and they're the ones actually doing the work, which is going to reinforce the learning in a way that just watching isn't going to (similar to how note-taking helps to reinforce memory and learning in lectures).
This takes a whole lot more patience though since you can't just sit down at the computer and start bashing keys yourself but have to "use your words" and requires some ability to instruct.
And I've done quite a lot of this kind of mentoring at my last job and this was the approach I've most often taken.
Where I found it more useful to drive the keyboard myself was in sessions where I was working on solving problems that were at my level where I didn't know the solution. That way they could watch my entire thinking process as I figured it out in "real time" and see where I went down avenues that didn't work out and how I thought about finding the right solution, along with the workflow that I used.
I wouldn't expect anyone to be able to replicate that after they were done watching me, that is more to show where there's more room to climb.
The manager's options are more nuanced then either you do it, or I do it for you.
> 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?
https://blog.codinghorror.com/mort-elvis-einstein-and-you/
This is laughably untrue and, oddly enough, the part of this post that left me most bothered.
I've seen countless arguments about higher edu and whenever somebody says that school didnt teach him x,y,z,
then people often try to counter it with something like
"ohh, uni's goal is to teach you how to learn and make aware of how big some domain is!
what you're talking about is trade school!" (it's terrible counter in my opinion)
Whether that's a good way to spend 5 years - I don't know. But in practice it turned out that way.
> I thought the remote work was to blame — it made it hard for me to use my charisma
Pure narcissism
(Although, there could be another level of irony, i.e. he is narcissistic, and worries you might think so, so he deploys irony to persuade you that he isn't by making a narcissistic-seeming comment in a self-undermining fashion—but I doubt it in this case).
In my experience, much British humor tends to follow a similar model (and Russian too perhaps), but I've observed that it's common for people who don't share that type of humor to misinterpret it.
It's much harsher in Russian than the English translation. Compare:
> You'll sit next to me and memorize the way the work should be done.
and
> А ты, бездарь, сиди рядом и запоминай, как работать надо.
which literally translates to "And you, bungler, sit and watch how the work is done [right]."
And I utterly fail to see any self-deprecating piece that would turn this into a joke. If anything, author treats those "Google"-programmers as trash.
Even as a joke, I would say it's very poor and distasteful one, especially for a public blog post.
See, if I'd say that I'm an idiot for not realizing someone is trash (or some stronger expletive) - yes, that would be ironic, but all the irony would be in the invisible quotes around the "idiot", with none around the "trash". A totally opposite effect.
And the author talks about "Google" programmers in a clearly derogatory manner. It is not just in the title (which would've been okay on its own because it uses "idiot" for both sides).
For example, I'm fond of pointing out that I'm aware that American scientists have mathematically proven that it is not possible to determine sarcasm from the written word.
That is clearly sarcastic because thinking that you could mathematically prove that is just not grounded in reality and nothing anyone would seriously suggest, so it provides a 'tell' that it is sarcastic. Read sarcastically it is self-referential and makes perfect sense.
Another classic example is _A Modest Proposal_ where its so over the top that it has to be sarcastic.
Just posting something "edgy" without any kind of a "tell" isn't really sarcasm.
I can't really find much of a 'tell' in this whole article. The whole article is consistent with him being a total narcissist. And the way that goes around "correcting" people by forcing them to watch him solve their problem the "right" way is something a narcissist would do that someone who was actually instructing and teaching someone else wouldn't do. So if I read it like he's just a narcissist then its all consistent. If I try to read it like he's being ironic, then he's at a minimum both really bad at sarcasm and irony and still really bad as an instructor.
> Of course, I realized that it was not about them. I was the problem.
> They only followed the laws of their own world. And I was the fool for not seeing these laws — I did not understand them, did not realize their seriousness. The seriousness of superficiality.
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.
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.
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.