I also think that the type of applications you work on make a HUGE difference as well. For the most part, I work on server side applications and services in C#. I added accessibility because I think that it is extremely important, but if you are working completely in the server, it's not super applicable.
I'm also biased towards security because I work for a HIPPA compliant company, so that is something that we have to have drilled into every app.
Finally, at least with service side stuff, performance can be bought. If something is slow, there are many instances where you can just get a bigger box to speed things up. I know that is the worst way to look at it, but there is some truth to it.
Completely agree. It really depends on the application and on what parts you (and the team) are working on.
Myself I am more of a front-end guy, but work and lead a team that does the entire stack. From React front-end to .NET Core micro-services on Azure. My expectation would be that the order would slightly differ for the entire team, compared to your view. But the front-end view would even differ some what more.
On the other hand, it also depends on how you can implement. On the front-end you could put a lot of effort in 'perceived' performance by implementing optimistic UI. But something like that has other big downsides (e.g. it is a lot harder on big applications that have a poor maintainability). In the dependencies, how you apply them weigh more heavily down the line. Personal preference would influence it only a little I feel.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I also think that the type of applications you work on make a HUGE difference as well. For the most part, I work on server side applications and services in C#. I added accessibility because I think that it is extremely important, but if you are working completely in the server, it's not super applicable.
I'm also biased towards security because I work for a HIPPA compliant company, so that is something that we have to have drilled into every app.
Finally, at least with service side stuff, performance can be bought. If something is slow, there are many instances where you can just get a bigger box to speed things up. I know that is the worst way to look at it, but there is some truth to it.
Completely agree. It really depends on the application and on what parts you (and the team) are working on.
Myself I am more of a front-end guy, but work and lead a team that does the entire stack. From React front-end to .NET Core micro-services on Azure. My expectation would be that the order would slightly differ for the entire team, compared to your view. But the front-end view would even differ some what more.
On the other hand, it also depends on how you can implement. On the front-end you could put a lot of effort in 'perceived' performance by implementing optimistic UI. But something like that has other big downsides (e.g. it is a lot harder on big applications that have a poor maintainability). In the dependencies, how you apply them weigh more heavily down the line. Personal preference would influence it only a little I feel.