[zebraflask]

... not to belabor the discussion, but have you ever run across a scenario where one of the non-technical people tried to insist on something absolutely boneheaded from either a business or technical perspective? Who gets blamed if the dev just shrugs and does it?

Hint: not the person who insisted on it. The developer.

I've seen that play out too many times. Expanding out of a strictly coding role isn't just good for career progression, it's a necessity for career self-preservation, too.

[johnnyfaehell]

Yes, refusing to do things that are technically bad is a technical matter hence a developers job. And what happens if you say no, they either go find a developer who will do it (seen that so often) or they go to the CTO/Engineer Manager/etc to try and get them to agree. In both cases, a developers job is to give technical feedback such as "Sorry but that's a security threat, you'll need to figure a new approach. Maybe try Z." not, "I think it is a better idea to work on X instead because it's going to generate Y". One is technical feedback on their idea and the other is a product/business idea.

> Expanding out of a strictly coding role isn't just good for career progression, it's a necessity for career self-preservation, too.

The first part is pretty much my point. To progress in a career in IT you have to stop doing technical work to progress. Development is a dead end job, just a reasonably well paid one. The second part, for the most part, I've never really seen. Most developers I've worked with haven't been held accountable for anything in such a long time that they get offended when you point out 500 servers going down in 20 countries because of one Redis server is embarrassing and we should work on stopping that from ever happening again and give excuses why it's not.