That's not the definition of full stack I've ever heard of before.
To me, full stack means front end + back end -- can write good CSS and can write good queries. Knows how JavaScript's "this" works, and can intelligently converse about data sharding.
Database administration, network problems, app servers -- these are most certainly NOT part of a full-stack developer's knowledge, any more than fixing the oven in the company cafeteria. And I wouldn't want a full-stack develop touching the company's network configuration or trying to do database administration on high-load production servers under any circumstances -- there are very good reasons that those are left to specialists in these areas.
Of course, it's possible you could have someone who does both full stack and DBA, or full stack and knows a lot about networks, but that has nothing to do with full stack. The "stack" web developers are talking about is, for example, LAMP -- Linux, Apache, MySQL, PHP (or pick your own stack), and it's about being proficient in all the layers of that stack, when writing applications -- not running servers or networks.
That's an interesting definition. I agree with the OP and I don't think you did a good job writing a convincing argument regarding your definition.
I think it's because of your clouded definition of "stack" when talking about a full stack developer.
You first say:
To me, full stack means front end + back end -- can write good CSS and can write good queries. Knows how JavaScript's "this" works, and can intelligently converse about data sharding.
Then you conclude with:
The "stack" web developers are talking about is, for example, LAMP -- Linux, Apache, MySQL, PHP (or pick your own stack)
Nowhere in your conclusive definition does JavaScript or CSS come into play. You began discussing various technologies and concluded with a description of back end development stacks (LAMP, LEMP, WAMP and so on), but not "full stack."
Your previous definition was a bit closer when you included JavaScript, HTML and CSS in my opinion.
When I think of a "full stack developer" it means that they can work anywhere in the entire technology stack, not necessarily the software development stack. That means they can SSH around to various services and fire up databases or tail log files or write JavaScript or generate Perl scripts or tweak CSS or anything in-between.
Are they a systems administrator? No.
Are they a database administrator? No.
Are they a front end developer? No.
Are they a designer? No.
Can they perform many of the common duties of those positions? I would hope so.
What you seem to have defined, is simply a front and back end developer, and not, in my opinion, a full stack developer.
And for a majority of the startups represented on HN, I'm willing to bet they don't have dedicated network guys, heavily-loaded production servers, let alone a dedicated DBA. As a company grows, the responsibility (and hopefully expertise) of a single employee narrows.
To me, "full-stack" means: You can do everything because we're a small startup.
If the stack, LAMP in this case, is Linux, Apache, MySQL, and PHP/Python? Why shouldn't you need to know about running servers, configuring databases, or other stuff to be a full stack developer?
Linux is the operating system of your server, you should know how to use it. Apache is your web server, you should know how to set it up and configure it. The same for your database MySQL. Obviously you had better know PHP(Python if that's what your P stands for) to develop any software.
I think you're mixing up Full Stack developer with Application developer. The application developer would take PHP and connect to a database to make the application and that's normally that. The full stack developer would set up the servers, configure them, create the application, deploy it, and all that jazz.
I'm not saying one is better than the other. You get more flexibility with a full stack developer but you can get more expertise with an application developer. It all boils down to the opportunity cost of having someone who can do everything well or 2-3 people should all be experts at their part of the puzzle.
I've never heard the term "application developer" in a web context before -- in all the jobs I've looked at and companies I've worked with, the terms have been "front-end", "back-end", and "full stack" which is the combination of the two.
I agree that a full-stack developer should have familiarity with Linux, setting up servers, configuring MySQL in basic ways, and whatnot -- that's what the "backend" part is built on, of course. As you say, they need to be able to deploy an app. But their main job is coding, not administration.
So they only need familiarity with deploying, not expertise -- they should be able to get a few servers running for a startup with load balancing. They should not be expected to know the intricacies of MySQL tuning, network security, Linux security, network management, and so on. You're not going to expect a full-stack engineer to know how to use Wireshark. (Gravy if they do, of course.)
I'm just making the point that full stack does NOT include professional-level systems administration or database administration. A full-stack engineer is not a magical go-to guy who knows everything. It's just front-end plus back-end. It's firmly in the realm of coding, not administration.
This is a good way to look at things. It is also very frustrating when there are administrative barriers to working the full stack. Not that I advocate handing out root password with your new employee badge, but I don't like it when it is easier to call the ops team than just take a quick peak yourself.
Full stack web developer doesn't mean he can do any kind of programming job (embedded, mobile, kernel driver, whatever). It means he can make a web application from A to Z.
A web application involves a lot of very different tasks that are detailed in the article, while other programming fields don't necessarily have such a broad set of tasks.
> A web application involves a lot of very different tasks that are detailed in the article, while other programming fields don't necessarily have such a broad set of tasks.
Or, depending on the field, a vastly greater set of tasks.
That's not fair. Unlike many areas of software engineering, web development uses a long list of technologies interchangeably. This set (HTML, CSS, js, rails, some db, lamp, aws, etc) is a mix of languages and platforms. A "full stack developer" is one who can choose the right set of tools from a long list and get a site built from scratch.
There is an element of breadth vs depth in this definition. In some types of software engineering it's crucial to have deep expertise of one or a two languages (oracle, or java) but on web development it's often better to have a much broader view of more things.
This is why 17 yo web full stack web developers are more common than deeply experienced .net developers. The former takes constant curiosity and the ability to stay up to date on what's new in a changing field. The latter takes thousands of hours of experience.
Electronics, CPU, memory, assorted glue chips, IO chips, memory devices and so on. In the embedded computing world it is not rare at all to find a single guy that designs the hardware who programs it as well, from the ground up if need be.
The first few times I heard the term "full stack" developer it meant somebody who could understand what's going on at all levels of the call stack.
That means from the kernel through C libraries, web server / JIT / high-level server langauge, through network layer, through browser implementation, javascript JIT, javascript / CSS / HTML interpretation and layout and so on.
Has this turned into "I can does the servers and the javascripts too" or did I encounter the term out of its original context?
Full stack developers have definitely been watered down over the years. In addition to your list you had to know all the electrical engineering behind the hardware. Further you at least needed a minor in chemistry. I scoff at someone who calls themselves "full stack" developer and couldn't even draw the silicon molecule.
I just don't trust someone to write my web app who doesn't understand how electrons move.
I know you're tongue in cheek, but it really is true, that 'stack' depends entirely on your viewpoint.
For an electrical engineer, working in wireless communications, the stack starts with radio propagation, then radio transceivers, sampling/reconstruction, (de)modulation, error correction, medium access and ends at the kernel driver. Someone who is "full stack" above the kernel driver could be blissfully unaware of the layers of turtles below them.
Then, for the know-it-all communications engineers, there are the device engineers, whose stack starts at the subatomic level, and progresses through atoms, molecules, layers, devices, subsystems, circuits, packages and ends at the integrated circuit.
The term "stack" has been used to indicate the server OS, database and programming language for a while (i.e. LAMP). With client side code having really exploded from a few years ago I had just assumed, in the context of web development, "full stack" to mean somebody who can do both. It's probably only relevant recently when you could choose to be a "front end" developer that only does the browser code. A few years ago the browser code was just something we all did - which is why sites were often ugly!
Obviously we're dealing with stacks upon stacks if you want consider all aspects of computing. I would not think it was very common to find anybody who is truly skilled all the way from chip design up to the graphic design of a web page. Well, at least, I would not expect somebody to be great at every layer. Some of these areas are a career's worth of dedication to master and then also keep up.
I think this might be a pointer to older engineers. Let's face it, Full Stack developers are rare; 17 year old Full Stack developers are unicorns. Older engineers (worth their salt) have been around the block a few times and have probably encountered the problem you're having before.
So, don't ditch that 45 year old guy in the corner. He/She's probably the closest thing to a Full Stack developer you're going to find.
> True - often "full stack developer" is synonymous with dilettante
To me, it reads like this: let's take away one of the only advantages of the web, the strict separation between frontend and backend, by mercilessly introducing heavy coupling and making one end depend completely on the other end for the sake of short-term one-off projects. After all, rockstar developers have long moved on to their next glorious project when maintenance time comes. After all, you don't want to slow down a rockstar full stack engineer with mundane un-agile concepts like layers or such archaic waterfall nonsense.
I self-describe as a full-stack web developer because I've worked on both the front-end and back-end without distinction, and have no particular preference to working on either. Is this considered a bad thing? I don't consider myself a 'rockstar.'
On the contrary, I would describe it as normal, in the sense that all of these web technologies are just tools and protocols. Any software developer with broad experience ought to be looking at general software architecture principles and programming techniques and testing strategies and all the rest and then choosing whatever tools help them get the result they need.
"Front-end developer" and "back-end developer" always seem like "C programmer" or "Python programmer" to me: they're job titles you use when you don't have enough experience with different tools and techniques yet to drop the qualifiers and just call yourself a web developer or programmer. And those in turn are just titles you use until you realise it's all about building something useful and the job title doesn't actually matter at all except perhaps as a convenient shorthand for initially finding people you can talk with intelligently about getting stuff done.
| a convenient shorthand for initially finding people
| you can talk with intelligently about getting stuff
| done.
I agree. I mostly use the term "full-stack web developer" to convey the idea that my experience isn't confined to a niche of solely "front-end" or solely "back-end" development.
To me, it reads like this: let's take away one of the only advantages of the web, the strict separation between frontend and backend
Interesting position. To me, that strict separation is more often a curse than a blessing in web development.
I'm all for maintainable, modular software architecture, and you obviously have a distributed system if you're running some parts on a server and some parts in a browser. However, I don't see why it's helpful to elevate the physical barrier where the remote comms fits to a kind of "strict separation" more than any other case of separating concerns.
IME the browser/server divide tends to introduce heavy overheads (on the scale of using completely different programming languages, and marshalling all useful data from one form to another) that don't in themselves offer much benefit in return. It also tends to push less experienced developers into treating the entire system as composed of just two modules (front-end and back-end) or maybe three (throw in a separate database/ORM component) rather than thinking about what they're modelling, how their business logic needs to work, how their user interface logic should be structured, and so on.
Now we are blurring into the line of architect, but that is too much of a hands off role.
If an architect is hands off he or she is either a project manager or a business analyst. Consider the definition of architecture -
Architecture in the computing world consists of a system’s elements; the relationships between those elements; the attributes of the elements; and the attributes of the relationships. [1]
A "full-stack" developer is an architect.
While the list covers the usual suspects, I'd also mention tiers, how they facilitate scaling out and up, and how a layered design facilitates them.
I think he's referring to an information architect, which could be its own profession, or fall into the role of a PM or UX person. Architect is somewhat of a generic term, but an information architect is an important role in many organizations.
The first link that search returns is solution architecture from Wikipedia [1]. In "Overview of solutions architect", second paragraph:
A practitioner of Solution Architecture, Systems engineering and Software engineering processes, the Solutions Architect is...
I've been writing code for over 20 years, and have been an architect (I dislike that title as much as I do full-stack dev) for 14 of those. If you tell me you're an architect that doesn't code, you lose credibility (with me).
Network architecture might involve scripting or code but is predominantly about configuration [2]. It's simply an infrastructure stream as opposed to a dev stream.
If you tell me you're an architect that doesn't code, you lose credibility (with me).
It's an overloaded term these days, and things like "information architecture" are very different to "software architecture", so I wouldn't put it quite as strongly as you did there.
That said, I agree completely with the point I think you were really making. To me, a software architect is just a senior developer who has particular responsibility for big picture and integration issues, possibly along with other development roles they play. It's the breadth counterpart to a technical lead, who is a senior developer with particular responsibility for specific parts of the system and a deep understanding of those parts.
IME having a software architect becomes useful somewhere around the time that anyone on your team can no longer talk to anyone else just by swivelling their chair and saying hi. They don't have to have the word "architect" in their job title, but somebody had better be making sure that Andrew, Bill, Claire and David are all writing code that's going to fit together in a maintainable way and that the tools are there to build and test the combined code.
I feel as though there may be a bit of misunderstanding as to what the term implies from an employer's perspective and hence what is actually being requested by "full stack" positions. Given the ever-changing state of the tech industry, the term offers a comparatively safe option to an employer.
If any of us were to make an investment, maximum return with minimum risk is our natural choice. Given that an investment will never come without risk, we will obviously seek to minimise them. A business investing in an employee can seek to minimise their risk by hedging their bets and advertising for a role requiring an individual that is capable of multiple functions and is capable of adapting to changing needs.
Generally speaking, a "full stack" developer has a particular strength, but is capable of much more. The potential that exists in a multi-skilled developer is what appeals to an employer. Multi-skilling often implies experience adapting, learning and improving, so as a business changes, as its needs change, its workforce's capabilities can change to adapt.
Technical competency across the entire stack is rarely a necessity; intelligence, motivation and an open mind are the essentials. Maintaining an awareness of the broader picture is definitely helpful - when you have a new problem an awareness of the stack can provide an idea of where to start, which logs to start tailing and how you can start trying fix things - but it's the ability and openness to flying by the seat of our pants that makes the "full stack" magic.
Personal experience is the best. I work alone. I get the business requirements from the Client. I decide on the hardware i.e. the hosting provider, the OS, the web server. I can install and configure Debian, apache, MySQL, Perl and PHP. I use my own web framework. I write my own HTML/CSS.
Realize this sounds quite narcissist, but IMO, I am a full stack web developer. :)
This is totally what I see as a full stack dev also.
Speak to client about their problem. Understand 100% of what needs to be done in solving that problem. You can usually do 90% your self or write requirements / wireframes for the other 10% (I usually stay away from design).
Synonym: Loch Ness monster, unicorn, "that dude your boss keeps raving about as the mythical man even though he's a 400K/year pipe dream he can't afford".
In a Microsoft centered development shop the full stack developer needs to have enough knowledge to install the operating system, on server or desktop, configure the appropriate services (understand most of IIS and be able to troubleshoot it), create applications (web or desktop), create databases and configure/install database server (we are talking SQL here, not Access), and troubleshoot the users desktop at an advanced level. Basic knowledge of networking (can you analyze packets?) is also a plus.
In a non-MS environment just replace the pieces with the appropriate pieces necessary, apache, mysql, or whatever is being ran. As well as ability to install OS, and troubleshoot.
A full-stack developer should know more about the technology in the network/infrastructure/database than the average person who is responsible for those items at a company. (A full stack developer should be able to beat out an average DBA at their job--)
I mention the Microsoft environment, because the biggest problem for web development in that sort of world (mostly enterprise, still I think) is figuring out obscure IIS issues.
tl;dr: I've seen so much quibbling about what a full stack engineer really is, and it often seems to conclude with the idea that a "true" full stack engineer doesn't exist. It's not that we don't exist. It's that the actual market for us is tiny.
In terms of layers of abstraction I've worked professionally from one step above the silicon (digital/analog circuit design and FPGAs) to domanin-specific language design. I refer to myself as a "seriously full stack" software developer.
As an example I once wrote a device management framework which would allow you, in a short single line of C, to expose a REST interface to a getter function and a setter function for an arbitrary value to a device's management page. The management page would query the device's embedded HTTP server for its configuration schema (generated with the help of type info and "hint" flags from that single line of C), and render a very pretty, very usable hierarchy of AJAX forms to administer the device.
This was written to serve as a configuration mechanism for a computer vision sensor (networked or individual units) for which I helped design the circuit (both logic and power), ported uBoot, ported the Linux kernel, ported the Angström distribution userspace (not as much effort as it sounds thanks to OpenEmbedded), wrote and/or debugged a myriad of drivers (camera, NAND flash, filesystem), designed the application-level architecture, helped with vision algorithm optimization, integrated MPEG4 video streaming, and built all of the (surprisingly snazzy) user interfaces.
I did this work over the course of a year as a member of a core 4-person team with additional help from 8-10 other people who served in various shared support roles. As teammates we all had our unique preferences, talents, and thought processes, but only our Electrical Engineer was somewhat specialized.
The problem for people like me is that it's exceedingly rare that I get to actually flex my true generalist muscle. I'd bet anything that the team on which I worked was faster and far cheaper than any larger, more specialized team competing in the same space. But how many companies are actually willing to take the risk on a team like this? Of those companies, how hard is it for them to put together this kind of team? How many really have the leadership talent necessary to do so?
Edits:
Restructured so I'm making my overall point in the first paragraph rather than the last
Backend programming in one or more of the following (java, php, ruby, c#, python, node.js, etc)?
Do they know how to optimise and profile code written in the chosen language?
Write SQL queries without the help of a framework, can they do (somewhat) advanced things in SQL like sub queries and left joins, do they know how to optimise the db and the queries?
Do they know how to install and configure the OS and the tech stack (http server, database/datastore service, memcached, load balancer, language runtime)?
~~~~~~~~~~~~
Do they know how to write native system code?
Do they know how to write hardware drivers?
...etc, etc, etc
To me you are a full stack developer if you can do all the things between the two lines in my list above. Some people extend those lines further up and further down. But to me if you can do the things in between the lines well, you are full stack
Full-stack just means they do back-end and front-end work.
Don't try to make it more complicated than that.
The reason I put 'full-stack' on my resume is because I know a lot about back-end programming AND front-end programming and don't want to be in a role where I am only supposed to contribute to one of them. Because the majority of web development jobs are either labelled as 'front-end' or 'back-end'.
It's all about touching every vital task to operating an application.
* Domain Configuration
* Site Architecture
* Database
* Pre Processor
* HTML + CSS + Other UI
* JS
It doesn't matter how "knowledgable" of each operation your are as long as you can get to point a to z. I've work plenty of developers who wear only one hat.
TLDR:
Is it reasonable to expect mere morals to have mastery over every facet of the development stack? No it is too much for mere mortals
My Answer: Is it reasonable to expect mere morals to have mastery over every facet of the development stack? Yes, it is called 4 years min. of a CS degree, and then continuous studies in multiple areas... like any other respectable professional
I have an above average understanding of RDBMS/Data-Persistence as well as back-end services, communications interfaces, front-end services (jsonp/cors) and their interfaces along with front-end (HTML/CSS/JS) and related tools at each tier from the backend (in the .Net world this includes WCF, ASP.Net Webforms, MVC, Unity/IoC/DI in addition to other toolchains such as NodeJS) to the frontend (grunt, bootstrap, amd, less, jquery).
I have no formal training of any kind and have been developing web based applications for the better part of 18 years now. In my experience, a C.S. degree provides absolutely no guarantee of mastery of any portion of software development, let alone a full-stack.
Software development is not about mastering a set of tools, the same way that mastering x ray machines, a scanner, and an echografy does not makes you a doctor. It does makes you a great technician.
There are more abstract concepts, as well as reasoning methods in CS than just tools.
I understand your reply above... my point was in response to... "Is it reasonable to expect mere morals to have mastery over every facet of the development stack? Yes, it is called 4 years min. of a CS degree" I know there was continued study after that... but the CS degree here is immaterial to mastery over every facet of the development stack.
- "I know how to drive all kinds of cars, and I can do whatever trip I want"
- Me: "Airplanes are important, is a different level"
- "But knowing what car to drive for what trip has big business value"
- Me: "I'll wait for you in airport"
We are talking about different things that do not contradict each other. The fact that you are good at what you do DOES NOT PROVE that formal education is unnecessary. And the logic is faulty because what you know has nothing to do with what you learn in CS. We are talking about different axis.
"Full stack" is just a re-fusion of the "front-end" and "back-end" web developer separation that was already tired. Something about "the geeks" not having aesthetic sense and "the backend" being too "hard" for "the designers".
It's much deeper than that. A full-stack "backend" developer also understands networking and how to fully use HTTP headers as they were designed (or maybe even stretch things a bit as necessary). They understand that even though their ORM tool makes it easy to individually fetch a dozen objects from one database table, the particular method they are writing right now, will get heavily called in production and they should configure the ORM tool (if possible) or hand roll the code (if necessary) for a custom query to fetch exactly what they need in one call.
In short, full-stack developers just "get it": network, database, ui-design, system calls, OS configuration, software construction, front-end, back-end, etc. There are trade offs everywhere: risk, complexity, effort, cost. Usually solving improving conditions for one area of the system just push these trade offs to other areas. Full-stack developers get this and can help make better architectural and implementation decisions.
So now there's full-stack and non-full-stack backend developers too? And a non-full-stack BE developer doesn't know how to deal with HTTP headers and ORM?
My main point was that the separation into these buckets is strained already.
Good, well-rounded developers should know the full ecosystem they're operating in. Some will always be better at and more interested in something, other in other things, that's no surprise, but we don't need to invent a stream of vague titles.
So a Full Stack developer is just someone who likes to work in various fields of Software Engineering and has a quick and broad understanding of all kinds of protocols, technologies and design methodologies, plus some amount of creativity ?
I don't understand why any Engineer would want their job to be any other way. Moreover, it's not like you can't be full stack anymore after you become an expert in some technology.
Some people have problems keeping the conceptual differences between different fields apart.
So if they become experts in one domain, it hurts their expertise in other domains as the newly acquired knowledge "swaps over" and "pollutes" the others.
This is contrary to my own experience but if that's how they feel ...
Would you believe I was once chewed out by a co-worker for studying design instead of focusing 100% on back-end development?
The full-stack label is important to me because too many developers are eager to pigeonhole themselves, and non-tech people want to apply descriptives to the people around them. People are constantly surprised to learn I can do CSS and Javascript because someone told them I was a "PHP developer". Better hire somebody who knows WordPress because I'm a "Drupal developer".
Of course, my college coursework really was full-stack. I love the smell of solder in the morning.
My thoughts exactly since I've began working, I have now decided that whoever tries to put labels on me such as "Back End developer" is being problematic.
Like in the web world, full stack would be both frontend and backend. The frontend would be the part that interacts with the user (i.e. WinForms, Cocoa, GTK, etc. depending on your operating system and GUI library) and the backend would be code that interacts with the operating system, makes use of the network, manages the database, computes something interesting, etc.
A simple example would be to take a web project that you just built and bundle the backend and frontend together into an installer, have users download and install it, and only run it locally. If you know a user's platform, you could conceivably replace individual web components with native ones. Upon doing so, you have become a non-web full-stack developer.
In my world (systems development) we have full stack engineers too.
Full stack in my field usually means OS internals, which in itself is reasonably large, usually encompassing kernel structure, driver development, network stack, filesystems and HAL/kernel abstraction layers. Ontop of that it's expected that you know network programming and protocols (TCP, UDP but also stuff like HTTP, AMQP, 0mq etc), databases (including basic understanding of their internals too), also generally stuff like frameworks and APIs that are available.
I know "full stack" developers in the enterprise space too, which again doesn't have much to do with frontend/backend instead just deempasizes importance of kernel knowledge. In it's stead it's expected that they know internals of their VM (JVM or CLR), deep experience and internals of libraries like Hibernate, ASP.NET.
I guess what I am getting at is that the frontend/backend thing is a really web specific thing that though it does exist elsewhere there is much less emphasis is other fields on the actual distinction between the two.
To me being "full stack" only means that your experience encompasses the entire range of layers your project requires.
My intepretation of his definition is for a developer (web or other-wise) to be able to build an entire software mostly by himself, from setting up the server/database/network, designing the data models, implementing the business logic (with frameworks, APIs) and then designing the HTML/CSS/JS UI.
I'm not sure what you're saying. You think this term was made up by HN? Or is brand new? I can find references on the web dating from 2008 without even trying.
I'm not claiming any prior use of "Full stack developer"(TM) (haven't researched that), just that HN discussions often have a web-technology bias, where "designer" implicitly means "web designer", "low-level" means "in a VM inside a browser running on an OS running on a processor", etc.
How deep do you mean? I once did a project that involved:
1) a kernel module to do packet-level manipulation (intercept, hold, modify, inject packets) of TCP streams in real time
2) a user-space daemon to control the kernel module (Python)
3) a web service to control the daemon (Java)
4) a web front-end to administer it (PHP, HTML, CSS, etc.)
I don't want to go into the details about what exactly this system did, but suffice it to say I worked in all parts of that stack. At another job I worked on DSP firmware code and in my spare time I've written simple OS kernels.
There isn't much deeper unless you're soldering wires (spent a summer doing that once...) and flashing FPGAs (never done that). These days I work on web applications doing everything from diagnosing production issues ('why is the database doing that..?') and coding on a Java back-end, to working on iOS and HTML5 applications.
You'd have a hard time saying I'm not a 'full stack developer' by any definition. But to be honest I don't like the term and don't call myself that. I just don't believe in pigeonholing myself into solving particular kinds of problems.
Agreed. This is similar to the generalist sysadmin that can step into a startup to handle all aspects of test/dev/production infrastructure. They don't need to know everything, but they know enough about how it works and can figure out what else you need.
The definition of a full stack developer is someone who can develop for all of the technologies involved in the stack. What those are depends on the stack (e.g. Postgres SQL + Ruby on Rails + HTML5 + CSS + JS vs. SQL Server + C# + AppFabric + WinForms vs. every other combination of technologies people may be developing on).
Understanding of hardware / environment is a useful skill for any developer - not just a full stack developer - the only difference is the full stack developer needs to know about the intricacies of all areas rather than just the parts which affect their part of the stack (since they're dealing with all parts of the stack).
Understanding of the business is again outside of the definition of a full stack developer, but is a useful skill for any developer to have - if you can understand the problem you aren't so reliant on the spec/analyst to dictate requirements to you meaning you can make assumptions about how your code may change in the future and consider edge cases which are important at a technical level but analysts wouldn't have spotted from a functional level.
With both of the above points these are definitions of good developers - but don't sit in the core definition of full stack developer - the same as a good musician should be good at languages since they'll likely tour; but not speaking French won't affect their piano performance.
> Understanding of the business is again outside of the definition of a full stack developer
Like all of these aspects you don't need to be a full blown business analyst, but a full stack developer does need to understand the business to translate business rules into application behavior/logic. Ideally this full stack developer can also understand the problem domain and app code well enough to collaborate with management / business when they try to introduce rules that would contradict other behaviors of the app or the current app architecture. And, doing this for enough time, you should start to internalize the business rules.
To me full stack means front and backend.
You have to have css and js in addition to whatever is running on the servers and persistance.
We have no frontend where I work - it's all hardcore SOA - I wouldn't call myself or any of us full stack.
I've done fullstack and it is a much softer skillset as you need to talk to a lot of people like product owners etc.
We can use the term "full-stack developer" without having a definition, checklist, or example. In fact, I think it is pointless to do otherwise. We use the term as a shortcut in a highly context dependent manner, and will followup with details and specifics afterwards as context demands. I don't think there is such a thing as a "full-stack developer"; instead I think there are developers who use the term "full-stack" to refer to their skillset and/or interests. Recruiters aren't trying to hire "full-stack developers"; instead they use the term to cast a reasonably appropriate net, and then verify key skills and aptitudes at the appropriate time.
Also, "experience" and "full-stack" should be considered orthogonal modifiers. An inexperienced baker may not know how to bake some items; but that doesn't make them not a baker.
Would the term 'full stack developer' really need explicit (i.e. Cisco) sysadmin qualifications?
What about more of the devops "get stuff working" on cloud platforms (EC2, Google App Engine, Heroku etc) using proven load balancing / caching / static serving software, changing your stack as and when you need rather than over-engineering something?
I used the CCNA as a proxy for the level of knowledge as the proper class room taught CCNAs do cover a lot of the basics from first pricipals.
eg how to design and build a small network (2/3k hosts) from the ground up starting with layer 1 the physics behind wifi, how switches STP Ethernet TCP/IP and so on.
It seems like full stack means a different thing for different people or different companies. I started as a full stack developer [1] and now am focusing mostly on business logic.
Usually for a big company specializing make more sense, that way they can hire experts in all fields.
This is pretty interesting. I would add mobile development, perhaps to the User Interface layer? I have not worked at Facebook but I seem to remember hearing that the mobile site used to be a feature team on its own, but has now been split out so each regular group is expected to produce a mobile-ready feature. (If anyone knows more about that I'd be interested in hearing more).
I think mobile development can be considered both frontend and backend, depending on the application and the context. At least on iOS, an app is required to have user interaction so there will be a frontend component (if it is possible on other platforms to write code that the user doesn't interact with then there might not be a frontend component.) If the app gathers information from the phone (such as collecting contacts, getting a list of other apps on the phone, etc.) or makes its own network calls then there is also a backend component.
Even if a mobile app has a backend component, if it connects to some server, then in a web context the app as a whole would be considered as frontend. So if you were writing code to gather contacts, you would be working on a backend portion of the frontend.
Every startup tech founder has to be a full stack guy. To be honest, it's just so much more fun to build a system full stack than just building a piece of it. At the same time, if you understand the entire stack, you will know how to and what not to do for a particular piece of the puzzle.
In a web context, full stack development includes the interface design side of the job as well. So you probably need to add Photoshop, and possibly a bunch of other design tools to your list.
Is it acceptable for a web developer to not be competent all parts of the stack nowadays? Be competent in all parts and specialize in some areas. Also, are points 6 and 7 really a part of the "full stack"?
Interesting, seems that many a ready to imply that it is not really possible to know more than one field well. Why is it so? Maybe I'd agree if we were considering totally unrelated fields, but that's not the case.
I consider myself full-stack+ developer, meaning that I can design and implement backend (RoR, PHP), deploy it, make a frontend (including mobile/responsive, whatever) and make an iOS app using that said backend (btw, drop me a line if anyone needs this ;).
I'd gladly let setting up production servers and doing graphical design being done by someone better skilled at these areas than me, but the rest would be pretty solid and you wouldn't get better results if "specialist" would do that. I do however have 15+ years of experience with web and it is not of "doing table layouts all over again" kind.
My point is: with enough experience, practice and interest it is possible to full stack expert without quotation marks, and more. You may not reach 98% of "expertness" needed for some one-of-the kind project, but 85% will be more than enough for the rest of the project we deal on the daily basis.
Simlar to natural languages, when the more you know the easier it gets to pick up another because you start to see patterns and differences the more of related tech you know the better you get at understanding other.
You will never have enough time to be really good on every part... except you have no private life.
I can develop "everything" too, from Assembler, many Basic dialects, VisualBasic, C, C++, PHP, JavaScript, CakePHP, Typo3, Node, Java, Android, MySQL, MongoDB, Apache, Nginx, to different CloudServies (S3, Rackspace) and many things i forgot in my 25 years programmers life. I can use them all, but i not assume that i can use them all like somebody who is specialised and thats the difference.
Yes, full-stack developer are needed, because they have an overview of many things, but in detail a specialised programmer is meaningful.
And your are right, 85% is for most customers more than enough, but the really good payed jobs are not from 85% of this customers ;-)
* It's a database problem. Call the dbas.
* It's a network problem. Call the network folks.
* It's an app server problem. Call the ops team.
* It's a user interface problem. Call the UI team.
A Full Stack developer first says, 'This is my problem until I can locate the problem and possibly identify someone more skilled than I at fixing it'.