I agree. The assertion in the article that "when engineers are developing products strictly for other engineers...their UX is fantastic" seems way off, at leas

I agree. The assertion in the article that "when engineers are developing products strictly for other engineers...their UX is fantastic" seems way off, at least from my experience. I think one of the problems that no one has mentioned yet is that developers like to think about things in logical absolutes, which doesn't work well in UX, which is a more holistic field. In UX, there are always trade-offs. For example: - Adding features to a UI could help support more complex use cases. - BUT the new complexity might using the core functionality harder. - OR we could refactor to a different conceptual model that intuitively supports all use cases - BUT this shift could totally confuse the existing users who are used to the old model. The only way to solve these sort of problems is to collect information about all the tradeoffs, make a judgement call, get the change(s) in front of users, and iterate. Unfortunately this isn't always how internal dev tools are built. I've seen entire systems planned and roadmapped following some abstract ideal like "consistency" or "flexibility" and built out over months or years without ever really consulting the users who will be using the systems. Concerns about the system being too confusing are dismissed because "we'll just add documentation in confluence."