> 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.