title: Inclusive developer
slug: inclusive-developer
date: 2016-12-08
lang: en
chapo: Inclusive developers lead to inclusive teams. Inclusive teams lead to inclusive products.

> So where have we got to? Access is important, but inclusion is bigger than access. Inclusive design means making something *valuable*, not just accessible, to as many people as we can.
>
> <cite>*[What the Heck Is Inclusive Design?](https://24ways.org/2016/what-the-heck-is-inclusive-design/)* ([cache](/david/cache/bbc4e316b19a81c3e220cefd6bc73af6/))</cite>

Job titles are hard. I always wondered which is mine. I think Heydon Pickering nailed it with his last article on 24ways. I’m working on inclusiveness due to recent changes within [my team](https://github.com/opendatateam) and as part of my road to become a [senior developer](/david/blog/2016/senior-developer/). Being inclusive means a lot of things to me:

* help newcomers jumping into projects smoothly with explicit [documentation of governance and participation](https://github.com/davidbgk/open-source-template/)
* enjoy nonviolent communication during developments (pair-programming, code-reviews and so on) and quick feedback loop on iterative releases
* avoid burn-out/isolation for co-workers with healthy lifestyle and solidarity
* turn [open-source](/david/blog/2013/open-source-solidarite/) into free software (more in a future article)

**Inclusive developers lead to inclusive teams. Inclusive teams lead to inclusive products.** Not the other way around. The values you share within your team will be the ones transmitted by your product. It’s hard to have empathy for your users if you don’t have empathy for your colleagues first. I’m paying the price these days for not being careful enough about people I’m working with. It will be one of my take-aways from 2016. No matter the importance of your achievements, you are interacting with humans and taking the time to listen to them is important.

*I hope I’ll be able to qualify myself as an inclusive developer, someday.*
