The "math" that you would apply to the average website/web application, is often limited to some dimension/scaling computation. A sorting algorithm perhaps, or something with applying interests/taxes to a certain financial amount.
There are of course exceptions to the rule, but those are not the standard projects for web developers.
Does that mean that web development is easier? I believe it's not. It's different. Not every engineer is suited for both fields. I expect from a senior web developer to have a certain "feeling" about what he is building.
This feeling; you have or you don't. An algorithm can be tested by a unit test. The decision if the button should be aligned left or right, can not. In the perfect world, we have UX designers for that. But in the real world, they are not always on the team.
So a senior web developer should have a certain feeling for common sense. Also there, I'm sure that not everyone agrees. But that's how I run my team. I don't spec every integration. I don't convert every mockup to a final UI design. The mockup is what you use, and convert to match our standards and used frameworks.
I had a comment once on a retrospective; the point for improvement was that new functionality should be specced better. Because there were multiple development cycles required before we reached a final thing that worked in a nice way.
The point being; that development cycle was planned that way. But the developer wasn't comfortable with that. We often need something, of which we are not entirely sure how it should work. So we start with a prototype, we stabilize the code, get some users to try it, collect feedback, improve usability, collect feedback, ...., finalize.
Sometimes the feedback part is internally between developers, sometimes clients/users are involved. Sometimes this cycle spawns a few product versions, sometimes it's a faster iteration.
The alternative is to spec everything. That's more clear for the developer. And it might even be a bit faster in total time spent if there is a good idea of the product you want. But chances are big that you don't get what you wanted. That it works suboptimally. Just because something works in your mind or on paper. Doesn't mean it will work in the real world.
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.
Definitely, agree there.
The "math" that you would apply to the average website/web application, is often limited to some dimension/scaling computation. A sorting algorithm perhaps, or something with applying interests/taxes to a certain financial amount.
There are of course exceptions to the rule, but those are not the standard projects for web developers.
Does that mean that web development is easier? I believe it's not. It's different. Not every engineer is suited for both fields. I expect from a senior web developer to have a certain "feeling" about what he is building.
This feeling; you have or you don't. An algorithm can be tested by a unit test. The decision if the button should be aligned left or right, can not. In the perfect world, we have UX designers for that. But in the real world, they are not always on the team.
So a senior web developer should have a certain feeling for common sense. Also there, I'm sure that not everyone agrees. But that's how I run my team. I don't spec every integration. I don't convert every mockup to a final UI design. The mockup is what you use, and convert to match our standards and used frameworks.
I had a comment once on a retrospective; the point for improvement was that new functionality should be specced better. Because there were multiple development cycles required before we reached a final thing that worked in a nice way.
The point being; that development cycle was planned that way. But the developer wasn't comfortable with that. We often need something, of which we are not entirely sure how it should work. So we start with a prototype, we stabilize the code, get some users to try it, collect feedback, improve usability, collect feedback, ...., finalize.
Sometimes the feedback part is internally between developers, sometimes clients/users are involved. Sometimes this cycle spawns a few product versions, sometimes it's a faster iteration.
The alternative is to spec everything. That's more clear for the developer. And it might even be a bit faster in total time spent if there is a good idea of the product you want. But chances are big that you don't get what you wanted. That it works suboptimally. Just because something works in your mind or on paper. Doesn't mean it will work in the real world.