The idea to fight for the architecture means take ownership for quality and user experience of your area... don't just blindly implement whatever is asked. Investigate, negotiate, and if necessary once in a while even say "no" to requests. @ben
this might go without saying (to protect the quality/user experience) when you start your own company. But this is a strange concept to juniors and business devs in general. For the latter, most companies treat you simply as a gear that turns the software wheel, so you feel equally dispassionate to the software you create. "Just doing what I was told." Over time it becomes a mess because no one cared enough to understand what they were actually coding, only how to technically accomplish what was asked of them. As a junior dev, focusing on the technical part is kinda where you have to live for a while until experience teaches you enough about the business to know when a request is going to actively harm quality or UX. This is why apprenticeships/mentorships are especially useful.
I have an example along the line of "fighting for". A customer stakeholder asked us to add a field to keep some information. But then we started to think about how someone would actually go about using that information for its stated purpose. We saw it was going to be very awkward and would probably never be used. So instead we brought an alternative idea to the customer. It was a little more work to implement, but it directly addressed the problem they were trying to solve. They loved the idea and we implemented it instead of the original request. Turns out other customers really like it too, and we've had followup requests to add a few more options to it.
Yeah I totally agree. This sort of thing goes without saying for me, but is absolutely not what I've observed. The fight is the more typical scenario, which is not ideal. An ideal would be that all parties understand ahead of time that this is the reality, so the "fight" stops being a fight and ends up being a mutual collaboration. Other problems might prop up, but we address the fight by making the stakeholder reality a core part of the work and use it as a hook to hire talented and empathetic engineering candidates.
I agree, mutual collaboration is the best way. "Let's work together to do our best for the user/customer." However, it is an impressive feat to consistently hire people who hold to that. Even then I think gets harder to stay that way in larger teams. When things are small everyone is more individually connected and accountable to everyone else. I like working in my smaller team. :)
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.
The idea to fight for the architecture means take ownership for quality and user experience of your area... don't just blindly implement whatever is asked. Investigate, negotiate, and if necessary once in a while even say "no" to requests. @ben this might go without saying (to protect the quality/user experience) when you start your own company. But this is a strange concept to juniors and business devs in general. For the latter, most companies treat you simply as a gear that turns the software wheel, so you feel equally dispassionate to the software you create. "Just doing what I was told." Over time it becomes a mess because no one cared enough to understand what they were actually coding, only how to technically accomplish what was asked of them. As a junior dev, focusing on the technical part is kinda where you have to live for a while until experience teaches you enough about the business to know when a request is going to actively harm quality or UX. This is why apprenticeships/mentorships are especially useful.
I have an example along the line of "fighting for". A customer stakeholder asked us to add a field to keep some information. But then we started to think about how someone would actually go about using that information for its stated purpose. We saw it was going to be very awkward and would probably never be used. So instead we brought an alternative idea to the customer. It was a little more work to implement, but it directly addressed the problem they were trying to solve. They loved the idea and we implemented it instead of the original request. Turns out other customers really like it too, and we've had followup requests to add a few more options to it.
Yeah I totally agree. This sort of thing goes without saying for me, but is absolutely not what I've observed. The fight is the more typical scenario, which is not ideal. An ideal would be that all parties understand ahead of time that this is the reality, so the "fight" stops being a fight and ends up being a mutual collaboration. Other problems might prop up, but we address the fight by making the stakeholder reality a core part of the work and use it as a hook to hire talented and empathetic engineering candidates.
I agree, mutual collaboration is the best way. "Let's work together to do our best for the user/customer." However, it is an impressive feat to consistently hire people who hold to that. Even then I think gets harder to stay that way in larger teams. When things are small everyone is more individually connected and accountable to everyone else. I like working in my smaller team. :)