Is front-end development having an identity crisis?
dev.to
dev.to
I have a similar task description and my title is "full-stack web developer".
I simply call myself "web developer" as I consider that being able to deliver a website from A to Z is a requirement of my job. From design to back-end to hosting to SEO.
It also allowed me to develop a really strong pragmatism. With so much to learn you have to be really lean and effective with your learning and cut requirements where they don't make sense.
But now that I’m trying to fill out the gaps on both ends - back end with a deep knowledge of AWS, Linux, Docker, devops, Node. and the front end along with some more project management experience, I’m trying to qualify for overpriced “implementation consultant” roles - since those are the only roles that pay significantly more than I’m making now in my market without going into management.
But the fear is that while having the broad expertise will qualify me for high paying jobs, there are relatively few of them out there. I have to have a deep understanding of at least part of the stack to get a job or contract gig quickly.
"while it's great to be able to do lots of things and own the whole product, it is detrimental to your knowledge and your CV."
i.e. learning larger set of skills is bad for job prospects
"my skillset is so specialised that it is hard to get a job."
i.e. focusing on a smaller set of skills is bad for job prospects
If your experience is in "I do a lot of everything, really well at much of it". Then you have lots of valuable knowledge and skills, but those skills look terrible on a CV.
In practice, you could be 80% of an entire standalone product or service, you would make most companies a good chunk of money. But on your CV, you look like a part-time Junior Dev and part-time Junior Designer and part-time Junior Manager, etc. That's not a fair reading at all, but that's what ~90% of companies will assume.
---
We don't really have a word for people who can be responsible for and execute well on a most/all of a product or service. (I wish we did, because that's my history to-date, and my CV could really use a word for it).
So, when a person like this tries to apply for a job, they often have a far rougher time than you'd expect. These folks have to essentially eject a different 60% of their value for every job they apply to, which hurts them significantly in hiring/recruiting despite being an advantage when doing actual work.
As far as I can tell, the only real end-goal for people like this, is to work at a small boutique consulting firm, or open their own product houses / development studios / consulting firms. Because the majority of companies simply don't value this approach.
I'd rather be building things but the truth is I primarily manage. I've had my fair shares of poor hires. One was overly obsessed with tooling and couldn't deliver in a timely manner. Another I was too naiive and circumvented upwork to appease him.
It sucks when you have to figure everything out yourself. I am constantly analyzing how little work I need to do to make things run smoothly. Because there are so many battles you can fight, and so many actions you can do it one day. Delegating development tasks just makes more sense in the long run.
As a result, my CV is not really appealing to most companies. What I do instead is spend my freetime developing a personal project I have. And do technical talks / live development at my local meetups.
Sure, the tools mentioned were more difficult to deploy to users, but we jacked up programming costs to gain deployability. We need better standards: HTML/JS/CSS/DOM is okay for some things, but one-size-fits-all has dragged down a lot of specialities, including in-house CRUD. Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's.
I had hoped "The Web" would mature and solve the bottlenecks, but it didn't. Are we really stuck with 5x the programming resources? Accountants, wake up and bop IT on the head.
The thing is, the tools I mentioned didn't need frameworks; they were frameworks. This reduced the urge and ability for "local creativity" to run amok with fads and experiments. Fear of keeping-up-with-the-IT-Jones often creates chaos in my observation. Devs have to stick the latest and greatest into the stack to placate the fear of being obsoleted.
Exactly!
Without an engineer (or a team) to manage this then some serious problems can arise, including loss of productivity. If there _is_ someone managing this then productivity gains can be enormous.
If something is truly better, then it should be easy to articulate why in a concrete manner, such as exploring total lines of code that need to be changed per a change request scenario that's realistic for your particular org (and not a cheesy textbook example).
It's also good to see it actually working in similar organizations. Often people copy from dissimilar organizations and make a mess. Microservices are like this. They don't fit many shops or orgs; but because Netflix finds them useful, everybody has to copy.
Often "new things" are passing fads. It's good to vet things for actual productivity improvement instead of just using buzzwords such as "separation of concerns". Otherwise, the org will have separation-of-wallet.
Layers of crap in "Enterprise" .net and java projects. If you actually have lots of complexity in the app, with lots of test coverage, or multiple target libraries, sure... but most don't have that.
Aside from that, it really is resistance to change.
Well, to be fair, they get enhanced by developers... but the basic CRUD isn't an issue. Tying it to business workflows is. But the point is that LOB apps are not custom development anymore, and have not been for a long time.
I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc. The web is very simple but extremely flexible and you can get as much or as little out of it as you like. If it takes 5x as long it means the technical management is inept. I also have personal experience with some huge internal VB and Delphi projects during the 90s that were utter nightmares, and I know anyone else working in that era can attest to similar experiences.
> JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison.
This is just false. Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases. The DLL-Hell comparison is ridiculous, there is simply nothing even remotely comparable to that on the web today.
> Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's.
This is an arbitrary distinction and not a technical one. The solution is to understand which problems need solving and then to select the appropriate tool (that you understand how to use) for the job.
Well, I have!
We actually did the test, with Anvil (https://anvil.works), which is explicitly a VB/Delphi-like platform for the web.
We took a straightforward CRUD-y consulting project as a spec, and built it with traditional tools and with Anvil. We did our best to keep it fair: We raced an expert against an expert, and we kept the web tech simple: simple templating, minimal JS, etc. And it was still about 7 times faster with the Delphi-like tool.
(It was actually 10x faster if you just count dev time, but we counted overhead meetings too - again, in an effort to be fair. It was still "one week" vs "one afternoon".)
[1] As suggested earlier, if the MVC stack is well-managed this may not be the case, but the average company has average management, by definition.
For one the standards have many fuzzy areas in them and/or vendor-specific enhancements. JS widgets may purposely or accidentally rely on such grey areas. Second, being standards-compliant doesn't mean it doesn't have bugs.
As a thought experiment, if there were a decent standard multi-select-list widget (that doesn't require the Control key) in HTML or an equivalent, then it would likely be more stable than having to choose from 20 or so custom JS ones found on the web. This is because there would be roughly 20x more testing done on it because 20x more would be using it because we wouldn't need custom ones (or need them much less often).
> if there were a decent standard multi-select-list widget
I don't get the argument. You're right that there's no multi-select-list standard. What is the problem if there are 20x custom ones? Just use the one that meets all your needs. Who cares if there are 20 or 200?
Why "doesn't require the Control key"? AFAIK,
<select multiple></select>
Again, the standard, very simple control in html works analogously to the standard Delphi or corresponding control. The non-standard checkbox + multi-select widget you envision would be, IMHO, simpler to implement in js+html than in Delphi--but would be a custom widget in any implementation, as it's not a standard UI control.
To paraphrase:
The thing is, web technologies don't need frameworks; it is a framework.
Use standard widgets and controls, style and enhance them if needed, stay away from kludgy plugins, and you'll be fine. Input validation, standard keyboard, mouse, touch navigation, etc built in, for free.
As to multi-select and the like... this is why groups of developers are now leaning towards tooling around React, Angular, Vue and others. If you want something not in the box, you either make it, or pay for a custom control... of find an open-source one.
Developing web apps isn't so significantly different from desktop apps from a UI perspective, it's just you get a lot more in the box. (like layouts that grow/shrink to fit with nearly 0 cost).
I'm not an Oracle Forms dev myself; I just observed productivity. Oracle should have left the "gui browser" (client engine) as a dedicated product (compiled EXE) instead of convert it into Java, because Java had too many security bugs because it tried to be too much. The concept of Java Applets failed, not Oracle Forms itself.
It was a little painful but far from the end of the world. Classic VB, Delphi, Access, and Flex/Flash have all been good at delivering CRUD apps, if you exclude the security concerns in talking to the backend, and storing application configurations, dealing with updates etc.
In the end, I don't feel it's any better overall either way. The difference is it's far easier to automate one server (or two) in a business environment than dozens or hundreds of systems.
It isn't true to say there's no such thing as a regression bug with browser releases.
Example: With the release of iOS 7, for a webapp I was working on (big, household name client) we had a damn mysterious bug pop up in Mobile Safari regarding a specific event handler simply not firing on an app I was working on. After about 2 weeks, I figured out it was a newly introduced browser bug. It took another 2 weeks for the rest of the team that didn't believe me (fair enough, I probably make mistakes more often than browser teams do) to come to the same conclusion. We kludged our way around it. The bug went away an update or two later, but not w/o burning more than a solid man-month on it.
That and some of my experience with Android layout bugs (as far as I could tell, there was no such thing as reproducability on that front circa 2013/2014, and nobody really cared) started the realization that, sure, we'd sortof gotten mostly past the era of IE standards lag and into a place where there'd been stable capable cross browser web standards for years... but that wasn't going to keep regressions from happening, and it was obvious that when it came to mobile, vendors were more than happy to push their own not-identically-behaving solutions to problems for things as simple as a scrolling container.
And that's before we get into framework issues and dependency scenarios.
I also find the web remarkably powerful and flexible as well, and calls for some other platform with platonic superiority seem odd to me... but I can see why people get frustrated. Myself, I've been moving towards backend development again (where I started), dipping my toe in occasionally to see if any of the hyped new solutions are more than rearranging the deck chairs.
I declared myself out a while ago. It took some digging in of the heels and a bit of a short term career hit, but I no longer do much web development. I do data work, I guess they call it "data engineering" now, lots of pipeline stuff. My background was in math and operations research, and I do calculation as well as data pipelines, so it works out nicely. I really had to start refusing to do javascript, though.
I'd still do full stack (which means I handle simple frontend stuff but pass it onto someone more talented if it needs to be more elaborate) if we used Rails or something like it. That, I don't mind, and if I had to do it all myself due to it being a personal project, I'd happily keep things relatively simple in rails. If I needed something more specialized for data analysis, I'd probably write it as a service in python.
Til then, I love that ostensibly Polish expression "Not my circus, not my monkey". Front end developers are going through framework churn unseen since the MVC days of 2005. You do what you do, folks, have at it, knock yourselves out.
One thing, though - no, I'm not going to start writing data analysis code in Javascript so we can keep things consistent with the front end.
The second is a much more development focused developer role, someone who can take the work done by the first variety of frontend person and then break it down into components and integrate that with a backend API in complex ways.
The two are very different roles which can rarely be fulfilled by a single person. I think we should stop trying to bundle them into the same thing.
Think for example of developing a static website. I wouldn't ask a developer to do that, I would ask a web designer, which I expect to be versed both in "design for the web" (as opposed to, e.g., "design for print") and being able to translate it to the chosen medium (that is, HTML and CSS).
Anything more (business logic etc) are the domain of a developer. So as soon as the site is not static anymore and becomes an actual web application, that's where designers are out of their area of expertise and developers kick in.
This is how we are organized where I work, at least.
One of the hats I wear is what I'd call a "frontend app developer," corresponding to the second role mentioned by OP. I work with vue/webpack/etc. I have a passable knowledge of HTML/CSS. Give me a CSS framework and I can give you a LOB crud app with minimal fuss.
Occasionally I've had to work on visually cutting-edge projects. In those cases, I've found that having a traditional frontend dev (OP's first role) and a designer on the team to be indispensable. The frontend dev specializes in thinking/coding visually with the toolset specifically provided by the web. Sophisticated layouts need careful consideration, balancing new specs (grid, flexbox), performance, maintainability, backwards compatibility, and responsiveness. Dynamic/interactive graphics and animation present a large number of approaches and frameworks all with their own tradeoffs. Then there's font rendering/scaling, optimization for print, email, and the list goes on.
I guess what I'm getting at is that the strictly visual part of frontend development is huge. Easily big enough to justify its own specialty. And for me, keeping up with the frontend app-development landscape, in addition to backend/distributed-systems, that all just doesn't leave enough bandwidth for me to become amazing with the visual side of frontend dev.
And the idea that a designer could do this is, to me, really improbable. Most designers I work with spend their lives in Photoshop/Sketch. Some know the basics of HTML/CSS - the box model, selectors, margins and padding and box-shadows and font-sizes, maybe some basic layout. I haven't met a single one that knows what a polyfill is, or could come close to dealing with flexbox/grid layout, or scss, or webpack, or git, nor could they set up a good workflow that rebuilds and live-reloads 4 different views every time you hit save.
The frontend is now an app distribution/fat-client system. And it's huge and requires more and more specialties, there's just no getting around that.
Places I've worked have been relatively small though (30-150 employees including non-technical staff), and I can totally see that in larger organisations there would be roles which specialised in only one of these areas.
I also think that while in some cases the projects requiring these skillsets are distinct from each other, there are plenty of projects that require both. Consider Google Photo's infinite scroll feature for example.
A designer does not need to know how to code, but to think in terms of elements and components.
Otoh. a developer does not need to know how to design, but basic typography and whitespace should be taught on the job. We are design implementors.
I agree that they are separate roles though.
Thing is I've never met anyone who enjoys the so-called "designer" role. Translating a mockup means dealing with CSS which is a pain in the ass, there's no creativity, and it's not intellectually stimulating work. Add to that the fact that the "designer" role is often treated as low status/prestige and it's difficult to get people to do it.
It seems like the kind of role that companies should just outsource.
Writing good, maintainable HTML and CSS is fundamentally an engineering role -- how to deal with z-index, how to structure into components to avoid abuse of !important, the performance implications of animating transform() vs other properties, how to factor into variables for colors and distances, how to avoid spaghetti classes because CSS is fundamentally global.
In my experience, good designers and good engineers generally come from quite different mindsets, and I would never expect a designer to write well-engineered and maintainable HTML/CSS, the same way I would never expect an engineer to be versed in the intricacies of the rhythms of typography, color theory, or the emotional associations of positive and negative space.
We asked the designer to do the HTML/CSS/JS for his web designs. Brochure website turn around times decreased but the code is far more difficult to maintain. In some cases, I've had to reimplement a component just to adjust sizes.
There's a lot more technical thought than meets the eye behind well structured static frontend code. It's a skill in its own right and programmers tend to produce better work than designers when judged solely on technical aspects. Alas, a designer always has the edge when it comes to visual quality and that's arguably what sells the work.
(One of my friends that meets this description is looking for a new remote Ember gig. If one of you out there at a cool company looking for a new dev+designer send me an email and I'll intro you.)
As a front end developer this is a bit insulting. This idea that JavaScript developers are somehow "lesser" is tired and totally overlooks the complexity and challenge of modern web development.
The problem is that as a web developer you really need to know how to do all of these tasks. I'm required to make mock ups, write business logic and all of the CSS design.
Wait, where did I say that? Wouldn't you say "develops logic" is develompent work, even on the front-end? I was contrasting it with "click button, accordion collapses".
You leave a comment saying what a variable does?
Also, does a Css/html dev have less prestige than a front end logic dev?
I'm admittedly an outsider, engineer by degree, but casual programmer of 10 years. I can do html/css for fun, logic takes music and caffeine.
I wouldn't expect the developer to be able to come up with a good web design with the right choice of colors, spacing, etc. but I would expect that given a design he can both turn into HTML and CSS and split it into components.
That is how we organized in several teams I've worked, and there was never any issue.
I have seen however developers who do frontend work who know hardly any CSS and are even proud of it, and that is just not productive.
I used to work in an architecture team and sometimes I would get support requests from development teams because someone couldn't move a button 30px to the right, literally.
I think if someone is a frontend developer, they should be able to write their own HTML and CSS, besides knowing Javascript and a framework like React, Angular or Vue.
Because well-engineered HTML and CSS that works across all major browsers and can handle everything from tiny phones to high res desktop sizes and meets accessibility requirements is a very difficult skill to acquire. In addition, that skill has very little to do with the skills required in more traditional programming languages, even JavaScript.
It's perfectly possible to have someone fulfill both roles (I do, but I'm the senior-most FE person at my company.) It just takes a long time to master both sides of that equation.
Everyone should be able to do basic HTML & CSS, but deep expertise as I described above requires either a specialist or someone with a lot of experience.
I don't know if this is universally true. While there may be some cases where splitting up the the visual elements from the API calls is necessary for a company/team, I don't think it's common. The problem with that division is that while it may make the scope of development smaller for each developer, it makes the process of implementing features harder. Unless you work on some monolith service that handles hundreds of UI changes and has an (overly) complicated backend API, or you are super short on devs, I'm not sure it makes sense to dedicate one person fully the role of 'html/css/js dev' and 'front end api dev'.
CSS/HTML/JS animations/interactions are pretty trivial to implement. The bulk of being a 'front end developer' is getting the visual components to talk to the backend-api.
Furthermore, I think the more we (as a community) define this developer roles into sub-roles, we ourselves a disservice. It makes the recruiting landscape more hellish (no 'front-end api developer' title on your resume? Guess you won't get past the robots even with 10 years fullstack experience).
Well... I don't want to force someone to do that, but I'd really really really prefer if design people actually did code sometimes, so they understood the reality of what they're 'designing' from an implementation standpoint.
It may take you 6-8 hours to mockup something that is ... logically impossible, which someone 'signs off' on, then 40 hours for someone else to try to cobble together - pushing back is 'combative' and 'negative', etc.
You know how designers don't like people who ask for stuff that "pops" and then want more "pop"? Designers 'designing' stuff that creates practical impossibilities or gaps in state, etc. - programming folks hate that just as much as you hate 'make it pop' requests.
Hey - cool - you "designed" a form with 3 elements! The actual implementation options are 17 for that area. What should happen with 0 selected? Do we want notifications or help text?
Nice - that design looks really slick with 3 checkboxes in a pulldown, but you've sort of just invented a widget that doesn't really exist, will create accessibility nightmares, and you didn't show how this should behave on mobile/tablets.
The number of design people I've met who can actually reconcile clean design with real implementation, usability and accessibility issues addressed is very small.
I doubt the real answer is for the designer to code (though it's nice when you get to work with someone like that), but you sure have to ask a lot of questions, and you never manage to check everything up front. Especially anything that doesn't immediately open a new web page, at every step there are just so many input possibilities: the user clicks this button or that, clicks elsewhere, types a bit here then a bit there, presses Enter, presses Tab, presses Escape, has a screenreader, is on a phone, is on an iPad, gets an error, gets 1000 results, changes the dropdown that enabled this other control. . . . I guess you do the best you can imagining flows up front, but plan on having some iteration as you discover gaps in the design.
I'm not saying they have to code 100% of everything, but I'm really fed up with having to deal with that sort of "well gosh that's not our issue!" hands off sort of 'design' folks.
Internal design teams that work in the same building as the implementors/devs... maybe a different experience. I'm sometimes brought in and given "mockups" from an external team, done in whatever tool of the day they use, that have little bearing on real world web implementation.
it's apparently beneath some of these folks to learn css/html and use ... you know... a web browser to mock up a web site. i don't care how much 'freedom' some tool gives you, you're just punting the hard implementation to someone else.
Came off a project recently like this - the original team had done 'weeks' of 'design' and 'planning' with an external design firm. "but plan on having some iteration as you discover gaps in the design" sounds nice, but in their mind, they'd already "thought a lot about it" 8 weeks earlier, so any implementation issues I found were somehow... my fault? my problem? "these guys are a really strong design firm..." who don't seem to have ever actually implemented anything they design, from what I could tell.
From the other side of the aisle, this isn't what happened.
I want to preface this by saying that in general I like designers, but there are things about your good friends that you find annoying and tease them about. So now for some teasing.
What happened was that a bunch of up-in-the-clouds designers kept denigrating (directly or by omission) developers in front of their bosses and we got tired of it. The response to "why can't you guys figure this out? It's really simple" was "Well if you're so smart why don't you implement it?"
Constructively, that translates to engineering the situation so the designers felt our pain. But on a particularly bad day the sentiment tended to be more like "choke on it."
I'm not complaining, just pointing that scope of frontend is still relatively small as compared to other roles.
I guess if 2 full stack engineers provide equal work as 1 front-end and 1 back-end engineer, there are no reasons for full stack engineers to be paid more
My point is that people should be less entitled in terms of what's expected from them.
However,. I think that two good full stack developers should be able to outperform a frontend/backend pair because they reduce the need for communication. Many problems take as long to describe as to implement, so you'll iterate a lot faster with two full stack developers focused on one feature each than a frontend/backend pair sharing two features.
The only time having two specialists is important is if you have plenty of talent and projects are well separated. That's rarely the case, so a full stack developer should be significantly more valuable.
A pure SQL specialist of similar talent as you probably knows tons of stuff you don't. Man, I would love to have one at my side all day.
I would expect an SQL specialist to know more about SQL than a backend engineer. But that's a different scope all together.
Isn't that basically "backend" with lots of experience around automation tools?
I have only worked at startups, so I guess I wear all hats. Here's what I understand:
- frontend - presentation bits, can further separate into developer and designer for UX and logic respectively - backend - APIs, database interaction, concurrency, etc - full stack - backend and frontend - dba - tuning databases - server admin - tuning OS - devops - automation, with a splash of backend and server admin
Does that sound about right? If so, full stack and devops overlap quite a bit, and must full stack should be able to handle devops tasks, so wouldn't "full stack" be sufficient to fill your ranks?
It costs more because someone with both skill-sets will demand a higher salary than someone with only one of the skill-sets.
Well that's the difference between a frontend developer and a designer... I don't think fronted dev has changed that much. frameworks have, but the core of the role is the same: understanding/organize ui states, understanding threading models, events, interact with backend apis, know some design, etc.
Why should someone be able to become an expert in HTML but not, say, SQL? Only because one of these runs on a client and the other typically runs on a server?
Software development should be about creating something useful. Usually, neither back-end nor front-end code is useful on its own.
By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it.
Front-end is commonly used to mean writing code that runs on a client browser or native environment, like iOS.
Back-end means writing code that runs on a server.
Sometimes they're intermingled code bases. At my companies, they aren't.
Browsers are sufficiently complex targets that it's reasonable to specialize.
In a typical web stack the front end is the UI and the back end is the database. You notice that precludes about 80% of the people writing code on modern web apps (such as Java people) who are somewhere in the middle. Its not backend just because Apache (or Tomcat) is somewhere in there.
Front-end devs might be working on server-side code that's generating their HTML/CSS/JS, but that doesn't require them to deal with the business logic between the database and front-end.
Frontend does not mean visual, not at all.
See: https://www.quora.com/What-are-front-end-and-back-end-compil...
In this case it's pretty clear we're talking about front-end as in "web front-end". The front-end/back-end distinction of a compiler is in another field entirely and means something completely different in the topic at hand.
While a compiler has a front- and back end, I doubt there are many ads for compiler frontend developers or compiler backend developers.
While you're right that there are other kinds of front ends, that's a different context than this entire discussion has been confined to.
If you want to be extremely literal, you can always find a way to disagree with people, but is that disagreement actually contributing meaningful information to the discussion?
It's not the case that an X developer has to know Y.
It's the case that an X developer that doesn't know Y will lose in a competition against one that does.
Hiring, job advertisements, recruiters etc are and always have been nonsense, we know that. It's certainly the case that developers all over the place are being misallocated. But that's not unique to whatever we're calling "front-end" today. It's probably not even unique to software development.
I disagree. These are somewhat loose business standards that people have a general idea what they mean. The confusion mostly comes with the middle tier ( aka the interface between front-end and back-end ).
> By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it.
No. The front-end and back-end usually denote responsibility and security. Sure you can know HTML and SQL as a front-end developer but generally, the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc.
For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats.
Front-end usually deals with getting data from the back-end and showing it to the client. Back-end deals with clustering, replication, network availability, disaster recovery, etc ( i.e. making the data available 24/7 ) or whatever the SLA dictates.
The difference between front-end and back-end isn't HTML or SQL or even where the code runs. It's about responsibility and security.
The problem with these standards is that they aren't conducive to creating value. They mostly help with pigeonholing developers into neat categories so they can be treated as fungible resources.
> the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc.
The main idea of the DevOps movement was to break down these walls in order to establish a culture of shared responsibility. What's the point in that if we even have walls within the Dev part of that equation? People thinking "I've done my part. Not my problem anymore." once they've thrown their stuff over the wall can be hugely detrimental to an organization.
> For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats.
You don't have to be an expert at everything. Asking and relying on the expertise of others is perfectly fine. A developer in my opinion should however be able to take responsibility for creating an increment of business value without having to resort to managers or similar interfaces for coordinating the efforts required to do so.
Dividing developers into "front-end" and "back-end" lends itself to silo creation and the notion that someone higher up in the hierarchy is responsible for the business value your code contributes to.
The more things you become expert at, the less deep your expertise can be. Some people may have the talent to become extremely deep at html, css, javascript, react, sql, and whatever back end language and frameworks, all at the same time. Many won't.
80% often is more than enough. The remaining 20% can be researched or compensated for by an IDE if need be.
There's no need for example to know the complete JavaScript API by heart. That's what documentation and autocompletion are for. You just need to know where to look and have an understanding of how things work on a conceptual level.
Beyond that, it's similar for the very back. When to lean towards a given database type or environment is helpful. It depends a lot on your needs and other specifics to a situation.
I would say that a lot of higher level concepts and specific language syntax can help. I reach for map/reduce/forEach daily, as well as a ton of other things. Just knowing what's in the box can help a lot in a language... a given framework, meh, know enough to get things done and refactor/read a lot.
From the start of college to about 4 years into my first developer job, I spent most of my free time building my experience. I'd experiment with new languages, build projects using different tech, etc, all to deepen my experience across the board.
To summarize that with "talent" cheapens the work that has gone in to it, and I think most people who are in the same position would feel the same way.
It's mostly about time invested, though aptitude certainly helps. Talent is learned and trained, not innate.
It's sad people get impressed when you can just program and handle servers at the same time.
Personally, I work on business applications exclusively. Creating value in that realm nowadays usually involves a web front-end and a back-end. The front-end in these cases often is required to run on mobile devices, too, which however is perfectly achievable by using web-based techniques.
Occasionally, there's the need for having a dedicated mobile app. In those cases, I make use of web-based frameworks such as Ionic. Not only do those provide the additional benefit of staying platform-independent but they also abstract over the specifics of mobile platforms.
This might not be the perfect approach in each and every case but for business applications it's often more than good enough and the little additional value created by maintaining a dedicated Android or iOS codebase doesn't warrant the additional effort required to do so.
If you want someone to write an etl script from SAP to salesforce you could probably trip over one in the street. But if you want someone to define a well thought out data model in 3rd normal form with versioned entities, property based testing coverage and full CICD pipeline you will have to search hard.
This system seems to work out pretty well on most projects. There is a significant body if knowledge required to get the styling and markup in an application built properly, with a high degree of cross-browser compatibility, and in a reasonable amount of time.
When I think of a front-end dev I tend to lean towards this definition. Which leaves me at somewhat of a loss to describe my role as a "back-end" developer, as I spend a generous portion of my time coding with Angular.
Designers don't need to know HTML/CSS when frontends can just build it up from images.
It's a weird place to draw a line that designers need to pass the result as HTML/CSS instead of just the image file.
If you are struggling to find work, then expanding your skill set is the answer, not restricting the meaning of a specific title down to your comfort zone.
Not having to think in a different language helps a lot too.
Whit that role gone most web designers now find they are more needed as traditional app developers creating crud interfaces to data backend which requires less design and more business logic.
And, conversely, HTML, CSS & basic interactive Javascript (or at least the UX/artistic aspects thereof) can be hard to get a handle on if your background is functional programming, high-order functions and hoisting.
But for external use (such as in a pay comparison or job posting) they are pretty meaningless. Just recruit a software developer and specify what skills the job requires.
Html/css to me is a design activity and probably better described as "web designers" or "interaction designers" and not developers at all (even if some JS is sprinkled on top to make the html come alive).
This idea doesn't necessarily hold up when you get into very deep topics like data science, db admin, cloud administration, server admin, etc. But it absolutely holds up for product development, and nearly all frontend, backend, and "modern devops" should actually be called by its real name: full stack development, or my preferred term, Product Engineering.
I view every single product-focused engineer we hire as "full stack with a focus". The job titles might say things like "frontend engineer" for SEO, but the descriptions are clear: you're going to mostly be working on frontend and we expect competency in that, but you might be asked to reach into other parts of the codebase, or at least have opinions on how things are designed there. You'll be asked to participate in product planning and design. Everyone is general, but you do have a focus which represents 80% of your work.
I know coding schools would love to just teach someone React and then the bare minimum of a NodeJS backend to check a box then say they're competent. Bad news: I've worked with a dozen coding school grads over my career, as well as a dozen people who classified themselves as "backend engineers". None of them were even playing the same game as the people who took the extra time to expose themselves to the entire spectrum of technology a modern product might use. Mind you, many of these fullstack people were CS grads, many others were just people with no formal training. Formal training only matters if you limit yourself by how you've been trained, and then it matters in a negative sense.
I think I have to take the inteviewer's side there. Or I would at least ask a follow-up question.
This is an area where flash actually did a good job. What was the deliverable from someone building a flash site to the web? The flash binary. There was little reason to try and blend the tooling of what the flash author built with the rest of the site. It was typically the point of the visit.
Instead, we try and do a ton of stuff to setup the developer to more easily incorporate a designer's work. We do basically nothing to allow a literal handoff of a deliverable.
Until that changes, I don't see it getting any more straight forward for designers/developers any time soon.
Any job posting asking for proficiency in Yarn or SASS or React or whatnot is for expert monkeys who will produce web trash.
But what boils down to on the day to day is this:
I'll spend some time, turning mockups into static pages using HTML, CSS (and the occasional sprinkle of JS), but the bulk of my time is spent on implementation -- everything required to go from static site to a functional web application. Together with the other "Associates" on the team, we'll do everything from cutting the UI up into components, implementing business logic to handle behaviour and user interaction in these components, talking to the backend, and managing application state.
So what we decide to call these roles isn't important. Rather, i think, we should focus on hiring for skills. This means that we should do a better job of describing the skill sets, that we are hiring for.
If you are struggling to find work, you should invest time expanding your skill. Trying to restrict some arbitrary title to suit your comfort zone doesn't help either.
Twenty years ago you could have a designer writing simple HTML/CSS pages and then a Java developer filling in the functionality with JSP pages.
Today, the advent of sophisticated frameworks like React, and the browser becoming a highly capable development platform, it makes perfect sense to identify a separation of design-oriented UI/UX developer roles who are presentation experts and more engineering-oriented devs who focus on immutable state stores, app architecture, API design, implementation performance, testing, etc.
We really need good names for these two roles.
I think this is in part why you see these skills mixed in on job descriptions. There often cannot be a complete separation of concerns.
I need someone who can build a decent UI using Vue. I can do the tricky bits with Vuex and communicating with the server, but I do need them to be get the visual design parts of the thing, and the quite complex and advanced JS coding needed to make it happen. Am I looking for a designer or a developer?
I can understand how this blurs out to needing to understand MongoDB and functional programming. It's a tough line to draw.
You just described a designer and a developer.
For your reference: https://careers.google.com/jobs#!t=jo&jid=/company/ux-engine...
Knowing JS and some additional information can get you a lot farther, and to where I might consider you one... I happen to reach for node first in most cases on the server, so would say that a basic understanding of JS, node and build tooling would be sufficient.
Personally, I HATE getting cast into the "front end" box when I have a lot of experience across the stack, but am simple far more experienced than most on the front end.