A great developer:
– is good at coding
– understands business
– knows the value of communication
– thinks about her own limitations
What am I missing?
— Yves Hanoulle 🇪🇺 (@YvesHanoulle) January 29, 2020
I make tweets like this, because I know my agile friends won’t let me down.
I got a lot of great ideas.
- values simplicity (Added by Anthony Palumbi)
- values feedback (Added by Anthony Palumbi) ==> that is important part of communication, that is wurth mentioning.
- tests or writes her own tests (Added by Jennifer Riggins)
- documents her own code (Added by Jennifer Riggins)
- contemplates ethical ramifications of code (Added by Jennifer Riggins)
- mentors or parallel programs with other devs (Added by Jennifer Riggins)
- doesn’t smell too bad for pairing. (Added by Dave Nicolette) Duh
- shares learnings (Added by The abbot of unreason) ==> how could I forget learning?
- can and offers to help her peers become better (Added by Irene Kuhn)
- admits to limitations (Added by The abbot of unreason) ==> I should have written that.
- considers the broader context into which changes occur (Added by The abbot of unreason)
- thinks about ramifications (Added by The abbot of unreason)
- can troubleshoot (Added by The abbot of unreason)
- has empathy for the user (Added by The abbot of unreason)
- writes as little code as possible (Added by Matthew Skelton)
- writes as little “readable ” code as possible (Enhanced by Grant)
- balances short-term and long-term solutions to problems (Added by Scott Dunn)
- offers those options to the business (Added by Scott Dunn)
- attends to folks’ needs. (Offered by Bob Marshall as a replacement for everything) ===> I would say not replace, yet it should indeed be the goal of all developers.
- In a later tweet Bob added the antimatter principe with more explanation.
- knowing your internal and external customer. Not just their names but who they are, the way they think and what their actual needs are. (Added by David Benson)
- is nice to people! (Added by Lanette Creamer)
- cares that non-technical people understand what their code does (Added by Lanette Creamer)
- has humility (Added by Lanette Creamer)
- Jens Scheidtmann wants to replace “is good at coding” with
- writes instrumented code
- considers error handling first
- writes robust code
- thinks creatively (Added by Charlotte Ward)
- helps others grow (Added by JanTielens)
- can explain complex stuff to various audiences (Added by JanTielens)
- is open to feedback (Added by JanTielens)
- is open to hear other opinions (Added by JanTielens)
- in case if an error/bug/issuse he/she always blames his/her own code first, instead of blaming the framework, libary, other code (Added by JanTielens)
And then my friend Kris blamed me for making his life as Scrum trainer harder.
And I need to repeat over and over again in my Scrum trainings that Developer Team members are not necessarily technical people, let alone programmers 😭 you’re not helping me, Yves! 😉
— Kris Philippaerts (@kphilippaerts) January 30, 2020
You are welcome Kris. 😉 I still love you just the same.
I agree with the scrum guide that a development team contains more then coders. And indeed the “good at coding” part is probably the least important of being a great developer.
In fact the tweet was inspired by a conversation I had some months ago, where I spoke with a rather good coder, yet this person said he was to not interested in other things in this list.
It made me realize that my tweet might give the impression that I want all developers, be great developers. That is not needed. Although once such a developer in a team does make a huge difference. yet not in the 10 x developer way.
And that might give the impression I don’t value the not great developers.
the great development team.
Actually if we add a few more things, we come with a definition of a unicorn developer. The ideal not existing developer.
And then we come back to a definition of the great development team.
Where for me, the whole team should contains as much of these ideas. As a team.
That is where diversity plays a role in a team. As if this list grows even larger (which will happen for sure, knowing the agile community) it will be even impossible to have a team that contains all these things in the whole team…