Slashdot Mirror
Ask Slashdot: Are 'Full Stack' Developers a Thing?
"It seems that nearly every job posting for a software developer these days requires someone who can do it all," complains Slashdot reader datavirtue, noting a main focus on finding someone to do "front end work and back end work and database work and message queue work...."
I have been in a relatively small shop that for years that has always had a few guys focused on the UI. The rest of us might have to do something on the front-end but are mostly engaged in more complex "back-end" development or MQ and database architecture. I have been keeping my eye on the market, and the laser focus on full stack developers is a real turn-off.
When was the last time you had an outage because the UI didn't work right? I can't count the number of outages resulting from inexperienced developers introducing a bug in the business logic or middle tier. Am I correct in assuming that the shops that are always looking for full stack developers just aren't grown up yet?
sjames (Slashdot reader #1,099) responded that "They are a thing, but in order to have comprehensive experience in everything involved, the developer will almost certainly be older than HR departments in 'the valley' like to hire."
And Dave Ostrander argues that "In the last 10 years front end software development has gotten really complex. Gulp, Grunt, Sass, 35+ different mobile device screen sizes and 15 major browsers to code for, has made the front end skillset very valuable." The original submitter argues that front-end development "is a much simpler domain," leading to its own discussion.
Share your own thoughts in the comments. Are "full-stack" developers a thing?
When was the last time you had an outage because the UI didn't work right? I can't count the number of outages resulting from inexperienced developers introducing a bug in the business logic or middle tier. Am I correct in assuming that the shops that are always looking for full stack developers just aren't grown up yet?
sjames (Slashdot reader #1,099) responded that "They are a thing, but in order to have comprehensive experience in everything involved, the developer will almost certainly be older than HR departments in 'the valley' like to hire."
And Dave Ostrander argues that "In the last 10 years front end software development has gotten really complex. Gulp, Grunt, Sass, 35+ different mobile device screen sizes and 15 major browsers to code for, has made the front end skillset very valuable." The original submitter argues that front-end development "is a much simpler domain," leading to its own discussion.
Share your own thoughts in the comments. Are "full-stack" developers a thing?
Clearly the original submitter has only ever done simple front-end development. Back-end code either works, or doesn't.
Front-end code has to take into account multiple operating systems, multiple browsers, multiple versions of those browsers, hundreds of devices, an extremely wide range of processing power and RAM combinations... in short, your back-end code is a walk in the park.
#DeleteFacebook
A "unicorn" is mostly just someone who's been around for more than a few years and kept learning in a broad range of areas. There are plenty out there.
Some employers have trouble with wanting unicorns but only having the budget for newbies, but that's an entirely different problem.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
> 35+ different mobile device screen sizes and 15 major browsers to code for
This shows he doesn't understand the entire POINT of html, a web browser, and CSS. He clearly doesn't know the difference between a PDF and an html document if he's coding for many different screen sizes with many different browsers. PDF files are sized - you can make a letter-sized PDF or legal-size, for example. The entire PURPOSE of a web browser, of the rendering engine, is to format *information* coming from the server to fit nicely in whatever size the window happens to be at the moment. If you're coding you're web pages for lots of different screen sizes, you're missing the entire point of what a web browser does, and your pages will be fucked when the window isn't maximized. *Maybe* two versions - small and large. Other than that, let the browser do its job. Don't try to force something to be exactly 3 pixels over by loading pixel.gif three times and you won't have to worry about screen size (or window size).
Your html should describe *what* the page elements are, using tags like "header", "list (ul)", "top level heading (h1)". It's the browser's job to figure out how many pixels a top-level heading should be given the screen resolution, user preferences, etc. Your CSS then can give hints including "larger" which should generally apply to all devices.
Code for 35 browsers? Try coding html 4 or html5. Not IEthml, and not loading pixel.gif five times when you detect Mozilla. Just code to the standard. If one of the three or four major browsers is completely broken in respect to the standard for some tag you can adjust for that, but those instances should be rare.