About

This session was a discussion about bridging the gap between developers who actively take an interest in learning and growth with the many developers who do not share those priorities.

There was a similar session promoting a learning culture at work 

Anyone else who was there, please add to this.

Self-Selecting

There was a good amount of talk about self-selecting groups. If you start to bring in a culture that is concern about improving your craft and striving for better quality, you'll start to see two things:

1. People will adopt to these principles and start practicing them.
2. Others may self-select themselves out and leave the group.

If the second part happens, when you're looking to replace them, you're hopefully looking for and getting people aboard that follow these same principles. This just further builds the group to focus on that craftsmanship.

Isolation is not Realistic

Initial Discussion revolved around the idea of cre\eating "walled gardens" of like-minded developers, eliminating the need to deal with developers who do not share our ideas.  This was quickly dismissed as unrealistic-considering that a large portion of developers are not self-motivated to the level we might want, it's very likely to end up on a team with developers who do not share our interests-even if one is able to successfully create a "walled garden", many projects involve integration that would bring us into contact with others.  Not to mention that, hypothetically, if one were to remove, say, 70-90% of the developers from the workforce, there would not be enough people to complete all the projects that need to be completed.

It's Our Fault

A point was mentioned that in these situations where we encounter high friction, it's arguable that they are not the source of the problem-we are. We are the ones bringing friction into the situation and trying to shake things up.  Dropping into the team, acting like rockstars and declaring ourselves right is not going to convince anyone that we have anything to offer.  Conversely, if we are unable to influence the team and we are unhappy, the saying "change your job or change your job" definitely applies-for your own good, and the good of the team.

Learning

It was pointed out that there are in fact two gaps: 1) an inability to acknowledge a better way, or that there might be a better way, and 2) a lack of knowledge.  The way to deal with these two gaps varies.  For 1, concrete evidence, empirical research is the best way to argue.

If you help someone to learn new techniques and ideas and they go back to their old ways in only three months, you probably didn't really convince them your way was better-they may think "oh, that's just the way person X does things, when he's not around, I don't see why I should do that"

Ideas about learning:

• Give brown bags
• Keeps suggestions small
• Dropping "Code Complete" on someone's desk isn't going to help
• We didn't drop out of the womb with the knowledge we have now-there is a path for others to learn it as well
• Pairing is a great technique if it seems like there's just too much to learn
• Collective code ownership cross-pollinates and can expose people to other ideas, people can see that, for instance, your code is easier to fix six months later.

Leadership/Quality

A good book on about leading change in organizations is "Fearless Change" here is a link to the book on Amazon. There is also a page here on the wiki Short Summary Of Change Patterns

Leaders need to set the bar, many people are not self-motivated to reach a high level

Often there is not enough concentrated pain in the current ways to put the focus on quality

Most of the time people work at one place with no consequence of failure, makes people feel a high level of quality in their own work does not have any consequences to themselves either way-hold people responsible for their own work, make them accountable for the quality of what they produce.

One way to encourage passion in the overall quality of a product is to have the development team get to know the users- people naturally have empathy, and seeing the problems their work is causing or the benefits it is bringing the users can help developers understand that the quality of their work has a real consequences to real people.