I don't want to be a full-fullstack developer

https://artur-martsinkovskyi.github.io//2019/i-dont-want-to-be-fullstack/

by gentleterror • 7 years ago

115 84 7 years ago

artur-martsinkovskyi.github.io

the rabbit hole of developer-focused engineering process and developers go on to combine more and more responsibilities beneath the surface of single cranium.

(1) There's a strong reason for this desire. Software systems are very interdependent.

We you can see from front to back and side to side, and you can recoginze the potential for improvement or optimization.

(2) "Full-stack software developer" is more specialized then you might think.

As a "full stack" web developer, I can count on one hand the number of times I've looked at a browser's source code. Same for databases. I understand the basics of DNS, IP, TCP, UDP, BGP, but not the details. And my knowledge of common ISAs is laughable. And I have essentially no knowledge of hardware: physical CPUs/GPUs, displays, fiber optics, etc.

11235813213455• 7 years ago

For me, Fullstack is only enjoyable when using JS or TypeScript both in backend and frontend

hinkley3• 7 years ago

I thought I’d feel that way but it turns out I need a break from Javascript sometimes. Doing a backend story once in a while got me a little break from that before Node. Now I’ve only got the build system and docker as relief valves and it’s not enough long term.

alfonsodev• 7 years ago

Allow me the exaggeration but I think that if everybody would be full stack, frameworks would be much simpler, there is a lot of gratuite complexity that grows because people have the time to dedicated just to one side.

hinkley3• 7 years ago

I stumbled into the realization that teams should be full stack instead of horizontally sliced. Once I figured out how to map out data dependencies end to end as part of our planning process we made huge gains in productivity and similar reductions in stress.

crawfordleeds2• 7 years ago

Agree with all your points, but in my experience, early-stage startups require full-stack competency due to rapidly changing priorities and a small team.

hinkley3• 7 years ago

Generally they don’t require the entire team to be full stack. But being able to flip priorities from 2:1 to 1:2 front end vs backend is often necessary to maintain velocity between milestones. Prettying up the interface is a lot of work. So is scaling up your backend for the new customers your facelift just got you.

In a small place having a third of your team being full stack takes a lot of stress off the planning people.

crawfordleeds2• 7 years ago

Agree 100% on that, I didn't mean to imply startups want a team full of generalists. But engineer #1 likely has to be full-stack. As you say, once you have 3+ engineers, a mix of full-stack and domain experts can ease planning challenges.

wolco• 7 years ago

We had this role back in 1997 We called those roles webmasters. It involved everything frontend / backend plus running a server on your bedroom floor that powered a company

I'm fine with all of those roles. I've been able to pick them up along the way and others (report writer use to be a separate role).

The one role I can't master is designer (not frontend developer). It isn't logical and it can't be learned through instructions alone. And the rules change.. what looks great today looked alien yesterday and boring tomorrow.

spraak• 7 years ago

Have you spent any time trying to learn design? I agree there is some part that is one's own artistic style, but much of design can be viewed and learned systematically - ratios, patterns, color theory, etc

nicoburns2• 7 years ago

Indeed, I'm not really a designer. But I spent about a year reading Smashing Magazine (https://www.smashingmagazine.com/) regularly a few years ago, and I have the basics down now.

Turns out it's a lot like good code: keep everything consistent (padding, colours, etc) and clear, and simple and it'll ussually look decent.

tzhenghao• 7 years ago

Full stack engineers wear multiple hats and they have a strong incentive for picking just the right (sufficient?) tools for the job. The upside for full stack engineers are that things aren't overengineered.

mamon• 7 years ago

I think from the client point of view the advantage of having "full-stack" developers is that it saves you some trouble of team management. With more specialized team you need some fronted developers, some backend developers and an architect to ensure that the pieces fit. And you have some inneficiencies, when front-end peoples are swamped with work, and backend guys are sitting idle, or vice versa. In a team composed solely of full-stack devs people are more interchangeable.

hartator2• 7 years ago

Try to make a company. You have to be full-full-fullstack.

astral303• 7 years ago

If you like to ship business value for your employers, you will want to be full full stack.

If you want to be partially responsible for your work and put up “not my job” boundaries, then sure, proudly hail the part stack flag.

If you’re an architect or a lead engineer and you are not coding in the front end (and I don’t mean designing its visuals), then you are dodging solving hard engineering problems (let others do the toil), and you are on your road to losing useful perspective.

taneq• 7 years ago

