This. This is why you want senior devs too. You want people who can stand up to poorly conceived features. The most important job is to say “no”, or “how about X instead?”. I get furious when I see senior colleagues defend horrible design decisions with “it was what was specified”. Your job as a developer is to take the spec from the product owner and suggest one that actually fits the system in terms of maintainability, performance etc. Blindly implementing a specification is a horrible idea.
In team A, I challenged many ideas coming from the designer and the product owner. I was also pushing back on technical decisions coming from the CTO. They always listened: I would change their minds a couple of times, sometimes I realized I was wrong. Only a few times could we not resolve the issue, but in the end I felt that they heard me and considered my point of view.
In team B, I started out with the same mindset and was trying to challenge the validity of their product decisions. It was superficially acknowledged, but 98% time my input was basically ignored, and I felt like a party-pooper for pointing out contradictions and mistakes in their thinking. After months of trying to be listened to, I realized I'm here to be a coding monkey, they don't want my input neither on product, nor on technical problems. I learned to just nod and smile, cheer them on on their bad decisions, they felt great because they felt validated. It was also better for my happiness short term, as it's not a great feeling to feel that I'm bumming them out.
Long term, I started looking for new positions, and since then quit already. I still feel it's a shame as the "idea" had great potential.
In January I'm moving on to "Long term" and they will left with a bunch of juniors. Good luck with that on the long run
This is one of my pet peeves when it comes to software development. I _really_ think that software development project managers ought to be able to spot the difference between a good architectural decision and a bad architectural decision, a good design decision and a bad design decision, a well implemented function and a badly implemented function. It sinks my heart, as a software development professional, having to work for project managers who, in many cases, would be hard pressed to explain what a byte is. It's just so wrong.
It's like working for a newspaper editor who does not know how to read or write. It does not mean that you cannot produce a newspaper, but it depends upon the workers stepping in and doing all the strategical technical decision behind the project managers back. As an engineer you can live with it for some time, but eventually it ends up feeling fake, and like a masquerade.
I'm much more in favor of hands on leadership types like Microsoft's Dave Cutler, with the technical skills to actually lead, and not just superficially 'manage'.
example from my current project: 1. Inherit half finished large software with lots of features. 2. It contains bugs and is impossible to effectively maintain/develop for the allocated manpower. 3. Management still wants all features. 4. Be brave and don't work on anything except essentials until they're sorted out. Lie to management if you have to e.g. that you found serious bugs that must be fixed (which is kind of true but they wouldn't understand)
I don't know what good examples would be. maybe a word processor without support for bold and italics. Maybe a code compiler with no error messages. Maybe an email client with no threading.
Does a word processor need every feature of Word? No. But does it need more than notepad? Yes!
Basically you get one chance to make a good first impression. If the customers and press label your product a certain way it will take a ton of effort to change the inertia of anchor you've given them.
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 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.
You have to develop an opinion of the thing you're building/maintaining and what it should be able to do and not do. You can't count on project managers to do that.
The trick to doing this effectively is to find out the problem the feature is actually trying to solve and providing a better solution.
Usually the request is from end users of software and they have identified the problem (we need to do xyz) and prescribed a solution (put the ability to do xyz in a modal on this page.) But if you can look to what other software has done, do a UX review and find a way to add a feature in that solves their problem in a way that makes sense in the larger context of the software, they won't have a problem with it since it solves their problem and the codebase will take less of a hit.
Unfortunately, it's a lot easier to just add the modal without complaint.