My boss’s boss recently asked me, “If an Agile leader were to outline the top characteristic of their best developers, what are they? “
The response was relatively quick, and rather “off the cuff”. After re-reading it, I like my answer!
- Seeks to help others with any aspect of product development, regardless of her individual specialty
- Independently pursues continuous learning and shares new knowledge with the team
- Encourages and enacts technical practices to improve code and product quality
- Collaboratively and respectfully engages during all Scrum events
- Pro-actively seeks and provides feedback on code and the product being created
- Encourages, coaches, and embodies team-level agility
- Respectfully collaborates with other teams to ensure valuable features are DONE within each Sprint
- Embraces and actively supports organizational-level agility
- Enacts and coaches product instrumentation enabling Build > Measure > Learn
What’s missing from this list?
What could be improved in the original list?
Great list. The only point I miss is “her goal is creating value for the user” – something like that. What I mean is: we never should build things because it is possible. I know some of that kind and they could be really good devs – if they want.
Perhaps something from the likes of Uncle Bob’s “Demanding Professionalism in Software Development” talk (https://www.youtube.com/watch?v=p0O1VVqRSK0). Namely, that a professional software developer will not be pressured into doing the “wrong” thing. (i.e. shipping known sub-par software) even if this means directly contradicting requests/orders from management.
That’s integrity. True professionalism, agreed.
I’ll add: Learn, learn, learn
The ability to honestly look at code you’ve written in the past and cringe at your ineptitude; likewise to be able to take criticism, even of a level which might be “offensive” and use it to learn.
If you can’t do this, I struggle to understand how you can honestly say that you are continually learning and improving — for if we are continually improving, at some point we should be able to look back at our past code with an honest, brutal eye. And in doing so, we should be encouraging juniors who look up to their “superiors” with some kind of mysticism — by unabashedly exposing our own failure and accepting it as such, they should learn to do the same and not be hindered by the effort required to sweep past mistakes under the proverbial rug.
Agree with all of the above. Surely one of the fundamentals of a good software developer is the ability to write clear, effective code in a timely manner?