Ugh, so true. The hard part is building the non-tech part of the company so you can hopefully do some coding ever again.

hartator2• 7 years ago

Haha that rings so true.

LouisSayers• 7 years ago

Yup, I like to call it “true stack”. Sales marketing, design, development. Whatever needs to be done I’ll do it.

root_axis3• 7 years ago

As years go by the industry is going deeper and deeper down the rabbit hole of developer-focused engineering process and developers go on to combine more and more responsibilities beneath the surface of single cranium.

Why do you think developer salaries are so high? As the advancement and sophistication of open-source and SaaS offerings increasingly empowers individual developers to do more for businesses, so do developers leverage those capabilities to demand higher salaries and become more and more integral, as individuals, to the business process. The natural consequence of this is that companies have increased their expectations across the board because they ultimately get more value out of a highly paid full-stack than paying three moderately smaller salaries to a FEE, BEE and a manager/architect/SME to coordinate their efforts.

gentleterror• 7 years ago

But it does not work that well. Some individuals(not many) do apply to higher standard while the others just slack on the trend wave. And they can do more harm because their responsibility is almost everywhere.

20years• 7 years ago

The problem that I have seen is most companies don't want to pay a skilled full-stack developer what they are worth. They think $100k is the going rate and unfortunately a lot of junior developers are calling themselves full-stack and jumping at that salary. Then the lines get blurred and the true value of a full-stack developer gets diminished.

bradhe• 7 years ago

They think $100k is the going rate

Okay. So get a different job.

dgzl2• 7 years ago

I recently was looking for new work. When trying to apply to Developer opportunities, I realized that recruiters largely didn't know what they were talking about.

Many times I was told that my Computer Science degree, large school projects, personal projects such as random apps and maintaining an Arch Linux setup, awards such as winning 1st place in a Google Hackathon, several years of student work including iOS development work, and my 3 years industry experience as a Technical Lead somehow was less valuable than people graduating from coding bootcamps.

I was told by many people that I was not qualified for a Junior Developer position, but people coming out of these bootcamps were considered "Seniors". I was told by one recruiter that my "degree is almost useless".

root_axis3• 7 years ago

A senior full-stack developer has so many opportunities that they have the privilege of only considering positions with a compensation level acceptable to them.

exfaang• 7 years ago

I disagree with that assessment. Sophisticated open source, IaaS, and SaaS offerings greatly lower the barrier of entry in this industry and ought to have a negative effect on wages as dictated by supply and demand.

Your argument undermines itself by highlighting that a single open-source-equipped person can do the job of 3 grey beards of old. That automation of labor runs counter to rising wages.

As another data point, some of the highest paid engineers in the industry - those manning in the private battlements of the FAANG citadels - are specialist steeped in closed source arcana. I myself have been such an acolyte for many years.

My own take on the situation is that the distribution of skillets will further take on a bimodal distribution: the specialists and the generalists.

For now both the supply of sophisticated tools and capable practitioners has not kept pace with the demand from modernizing business. When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).

danmaz74• 7 years ago

Automation usually reduces the number of jobs, but increases the pay of those jobs which remain.

titanomachy• 7 years ago

You argue that powerful open-source tools should lower the barrier to entry. That's probably true. But I think there is also some differentiation that happens: the best developers are able to learn more tools and squeeze out more productivity. So a highly motivated and somewhat clever engineer can do a passable job of ops/db/backend/frontend/design on their own, which makes them quite valuable to businesses.

FAANGs are a bit of a different story, as you point out. But they also have a lot of infrastructure and culture in place that allows specialists to work efficiently.

root_axis3• 7 years ago

Sophisticated open source, IaaS, and SaaS offerings greatly lower the barrier of entry in this industry

I would question this assumption. In my view, the existence of these tools actually increases the barrier to entry because they represent additional skills that developers are expected to posses in order to be competitive in the job market. This is actually a common complaint among developers whenever a new technology gains viral popularity (e.g. AWS, react, k8s).

That automation of labor runs counter to rising wages

Well of course it does, except for the people who are paid very well to build the automated systems (i.e. programmers). Fortunately for programmers there still isn't enough supply to meet demand, so senior developers on the frontiers of popular technologies can command outsized salaries but still can't do enough work to eliminate the need for their less sophisticated colleagues (yet).

specialist steeped in closed source arcana

Sure, that doesn't really contradict what I'm saying, but I'd also note that whatever closed source project one might be working on is almost certainly benefiting from a gigantic open-source force multiplier in some form or another.

When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).

On this we agree. I tell developers all the time that they should enjoy it while it lasts because this definitely won't last forever. I'm pretty bearish on things like AI programmers, but I think open-source and commodity B2B software solutions are rapidly approaching the point where the costs associated with running an engineering department will appear much less imperative.

thatoneuser• 7 years ago

Then by your own logic developers salaries are low. If you're replacing three people and not being paid three salaries then the company has just found a way to squeeze more blood for less.

sjy• 7 years ago

That's competition. In a properly functioning market, in the long run, the company's reduced costs should be passed on to consumers and not captured by developers. (Unless we're talking about an exceptionally talented individual, rather than changes in the industry, leading to one person doing the job of three.)

dominotw• 7 years ago

Why do you think developer salaries are so high?

H1B visa limit?

johannes1234321• 7 years ago

Developer salaries are high across the globe (relative to local salaries)

rashthedude• 7 years ago

I do have to agree with this article insofar as to what companies are expecting from potential candidates way more than is feasible that's unless the BE and FE use the same language. But as a technical founder you just do not have a choice but to wear all hats.

cutler• 7 years ago

If you're a solo freelancer full-stack is exactly what you want to be. Being in charge of the whole development process is a big win. I'm not sure full-stack needs to include being an artistic graphic designer, though. Usually it's enough to be able to wield Photoshop well enough to produce business-grade (read boring) graphics. Farm it out to art school students if you need anything more exotic. They'll be glad of the extra income to supplement their grant.

thrower123• 7 years ago

I've worked with very few developers that I could even begin to call full-stack. They either segment themselves as front-end or back-end only, and can't cross the divide. I don't much like it, because that interface between the two is usually terrible as a result, with pieces that don't match, APIs that don't even work, and generally a huge amount of work to integrate by somebody that actually understands both pieces, that rivals rewriting it completely.

Owning an entire vertical slice is so much easier, and produces a better quality product.

fernandotakai2• 7 years ago

most fullstack developers i know have a strong expertise into something and ok knowledge (as in, they can write features, review PRs, fix bugs -- but they are not super experts) in the other areas. which makes sense, it's quite hard to be amazing at everything.

tetha• 7 years ago

I've been considering and pondering similar things for my own career. I think there are two things going on.

First off, there are assumptions that full stack developers are 100% amazing at all points in the stack. That's not the case. I consider myself more of an operator this day an age, but I still could take AWS or an empty linux box and build and deploy a java/go backend with a VueJS frontend for something. It won't be pretty, I can promise that. At the same time, that's why I have a great time with the other full stack developer who is much stronger on the frontend/backend side and kinda doesn't want to deal with the infrastructure and deployment.

And from that follows something that has taken a lot of stress from me. If the company is small, it's fine to have a full stack developer deliver something. There will be deficiencies in the stack somewhere, but who cares, there will be a minimally viable product.

Once the company scales however, people can start specializing into the areas they are good at. Why should I struggle too much with a JS frontend if I can make the entire application faster by thinking about the database? Why should the mentioned other dev struggle with one of the many ways to deploy the application if they could spend their time on features?

scarface743• 7 years ago

More and more agencies are looking for people who can do both frontend and backend, also participating in the business requirement development, writing unit and integration tests, being everywhere and doing everything

I like working with the users directly to make sure I’m writing what they need. If I don’t, I encounter too many instances of the “XY Problem”.

Who should be doing the integration and unit tests if not the developer? Why wouldn’t the developer be doing his own QA before he passes it off as “done”?

I work for mostly small companies so I can do the full stack - except for designing the interface. I can code the front end, backend in three or four modern languages well, know how to design and manage databases - RDMS (OLAP/OLTP) and I know my way around infrastructure at least with AWS. I can do passable Devops CI/CD pipelines. But, this is from a long career at working at mostly small companies.

ebiester5• 7 years ago

So, it seems like the pendulum is swinging back. I remember companies with more dedicated specialists, and it could be challenging to ship small features due to large coordination efforts.

Further, sometimes the work is unbalanced. In my current company, we recently had a backend-dominant release in a way that the frontend team didn't have as much work. That team rolled up its sleeves and dug in to solve problems, even if they weren't specialized in it. They weren't happy. It wasn't what gave them joy, but it was what was necessary for everyone to release what was needed. Now, we made sure that they had access to backend developers who could pair or guide work, and we knew the work would talk longer. (After all, these were developers who were stronger in the front end!) With our next release, we look to be more balanced, but we're looking at having developers with more backend competencies contribute to the frontend this release.

I think it's too much to ask for developers to be equally brilliant in multiple areas, but I don't think it's too much to ask that people have the willingness to develop minimal proficiencies in multiple layers and the willingness to contribute and learn.

mntmoss• 7 years ago

I think the broad historical sweep here is sort of along the lines of:

* From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era.

* Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers.

* Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications.

What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time.

But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries.

Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples.

And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.

ebiester5• 7 years ago

I think there's truth to that when looking at internal software, but external (B2C) software will continue to live in this division. (Think of hotels.com as an application, for example. There's no world where you can build a hypercard app that meets those needs.)

chx• 7 years ago

Further, sometimes the work is unbalanced

My team has just grown my two backend developers to three. We also have six frontenders. Yes, the work is unbalanced, hire for it.

ebiester5• 7 years ago

Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening?

I have a budget as a manager. I can’t always just hire more.

austincheney• 7 years ago

In the context of a large web application what many people describe as back end is hardly such. Typically that stuff is middleware. The actual back end would be things like payment processing, database access, internal services, and so forth. The code sitting on a service that issues server calls and into the business logic that builds anything client facing is middleware. I call that stuff middleware because at a large enough company they would not let anything on a webserver go remotely close to anything storing data for security reasons.

That being said fullstack doesn't actually mean the entire stack as the name would suggest. It really means the front-end plus the middleware, or both ends of HTTP. For developers experienced enough to write on both sides of HTTP it makes sense to tidy that up into a single position to lower labor costs.

jon-wood• 7 years ago

An early stage startup probably doesn’t have enough money to hire specialists, and doesn’t have the workflow down to make optimal use of them even they could afford someone in every position. At that scale you need one or two people who can do everything - probably they won’t do the best job of everything, but they’ll get your company off the ground.

Once a company starts scaling up they’ll find that they need someone with a deep knowledge of one particular specialism, such as mobile development, or backend, or maybe infrastructure. They’ll pick someone like that up who likely ends up taking ownership of it.

Over time they’ll end up with specialists for everything, but that comes with its own set of problems. At this point probably everyone can do a really good job in isolation, but there’s someone needed to coordinate the work to make sure people aren’t being blocked. That’s when the first dedicated project managers start arriving and getting the team moving in one direction. Probably at this point you’ll also start seeing product managers, because there’s no one around with a unified high level view of what customers need anymore - everyone else is down in the weeds.

At least in my experience scaling a technical team is at least, if not more, complex than scaling the actual product that team is working on. It shouldn’t be underestimated, and you should aim to have someone around who’s done it before and understands when it’s time to stop saying “we should just hire people who can do everything”.

marcus_holmes4• 7 years ago

Totally this. The difference is not "full-stack" vs "specialist" so much as "early/small company employee" and "corporate employee".

In small/early companies, there's just a few people. The same tasks need to be done (someone has to design the database, ensure the SSL certs work, and get that checkbox looking good in Firefox). But there's less people to do it.

"full-stack" in this sense means someone who is prepared to roll up their sleeves and solve whatever problem presents itself. It might not be the best solution, and a specialist can almost certainly do a better job, quicker. But it works for now, and moves the product on to the next step.

Corporate employees can be true specialists, because there's enough work and enough team to allow them to be. But this comes with an additional required skillset: corporate communication. To be an effective member of a large team requires a communication mindset that is completely different from the "roll up your sleeves and get it done" mindset of the small/early organisation.

I'm a small/early organisation guy - I can't stand corporate communication, and love rolling my sleeves up and getting it done, whatever "it" is. I know people who are totally the other way; they just want to focus on crafting amazing UI's, or designing perfect databases, and shudder with horror at having to deal with the "full stack" in all its nightmarish complexity. They're comfortable dealing with lots of meetings and reports in return for being allowed to do their one thing.

layoric• 7 years ago

I agree with the small vs large. Would be interested in at what head count you’ve seen this transition happen? Especially the need for project/product managers.

nicoburns2• 7 years ago

Fullstack is interesting because is seems to be almost unique to the software engineering field. Other fields mostly have more division of labour, you don’t expect the dentist to cure your heart and neurosurgeon to fix your hemorrhoids.

What about GPs?

Just like the medical field, software needs both specialists (to go really deep down the rabbit holes), and generalists (to tie everything together).

