Fellow programners:

[ainmosni@social.ainmosni.eu]

@mahryekuh A whole bunch of stuff, from version control, to linters, to git hooks, to editors/IDEs, to CI/CD, etc, etc, etc.

[benjaoming@social.data.coop]

@mahryekuh The idea of @adamchainz's books

[meduz@m.nintendojo.fr]

@mahryekuh Making programming more convenient (not at the expense of users).

[hacknorris@mstdn.social]

@mahryekuh idk, maybe devops

[id@fedi.4x31.dev]

@mahryekuh Plenty!

• accepting at leadership level that DX is at the core for quality, time to market, customer satisfaction and employee happiness - an overall win-win-win scenario
• self-service for platform stuff, reducing dependencies on other teams & processes
• automation for (almost) everything, esp. obnoxious audit trails, change protocols and the likes (often required for compliance)
• proper security modeling for both build- and run-time across the organisation
• enabling success by providing the best tools available (hardware, OS choice, team autonomy, ..)

There's a lot more to it, but this is on the top of my head. HTH!

[moritzglantz@mastodon.social]

@mahryekuh People who put their own comfort above the comfort of the end-user.

[lea@lea.lgbt]

@mahryekuh what @MoritzGlantz says. React/Webpack and the whole node.js ecosystem was built around this idea, resulting in JavaScript-first-driven architecture, which is still pushed in my work projects. It provides little value to the user but introduces a whole set of problems. No full page reload, but it's harder to get the accessibility right, increased load times, the site isn't ready before the JavaScript is there, and users are confronted with a blank page in case of a JS error. 1/2

[lea@lea.lgbt]

@mahryekuh @MoritzGlantz To address the increased load times and blank page issue, React provides SSR-techniques. They help, but are very much over-engineered and there are simpler approaches which are – in most cases – way more robust, such as static site generation or dynamic html-generation on the server, which we already have in common web frameworks (php symfony/laravel/friends, ruby, asp.net, node, even java) 2/2

[lea@lea.lgbt]

@mahryekuh @MoritzGlantz I do love how #eleventy (now build awesome) keeps the architecture at HTML-first while still providing a good developer experience. So, to me, developer experience as a webdev is: give me a development server which detects changes and reload the site automatically. Then I'm very happy as a developer. The rest of the attention should go towards the user. 3/2 ️

[andrew@social.hodgson.io]

@hacknorris @mahryekuh I'm doing a few developer experience projects at the moment and they centre around improving the CI/CD processes but mostly its about what happens on the developer's machine. These clients are hugely locked down and in one case the starting point is a portable copy of Notepad++ and an old version of the Python executables with some packages Pipped in, that's all they have. I could write a lot more obviously but that is where my head is at now.

[markwalker@fosstodon.org]

@mahryekuh Unhelpfully, for you, this came to mind.

Deus Ex - Wikipedia

(en.wikipedia.org)

[radicalpet@mastodon.social]

@mahryekuh freedom to choose my operating system and tooling (it's on the top of my head, because my employer is likely forcing us all back on Windows soon and it will be grounds for me to look for a new job).

[ainmosni@social.ainmosni.eu]

@mahryekuh And of course I mean how well those things work. Where things shouldn't be more complicated than required while also not stopping me from doing things that I need/want to do. In many ways it's a very different set of priorities than normal UX stuff because a certain amount of complexity isn't just needed, it's also often wanted by the developer.

[iamkonstantin@mastodon.social]

@mahryekuh accessible onboarding, quick iteration (e.g. hot reload), non-intrusive tooling, good/actionable diagnostics, reliable ecosystem with clear pathways for support, roadmap insights, community etc.

[groue@hachyderm.io]

@mahryekuh Tools and libraries that do not get in the way. As few bugs as possible (correctness), as few obstacles as possible (completeness), respect for the time that users devote to the tool, and knowledge of the users' needs (relevance and empathy). Expectable changes should not require a large rewrite. Being opinionated is not a license to raise walls.

[mpwg@hachyderm.io]

@mahryekuh https://www.devexpress.com
(We use their libraries)

[dirk@snac.ndrvn.nl]

A shared 'systems home' in which all team members can live. No one imposes their individual preferences on others.
For example, editor choice: some may prefer VS Code, some prefer JetBrains, still others some other editor. With onboarding, team members should receive help on how to set up source control to ignore editor preferences, though sharing config snippets in dedicated documentation sections should be encouraged ("Dirk's VS code tips", "Dirk's git tips" ("Dirk's hg tips" would be funnier, but I'm not that mercurial))

Also, a good unit test suite, that points out exactly what funky edge case I just broke, within a couple of seconds.

[webhat@infosec.exchange]

@mahryekuh Developer Experience only really means one thing to me: clear error messages. If it's not clear why something fails unexpectedly, or I need to paste the error messages into a search engine to understand what it means, it's a poor developer experience

[mahryekuh@hachyderm.io]

Well, that confirmed my hypothesis that developer experience is a broad subject.

Thank you to everyone who chimed in!

[iamdtms@mas.to]

@mahryekuh DX is engineering, design and much more also. Some can reach it after 10 focused year, some (me) never reach that viewport of knowledge. Making decision next to some part of it results not to view the full from another perspectives IMHO. I'm not capably to step forward in the past years that way. What do you think?