larlet-fr-david/david/stream/2018/09/17/index.md

title: Hard truth
lang: en

> The “developer experience” bait-and-switch works by appealing to the listener’s parochial interests as developers or managers, claiming supremacy in one category in order to remove others from the conversation. The swap is executed by *implying* that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. **This is not true.**
> 
> <cite>*[Infrequently Noted](https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/)* ([cache](/david/cache/7bc5331346ba44306777df275aa68a2a/))</cite>

Then:

> I want to see progress. I want change. I want state-of-the-art in software engineering to improve, not just stand still. I don’t want to reinvent the same stuff over and over, less performant and more bloated each time. I want something to believe in, a worthy end goal, a future better than what we have today, and I want a community of engineers who share that vision.
>
> What we have today is not progress. We barely meet business goals with poor tools applied over the top. We’re stuck in local optima and nobody wants to move out. It’s not even a good place, it’s bloated and inefficient. We just somehow got used to it.
>
> <cite>*[Software disenchantment](http://tonsky.me/blog/disenchantment/)* ([cache](/david/cache/866fcdfe728b5f87af78357ac5e6d674/))</cite>

And then:

> Over time, technologies are added, but are rarely removed. Left unchecked, production stacks that have been around long enough become sprawling patchworks combining everything under the sun.
>
> <cite>*[In Pursuit of Production Minimalism](https://brandur.org/minimalism)* ([cache](/david/cache/232f1334b14f4f17bac10b5c8c3fb555/))</cite>

Finally:

> The dynamic you see with especially long-lived code bases like Office is that the amount of framework code becomes dominated over time by the amount of application code and in fact frameworks over time get absorbed into the overall code base. The framework typically fails to evolve along the path required by the product — which leads to the general advice “you ship it, you own it”. This means that you eventually pay for all that code that lifted your initial productivity. So “free code” tends to be “free as in puppy” rather than “free as in beer”.
>
> <cite>*[Complexity and Strategy](https://hackernoon.com/complexity-and-strategy-325cd7f59a92)* ([cache](/david/cache/4823f239a69fb169fc9a91b8d52ba240/))</cite>

The most frustrating part of all this is the number of (old) developers getting to the same conclusion without any clue to avoid that extra complexity.

*Myself included.*