Your job description of devs is very limiting. Software developers should be close to the customer problem, work to understand it, and develop for it. When you silo them away this way and expect them to be order takers you add bloat to the team and inefficiencies.
If you're working with a small team on some customer-facing SaaS, maybe. But let's be honest, there are a lot of software developers out there who either don't have the inclination or skill to push back against their boss's boss's boss, or question why a particular abstraction is request over another. They've got to work too, and for the most part a senior or architect is just going to give them tasks and wait for them to be completed.
I've also noticed a distinct lack of "work[ing] to understand [the customer problem]" from the "I'm going to be a dev for 7.5 hours a day at work and not touch a computer or think about programming for a single moment more" subset of programmers.
I mostly run large teams who have handled both internal and consumer facing services. The software devs who don't have an inclination to understand the customer problem generally have not been highly effective and are not people I would use as role models or for setting expectations to others. I'll add to this that I do not believe there is a place for an "architect" role that is separate from a developer role. Good developers learn to think about architecture and do so with larger impact as they become more senior. "architects" who don't code tend to be "architecture astronauts" who do not help you ship value fast, at quality, to your customers.
>there are a lot of software developers out there who either don't have the inclination or skill to push back against their boss's boss's boss, or question why a particular abstraction is request over another.
I definitely agree with you. There are a lot of people who for various reasons (inherently lazy, not engaged with their current role, etc...) would not do this.
My problem is that I think this is a learned behavior in a lot of environments. A lot of places try to treat developers as code monkeys, where it's actually the brilliant designers and business analysts making the decisions and it's just the responsibility of these programmers to execute their vision.
This compartmentalization doesn't work well and it leads to a lot of really bad software. Here's my theory as to why.
If you look at all the various jobs involved in creating a piece of software: Design (UX/Screen Design), testing, project management, business analyst/requirements gathering, programmer. There's only one that's actually required to produce a functional piece of software: the programmer.
And as much as people want to pretend like this isn't the case, the programmer often has to do a little bit of every one of those other roles to effectively do their job. In this comment thread, we've been discussing how they have to put on their project management hat and help shape requirements, but it's deeper than that.
After all, what programmer hands off a feature for testing without themselves testing that it worked? UX might give you a wireframe, but there's almost always edge cases not accounted for. As for project management, if you're lucky you have a good one who actually makes the project easier but more often you will have a bad one who adds no value and only forwards emails to you and bugs you about timelines, which effectively means you're managing the work yourself.
And this isn't to say that the people in those other roles are necessarily bad at their job - but there's a context you get as the person actually building the thing that you can't get in these silo'd, standalone roles. You see issues that other people can't and you have an ownership over the end result that they don't. The programmer is the most important piece of it all. They tie it all together and the buck really stops with them. Programmers who don't take ownership ultimately lead to worse software.
If companies understood this on a more fundamental level and tried to select more for it in hiring than whiteboarding questions, they'd probably be more successful.
The parent comment tried to make a distinction between "architect" and "dev" - but this should start at the Jr. levels. Teach them at the beginning of their career.
To be clear, I do think those other roles are important and valid. I just think it's very very rare for a team to be staffed with people who are good in all of those areas and when someone is deficient, it basically falls on the programmer to make it up.
