Comment by warent | Hacker News Reader

Comment by warent | Hacker News Reader

This article is conflating junior developers with full-stack engineering.

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.

Agreed. I would also add, I don't think frontend vs backend accurately describes how skillsets are clustered anymore -- especially with JavaScript's increasing ubiquity.

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.

I think the crossover between frontend and backend is less effective than you imagine. Generally a backend dev writes horrible frontend code and viceversa.

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.

In the React / Node world I haven't seen this to be true. I can imagine it being more so if the languages and tooling are different like in the case if someone was doing Java backend Angular frontend.

Same with Vue. I used to be more back-end, but frameworks like Vue and React make front-end feel more like traditional back-end, and are a joy to work with.

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.

> so sometimes it is needed to have 1 person do design and another person code it up.

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.

More than that, we can talk to designers, product people, leads, etc and have a better holistic view of the glue that holds everything together.

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.

very good mental model for developer activities ..

> 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

Completely agreed. I find it much easier to communicate with specialists like our DBA, or DevOps team, having at least some mid-level experience or knowledge in each different domain.

Exactly. At small companies you need developers with multiple skill sets so you can keep overhead low during your infancy and growth stages.

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.

One thing I find interesting is that people refuse to believe that something is possible when they themselves are terrible at it. I suppose this is the new "there's no 10x engineers"

> That's not what's expected of a full stack engineer.

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.

Tradeoffs matter a whole lot. I recently had to replace some beautiful SVGs by PNGs for various reasons centered around the business requirement that a page be below some size, and loads in less than some time.

A purist would cringe. I cringed a bit too. But the end result matters the most.

That’s interesting, I was under the impression that SVGs where smaller for logos and, well, vector graphics. Would you mind sharing what kind of graphics you were working with?

Graph, like a graphic calculator showing f(x).

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.

If you only display the images at a predefined size, a PNG (designed for that size) will be crisper than an SVG. Discovered this at a previous job where we were doing a rebrand, we were using SVGs for the logo and monograms on the website and the designers complained that they didn't look good. We compared them with equivalent PNGs and the quality was much better.

General guidance:

* 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

Or your SVGs were desined in Illustrator without actually modifying the code so that all of the coordinates in them would be integers.

Had this issue about 5 years ago. Good SVGs need to go through a manual code filtering step.

In this particular case, it wasn’t integer coordinates that were the issue, but the antialiasing quality, browsers (at the time, 3 years ago, might be better now) just couldn’t cut it. Say what you like about Adobe, but their algorithms are top-notch.

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.

Reply on news.ycombinator.com