What is a Full Stack developer? (2012)
laurencegellert.com
laurencegellert.com
* 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'.
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.
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.
To me, "full-stack" means: You can do everything because we're a small startup.
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 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.
Elwood: What kind of music do you usually have here?
Claire: Oh, we got both kinds. We got country and western.
The tendency of web developers to appropriate well defined terms for their limited little world is a bit unsettling.
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.
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.
And sometimes even hardware all the way to application level.
I don't understand what you mean, what is 'hardware' here?
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?
I just don't trust someone to write my web app who doesn't understand how electrons move.
Kids these days, sheesh!
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.
Fuckin' magnets. How do they work?
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.
Haha, I cringed.
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.
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.
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.
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.
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.
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.
[1] http://en.wikipedia.org/wiki/Solutions_Architect
[2] http://www.wittenburg.co.uk/Entry.aspx?id=91035731-e5b6-491d...
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.
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.
Realize this sounds quite narcissist, but IMO, I am a full stack web developer. :)
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).
Get paid.
I think its great to be a full stack dev.
On the other hand you can build your own MVP's
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--)
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
Requirements analysis?
Project management?
Ui and ux design?
~~~~~~~~~~~
Front end web code (html, css and js)?
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
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.
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 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.
There are more abstract concepts, as well as reasoning methods in CS than just tools.
- "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.
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.
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.
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.
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 ...
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.
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.
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.
"Anyone who calls themselves a 'Full Stack Developer' clearly doesn't know how deep the stack really goes."
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.
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.
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.
AKA: Behavior Driven Development.
Start-ups want people like this because they can't afford the management overhead of making people with various skills work together.
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.
Does it fly in interviews to claim you are an expert in absolutely everything? Just curious.
It's a shame that good developers can be passed up because they don't have the right keywords.
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.
Surly a full stack means dev you can go from the wire up to a complete application. In practice this means at least a CCNA.
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?
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.
Usually for a big company specializing make more sense, that way they can hire experts in all fields.
[1] http://idiallo.com/blog/2013/05/from-full-stack-dev-to-backe...
Disclaimer: this is my blog, wrote it a few weeks ago.
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.
Anyone else is just a very snub, but not full stack, developer.
It has been a great learning experience for me.
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.
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 ;-)