The Full Stack Overflow Developer

Home > Others > The Full Stack Overflow Developer

The Full Stack Overflow Developer

October 27th, 2015 Leave a comment Go to comments

In a few talks and interviews I lamented about a phenomenon in our market that’s always been around, but seems to be rampant by now: the one of the full Stack Overflow developer. Prompted by Stephen Hay on Twitter, I shall now talk a bit about what this means.

Full Stack Overflow developers work almost entirely by copying and pasting code from Stack Overflow instead of understanding what they are doing. Instead of researching a topic, they go there first to ask a question hoping people will just give them the result.

In many cases, this works out. It is amazing what you can achieve by pasting things you don’t understand, that people who know what they are doing put out there.

I am not having a go at Stack Overflow here. It is an incredible resource and it is hard to create a community like this and not drown in spam and mediocrity (trust me, I am an admin on several technical Facebook groups).

We had that problem for a long time. I challenge anyone learning PHP to not simply copy the code examples in the notes. For years, code reference sites have given us answers we wanted, but didn’t need. Heck, even Matt’s Script Archive is probably the source for many a spam mailer as people used formmail.pl without knowing what it does.

I am, however, worried about how rampant this behaviour is today. Of course, it is understandable:

Creating something is more fun than reading up on how to create something.
Using something that works immediately, even if you don’t know how it does it, feels better than encountering the frustration of not being able to fix something.
You feel like you cheated the system – shortcuts are fun, and makes you feel like you’re cleverer than all those chumps who spend all this time learning.
Our job is mainstream and there is a massive need for developers. The speed of how we are asked to deliver has massively increased. People want results quicker, rather than cleaner.

We, as a community, are partly to blame for breeding this kind of developer:

When we answer questions, we tend to give the solution instead of analysing what the person really needs. This is much more work, so we tend to avoid it.
Posting the “one true solution” and winning a thread on Stack Overflow feels great – even if we have no plan whatsoever to come back to it later if it turns out not to be such a good idea any longer as the environment changed.
Getting recognition, Karma and upvotes for giving the solution is much easier than getting it for being the person who asks the right questions to get to the source of the problem.
It is easy to lose patience with getting the same questions over and over again and a “just use jQuery” is easy to paste.

SO WHAT? WHY IS IT A PROBLEM IF PEOPLE ARE FASTER AND MORE EFFECTIVE IN RELEASING PRODUCTS?

Of course, you can call me a grumpy old so-and-so now and tell me that the concept of learning the basics in software is an outdated concept. The complexity of today’s products makes it almost impossible to know everything and in other, highly successful environments using lots of packages and libraries is par for the course. Fine, although we seem to be understanding that software as a whole might be more broken than we care to admit, and this might be one of the causes.

There are several problems with full Stack Overflow development:

It assumes the simplest answer with the most technical detail is the best. This is dangerous and can result in many a copied and pasted example which has a lot of issues surviving for years and years on the web.
The most copy-able answer being used, upvoted and linked to means that better solutions that fix its issues are much less likely to succeed in replacing them. There is no “digging deeper”, so even important fixes will fall under the radar.
Any expert community is most likely to have a lot of assumptions as to what makes up a “professional environment”. That means that answers giving in those communities are very likely to work in a great, new and complex developer setup but are not necessarily useful for our end users out there. It is very easy to add yet another library or npm package or bootstrap solution to a project, but it adds to the already full-to-the-brim landfill of outdated code on the web.
It perpetuates the fondness we have for tersity over writing understandable code. The smallest solution – however unreadable – is always the one that wins the thread. As people copy and paste them without understanding, that’s fine by them. For debugging and maintenance, however, it is the worst solution. A great example for this is the use of || for default parameters. Short isn’t better, it is just less work.
It cheapens our craft. If we, as the people delivering the work, don’t have any respect for it and simply put things together and hope they work, then we shouldn’t be surprised if our managers and peers don’t see us as professionals.

The biggest problem, however, is that it is bad for the developers themselves.

FINDING PRIDE IN YOUR WORK IS THE BIGGEST REWARD

Going on the web, finding a solution and copying and pasting it is easy – too easy. There is no effort in it, and it is not your work – it is someone else’s. Instead of being proud of what you achieved, you are more likely to stress out as you don’t want to be found out as a phony who uses other people’s work and sells it as your own.

Repetition is anathema to a lot of developers. Don’t repeat yourself (DRY) is a good concept in code, but for learning and working it is a terribly idea. We need repetition, to build up muscle memory. The more you repeat a task, the easier it gets and your body does it without you having to think about it.

When you started driving a car, you probably sat down on the seat and got utterly overwhelmed by all the gears, levers, pedals and things to pay attention to. After a while, you don’t even think about what you are doing any longer, and even switching from UK to other cars is not an issue. Failing and learning from it is something we retain much better than simply using something. We put more effort in, it feels more worthy.
Dan Ariely’s TED Talk “What makes us feel good about our work” has some incredibly good points about that topic:

Recognition is what we crave as humans. And we can’t get recognition if we don’t own what we do. You can totally get by copying and pasting and using solution after solution and abstraction upon abstraction. But, sooner or later, you will feel that you are not achieving or creating anything. Many developers who worked like that burned out quickly and stopped developing, stopped caring. And that is a big loss as you might be the person to come up with the next great idea that changes things for a lot of us. That’s an option you shouldn’t rob yourself of. Don’t be a full Stack Overflow developer. You deserve to be better.

More Hands-on with JavaScript

This article is part of the web development series from Microsoft tech evangelists on practical JavaScript learning, open source projects, and interoperability best practices including Microsoft Edge browser and the new EdgeHTML rendering engine.
We encourage you to test across browsers and devices including Microsoft Edge – the default browser for Windows 10 – with free tools on dev.modern.IE:

In-depth tech learning on Microsoft Edge and the Web Platform from our engineers and evangelists: