Hacker News Reader

I doubt that they take different mindsets, many frontend engineers make extremely complex applications that need to maintain state and queue tasks.

That said when I say I'm full-stack I say there are parts of the stack I am more comfortable with than others.

I think I'm equally good at the frontend and middle layer, the data layer I am passable, the backend processes - meaning receiving data/pulling data from other sources for insertion in my data repositories, processing data, queuing data, optimizing processes for images, anonymizing data etc. I hack stuff together and it looks pretty ugly to me (unless processing XML where I am very good), but I can get it done. It's not a different mindset that makes me less competent in those areas, in my opinion, just inexperience.

on edit: and of course one will always be less than perfectly competent in every part of the stack, because the stacks cover a lot of ground. I think I'm pretty good at CSS, but really am weak in use of some parts, what I'm better at in CSS than most developers is understanding the cascade rules and when things will conflict.

I think I'm of a similar mindset. I started my career working on low-level things in C, and later moved towards being a sysadmin - largely as a result of working for a company who's sysadmin quit with zero notice.

These days I'm a devops-engineer, whatever that means, and I think my background of low-level understanding/coding has been very helpful.

Developers these days who can do amazing front-end things tend not to understand how computers work, how servers work, and how to debug problems under pressure. I'm sure they're entirely capable of doing the obvious/basic things, but their experience doesn't often qualify themselves to work from the bare metal upwards.

Right, similar experience here, and that's exactly what I mean. For example, I don't think a typical fullstack dev would know what it means to see a 'too many open files', how to debug, or how to fix. Hell, most don't understand the difference between a 'connection refused' and a 'unknown host.' In fairness, they don't have to. I started as a full Linux/C nerd who thought I'd conquer the world, and watched as tools like Docker attempt to make it irrelevant. I say attempt because I find it typically a huge waste of resources as an abstraction, but people love it, so I lost.

I don't feel defeated or obsolete, just the nature of an ever evolving curriculum I guess.

There are plenty of front end engineers that understand how computer works, how server works, and how to debug under pressure.

It's good enough to debug performance and compilation problems.

They exist, definitely.

But I think there are far more front-end developers who know (and are amazing at) CSS, Javascript, react, and all that stuff - and have no ability to diagnose, or resolve server-side problems (be they overheating CPUs, bad RAM, flaky DNS, or other problems).

I'm full stack. I see what you're saying and I think that in some (many?) cases your impression is correct.

In my last job, I entered as a frontend developer and moved into more backend work in addition to frontend work. There was strong engineering vigour, rigorous code reviews and careful coding standards to ensure consistency. I'd like to think I was competent across the field and at least equal to my peers but that's not for me to judge. My peers and those to whom I reported were very pleased. This suggests externally-verified competency.

I find it better to enter as either a frontend developer or backend developer and then demonstrate internally competency at both rather than trying to sell yourself as full stack from the outset.

It helps to have been developing web-related software for the past 25 years. Over time you learn new things because they fascinate and interest you.

Recognisable competency throughout the stack is achievable by anyone with enough curiosity to explore combined with enough experience to know how little you actually know.

I'm sort of from the middle but have recently been more frontend by dint of doing a lot of frontend. We are a design studio so getting design right is also pretty key. That said I built and maintain a large RoR ecom app with heavy customisation and a purpose built integration framework written in node.. and I enjoy it just as much, even if I might not be as expert tier as someone who does nothing else. All of one would be boring for me, do what makes you happy.

> I've never met a perfectly competent "full stack engineer". Most seem to learn just enough to hack both together.

I hear you that there are plenty of "full stack devs" whose competency is mostly in one area.

But (at risk of sounding cocky,) I would consider myself competent on both the front and back end. And I'd say I'm not alone.

"Absence of evidence isn't evidence of absence." You just haven't been around these people. Frankly, I think this is more a statement about the industry as a whole than "full stack". There are a lot of gainfully employed but mediocre developers.

I think having both skill sets affords me the perspective to see whenever e.g. the front end is doing things the back end should be doing.

Sometimes specializing in one area means "you have a hammer, so everything looks like a nail." I've seen _way_ overcomplicated front-ends that would be a much lower long-term maintenance burden if the developer wasn't looking through "everything should be solved with client side JavaScript" tinted glasses. ;-)

Sure, I believe you completely. People are perfectly capable of writing great code in both. I think when it gets to errata, domain knowledge, errors, etc is where it really starts to open up. I can hit some opaque error and a good frontend dev can tell me what it means, or that it only exists in X browser, etc.

Similarly, some know about every Linux error code, and how to tune systems around applications, which is a bit of a lost art.

So sure, fullstack exists in a way, but I still find it too broad a concept for any human to master on both ends.

So sure, fullstack exists in a way, but I still find it too broad a concept for any human to master on both ends.

Like almost anything, it's just a matter of time and experience. Plenty of people in the industry have been around since the Web was young, and have watched the technologies evolve over the years. We've built UIs rendering on the back end and we've built UIs rendering on the front end. We've built back ends that talk to databases and we've built front ends that talk to an API that looks like a lot like a thin wrapper around a database. So many of the skills and so much of the domain knowledge in web development is useful, or at least potentially useful, on both sides of the HTTP divide that it's hard to see the front and back end as significantly different from this perspective.

Once you've got your fundamentals sorted out, the important things don't change very fast in this business. Much of the "rapid development" is just hype and reinventing the wheel, and every time a new generation of young and enthusiastic developers thinks they've discovered a radical, game-changing idea, which in time they will discover the old fogeys had been using since the last millennium. Again like anything else, with enough experience you can easily see through most of that, but also learn to pay more attention to things that might actually matter. This is true in front-end development, back-end development, usability and accessibility issues, databases, visual design...

To put this in concrete terms, if we say (just to choose a number) that someone reasonably conscientious with 3-5 years of professional experience behind them could be proficient with the technical details of current front-end or back-end development, is it really so implausible that someone with 7 years of professional experience behind them could not have developed and maintained similar proficiency with both?

> To put this in concrete terms, if we say (just to choose a number) that someone reasonably conscientious with 3-5 years of professional experience behind them could be proficient with the technical details of current front-end or back-end development, is it really so implausible that someone with 7 years of professional experience behind them could not have developed and maintained similar proficiency with both?

Yes. The world doesn't stop spinning so you can learn both. In the time you're focused on one, the other changes. Computer science fundamentals are going to be consistent, but the problem domains of front-end vs. back-end are vast. You can have skills from either, but ultimately either one is complex and wide enough that an individual focused on just one won't master it but merely be more than competent.

Also, just keeping track of the tech either side is discarding is enough to fill one mind. Keeping a pulse on useful best practices from multiple domains while the world races forward is no small feat.

The world doesn't stop spinning so you can learn both.

That is true, but the world seems to spin a lot slower from the right perspective. Most of the "progress" in web development really isn't. Game-changers come along every now and then, but much more rarely than hype. Someone who is already proficient with both front-end and back-end work can easily keep on top of the developments that actually matter.

Also, just keeping track of the tech either side is discarding is enough to fill one mind. Keeping a pulse on useful best practices from multiple domains while the world races forward is no small feat.

Yes, professional development takes work, and keeping up with technology requires some of your time. But once again, the more you already know, the less any given development is likely to make a profound difference to you, and the more quickly you can scan what's happening and focus in on anything of real interest.

For example, on the front-end side, I probably find one or two articles or videos per month that offer some genuinely new insight or understanding. I might find one or even two front-end tools per year that are sufficiently interesting to be worth investigating in more detail and potentially adopting for future work. It's not that I don't read or watch more than that, but I filter ruthlessly and rarely waste time on anything that doesn't have either an immediate benefit or obvious potential. This also means I usually haven't wasted much time on tech that didn't stick around for long.

Statistically speaking, I'm probably a more experienced developer than most here, but I make no claim to being unique or superhuman. I imagine there are others reading this discussion whose experience is not so very far from mine.

Unrelated, but there are plenty of people having above average knowledge that's good for real world use. Say 80% (if you define mastery as above 95%)

Aside from being a software engineer. I also have various hobbies that I cultivate with above average level, graduated from 3 degrees in unrelated field, and know three languages.

And I know there are plenty of people who do more than me.

It isn't a stretch by any means. I believe plenty of people are very capable than what they think they can do. Human capabilities are more able than you think. Little by little knowledge compounds. i.e. if you can play guitar well most likely you can pickup bass quickly.

I think the attraction of "full-stack engineers" is exactly that they're a jack of all trades, mastery optional. They're incredibly useful for smaller companies that can't afford, or lack the workload, to separately hire serverside, front end, and devops engineers.

As you said, most full stack devs tend to have an area they're strongest in, and know enough to be able to hack things together for the rest. As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint.

I like to describe it as being analogous to an infantry squad, you have the machine-gunner, the grenadier, and the designated marksman, but everyone on the team is capable on some level of using a machine gun, a grenade launcher, or a sniper rifle.

The important part is to ensure that there are people with enough experience in each area to be able to provide technical leadership and mentoring. If you have a bunch of backend devs trying to hack away at JS and reviewing each others code, with no concept of best practice, you're going to get an amateur end result.

> As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint.

