Fellow programners:

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

https://en.wikipedia.org/wiki/Deus_Ex

[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?

[mahryekuh@hachyderm.io]

@iamdtms You probably know more about it than you think.

I recently got a request to do a DX presentation after someone refered me for it and… I’m just learning the scope of this subject.

Apparently, a lot of wisdom that experienced devs considers common sense (or at least I did) is also DX.

[frytg@beoriginal.social]

@mahryekuh amazing docs