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.
- 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)
Christian Baumann reminded me of the 1x engineer, which is a great list. I personally don’t believe in the 10X developer. There is a reason why I wrote great developer and not 10 x
And then my friend Kris blamed me for making his life as Scrum trainer harder.
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…
Last week I published an Agile Thursday Quiz about PairProgramming.
(You can found previous quizes at ATQ )
The quiz was created by Sallyann and you can find her answers below.
1. Which of the following has Pair Programming as a core practice?
b. Extreme Programming. Although pairing is useful in any other the others is it only described as a Core Practice in XP.
2. When pair programming, the most regularly used names to distinguishing which person is currently typing are:
c. Driver and Navigator. Some say the Driver types, while the navigator looks at the broader problem / real world level. I (Sallyann) dispute this though
3. In Jim Coplien and Neil Harrison’s book “Organisational Patterns”, pair programming is referred to as:
c. Developing in pairs. Illustrated with a lovely ‘Two Amigos’ picture.
4. Pair programming has not been shown to have a helpful effect on:
b. Pair programming has actually been shown to lengthen the amount of effort required to develop a feature, however this is considered a cheap price to pay for the eventual time saved through not having to fix the extra defects found in solo-developed code.
Do you want to learn more about PairProgramming?
Brian Marick wrote a nice post about pairing with Corey Haines
A Pair Programming Experience by Randal Jenson
You might want to spend a while on Wikiwiki: (If you have never been to the first wiki, make sure you take some time to look at everything written here.)
You can also find these links and other on my delicious page for PairProgramming