Developer Experience - How to improve your App
by
Vaclav Tunka
Senior Software Engineer
Red Hat, JBoss EAP
Inspired by today's lab on Forge, thanks Koen!
A nice scaffolding project, that helps you create runnable skeletons of Java EE aps.
Didn't use it much before - so first proper hands-on lab on Forge.
Great project, gets the job done, *but* needs a lot of love and detail polishing.
By Developer
for Developers
We suck in making UIs as devels, and we know it.
We have UX people for designing wireframes, designers / graphics and coders for the end product eg. cutting to images, HTML / CSS, etc.
What about developer experience?
Why is developer experience important
(Hope everyone knows it's important already so this slide is theoretically not necessary.)
Without developer mindshare we have lost, please reward your contributors & dev consumers.
Developers are quite picky, lazy and easily migrate elsewhere or fork stuff - eg. Hudson/Jenkins, OpenOffice/LibreOffice, etc.
People like to learn & have expertise in something - reward on its own.
What is developer experinece?
When was the last time you screamed in front of a dev. tool?
We do complex platform / generic SW, solving real-world issues.
SW quality is usually quite good nowadays.
Tiny things matter - polish your tools.
If you are not the "polisher" type - ask bachelor / master students, newbie upstream contributors.
Make these tasks a low-hanging fruit.
Examples of good developer experience
Code is publicly hosted on a site using Pull requests / Merge request workflow.
No patches on mailing lists! => see my other talk
Clear roadmap published on dev mailing list / forum.
Accesible chat, eg. IRC, Atlassian Hipchat, whatever suits the team.
Documentation is available - no, code does not count as documentation!
Jenkins
The good ol' CI server you all know and use (hopefully you use CI, if not you should fix that ASAP, see my other talk).
One of the most open upstream projects.
Not always good to be as open and welcoming
"Use the Force Luka" scandal.
Ironically a guy writing book on code review in gerrit.
But hey nobody is perfect.
Doing CLI?
Include loading indicator for example rotating semigraphics like: | / - ...
Provide programmatic API.
Maintain the contract.
Properly divide the outputs & use logging properly.
It always helps to have good ol' UNIX/Linux style of CLI.
Doing desktop application?
Enable power-users to edit configs outside your app.
Provide programatic API.
Think about modularity & plugin architecture.
Don't constantly change UI - this is more of an UX thing, but you know how easily this can annoy devels.
Generally
Look around you!
Are similar apps integrated with other apps?
Provide plug-ins / integration options from the beginning.
Maintain contract.
Don't package the world, leverage the live system.
This issue is going to get worse with containers imho.
Questions?
Thanks for being awesome audience!
Made with Slides.com