Personally I love being a generalist. Sounds like the OP just isn't in quite the role for them.

ellius2• 7 years ago

Architectural coherence is such an important part of software design. I agree with your point completely—you need specialists for deep, specific problems, but you also need people with a view of the entire system.

lioeters• 7 years ago

Great point, and I think it relates to the market need for a "full-stack developer", an all-around generalist who understands (more or less) the entire stack and areas of endeavor.

It also made me think how, typically, the problem with "design by committee" is that it's often a mere collection of specialists, without the necessary generalists (those with an understanding of architectural coherence, system-level thinking) with the power to tie it all together.

I think the reason why many great software projects are created by an individual or a small team, is that coherence and consistent vision across the system.

antoineMoPa• 7 years ago

If you are doing web dev, it is normal to require a wide set of skills (but not very deep). You are not a researcher or PHD student. Also, you are not working on a pacemaker or anything with life/death consequences, so cutting some corners like merging UI/UX/QA can only be profitable. Communication is faster within a single brain than within 'n' amount of people with slightly different jobs.

choeger2• 7 years ago

you don’t expect the dentist to cure your heart and neurosurgeon to fix your hemorrhoids.

That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery. If you think it is, you might lack some understanding of how things work.

Tbh., whenever someone hails the specialization and how their particular field is so special, I hear them saying "I really do not want to be bothered with all these nasty details". And that's fine. But it's not something to be proud of. Personally, I would love to have a better understanding of how user interfaces or database work internally. I think the understanding would only make me better.

marcus_holmes4• 7 years ago

That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery.

I'm not a neurosurgeon, or a dentist, but this doesn't strike me as true. Front-end dev uses totally different tools and languages, and a different set of design principles, than back-end dev. It didn't use to be this way, but it definitely is now. There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.

choeger2• 7 years ago

totally different tools and languages

do they, though? What's distinguishing JavaScript from, say, a poorly implemented lisp? What's the main difference between typescript and a poorly implemented ML? Syntax? Come on! There are maybe a handful of really different programming languages designs. And only three of them are really widespread.

There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.

If you are talking about Elm the language then it is very clearly influenced by Haskell. It is literally rooted in FRP. So to understand elm you need to know something about functional programming and type systems. Then you read the docs and you are in the game after a few days.

ThomW• 7 years ago

Front- and back-end are very different things. I’ve worked with some brilliant engineers who couldn’t make a serviceable UI to save their lives, never mind the intricacies of overall user experience.

I’ll balk at UI/UX people who can’t code, but I’ll stand by the value they can add to a project.

justaaron• 7 years ago

I have the (admittedly subjective) sensation that I read a similar blog article just about every week. As the author aknowledges the various opposing points, we could, perhaps, sensibly surmise that it's contextually dependent.

andrewingram• 7 years ago

I disagree with the argument that you can't have a high level of skill in multiple parts of the stack without sacrificing a personal life. But I do tend to believe you can't operate at that skill level for each discipline at the same time.

This is based on my own personal experience of course, but in any given job I tend to be full-stack, but with a bias towards a certain area of the stack. My contribution to the other areas of the stack is in more of an advisory/consultant role.

On the other hand, I know full-stack devs who are far better at context-switching than I am. Subjectively I don't think their output is at the same quality as mine, but there is definite value in what they're able to do.

bobjordan• 7 years ago

From my experience, as a backend engineer develops more frontend/javascript skills, the solutions tend to become more intertwined. We now have some parts of our app where you couldn’t change the tiniest detail in a view method, without thinking about how that’s going to break client side. I’m not sure that’s moving in the right direction.

anotherevan• 7 years ago

So is a full stack programmer someone who can write javascript for the server AND the browser?

je42• 7 years ago

you need a team for larger applications, however the members of the team should have overlapping skills. so you don't always need to do everything all the time. it is fine to be a specialist in some areas. actually, a team needs specialists, to solve difficult blocking problems.

However, when you got someone with excellent frontend skills, they still should know how the backend works since they interact with it. they should also be able to pick up changes there. since amount of work is not always balanced. further, doing work in a particular area outside of the main expertise raises the understanding of specifics there as well increses the overview of the complete system.

in the end, being full-stack dev is a strategy to prevent local optimization and comm-overhead and emphasize global optimization to develop a good application for the customer.

ryanthedev• 7 years ago

I totally understand where the author is coming from. Though a full stack dev like an ER doctor.

I don't want to be a full-fullstack developer

Related Stories