The challenge here is that, at least in the front-end (I'm a front-end engineer), it's not so much the case that there are certain problems that are hard and you need help with, but that there are things you should know you're doing wrong, or at least suboptimal.

For example, you can add a loading spinner, but you need to do some extra work to make sure people relying on screen readers, for example, know what is going on. After you've implemented a loading spinner, there is nothing that is really pointing out to you that you forgot that.

Though I guess the same holds true for the back-end: if I write a really inefficient database query, everything still appears to me as if it worked just fine. Only when it blows up later will it become clear that I lacked knowledge there - and let's hope that I did have enough knowledge to properly instrument the logs.

Of course, this isn't necessarily problematic. When you're a small team, getting something out the door that can load data even though the UX for some people sucks is better than not being able to do anything at all. But if you can afford specialists (at least in the sense that e.g. the front-end will typically only be touched by those who are strong on the front-end), you can get higher-quality products.

I don't call myself a "full stack" engineer. I call myself a software engineer (or software developer); this pretty much means: I am a problem solver. Do I have to design a relational data model? Sure, there I go. Do I have to keep the state of a client side app in sync with our server's database while client is offline? Ok, let's do it. Do I have to design an api that exposes resources to the public? I can do it.

If I don't know how to do something, I go and learn what's the best way to do it (by reading documentation, books, or just be asking more experienced devs). That's all.

If a company I want to work for is looking for "JavaScript" devs only (or "Python" devs only), that's a red flag... But if I really want to work for them, I would just apply because if you are a decent software engineer/developer then it does not matter if the job involves JS or Python or PHP. You can learn without too much trouble.

Most importantly, I think I know how to build things so that I can fix whatever I do wrong later, without having to tear the whole thing down.

I share this mindset, but I don't love pigeonholing myself to software. If the problem is better solved with a mechanical machine, I'll build that instead. If the problem is best solved by baking bread, I'll do that. Software has its place, but is not the best solution to all problems.

I don't think it's a skills thing, it's a time thing.

Personally, I work as the architect/leadership level, but I'm still pretty handy at DevOps, SRE, RE, Back end, and have even delivered a few front-end projects in my time (mid 30s).

I'm not claiming to be the best, but I'm good enough that I mentor engineers that are senior and costing >$250,000, and I did not gain these skills simply from being a generalist.

What I simply cannot do is keep up with 10s of engineers changing a code base when I spend a lot of the day in meetings. My choice is to be the bottleneck the project and cause discontent, or let the team roll with it and pick up the pieces that fall through the cracks.

Does this means that I could never again be an IC which specialises in any part at a reasonable enough level? I doubt it. But pragmatically, there are few people who see the bigger picture who have enough technical chops to get disparate specialists working together, so rather than be the 10x engineer, I try to focus on amplification and making my team a 10x team.

That propped up 10x engineer always working overtime, is really a 10x*0.3 bus-factor engineer. Team members can each be 3x engineer with significantly improved bus factor (though not without investment and some coordination).

The funny thing is that 10x engineer drains mindshare from the teams, rest of the org, and will lack diversification, like architecture, testing and Ops.

Over the years I worked on native desktop apps, mobile apps, a Scala backend.

Now I work on a complex React app in TypeScript with a GraphQL backend in TypeScript. I can build a feature end-to-end. From domain modeling to an API to UI with animations. Optimising SQL queries.

There are people like this. Software engineers who have experience across the stack.

I don't do devops but I've met someone who can do full stack app development and devops pretty well too.

> That out of the way, I've never met a perfectly competent "full stack engineer.". Most seem to learn just enough to hack both together.

It's mostly due to the sheer amount of things you have to keep in mind at any given time. Not the core things like algorithms and such, but (Javascript + Typescript + React + Redux + GraphQL + Apollo + .... ) + (Java + Spring Boot + MySQL + BigQuery + PubSub + Datastore + ...). All the different libs, and the ways to communicate, and idiosyncrasies specific to different languages and different libs.

There's never time to get good at something, as you're pulled apart :)

What is the issue of figuring just enough NodeJS as long as they can solve the problem at hand ?

At the end of the day what we do is to solve problem.

Even if you specialized in let say just front end, that itself can be broad enough to master.

There are plenty of very competent fullstack engineers, one man army people around the world.

I think you just haven't seen them yet.

Is it not possible to be highly competent at playing the piano and also at carving wooden sculptures? Or not possible to be a master of C++ _and_ CSS? That just doesn't make any sense.

Perhaps your views are more a reflection on people getting pigeonholed at large companies, or otherwise choosing to specialise? Or something like that?

I personally think it's hard to be a _really_ good frontend dev without a chunk of more general development experience. What wider experience will you draw from to solve hard frontend problems otherwise? If your Angular/React app isn't performant enough because of the computations it needs to do or allocations it needs to make, how big is your mental toolbox to fix that if you haven't done more general backend dev work? It's all just software, ultimately.