I work on the entire stack. Can I work with databases and write queries? Sure. Can I do it as well as a data architect? No. That's not what's expected of a full stack engineer.
We can have meaningful, productive discussions with everyone on all parts of the stack. We'll talk with the data architect, write/tweak a query if we need to, we'll talk with the product manager and collect some features, we'll communicate the requirements to a backend engineer if one exists and help prepare the API as necessary to ensure the frontend can query for only what it needs when it needs it, and we'll connect it to the frontend which we built (yes, even using data chunking, semantic UI, and accessibility, all of which are expected in professional front-end development)
To the purist engineer, none of this is part of their reality because the purist doesn't have business requirements or tradeoffs. In the real world of business, these skills generate profit and are especially useful with new products and prototypes. If you're experienced enough and have a great team with you, you can execute on this with minimal technical debt that doesn't create long-term problems while still providing users with a great experience.
I would cluster skillsets into: ops, development, and design.
Ops: making things highly available, logging, performance monitoring, reliability, deployment scripts
Development: Writing code on both frontend and backend.
Design: Visual design and CSS/HTML
Most developers I've interacted with at various companies write both APIs in the backend and user facing UI. In my experience it's becoming increasingly rare that a frontend developer doesn't also write backend code.
They typically aren't very good at making their apps deployable and highly available, and they also aren't very good at making things look good with CSS. Sure they can do it, but it isn't their specialty and it would be quite a learning curve or it just takes them much longer than someone who does just that.
When hiring people, I like to find people who are strong individually in those 3 areas (ops, programming, design). I don't try to find programmers who can do ops or design. I don't worry so much about a frontend engineer being able to do backend work and vice versa, the crossover is generally smooth and interchangeable.
It is generally easy to find ops, and programmers who specialize and are talented. Designers who can do visual design and code it up are a bit rarer, so sometimes it is needed have 1 person do design and another person code it up.
Also, a very senior person is obviously going to be stronger in each of those areas, so full stack is highly correlated with working experience.
A very senior backend person will probably know many things about ops and frontend, but probably not about design.
A very senior frontend person will probably know a lot about design, UX and have a good enough experience with backend, but is probably not going to implement good ops practices.
I'd separate the client side scripting and styling / layouts, actually. While JS and JS frameworks are fun and enjoyable to work with, and I can architect the JS stuff well to make maintainable code bases, CSS is still a mess for me. Though getting better at that as well. Flex-box and CSS Grid changes the game completely from using floats to do layouts.
Honestly, even when it is the same person doing both, I feel like it is best practice to do these activities separately anyway. As in, literally on a different day, with a different mindset.
If you design an application's looks and UX according to how the code 'should' work, particularly backend code (DB queries and endpoints etc) you'll most of the time end up with something that's suboptimal for the user without being able to see it - because you have this very detailed mental model of the system behind the curtain and it's 'obvious' that things should work in this way or that in strict accordance with how that system is organised - whereas the user knows / cares nothing about these things and wants things organised in a way that's more intuitive to them.
Its EXPECTED however that one not have all the answers.
In my experience, across general app development there are 4 specializations, and any given engineer should be able to straddle 2 of them.
Client Infrastructure | Client Product | Backend Product | Backend Infrastructure
Full stack generally stays to the product side of both. They tend to have a relatively shallow context on the current goings on of infrastructure/tooling, but can focus on one area or another when the time calls.
> across general app development there are 4 specializations, and any given engineer should be able to straddle 2 of them.
> Client Infrastructure | Client Product | Backend Product | Backend Infrastructure
As you grow, companies can and do hire specialists who do one thing and one thing well which is great. But those things still need to be communicated and coordinated with other teams which is why having someone with multiple skill sets to bridge that communication gap is so important even in larger organizations.
That is highly variable. In a world where a lot of middle management considers "tech people" fungible, this is EXACTLY what is expected from a full stack engineer.
And, you get to do the work of front end, back end, and database developers all at once for the price of 1 person. What's not to love?
Only partially "/s", because although I'm not in that kind of position at the moment, I've seen it.
A purist would cringe. I cringed a bit too. But the end result matters the most.
Like you, I would have thought SVGs would be smaller, but experimentation proved that they weren't. It hadn't be checked before, but new options had to be found around the whole stack!
So instead of the crispy SVG that scaled so well, now there are some custom-sized PNG instead - served by geographically close VPS. It seems very dirty on paper, but in practice it works much better than the previous solution that as I purist I found very cute and clever. Unfortunately, it didn't achieve the goals and had to be discarded.
I find that a funny example that illustrates how full-stack engineering is very real.
* Photo - Use JPG, WebP or similar
* Images used at a single predefined size, where quality matters, e.g. logos - Use PNG
* UI graphics that are displayed at integer multiples of the base size, eg 24, 48, 72 - Use SVG
* Illustration graphics - investigate trade-offs between size and quality for both SVG and PNG
Had this issue about 5 years ago. Good SVGs need to go through a manual code filtering step.
On the integer coordinates side of things, if an SVG has horizontal or vertical lines, I’ll always make sure they’re well-aligned before putting them into a UI.
Sure, if you're a Fortune 500 company, go ahead and hire a DBA, Cloud Architect, Backend Engineer, UI/UX Designer, Graphic Artist, Social Media Marketer, etc.
You'll have a few million $ in salary overhead. It may take longer to produce a final product.
BUT, it will probably be way better than a product that a full stack developer knocks out.
BUT, if you're a startup or SMB or lean department and have a 100k budget and a 6 week deadline a full stack developer is a huge asset to your company.
Obviously when you take the same project and give it to a highly specialized team of people with lots of time they produce superior results. Do we really need an article about it?
PS. Giving a 10 person team a 1,000 hour time budget would not be a huge deal. Try not laughing when a single Full Stack developer asks for 1,000 hours.
Few people says one person can't do it all. Few people say that nobody can do it. But we specialize in areas for a reason. It takes a lot to be an expect in an area, and multiple that by three and its even more work and time.
So sure, one person can do it all. Sure, one person can do it all well. But the later is much rarer than the former. And have specialized people for each area who can focus exclusively on their area is better.
The key thing to understand is that while the overall variance will be small, you don't know what the multiplier will be. For teams that you are familiar with, technology that you are familiar with, etc, etc, in my experience people do tend to come out with about the same overall multiplier. Different teams are vastly different, though. I've had teams that operated anywhere from 0.5x (i.e. they overestimated by a factor of 2) to 4.0x (i.e. they underestimated by a factor of 4). It's always best to keep measuring your team's performance to figure out what the best multiplier to use (this is what's known as "load average" in some "agile" systems -- the inverse is "velocity"). Care must be taken to dissuade people from trying to optimise the load average/velocity because it will undermine your estimations -- usually I don't tell people what it is.
Now the other scenario is also fascinating, but requires much less statistics to understand well. Basically this is when the stake holder constantly inserts urgent requests, or cancels tasks mid-development because they thought of something better. Or when your team sits around for 5 days arguing about whether to indent with spaces or tabs. Or upper management decides to "accelerate" the process by constantly inserting new members into the team. Or someone intentionally tries to sabotage your project because they have a "competing" project in the company (or possibly just because they see you as a threat to their eventually triumphant march to the heights of the org chart). Or your lead developer decides that today is the day to institute a national "bring a firearm to work" day. In those cases your schedule is fiction, no matter what process you used to create it.
BTW, all of those things have happened on teams I was on in my career :-). Incidentally, not having a firing pin in a weapon is not considered evidence that it was "just a joke", strangely enough...
Even more interesting (and I was thinking about this only 5 minutes ago), there are models for defect discovery rates. This basically means that when we write code we make software errors. The amount of time it takes before we discover the error is a random variable with a particular distribution. There are several models which try to allow you to determine how long it will take before you find 90% of the errors, for instance. I was just thinking that I bet the model for errors in requirements is probably very similar to the model for software errors and you can probably fairly easily model how long it will take you before you discover 90% of the remaining functionality that you need after you make the initial plan. Indeed, I've measured in a few groups I've worked on that for those groups they needed another 30% of the overall project time to complete tasks that were not anticipated at the start. Unfortunately I no longer have access to that data so I can' look at it in more detail.
(NB: 30% was just for those teams and those projects -- I don't for a second believe that the number is universal. The fact that it was similar for a few teams is probably coincidental.)
It seems that the world clearly lacks a definition of what Full-Stack Engineering really means ...
In my spare time I also had to create some new admin screens and do a bunch of back end work. I also created a bunch of new svg images for the admin screens.
Basically I'm expected to do everything from setting up and managing linux servers, security, install and configure software, set up oracle and postgres databases, do DDL and DML work, write server-side code, write web services, create images and do layout work, write test cases, write html, js, css, and know a bunch of JS libraries like vue, vuex, vue-router, webpack, jest, bluebird, lodash, async, tailwind, scss, etc. ad naseum.
I consider myself a “full-stack” programming language engineer because I’m equally comfortable with type theory, user experience design, practical implementation, and instruction-level optimisation. Am I a full-stack web developer because I’m equally comfortable with front-end design & development, server-side infrastructure, and networking protocols?
Some would say yes, some no—but I can readily develop, maintain, and optimise a whole application by myself if I need to. I may not do as good a job in any particular narrow area as a specialist in that area, of course.
I'd defer to a specialist in essentially every field, but if you require a broad range of work to be done without hiring a half-dozen people, I'm who you're looking for. The best title we have got that kind of experience is Full Stack.
(It's also a well-understood recruiting buzzword you can use to quickly indicate the work you want and the salary you expect.)
The guy talked about having beautiful SCSS. At some point, you are talking about design and less about engineering.
Full stack is a job to be taken on by a small team. Having a large team with lots of full stack makes 0 sense.
Though to be fair it probably does, because having your entire professional community believe you don't exist creates ridiculous amounts of frustration, anxiety and imposter syndrome.
I do (with skill levels ranging from competent to highly regarded):
* UI design
* Data architecture
* API design
* Front-end accessibility (not the best, but I don't just do div/span soup and call it a day)
* Front-end performance (i'll spend weeks optimising the hell out of everything I see in browser devtools if given the chance)
* API performance (see previous).
I tend to draw the line at devops and sysadmin stuff, mainly because I don't find it interesting. But for everything listed, I do it because I enjoy it. And there plenty of aspects of engineering professionalism i'm not great at, which offsets the fact that I apparently have an impossible unicorn set of skills.
Honestly, I wish I didn't and was happy doing just a subset. But if I'm spending my time doing just design, I get frustrated that i'm not coding, and if I'm just coding i'll be dreaming of design. Also, the context-switching is hell. I wish my interests would let me specialise, but they don't.
* Recommendation engines (less relevant now a lot of it is easily achievable with tools like Spark)
* Data processing pipelines
* Search indexing, optimisation, and relevancy tuning for millions of products
* Actual database model definition and business logic (possibly where the confusion was, i kinda meant to say everything between database and request/response layer, when all I really said was data modelling).
* Weird stuff like integrate Django’s model layer seamlessly with RPC frameworks. Essentially you could define “foreign keys” that worked across service boundaries and they’d work transparently and decently optimised.
* Systems architecture. Defining service and communication boundaries, message queues, pub/sub etc.
There’s probably a bit more I’ve forgotten about. Does this address the imbalance a bit?
My point is that if you define full-stack as merely having the skillset to do these things at an intermediate/senior level, then there are plenty of people who fit the bill. The issue is time management, I don’t think it should be someone’s job to do all these things, quality will suffer regardless of ability.
Web development is and should always be a full-stack affair.
Otherwise your frontend developers would request apis in a way that destroy performance and create a database model or logic that is unmaintainable on the server-side.
Your backend developers would make apis that make the requested front-end design make a hundred api calls or api calls in the wrong places (like during a transition/animation).
It's not just about communication either, though that's also important - it's exceedingly hard for specialized developers to understand the reasons for another's requests, being full-stack means you can see the full-picture.
It's about owning the feature/product from beginning to end. It's about knowing what tradeoffs to make in the serverside, clientside, database or ops, which you can only do effectively if you are familiar with each.
It's about never being stuck waiting for your backend to fix an api that isn't right, for your dba to build that query so it won't take a year to run.
That isn't to say that you can't specialize while being Full-stack or that specialized roles outside of web development shouldn't exist (for example game development, big data, machine learning).
I'm a backend dev; I know enough JS and CSS to build a prototype, or to make a tweak like you're suggesting, but I can't build a production-level frontend app or website. If that's full-stack, the term is a bit too fluid to be meaningful, in my opinion.
For that matter if you were a senior full-stack developer I would expect you to be able to build a production level frontend as well as a production level backend (though maybe not operation-wise, I.E. deployments and configuration, depending on your background).
That still doesn't preclude having expertise. For instance I wouldn't expect a full-stack developer to know how browser rendering works or the difference between layout and paint events (but I would expect him to know to never access an element's size during an animation) - that's someone with an expertise in front-end performance.
But anyway that's not what I gathered from the article, to me it purports that back-end developers shouldn't do front-end work.
I expect a full-stack senior developer to be able to lift a webapp from scratch (frankly I'll probably expect it even from an experienced junior full-stack developer in today's PaSS world).
I expect every full-stack senior developer to be able to get the job done in both front-end features and back-end features, as long as they aren't very specific. I expect him to be able to do so in a maintainable and relatively performant way that has structure and consistency behind it.
I expect him to know best practices for both front-end and back-end. In front-end that is for instance knowing that you don't measure dom elements inside animations.
I don't expect him to know the internals that led to these best practices (in this case how the browser works and the nature of the layout phase) nor when is it ok to break them.
If best practices were followed but something still doesn't work it's okay to call an expert (for instance an expert on browser performance).
Specializing as a fullstack-developer means that you are also an expert in some field (for instance browser performance, or web animations, or graphs).
Perhaps a better phrasing is that since I don't really expect pure front-end senior developers to know it either, only those who specialize in certain fields, so really a full-stack developer is already a senior front-end developer and a senior back-end developer.
There isn't something that makes a front-end developer more specialized in front-end then a full-stack developer, it's just that he didn't work enough on back-end.
Do you really expect a backend java developer to be comfortable with angular/react and vice a versa?
So are we agreeing that being extremely broad is an anathema to quality because you cant possibly constantly practice will all things?
You can, if needed, produce a working app working from the database all the way to front end. This includes, design, ops and development. All of it.
Why? Because you believe the former causes the latter?
There are many valid criticisms to be levied against Oracle the company, enteprise software in general, and especially its pricing.
However, it's important to remember that, for many businesses, it's either impractical or downright impossible to hire enough engineers to make up for to lost features of replacing Oracle with even somethig as relatively feature-dense as PostgreSQL.
I would have granted you this if you'd said "for a few specialized businesses", but you're waaay overselling it. 99.9% of businesses using Oracle would do just fine with a "lesser database".
And I would grant you that if you could make the credible argument that a "lesser"  database could be a suitable replacement on a drop-in basis, without significant engineering effort.
As I pointed out in a downthread comment, a very useful feature is that existing stored procedure that encode business logic already work.
Are you really saying that only 0.1% of business database users fall into even that category? My second-hand (DBA I know) experience contradicts this, but if you have a better source, I'm certainly interested.
 I don't actually intend to make any overall value judgment, since my point isn't that Oracle has feature/performance superiority over any other database. Instead, I'm saying that it has specific features that the business needed at the time it was chosen that may not be offered by a different one.
But Oracle doesn't sell their product with the pitch "hahaha too bad you're stuck with us". They try to convince the next generation of ill-informed technology leaders that it would be a mistake to choose anything else. I've heard the pitch, and by the third time I heard "invest in Oracle RAC" I was consciously suppressing the urge to punch the salesman.
I'm saying that 99.9% of Oracle customers would have been significantly better off from a cost, flexibility, and support perspective going with an alternative like Postgres when they started building their product. And most of the remaining 0.1% would have been better off with MSSQL.
Although I agree that some huge proportion  of businesses today would do very well to seriously consider Postgres as the first option before even looking at Oracle, I don't recall this being true 17  or even 10 years ago.
Remember, we're likely talking about non-tech businesses here, ones where they're sustaining operations with a single developer. You mention "ill-informed technology leaders" but it's hard to imagine there are any technology leaders actually involved on the buyer's side.
I don't think it's helpful to look back at such a decision through the lens of today's technologies and the kind of talent/expertise that is, today, available to a business whose core competency is tech.
I'm no fan of "enterprise" anything, so don't mistake my critique as cheerleading Oracle. I just feel the context of technology decisions is paramount. It also seems especially germane to the overall thread topic, which is whether a generalist can possibly have enough depth in key areas to be considered competent enough in them.
 your repeatedly asserted claim of 99.9% is extraordinary, requiring extraordinary evidence.
 Oracle 9i was released in 2001. EnterpriseDB wasn't founded until 2004.
It reminds me of the early 2000s when IBM and WebLogic were selling 5-figure appserver licenses hand-over-fist into enterprises. I would have to dig, but I do recall a study sometime later finding that almost all of these customers were just using them as servlet containers. It's not that WebLogic, Oracle et al have no purpose, it's just that the people buying these things tend to have no idea what they're doing.
To whom? This particular business? 999 out of 1000 businesses (each of whose needs you evaluated and found only one of whom really needed Oracle and therefore excluded)?
What was the argument? That they could do it cheaper by hiring (possibly then non-existent) Postgres DBAs and using Postgres instead of Oracle DBAs and spending exorbitant amounts of money on Oracle?
To us, technical people, that argument might sound perfectly reasonable, but to a non-tech executive it might sound cuckoo-bananas crazy.
> It's not that WebLogic, Oracle et al have no purpose, it's just that the people buying these things tend to have no idea what they're doing.
This strikes me as a dismissive stereotype. As you admit, it's not as if they made a choice that failed to function at all. Social proof is a thing. They merely paid a very high price.
Where were all the people who did have an idea of what to do, those 20 years ago? Busy trying to educate them, or separate them from their money? How about you?
I'm not quite sure what your point is. It's all understandable because nontechnical people were making technical decisions? That doesn't make it ok.
And yes, quite a lot of those overpriced appserver installs failed to function. Let me tell you about the time I wrote the backend for Sprite's Sublymonal campaign; their IBM-operated datacenter couldn't provision WebSphere capacity in time (lead time > 2 months), so I ran the thing off a couple VPS nodes (IIRC rackspace), hiding the whole project from their IT staff.
My point is also that making sweeping, moralizing statements like "doesn't make it ok" (nor the repeated forays into other enterpise software topics) isn't helpful in general, and it certainly isn't helpful in furthering understanding or intellectual curiosity on the specific topic, as it relates to Oracle and a single, generalist (arguably "full-stack") engineer performing a sustaining and development role.
I personally know a "such a small development team" (i.e. a single person) who certainly has the expertise, by virtue of having trained to become an Oracle DBA after a fairly extensive career as a software engineer.
As for need, I'm no expert on Oracle's unique features, but the GP specifically mentioned "reverse-engineering stored procedures", which implies at least previous developers thought there was a need to use an arguably advanced database feature.
In fact, even just having a substantial quantity of stored procedures written in PL/SQL, perhaps at a time when that company had (or contracted out to) a larger development team may make it prohibitive to switch to any other language. Reliably implementing business logic as-is is a pretty big feature.
We are talking about 10000s of dollars per CORE (not even per cpu).
Also for that matter, I've never met a company that uses oracle features that aren't available in Postgres or can be made with MySQL and another service such as Redis or ElasticSearch.
It also impractical to maintain without a dedicated DBA.
Which usually means that if a company uses OracleDB they are loaded with money.
Amortized over what period of time, though? Is that today's price, or 17 years ago? Is that list price or the price an actual small user would pay?
> I've never met a company that uses oracle features that aren't available in Postgres
I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
> can be made with
Businesses whose core competency isn't tech and/or who aren't located in a tech hub aren't likely even to consider the "make" option.
> It also impractical to maintain without a dedicated DBA.
That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I suspect there's another growth/tech-centric bias at work in this assertion.
All that said, I'm not a proponent of Oracle (or enterprise software in general), but I am a proponent of fact-based discussions.
Today's prices. 10s of thousands it is still whether you get it at retail price (which is unlikely) or if you amortize it for several years (including yearly support of course).
An actual small user is still likely to pay 10s of thousands of dollars a year.
> I'm sure you'r in the majority here on HN, but that's merely selection bias. Also, it's true today, but was it true 17 years ago, circa Oracle 9i?
Can you provide me with such a feature that Oracle has but Postgres doesn't and is in demand?
Oracle db is a masterpiece and has the best performance of any database I'm aware of , sometimes several times more if properly configured. That was it's big selling point in days of vertical scaling - the hardware was often a lot more expensive then oracle's licensing.
Why are you bringing up a version from 2001? Was that mentioned in parent posts?
> Businesses whose core competency isn't tech and/or who aren't located in a tech hub aren't likely even to consider the "make" option.
Business without tech as a core competency outsource.
> That's simply false, as the Oracle DBA I know routinely contraced out to companies as a temporary, non-dedicated DBA.
I suppose you could run an oracle DB with no or little DBA support. But the companies I know who use it use features that require constant DBA support - replication being the biggest one.
Perhaps not relevant, then.
> Why are you bringing up a version from 2001? Was that mentioned in parent posts?
Yes, Oracle 9i was specifically mentioned, which is why I find it bizarre, if not inappropriate, to criticize (let alone laugh, as an upthread commenter did), with not just "20/20 hindsight" but also with today's technology availability.
> Business without tech as a core competency outsource.
That's just a synonym for "buy" in the "buy vs build" decision, whereas "make" is a synonym for "build".
As somebody working on PostgreSQL full time, I very much agree on that. Neither today nor back in the 9i days has PostgreSQL implemented everything Oracle provides. Nor the reverse, for that matter. And I'm not just talking about features nobody uses.
> > It also impractical to maintain without a dedicated DBA.
I do think it's easier to operate several databases, including PG, without a dedicated DBA in comparison to Oracle. Obviously it's entirely possible for both.
> writing brute-forcer to crack P12 private key because someone forgot password
I like coding and I definitely find programming enjoyable. But, importantly, I don't write software for the hell of it. If you actually give a damn about software development, I don't understand how you could simply dismiss one side of software development due to where it gets executed in the stack.
You've spent enough time designing software that you can take a vague spec, design a solution avoiding common pitfalls and following a very easy path. Then you hand back a prototype followed by a complete and maintainable solution to a happy client.
At that point, your services should no longer be _required_ to keep the product working.
Of course, it's software. We can change anything!
Even better, I'm not busy trying to keep your current software working - so I can get right on it.
Junior - Needs close supervision. Can't reliably develop something more than 1k lines.
Mid level - Has learned to follow a design consistently. Doesn't keep an eye on the bigger picture. Likely to fall apart around 10k lines.
Senior - Can work in the weeds and keep an eye on the business as a whole at the same time. In my experience is likely to be able to design something that can scale to 100+k lines.
I think the real maxim is more along the lines of "if you need actual full stack engineering, you don't want a full stack engineer."
Because full stack engineers are not there for large, highly engineered, Amazon/Google scale sites.
They are there for the MVPs, the startups, the moderate scale internal line of business tools, your local city government, or one-off moderate projects.
A full stack engineer is not there to have expert knowledge of every single micro detail of front-end, back-end, databases, site performance, SEO and such.
They're there to have a general knowledge of them, produce something reasonable, and know enough of all the ends to ship in a timely manner, hopefully with design decisions that can be easily tweaked, meet requirements, and don't have boatloads of technical debt, until 'till it justifies a larger, more specialized, engineering investment, or just putters on with light support 'till end EoL because it's good enough for the scale of operation.
A full-stack engineer is not always going to write the best front-end ever; there may be some kludgey stying and some non-semantic HTML (divs and spans!). As a non-DBA, queries may not have optimal execution paths. There may be questionable backend design decisions.
This is an obvious conclusion and does not really speak to the value that a developer brings to an organization. Development is a means to an end, and there are plenty of business cases that an experienced full stack developer can solve in a 'good enough' manner.
We run the risk of letting the perfect become the enemy of the good. Any mature developer should have one or two areas of deep expertise and have enough skill in other domains to get a job done.
The front end of a single-page React application is a lot more complicated than just HTML templates and CSS, and you can get all sorts of productivity and developer happiness gains from being able to jump between front end and backend - consider implementing the network layer in Redux, breaking out validation logic into a shared library, or fixing a bug that can only be understood by looking at both a front-end request and the endpoint that handles it.
He is complaining that someone who does many things won't be as good in front-end as someone who does only front end.
Nobody expects full stack engineer to be all that great in front-end. That's why he is not a front end engineer.
Vice versa he won't probably be all that good in SQL or in administration and devops.
I am not even sure what is this guy complaining about exactly
I think that bias says more about the particular kind of company you're in than the general label of "full-stack".
Back-end is where the state of the application is. Where all the users are served, not just a single user. The back-end is where things are going to melt down with scale.
If you make bad decisions in your backend you might find it hard not to lose customer data. They might also create user-visible latency or reliability issues.
Front-end by contrast tends to keep working as well on day 100 as it did on day 1.
If your point is that stable and boring back-end with shiny front-end is good, then yes, I agree with you.
* provisioning and updating servers
* installing and configuring software on those servers
* keeping server system software up to date (Apache/MySql/Php/etc)
* maintaining and developing custom frameworks
* writing all the admin tooling for getting sites up and running and configured
* working in our backends including writing queries
* designing databases and migrations
* maintaining deployment of new code and version control
* setting up build systems for our apps
* designing frontend systems (how they use api's, deployment of them, stores, etc..)
* writing components and styling them
While I am a Senior/Team Lead and don't expect people to be experts in all of that stuff, debugging requires at least being willing to take on any of that.
The author seems to think that just frontend development requires all your mental capacity. I really don't want this to come off as me being arrogant but feel very confident in my skills in everything he described AND I do all of the above web stuff and more. I also manage a team and meetings and timelines and quotes and resourcing and sales questions etc... It's not that hard. And I know I am not a 10x or 100x dev (maybe 2-3x)
For example, a front-end specialist would be better off optimising the slow page response times of the product's news feed or implementing a new application page altogether than, say, adjusting css that break on a few view ports. In a big team, you can push the CSS fixing job to a junior; but in a lean team, it's better if this goes to a generalist in your team.
If your backend dev is busy on implementing OAuth, he can off-load fixing a bug that has a small fix but is hard to test like a minor refactor. You compound this "minor" jobs and you will need a lot of junior staff to help on the load, or you could hire a full-stack developer to help with the whole team.
Eventually this generalist gains a good understanding of the full stack, as his title implies, and can contribute good ideas that affect all parts of the system. They also make good tech leads because they can interact and empathise with all members, and can call out decisions that may seem good on one part of the stack but could have horrible implications on the other end. Some progress to Architects simply because they have the bird's eye-view of the whole system.
Lastly, if you are a fledgling web startup, it would work against your business interests to hire an expensive specialist right away.
I disagree mostly. I’m pretty full stack from UI down to circuit design, but that’s after almost 20y in the business.
To fully prove my point, here is a quote... also written by me. Huh?
Is that supposed to be convincing? Odd assumptions here.
Like that guy on FB that always likes his own links.
In the first paragraph, the author sets up a really weak straw man for himself to defeat. If you define "full-stack engineer" as "an expert at front and back end", it's pretty easy to not believe in it since you may as well be restricting the category to people who are 3σ. If you define "full-stack engineer" as someone who "can do front and back end moderately well". This is much easier to believe in.
As products and teams scale up, cross-stack expertise becomes far less valuable than domain expertise and institutional knowledge.
This post also leaves off another area that I'd expect of a senior full-stack developer: Infrastructure/Ops.
OP, feel free to chime in!
Later, in highschool, the first real programming language I learned was Java, and I did some personal projects with that on my own.
To learn the backend, I built from scratch:
* a simple (and crappy) ORM
* a simple (and crappy) db-backed session system
* a simple form-generator (similar to Django forms, for flask)
* login / user handling (etc)
I have worked for years doing both backend and frontend development (JS visualizations for SVG/canvas, data-heavy SPAs, backend APIs, Golang services to process data, work with AWS, docker, etc), and I doubt that I am unique. Full-stack developers do exist, though of course one only has so much time and "jack of all trades, master of none" will apply to many.
Many of these new-bootcamp grads build a simple Node web-app without realizing many of the problems (and solutions) inherent in the backend and label themselves full-stack. That's the problem; not that the frontend is somehow too difficult to master, or that the backend is somehow out of reach.
I would consider a full stack developer to be someone who likely has one or more areas of expertise, but is able to quickly move out of their comfort zone(s) and contribute in a meaningful way towards any part of the stack.
I blogged this with the point of view of a full-stack developer that can do front-end development, but rather didn't a while ago: https://coderbyheart.com/the-full-stack-developer-trap/
So, here we have a click-bait title and our reactions are feeding into the apparent pretensions to fame engendered.
It seems that the real approach of this article should have been to outline why hiring ONLY full-stack engineers may not be a good idea.
I remember the last big company I worked for, they asked me "What are you: Front end or Back end?" and when I said that I could do either equally well, they said something like "Lots of people claim to be both but you can be honest with us, which one are you really?“.
I ended up doing only front end at that company for a while then got bored and quit. My next company I did full stack and they actually got to see the benefits of letting engineers use ALL of their skills.
To be honest, I'm getting sick of the front-end/back-end bifurcation that I see literally everywhere now. I'm even guilty of it. It has this notion that you are either back-end only or front-end only. It really leaves no room for actual expertise that allows a software engineer to actually build software.
In fact, the terms back-end developer and front-end developer imply neither person on his or her own can actually build working software without the other. And that's total crap.
These terms started appearing more frequently in the mid-to-late 2000s and nowadays they seem to be all over. But back in the early and/or mid-2000s, "Web Developer" or "Software Engineer" or "Application Developer" sufficed and it was implied that you could build software from scratch, soup to nuts. Of course, in a large organization you had multiple "Web Developers" who surely specialized in one thing or another in order to help their comrades out so not everyone was doing everything at the same time to maintain sanity. But still, as a "Web Developer" it would be expected that you could build software and everything that entailed for the web. Not "Oh well I built the backend... now you just need one other person to do the rest."
Internal software usually doesn't have to be as aesthetic on the front-end (UI) such that you can maybe sacrifice there, for example.
Sometimes you can throw hardware at poor performance if performance tuning is not a person's forte, but sluggishness may snag you at a bad time before you have time to upgrade to a more powerful box(es).
Databases? Containers? VMs? I don't even know where to start!
But when I got into serverless, it wasn't that hard.
Sure, with DynamoDB and S3 I have to manage aspects of my storage, but not much.
Sure, whith Lambda and API-Gateway I have to manage aspects of my back-end API, but not much.
Setting up a DB cluster and microservices with containers is something a fully fledged back-end dev needs to do.
But getting something decent up and running with serverless technologies is something I can do too.
Also if you become really good at something you'll realize that actually it is not all about more skills. There's a point where strategic decision making overcomes coding skills.
E.g. 1: I spent years to really learn vim and git indepth. I can write my own git clone and did that before as well. However I have seen so many different editors and IDEs that I'm at a point where I can take whatever is there. I use nano with ease if the situation requries it. This makes me quicker than installing my favorite editor, my configs and then start working.
E.g. 2: The more experience one gains the more one sees that the biggest drag on progress is usually misunderstanding, lack of info, lack of responsibility. So nowadays I do more for my team by creating meeting requests with the right people. For that I need to be able to read all of the source code and docs to figure out where the actual problem is and who really has the expertise to solve issues there. But I don't need to be as good as the topic expert.
That I don't think will be true unless it's pertaining the eventual abandonment of the web browser as the run-time.
The awful tangled spaghetti that is the current code for a web site UI is not tractable going forward. It takes way too much effort to make a usable interface for the value in return. It's also too limiting. And too difficult to maintain. These are all problems caused by using a run-time originally developed for document browsing that has been pressed into service as an application platform.
As a full-stack developer, the front end is the most annoying to work on because it's the most deficient and under-powered. Consequently, we don't put as much effort into it.
Eventually it has to come to something more sane. Maybe web assembly running in a virtual machine - in don't know. What I do know is the advancement of computing is being hindered by the lack of a competent UI system.
Hasn't that always been the case? UI has always been a mess, at least as far back as I can remember.
Where the idea falls flat is where you draw the lines in each discipline. Do you expect a front-end developer to have domain knowledge of all the leading frameworks out today? Do you expect them to be immediately productive on an Node/Express project? Additionally, on the back-end side, would you expect that person to have written production-ready code in a set of languages like Ruby, Python, C# and so, with full domain knowledge of all their respective frameworks? There are front-end devs that know a huge amount on the frontend side, and backend devs with working knowledge in a whole range of languages, but it's difficult to find a (sane) person that knows it all.
But, if you're a Rails shop, it's not uncommon for someone to know Rails really well, and be a solid frontend developer. If Ruby/Rails is your bag then that person is a full-stack developer, even though they might be completely useless if you're a .NET shop. Using myself as an example, I was fairly solid on the front-end, but as I got more involved with back-end dev I found my domain knowledge falling behind. I reckon I could throw together a halfway-decent front-end application, alongside a Rails/Django/ASP.NET MVC application, but I'd feel uncomfortable calling myself a full-stack developer because I don't consider myself good enough to know it all.
I'd be doing myself and a future employer a disservice by selling myself as such, but it doesn't mean that people don't, especially more controlling developers that want control over every aspect of an application.
* Why are we doing this?
* What is the business value we expect from this?
* What resources do we need to do this to a level of quality where it has that business value?
And yes, I know about "font loading, images, SVGs, animations, auditing third party scripts". Still sometimes, you have to dig deeper in the stack to find the low hanging fruit that will make the difference between meeting requirements or not.
After throwing away the nice SVGs and replacing them by inline PNG (uglier, but you need that 15% size difference and the precious milliseconds), what do you do?
My current solution is a combination of various things - the last element being VPS close to the customers to provide resources with a very low latency.
(and by the way, if anyone happens to know reliable VPS companies in South America, Japan, South Africa, I would love some recommendations. I only know about Hetzner ZA and Linode JP. I would love to find some good host quality around Uruguay or Brasil)
Everyone else only gets to pick a somewhat arbitrary subset of those aspects. Some pick subsets from both front-end and back-end (in fact even for a front-end developer having at least some understanding of back-end development is a good idea and vice versa). If those subsets have no clear bias for one over the other, congrats: you're doing full-stack.
Yes, the label is misleading, not every full-stack developer can literally work at any level of the stack equally proficiently. And if they're relatively new to programming they may have spread themselves too thin.
Heck, in the 90s most web developers were "full stack" by necessity (mostly because there wasn't much of a frontend until CSS gained traction and AJAX became a thing). Back then we just called them "webmasters".
My boss at my last job had done the opposite. Coming from a tradtional compsci C/C++ background (many moons ago), he learnt Angular 2 for a frontend project that required it. Both his C++ and frontend code were among the best at our company.
Saying there aren't good fullstack engineers is like saying multi-instrumentalists aren't good musicians. Sure, the very very best violinists probably don't play other instruments at a high level. But the average multi-instrumentalist (who plays the violin) is a lot better than the average violinist.
What actually is your point? Reading between the lines, it seems to be:
"Anyone who calls themselves a full-stack developer is garbage - it's just a matter of what side your garbage is on."
I'm fine if people just call me a programmer or software engineer, but it seems that these days, full-stack developer/engineer is what people need to know in order to place me.
The fullstack engineer or T engineer is someone who shows versatility when it comes to the tasks given, he has an issue on the FE that is related to BE. He doesnt need to solve it but if the understands and then can point to the person who can fix it quickly thats key.
"I’m Robin, a web designer, writer and typographer living in San Francisco."
Some people want to focus on front end problems, some want to focus on backend problems. I personally just want to focus on problems. I'm neither front-end or back-end. I'm a software engineer.
Since the skill it's transitive and it's one of the skills that gives the highest value long term, I don't see how there couldn't be a fullstack developer.
That doesn't mean there aren't front-end people who can write a bit of SQL or back-end people who can throw together a simple website. That's fine, those are basic commodity skills now. But everyone has to choose the culture they are comfortable with and that will dictate where they fall on the technology spectrum too.
I know, consultant with expertise delivering delightful experiences.
Ridiculous to find out I've been doing the impossible for 15+ years now? Somebody give me a raise!
Maybe I don’t exist.
Thus, I find this entire conversation to be mostly useless, except as a survey of what the term "full stack" means to different people, particularly those who brandish it.
If you read between the lines, you could pretty much say that as much time as you split between backend and frontend you would need to become a solid engineer in either of those domains.
I wonder how many people honestly believe that they are doing good "social proof" work for their career when they publish pieces like this.
However, many of these read as insecure, pedantic, and a decent lack of self-awareness on the authors part.
Tone deaf. Pretentious SV "influencer word salad". When reviewing resumes, I always do a ton of Googling. This would have given me a bunch of soft data points that would potentially outrank his/her resume
"Full-Stack Engineering" as defined by Robin Rendle - would have been a more honest title, but no one would have clicked.
Ah yes, I love cleaning up the mess every "architect" I've ever worked under has left on the front-end. Front end development is an arcane art, full of a million gotchas that have nothing to do with intuition, intelligence, or programming skill. It's just years and years of running into stupid mistakes and API quirks to build that domain knowledge. Anyone who doesn't respect and accept that is sorely mistaken.
At least I get paid lots of money.