"I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI")."

Paranoia?

There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Has nothing to do with devs who are blocked by management.

▲

jeltz 4 hours ago | parent | next [-]

No, while the patent poster expresses their opinion quite strongly I have more than once encountered product managers and project managers who get almost personally offended when developers try to use their brains and don't just blindly implement incorrect specifications. If they have a vendetta I don't know but they clearly hate having to depend on engineers with free will.

That said I have also encountered lazy engineers who are totally fine with implementing obviously broken software, those are a perfect match for the egotistical product manager.

	▲	tcmart14 37 minutes ago \| parent [-]
		Shoot where I am at, it can also change on a week by week basis. This week, I can get away with some shit to improve the UX and depart from the mock up. Next week, if the feature doesn't look and function just like the mock up says that was handed in the case, I'm in trouble. No matter how bad it is.

▲

aleph_minus_one 5 hours ago | parent | prev [-]

> There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it.

Note that in my comment I wrote nothing about dogfooding - for a very good reason:

It is well-known that dogfooding leads to software that has rather few bugs, but also dogfooded software often shows a tendency to be "biased towards programmers and power users". So, there often exist very good reasons if the programmers actively don't dogfood their software, and rather trust someone else (who is very trusted by the programmers) that the workflow that the programmer should implement does make sense for the user, even though most programmers would implement this aspect very differently.

▲

msdz 4 hours ago | parent [-]

Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-)

	▲	aleph_minus_one 4 hours ago \| parent \| next [-]
		> Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-) Lessons that you should be taking away are rather: - Every tool that possibly might be good for improving the quality of the software is just a tool that can also cause harm if used in a wrong way. - Deeply distrust keynote speakers and thought leaders who sell their method for improving the quality of the software or improving software development as a panacea. Every method is only useful under specific circumstances and is harmful of used wrongly. Keynote speakers and thought leaders who don't go into details when their methods are helpful and when they are harmful are simply scammers and snake oil salesmen and should be called this.
	▲	lukan 4 hours ago \| parent \| prev [-]
		Well, I think you should always do that(if your constraints let you). But working with actual users and valuing their input is to be prefered of course. Every user can be a power user if you give them the tools so they empower themself.