Is front-end development having an identity crisis?(dev.to)
dev.to
Is front-end development having an identity crisis?
https://dev.to/assaultoustudios/is-front-end-development-having-an-identitycrisis-2224
160 comments
I work for an ecommerce company that’s just small enough that as a front end dev I wear a really big stack of hats. I regularly have to reach across .net MVC, React components, jquery, fairly complex scss and JavaScript written to what standards were 6 or 7 years ago in order to implement new features. On top of that, I regularly fill in UX and design work when a designer isn’t available, and I run the company’s entire A/B testing process, and even find myself working with AWS configuration and the build process occasionally. That said, I love it; getting to participate in so much of the process allows me to really get a feel for the entire structure of the site as a whole, and I feel like experience in one area often informs learning in others and helps me communicate with specialists from many different areas. I could see it being a bit overwhelming coming foremost from a design background, but in my experience you do not need a degree to do this work (Mine are in Biology and Psychology). It just requires you to put in the time to research, and I personally think it’s time well spent (and a good boss will account for the fact that you may be learning things on the fly in setting project deadlines). Getting into the nitty-gritty of JavaScript and really understanding how it works and modern best practices will save you so many headaches later. I will say sometimes I feel pretty amateurish when it comes to the design aspect, because it relies so heavily on cultivating good design intuition, but even then I appreciate those opportunities to flex a different mental muscle.
I was in exactly your shoes, and they can be pretty big boots to fill. But being able to take on so many parts of the process feels really good and you get a greater feeling of ownership over the whole product. You can make smarter decisions and understand the whys of more requirements rather than just the whats and hows.
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.
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.
Unfortunately as I am experiencing it right now 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 am in the job market after 14 years and my skillset is so specialised that it is hard to get a job. I got a few interviews but fell hard on home assignment. We'll see what the future brings.
I have the same fear with the road I’m taking now. I’ve changed jobs a lot in the last 10 years after staying at one job for 10, and just being a really good C# developer and then “architect” got me a long way. Along with barely passable front end skills.
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.
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.
[deleted]
I'm getting conflicting messages from your post
"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
"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
They don't necessarily conflict. People like to put other people into boxes. This person Sells. This person Develops. This per Designs. This person Manages. You are expected to be awesome at just your box, spend all your time in just that box, and above all else, to never leave your box.
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.
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.
This is unfortunately the way I stand right now, I do a lot of everything but nothing particularly well. I too do ecommerce development but I delegate outsource / project manage things as much as possible. Things I don't entirely delegate is research,frontend design, data loading, and anything that would be too complicated to explain in a few sentences. I have a large range of specialists that I work with to carry out things like automation scripts, plugins, templating, databases, backend development, etc. But I have to spec out everything, so I myself have to know how to do mostly everything as well. Including the business side of things.
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.
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.
Before my current position I was having a really hard time finding a job because most of my experience was Flash and ActionScript (talk about dead ends...). What ultimately got me a job (well aside from having a friend at the company, which is admittedly the best strategy for getting a job) was just checking out the requirements on as many job postings as possible and cramming the frameworks that showed up the most. For instance, if you want a frontend job, learn React. You may be surprised at how transferable your prior skills will be if you just put in the training time. In a more ideal world companies would recognize this in applicants and offer to train you on their time.
So, a regular programmer then?
Programmers that have front-end web development has their main area of expertise are still programmers. The difference is in the tasks. As this person said, they do CSS/JavaScript and even step in the UI/UX expert shoes. Then even do design work.
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.
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.
Something has gone very wrong in our industry. Typical in-house CRUD used to be relatively straightforward and a handful of developer/analyst hybrids could handle the vast majority of projects using tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer and has to be divided into specialists, including a front-end specialist. JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison.
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.
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.
Typical in-house CRUD is now handled just by analysts, with no developers, using tools like Salesforce and Sharepoint.
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.
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.
Really simple applications, maybe. But SharePoint can't scale well in terms of features and cross-table-relations if and when the application needs to expand. It may save you up front, but bottle you in down the road. (I don't have enough experience with Salesforce to comment on it.)
> tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer a
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.
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.
> 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
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".)
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".)
Similarly, many report that Dot-Net Web Forms development is usually quicker than MVC for in-house software (that doesn't need eye-candy) under normal circumstances[1], but developers don't want to use it because they are told it's "outdated" and it will rot their skill-set.
[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.
[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.
Huh? You don't see the irony in using a web toolkit as an example of how you can be more productive NOT using the web? Anvil is a VB/Delphi-like platform for the web, it even transpiles python down to JS in order to run in the browser. You're proving my own point for me. The web is so versatile that it gives you the power to do whatever you want, including clone a Delphi form builder in the browser. How is that an argument against the web?
I'm skeptical such a tool can stand the test of time per browser changes. A code base may work this year, but not in 5. A dedicated CRUD-friendly GUI standard would likely be well-tested on CRUD because that's its main job, not cat videos nor Amazon product lists.
You might want to mention that you are an anvil cofounder. Doesn't invalidate your point, but it looks a little disingenuous.
Re: 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.
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).
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).
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
Why "doesn't require the Control key"? AFAIK,
Why "doesn't require the Control key"? AFAIK,
<select multiple></select>
Many find usage of the Control key unintuitive. Why not have a standard widget that displays check-boxes on the left side of the multi-list? Keep Control as a secondary way to toggle, that's fine.
> Many find
[citation needed]
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.
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.
I guess I'm not understanding your point. I don't have a formal study about the (un)popularity of the Control key multi-select convention; it's merely my anecdotal observations. You are welcome to fund a formal study. (It's possible Delphi does it "wrong" also.)
My point is that the reason for web app development becoming cumbersome and time consuming is often unnecessary over-complication of simple, standard widgets using over-engineered and non-standard compliant JS "plugins", instead of built-in, standard elements. My point is also comparing apples to apples; when sticking to standard controls, web technologies are often simpler and quicker to implement than older frameworks, especially when taking into account the whole application lifecycle, including authentication, authorization, caching, and deployment of new updates.
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.
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.
I agree with native & YAGNI to a point. Multi-select that uses just the control key is confusing and clunky to users (in my experience). It just "sucks" too much. I'd prefer to see something like check-boxes on the left so one can select/un-select using the mouse. We'll just have to agree to disagree on this one.
Your typical CRUD app is not going to be on the bleeding edge enough to worry about many fuzzy areas and vendor specific enhancements.
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).
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).
But browser changes for other reasons may break what previously worked in a CRUD app. And we don't need gazillion widget types for most CRUD. Oracle Forms has a limited widget set, yet has been used to build a good many apps here at our shop quick and easy. It's not esthetic, but got the job done. (It has a few clunky spots, but everything does.)
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.
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.
In over 20 years of web application development, the single biggest breaking change (other than bleeding edge bits) was when IE 5.0 came out and broke the legacy api for populating select elements via JS. They added the new DOM interfaces but broke the old one.
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 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.
"Vendor-specific enhancements" are not a part of the standard by definition. If the project is built upon vendor quicksand then technical leadership has failed (unless the product is meant to target only one browser).
> 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?
> 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?
I thought I explained that already. Let me try to say it a different way: if there is no decent standard multi-select widget (as an example), you get lots of small shops reinventing their own. They have too few users/testers to have a reliable product. A standard multi-select would probably have more users and more vetters, making it more reliable in the longer run. Custom JS widgets going kerplunk is a growing maintenance headache here.
Clarification: I include vendors & suppliers of JS widgets in "small shops reinventing their own".
> Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases.
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.
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.
My experience seems to be a polar opposite of this.
A well-tuned web-stack can indeed lead to decent productivity. The problem is that the average shop either doesn't know how to tune the stack, or has no incentive to. A shop or domain settles on conventions, and one can potentially use these conventions to clean and tune a stack to fit an org like a glove. A handful of shops get it right. Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed.
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.
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.
> Web stacks have to be "managed", and if they have to managed, then the result depends on how well they are managed
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.
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.
It's kind of like restaurants. The tools I mentioned are like franchises: you know what you are going to get ahead of time: a "B" to "B-" level of quality at "B" to "B-" prices. Individually-owned restaurants may be roach-motels, and/or have the Greatest Food You Ever Tasted. But it varies per owner and time.
No different than any other part of the stack...everything that should be simple has become pointlessly complex. How many people here are evaluating Kubernetes for trivial services that could be easily addressed with twenty-year-old scaling models?
Do you have a particular example of something that should be simple but has become pointlessly complex? In my experience when people complain about complexity they are often complaining about a change from the thing they know to something they don't. On objective examination it can be the case that the old way wasn't simple either, because the complexity is inherent. Typically we move it around, put abstractions around it, but don't really change it fundamentally.
Re: when people complain about complexity they are often complaining about a change from the thing they know to something they don't.
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.
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.
One area of complexity I constantly rail against is dependency injection framworks or IoC... In most cases you can use what's built in, or don't need it.
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.
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.
Probably 90% of projects that are using Kubernetes
I'm glad to see this post, and I'm glad front-end developers are starting to rebel against the nuttiness of what has happened in their corner of the web.
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.
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.
Over the last year or so I’ve started splitting what was once the big “Frontend Developer” role into two distinct parts. The first is the traditionally thought of one - taking mockups or a style guide and using that to create the visual elements of an application. CSS, HTML, and some JavaScript sprinkles.
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.
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.
Then the first should IMHO be called a front-end designer. Developer to me is someone who develops logic, not some interaction with JavaScript.
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.
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.
> and being able to translate it to the chosen medium (that is, HTML and CSS).
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.
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've recently learned about that designer/developer distinction where I work.
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.
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.
They exist. They're exceedingly rare, though. I know only a handful and they tend to stick to one framework or way of doing things at a time to keep their learning burden to the absolute minimum. They're also pretty picky about who they work with.
(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.)
(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.)
My 2 cents:
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.
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.
I agree that there are two more or less distinct skillsets here. Although as always, it more than possible for someone to be adept at both. In fact, all the places I've worked that were hiring front end devs were looking for people who had both of these skill sets. And indeed we are often hiring for Full-stack developer who have both of these skillsets + ability with backend lanaguages and frameworks.
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.
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.
Do you really have someone who would be equally comfortable/effective with a large complex PWA, on the scale of, say, Trello - and with a beautiful boutique site (say, for a sophisticated web-native publisher), with lots of motion, infographics, video, layers, custom interaction, heavy photography, etc. I've yet to meet such a person. Of course I agree that one can specialize in one and be passable at the other, but to be equally strong in both, I also wonder what sort of career or company produces that...
Not equally comfortable. I think people will always have strengths in some areas over others. But good enough with the weaker skill that they might be preferable over another candidate whose specialism was that skill.
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.
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.
I completely agree. But I think that small amount of knowlegde does wonders.
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.
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.
Calling that person web designer is wrong on so many levels, just like in print the guy doing the preparations for printing and setting up machines is not a designer (although many designers do that part of the work too). In web it's the same, it's the step of implementing the design (a picture) into html and it's a separate role that's often been looked down by us (real?) programmers, but in reality it takes a lot of expertise to be good at it, so we should at least acknowledge it as a position that is much more about programming than designing. Actually I know quite a few people who are excellent in css and not know the first thing about design...
>Developer to me is someone who develops logic, not some interaction with JavaScript.
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.
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.
> This idea that JavaScript developers are somehow "lesser" is tired and totally overlooks the complexity and challenge of modern web development.
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".
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".
One who is translating a mockup into HTML/CSS isn't "designing" anything, at least not in the sense that most people associate with the word.
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.
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.
Probably the UI Designer should be the one converting to HTML/CSS.
I've never worked at a company where the designer was also doing HTML/CSS. Design and HTML/CSS are totally different skillsets. I'd be impressed if a designer also knew how to write HTML/CSS for responsible websites/webapps, especially CSS and it's nonsensical rules.
>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.
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).
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).
Probably "frontend api dev" doesn't fully describe what I meant. The point I'd split the two roles is in an environment where it's a client side application being built as opposed to a website. That's the point when being good at making things look right visually, and making them work coherently and in a maintainable manner, becomes a skill in itself.
I don't see why the developer that builds the interaction with the backend can't be given directly the design and turn it into HTML and CSS himself.
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.
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.
> I don't see why the developer that builds the interaction with the backend can't be given directly the design and turn it into HTML and CSS himself.
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.
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.
After building a full stack app (with limited users), what does the handoff look like?
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.
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.
[deleted]
Hi there. The reality is this was totally predictable. In the beginning things were simple. UI/UX is focused on creating the prototype and actual implementation was done by front-end programmers. But nobody likes to pay extra, so why not make designers code? Yes, i am one of those designers, old enough to remember frustration with tables and inline css. So if you asking your self why there are no more websites that are beautiful and usable? This is your answer: Is very rare someone with artistic abilities to have "programmers mind". Is enough frustration to deal with browser layout to expect someone to do full stack front-end dev. In the end you have mediocre designers (without basic understanding of color theory or typography) that are mediocre programmers (using all the cool JS tech, without CS basic understanding), so websites have interactive technology with design interaction from 2005:)
> so why not make designers code?
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.
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 can sure relate to this. Or my favorite question: "What happens when I click that magnifying glass in the top nav?" and they say, "Oh, I didn't think about that!"
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 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 doubt the real answer is for the designer to code
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.
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.
> But nobody likes to pay extra, so why not make designers code?
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."
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."
Nice:)) Very Nice. Actually i understand it, so much that i fired a lot of brogrammers, because in the end a lot of the "heavy and impossible work" of programmers is to implement someone else's real hard work and claiming the check. So now we are all suffering together.
As a full stack engineer, I'm expected to know all of frontend, all of backend, and some level of devops. but I am not paid twice, or even close to twice.
I'm not complaining, just pointing that scope of frontend is still relatively small as compared to other roles.
I'm not complaining, just pointing that scope of frontend is still relatively small as compared to other roles.
You are not expected to know ALL of both. You don't know ALL of both.
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.
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 guess I should qualify my statement better. You are expected to know both frontend and backend, in interview or daily work, to the same degree of a frontend engineer and a backend engineer respectively.
I would expect an SQL specialist to know more about SQL than a backend engineer. But that's a different scope all together.
I would expect an SQL specialist to know more about SQL than a backend engineer. But that's a different scope all together.
To the same degree? I disagree there. I would never expect a full-stack engineer to be more proficient at front-end when compared to a FE specialist. You are expected to know some, but not to the same degree. That’s the reason they are specialists, in comparison.
Yeah, if a company is interviewing full-stack devs at the same level as they do front- or back-end specialists, they probably have a severe shortage of full-stack folks (bar too high) or a glut of mediocre specialists (bar too low).
I wonder though, how can you be a frontend specialist when you don't even know how backend and servers work?
I am sure there are people that expect that, but they are wrong to do so!
I have been in the mobile space. Backend to me means: server side (rails/go/python), javascript, sql, devops, react admin panels, aws, css. Frontend to me means: Android or iOS. When someone says 'full stack' -- that to me means they know iOS or Android AND all of backend.
Front end traditionally has meant the browser.
Mobile apps have been around for over a decade.
Yes. That's an alternative definition, and a valid one as well. And it's more related to the topic of identity crisis.
You are not paid by the amount you know, but by the amount of work you produce.
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
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
I disagree. What happens if one frontend or backend developer isn't available (quits, vacation, etc)? One of your full stack developers can fill in. You're paying for flexibility as well.
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.
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.
I think we are in agreement?
My point is that people should be less entitled in terms of what's expected from them.
My point is that people should be less entitled in terms of what's expected from them.
makes me wonder when people will realize that "full stack" and "devops" are great ways to have less persons do more things and save a bunch on salaries. a gold mine for my corp.
> devops
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?
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?
My devops experience hasn't been much backend at all. Mostly scripting, server configuration & stand-up, etc. But I consider backend API programming.
It doesn't really save on salaries, though, unless the company is so small that it doesn't have enough work to take up the time of both a full-time full-stack developer and a full-time operations person and can replace two people with a single person who does both jobs.
It costs more because someone with both skill-sets will demand a higher salary than someone with only one of the skill-sets.
It costs more because someone with both skill-sets will demand a higher salary than someone with only one of the skill-sets.
> Frameworks like Angular or libraries like React require developers to have a much deeper understanding of programming concepts; concepts that might have historically been associated only with the back-end. MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript.
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.
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.
These "articles" on that site always leave the taste of frustrated redditors trying to make a name for themselves. They rarely make sense or have any meat to them and, after a few days of following it, I thoroughly ignore everything published there.
Front-end and back-end are pretty arbitrary labels. Labels like these first and foremost are designed to help those who try to commoditise development work (e.g. recruiters).
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.
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.
I totally disagree that they're arbitrary.
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.
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 the case of web these terms are still defined by non-technical people and heavily misused.
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.
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.
You can still somewhat stratify people by their specialty.
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.
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.
If you want to be good, you need to know both anyways. Being a specialist on one side is for people who are still on their way to go deeper to multiple parts of the stack or those who feel good just by knowing 1 thing sufficiently.
To your surprise code that runs on a server can have a frontend and backend too, this holds true for a lot of other things too like compilers.
Frontend does not mean visual, not at all.
See: https://www.quora.com/What-are-front-end-and-back-end-compil...
Frontend does not mean visual, not at all.
See: https://www.quora.com/What-are-front-end-and-back-end-compil...
"Frontend developer" is shorthand for "frontend web developer" or "web frontend developer". There is rarely any ambiguity in that.
While a compiler has a front- and back end, I doubt there are many ads for compiler frontend developers or compiler backend developers.
While a compiler has a front- and back end, I doubt there are many ads for compiler frontend developers or compiler backend developers.
There aren't many ads for any compiler related issues, but that doesn't mean they aren't "real".
I'm not surprised. Keep your assumptions about my knowledge to yourself.
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?
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?
So does the word "design". The terms are overloaded and get a different meaning depending on the context.
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.
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.
> Front-end and back-end are pretty arbitrary labels.
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.
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.
> I disagree. These are somewhat loose business standards that people have a general idea what they mean.
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 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.
>Why should someone be able to become an expert in HTML but not, say, SQL?
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.
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.
I think it's less talent and more dedication. My coworkers are impressed when I'm able to help them on all parts of our stack, but it's really because of the extra time I spent over my career outside of work learning new things.
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.
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.
This. You won't be much special if you stick to one side of the stack which will give you only average salaries.
It's sad people get impressed when you can just program and handle servers at the same time.
It's sad people get impressed when you can just program and handle servers at the same time.
That's true but then again you don't have to be a 100% expert in a particular area to be useful.
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.
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.
I'd say even 50% with some firm conceptual understandings, and syntax for what you're working in/with. I don't consider myself an expert in React, but I'm more than sufficient with a relatively good understanding of concepts. Rarely do you really have to dig deep into event models, but when you do it helps to know conceptually.
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.
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.
Yeah, the whole issue seems like one of terminology to me.
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.
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.
Where and how do you then draw the line? Should I expect you to also know Mobile Development?
I draw the line where it makes sense from a business value perspective. If the product you're working on is a mobile application then it makes sense to both know mobile and back-end development.
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.
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.
The biggest problem is most companies hire by ticking boxes. On the other hand, a developer is a developer. Yes, it will take a while for them to adapt if you hire a "Ruby developer" to do, say, embedded systems, so yes, it makes sense to check for patterns, but trying to match a profile is a somewhat unreachable target and useless to begin with.
A developer is not just a developer. I've been in the industry for quite a while and life for quite a bit longer and I have just never found this sort of pluggability in developers or people in general.
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.
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.
In my experience, a developer is a developer; given time and an internet connection you can fill in any knowledge gaps reasonably easily (even the kind you usually go to school for), but depending on specialization and experience you can have a project done in a week or you can have it done in half an hour.
There's a lot of software projects that don't need 'a well thought out data model in 3rd normal form with versioned entities, property-based testing coverage and full CICD pipeline' out there.
I know some of these words.
The way this works out at the shop I'm currently at is that you get a bunch of devs who are, for lack of a better description, 3/4 stack developers (back-end, database, anything on the front-end that isn't CSS), and a few other devs who are strictly involved in the design/HTML/CSS portion of projects.
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.
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.
Why would someone drop CSS as their skill when they know other frontend bits?
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.
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.
I really like this term "3/4 stack developer". Is it used elsewhere or did you make it up?
As far as I know I made it up. It's the term I typically use to give potential employers (and other devs) a general sense of where my competencies are.
I fully agree that the skill sets and demands of different roles sometimes all get labelled with the same title. But that is true of any developer role. Titles are not standardized to skill sets, and trying to do so for one type of developer while the rest of the industry is still varied makes little sense to me. Yes, you will look at job postings that aren't really what you do. So keep looking, just like the rest of us web devs do when an SW Engineer title ends up being an embedded C role on robotics, and not app development.
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.
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.
Me and my collegues like to talk about the "back-end of the frontend". This includes all the client-side logic and scripting. You have a server-side application primarily consisting of validation and data storage concerns, and a back-end of the front-end implementing some business rules etc.
This is fun, in my last job I used to call "back-end of the frontend" the nodejs server (of which, as a FE developer, I was in charge too) that talked to the "real" backend and aggregated data from various other sources. So in your schema that would have been "the backend of the frontend's backend" :)
lol.. I really like having a Node server for the app to talk to... for the most part it removes a lot of barriers to basic data transformations for requests and merging results closer to other data sources.
Not having to think in a different language helps a lot too.
Not having to think in a different language helps a lot too.
Is’nt the real problem that the market for web designers have imploded as social media became the primary platform for web marketing and customer outreach for most small businesses, killing of the need for a bespoke semi static website.
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.
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.
Things like squarespace and webflow probably contributed to this effect as well.
> MVC, functional programming, high-order functions, hoisting... hard concepts to grasp if your background is in HTML, CSS and basic interactive JavaScript.
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.
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.
No, not really.
I think it's less of front-end having an identity crisis and more that every major programming language is trying to do the job of every other one, as opposed to languages being specialized for certain tasks, Javascript and it's variants especially. But everyone's now got their preferred language and they won't budge. So it's another thing you have to learn in order to do the job, even if you don't actively use it.
I think trying to standardize roles and role names is a pretty meaningless activity. Recruit for skills, not for some form of arbitrary title. In some stacks and some organizations these roles are well defined and meaningful - so they can be used internally.
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).
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).
There is a substantial amount of evidence that the most effective product teams are cross-functional, and in parallel, the most effective product engineers are cross-functional.
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.
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 don’t inherently disagree with you but you’re not recognising that as tech evolves, you’re asking people to span an extraordinary amount of complexity. In fact, the premise of the article is that front end development is now essentially two different roles.
It’s amazing how little you can get done with a big team, and yet it’s trendy in development to push for specialized roles that lead to huge communication inefficiencies.
"'It secures HTTP requests and responses' wasn't deemed a sufficient answer when asked what an SSL certificate was in a technical interview for a front-end role."
I think I have to take the inteviewer's side there. Or I would at least ask a follow-up question.
I think I have to take the inteviewer's side there. Or I would at least ask a follow-up question.
Errrr no, that's a perfectly sufficient answer for someone who's primary concern is UI layer. Is it a secure connection or not? It is? Then we're done here.
The irony in this is that much of the complexity in these newer frameworks is supposed to make it easier to separate the concerns.
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.
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.
A good front-end developer knows how to architecture code for creating user interfaces, has a sense of design, is aware of UX, is sympathetic to accessibility, understands how the browser interprets CSS, is knowledgeable about the browser's rendering pipeline, knows the typical performance of API calls anywhere in the front-end stack, gets the division of responsibility between front-end and back-end.
Any job posting asking for proficiency in Yarn or SASS or React or whatnot is for expert monkeys who will produce web trash.
Any job posting asking for proficiency in Yarn or SASS or React or whatnot is for expert monkeys who will produce web trash.
These titles are pretty meaningless in my opinion. Plus, what front-end developer means depends on who's looking anyways. Where I work, for example, my official job title is Senior Frontend Associate. What does this means exactly? I haven't got a fucking clue.
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.
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.
[deleted]
Technology evolves. As it evolves, it becomes more sophisticated and the roles themselves become more specialised.
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.
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.
Honestly - I would actually require front-end developers to have some backend coding experience in our case, we have a very large monolithic app that we are attempting to break down to a more MSA type app but it still needs upgrading.
This means they will need to wade through code templated HTML / CSS / Javascript in order to re-skin the app.
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 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'm trying to hire someone for this kind of role at the moment, and it's really confusing.
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.
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 could search for a front-end-engineer with some design-experience for hiring. Then get the initial visual/interaction-design from a freelancer. The dev should be able to fill in blanks and continue the initial design-work.
You need two people, sorry.
You just described a designer and a developer.
You just described a designer and a developer.
I only have budget for one, and have met great designers who are also very good JS engineers. What do we call those people?
The keywords you should use in filters are "UX engineer" and "JavaScript". You don't need two people if you have a small team. I know a few people who meet your requirements (one person doing both design and coding).
For your reference: https://careers.google.com/jobs#!t=jo&jid=/company/ux-engine...
For your reference: https://careers.google.com/jobs#!t=jo&jid=/company/ux-engine...
Someone who designs how everything should look and feel, and someone that implements that in Vue and JS.
To be fair, we could say programming itself also has identity crisis. Job posts don't look the same as they did 30 years ago. But in this case we accept it as part of the progress we've made. Frontend development is in the spotlight now, and it's in a far better position that it was a couple of years ago. Even for the same apps, I like them now compared to what they were a few years ago. It's a good time to be a web developer. Even better to be a web user.
We have shifted a focus on the developer comfortability than on the user's. All these new implementations (or libraries fundamentally) biggest selling point is making the developer life easier. Although it may make them more productive, we lose sight on the user needs.
Same thing happened to SysAdmins with the conversion to SRE. Industries change. Sink or swim.
Looking at many startups and even larger companies anything sysadmin and devops is for them just couple of clicks away in the AWS web console. They fail usually.
imho, if all you know are HTML and CSS, you are NOT a front end developer.
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.
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.
I saw a tweet the other day how react hooks are the controller of the MVC in react. Wtf
Ya that kinda makes sense. They seem like a great feature that will help smooth over some of the less sane patterns that exist in React today. I think "hooks" is a somewhat misleading name though.