Exercise: Super Epic Competition Score Board

Effective Python Chapter 1 Exercise

We have been tasked with creating a score board for the Super Epic Competition. All the work for scoring the competition is already done, and we will be given a list of users that are ordered by the place they took in the competition. We need to take that list and format and print out a score board according to the following spec:

The score board will print out all participants ordered by their place in the competition. There are a max of 8 participants per competition. Each line will have a single participant. On the left side we start with their rank, followed by their user name. If the user is part of a team (which can be determined by whether or not the user object has a team name field), then the team name should follow in parentheses. Both user name and team name have a max limit of 20 characters. On the right their score will be displayed. In this competition the score is a decimal number that can have any number of decimal places. On the score board this number will be formatted to two decimal places. Also note that is is possible for the list of users to be returned as empty, in which case the message "Awaiting Final Ranking" should be displayed. Here are a few examples of input and expected output:

Example 1

Input

[]

Expected Output

Awaiting Final Ranking

Example 2

Input

[
  {
    "user_name": "hamster dance",
    "score": 1337
  },
  {
    "user_name": "success kid",
    "team_name": "nerf herders",
    "score": 1200.333333
  },
  {
    "user_name": "rickroll",
    "team_name": "the fellowship",
    "score": 1051.4
  },
  {
    "user_name": "ArrowToTheKnee",
    "team_name": "nerf herders",
    "score": 999.99
  },
  {
    "user_name": "grumpy_cat",
    "team_name": "the fellowship",
    "score": 999.98
  },
  {
    "user_name": "anonymous",
    "score": 561.12
  },
  {
    "user_name": "lol cat",
    "team_name": "allz te lolz",
    "score": 98.0432
  },
  {
    "user_name": "awkward seal",
    "score": -20
  }
]

Expected Output

1 hamster dance                                   1337.00
2 success kid (nerf herders)                      1200.33
3 rickroll (the fellowship)                       1051.40
4 ArrowToTheKnee (nerf herders)                    999.99
5 grumpy_cat (the fellowship)                      999.98
6 anonymous                                        561.12
7 lol cat (allz te lolz)                            98.04
8 awkward seal                                     -20.00

The answer to this exercise can be found here.

The Developer Book Club System

Over the last year I've experimented with what it takes to make a successful book club experience for software developers, and while I imagine that there's still plenty to learn and improve upon, I've found that the following system and roles work fairly well when tackling a technical book.

The System

When reading a technical book as a group, a good general rule of thumb is to cover a chapter a week. These kinds of books tend to be fairly dense, and trying to cover any more than that can overwhelm members of the group. But note that this can vary on a case by case basis, where some chapters in a book can be very short and could be combined, and other chapters can be overly long, and need to be further broken down.

Additionally reading speeds will very from group to group and from topic to topic. So during the first few weeks of a new book, be sure to gauge the how well the group is keeping up with the pace, and either slow down or speed up accordingly. With this being the case, it will typically take 2 to 3 months to go through a book, varying from book to book.

Meeting regularly to discuss the book is important and valuable, and meeting weekly for about an hour is a good cadence. During this time it's useful have people discuss any points they found interesting from the book, share example code, have a presenter present a practice problem, which the group can then solve, mob programming style, and generally give opportunities for the group to experiment with what they read about. In addition, a facilitator may need a few minutes to address points with keeping the book club running smoothly, such as meeting times, reading schedules, next book, etc. We'll further discuss the facilitator and present roles in the following sections.

The Facilitator

The facilitator is there to keep things running smoothly. This includes a number of responsibilities, such as:

• Determining what book to read. This involves first determining a topic, which can come from polling the group about interests or from determining business needs, and then from there researching what books are available on the topic. Note that while some technical books age well, many do not simply because of the rapid pace of change in the industry.
• Setting a reading schedule. Again, a good rule of thumb is a chapter a week, but be sure to look through the book and take into consideration the people in your group when determining this. And this doesn't need to be set in stone. If after a week or two, you find that the current pace isn't working for people, change it. Also note that it can sometimes be worthwhile to schedule in some break time, such as around holidays or in between books.
• Arranging a time and place to meet. One hour once a week should suffice. Ideally in a setting that would encourage round table discussion instead of a lecture or presentation. As such, a room with a large table and many chairs surrounding it works better than a lecture hall with all seats facing a front stage. Additionally, it is useful to have a large TV or screen in the room and a method to allow anyone in the group to easily cast their laptop screen to it, such as using a Chromecast or similar device.
• Sending reminders about the meetup. People get busy and even with the best of intentions will forget about the meeting. Sending out a simple reminder the day of or the day before drastically improves turnout.
• Arranging presenters for each meetup. When first getting things up and running, it may make sense for the facilitator to also be the sole presenter, but over time it is worthwhile for the facilitator to encourage members of the group to volunteer taking turns being the presenter because it puts less of a load on the facilitator, gives the group the opportunity to more fully learn the material (those who learn the material best are those who teach it), and ensures the long term success of the meetup because it doesn't heavily depend on any one person. Note that it's still worthwhile for the facilitator to take his or her turn as the presenter, as well. You should make yourself available to the presenters to help them come up with ideas for their presentations, as needed. Additionally, as the facilitator it is worthwhile to have at least a few thoughts put together of what could be presented at each meetup so that you could step in and present if the scheduled presenter is unable to make it.
• Coordinate the hand off with the next facilitator. When first getting things up and running, it may make sense to have a single person be the facilitator over the course of many books, but over time it is worthwhile to encourage other members of the group to take a turn at being the facilitator. This ensures stability of the group, since it doesn't heavily rely on any one single person. The ideal time to switch facilitators is as you're finishing one book and preparing to start another.
• Get feedback from the group. Regularly check in with the group and see how things are going. Get feedback and make changes and adjustments based off of their suggestions. Ultimately every group is different, and it is always best to tailor the experience accordingly.

The Presenter

The presenter's job is to help the group get the most out of what they're learning by coming up with a practice problem for the group to tackle.

• Come up with a practice problem. As you're doing the reading for the upcoming meeting, take note of the points being taught and which of those points would make for good candidates to cover in a practice problem. Think of a problem that could cover the use of multiple points from the reading. Note that you don't need to exhaustively cover all points brought up in the reading. Just a handful will do. If the points that you would like to cover don't fit together nicely into a problem, then trying making two smaller problems. It's better to have two smaller practice problems than to try to shoehorn multiple unrelated elements into the same problem.
• Solve the practice problem once yourself before the meetup. This allows you to give some guidance on good ways to approach the problem as needed.
• Lead the discussion at the meetup. My suggested format is to start out with letting the group share points they found interesting from the reading, and/or share example code, then move in to tackling the practice problem via mob programming, followed by allowing the group to make suggestions of other things to test or experiment with in the code, and end with a few minutes for the facilitator to take care of any necessary points that need to be addressed.
• Present the practice problem in the meetup. I've found that taking a mob programming approach works well, where the presenter is at the keyboard and lets the group tell him or her what to type. In general, let the group guide the code, but feel free to give suggestions here and there.
• Invite further experimentation on the code. After the group has finished solving the practice problem, it is a perfect time to invite the group to give any suggestions of anything that they'd like to test out on the code that you now have up on screen. This give the group an opportunity to further experiment and play with the code and discover things that they didn't know.
• Publish a write up for the group to reference later. At minimum take the practice problem definition and the code generated from the mob programming session and publish the two in an article that the group can go back to and reference as need be. That being said, by all means feel free to take it further than that. Add explanations about how the code works or why to write the code the way that it is. Expand further on the problem. Show different ways that it could be solved. If you feel like it would be useful to the group, feel free to add it. And then publish it. While you could put it on an internal company wiki, I'd recommend against this unless it happens to contain private company information. Instead I'd recommend that the article be published as either a github gist, a medium.com article, a dev.to article, a blog post on your own personal blog, or any other public facing option. Why? Because it can prove useful in your future as a way to show a potential employer that you have knowledge of a topic.

Accelerate Review and Book Club Experience

The book Accelerate is a solid book on DevOps culture, with many valuable insights resulting from a careful study of its principles and thoughtful consideration of how those principles could be applied to your current job or situation. It is undoubtedly a book that I will return to again and again over the years.

With this book having a greater focus on culture over any specific technology or skill, the book club experience needed to be different from how I've handled previous books. Whereas with a technical book, the how is very clearly spelled out in the book, and what was most beneficial to the developers in the book club meeting was to provide them with a practice problem that would allow them to exercise what they've learned.

But in the case of a cultural book, like this, you are mainly supplied with guidelines and ideas, and the how for your particular company and situation has to be figured out. As such, the book club meeting time was best utilized by discussing the principles and determining how to apply them.

With this being the case, something that I was able to do to help these meetings to be more effective was to create bullet point summaries of the chapters that were to be discussed in the meetup, which then allowed for easy lookup and reference of these points for the discussion. Here are links to each of those summaries:

Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 16

In addition to these summaries, I also had an ebook copy of the book that I had pulled up on a large display during the meeting that would then allow me to turn to any reference that the group asked for at a moment's notice.

All in all, I do feel that this went well, but I think there may have been a missed opportunity. Because culture takes time to implement and change, over the weeks that we were reading the book we came up with potential ideas at a far faster rate than they could be applied, and as such we've (rightly) put our focus on just a few key ideas, but with the detrimental side affect that a number of the ideas that were either small or of less immediate importance have potentially been forgotten.

Something that I would like to experiment with the next time I take a group through a book on culture would be to maintain and update a list of ideas that have come out of each meetup, which would be kept roughly in what people deem to be the priority order. The idea would be that it would still allow you to first focus on a small subset of ideas that seem to be the most important, while also maintaining the list of ideas so that good ideas don't get forgotten.

Accelerate Chapter 16 Discussion Points

Chapter 16 of Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, shares the experiences of Steve Bell and Karen Whitley Bell applying DevOps and Lean practices at ING Netherlands:

• We must improve  the way we lead and manage IT and reimagine the way everyone across the enterprise views and engages with technology
• A high-performing management framework in practice
• You have to understand why, not just copy the behaviors
• We'll share with you the sights and sounds and experiences of a day at ING, showing you how practices, rhythms, and routines connect to creat a learning organization and deliver high performance and value
• Entering the main space there is a large, open social area designed to create intimate spaces to gather, visit, and share ideas
• After that is the Tribe's suite, where upon entering you'll see a large room with glass walls, creating visibility to the space within
• This is the Obeya room, and is where the Tribe lead's work, priorities, and action items are visualized for the teams and anyone else
• Management meets on a regular cadence here
• Four distinct zones are visualized:
• Strategic improvement
• Performance monitoring
• Portfolio roadmap
• Leadership actions
• Each has current information about targets, gaps, progress, and problems
• Color coding is used to make problems immediately visible
• Each IT objective ties directly, in measurable ways, to enterprise strategy
• Each line of business is organized as a tribe delivering a portfolio of related products and services
• Each tribe is comprised of multiple self-steering teams, called squads, each responsible for a distinct customer mission
• Each squad is guided by a product owner, led by an IT-area lead, and sized according to Bezos' Two Pizza Rule
• Most squads are cross-functional, consisting of engineers and marketers, collaborating as a single team with a shared understanding of customer value
• This team composition is referred to as BizDevOps
• New roles emerge as needed through experience and learning
• There are also chapters, comprised of members of the same discipline, who are matrixed across squads and bring specialized knowledge to promote learning and advancement among squad members
• There are centers of expertise, bringing together individuals with particular capabilities
• There are internal continuous improvement coaches
• The squad workspace is an open area with windows and walls that are covered in visuals that enable the squad to monitor performance in real time, see obstacles, status of improvements, and other information of value to the squad
• Squad visuals share some characteristics; the similarities in Obeya design enable colleagues outside the squad to immediately understand, at a glance, certain aspects of the work, promoting shared learning
• Standard guidelines include
• Visualizing goals
• Present performance and gaps
• New and escalated problems
• Demand
• WIP
• Done work
• Visualizing demand helps prioritize and keep the WIP load small
• Squads have daily stand-up meetings
• Follow a leaders-as-coaches model where everyone's job is to
• Do the work
• Improve the work
• Develop the people
• Develop the people is especially important in a technology domain, where automation is disrupting many technology jobs
• For people to bring their best to the work that may, in fact, eliminate their current job, they need complete faith that their leaders value them
• A fixed percentage of each squad's and chapter's time is allocated for improvement
• Squads think of improvement activities as just regular work
• Jannes' tribes had been challenged by senior leadership to be twice as effective. "There was a tough deadline and lots of pressure. Our tribe lead, Jannes, went to the squads and said, 'If the quality isn't there, don't release. I'll cover your back.' So, we felt we owned quality. That helped us to do the right things."
• Too often, quality is overshadowed by the pressure for speed. A courageous and supportive leader is crucial to help teams "slow down to speed up," providing them with the permission and safety to put quality first
• The coaching team is experimenting with, and measuring, ways to maintain the same high level of collaboration and learning among cross-border squads
• As a leader, you have to look at your own behaviors before you ask others to change
• When you change the way you work, you change the routines, you create a different culture
• Transforming your leadership, management, and team practices
• We are often asked by enterprise leaders:
• How do we change our culture?
• We believe better questions to ask are:
• How do we learn to learn?
• How do I learn?
• How can I make it safe for others to learn?
• How can I learn from and with them?
• How do we, together, establish new behaviors and new ways of thinking that build new habits, that cultivate our new culture?
• Where do we start?
• There is a willingness to experiment with new ways of thinking and working
• You can't "implement" culture change
• Implementation thinking (attempting to mimic another company's specific behavior and practices) is, by its very nature, counter to the essence of generative culture
• A high-performance culture is the development, through experimentation and learning guided by evidence, of a new way of working together that is situationally and culturally appropriate to each organization
• Develop and maintain the right mindset. This is about learning and how to create an environment for shared organizational learning-not about just doing the practices, and certainly not about employing tools. Make it your own. This means three things:
• Don't look to copy other enterprises on their methods and practices, or to implement an expert designed model. Study and learn from them, but then experiment and adapt to what works for you and your culture
• You, too, need to change your way of work. Lead by example. A generative culture starts with demonstrating new behaviors, not delegating them
• Change takes discipline and courage. Practice patience It's going to take time to change actions and thought patterns until they become new habits and, eventually, your new culture

Kotlin in Action Review and the Book Club Experience

If you are wanting to learn Kotlin, Kotlin in Action will give you a very solid foundation. While the book only covers Kotlin version 1.0 an as such is lacking many of the newer features of the language, the authors, Dmitry Jemerov and Svetlana Isakova, have such a breadth of understanding for the language that you'd be remiss not to read it. (This of course comes as no surprise, considering that they helped design and implement the language.)

I went through this book as part of a developer book club where I took a number of developers through the book along with me. As I went through this book I built out the following exercises to go along with some of the chapters to give the developers a chance to play around with the concepts that they were reading about. When we met to discuss the chapter, we would go through the exercises in a mob programming style, with me casting my laptop screen to a TV, and having the others in the group tell me what code to write to solve the problem, with me giving thoughts and suggestions here and there.

The developers in the book club were mostly all familiar with Java, so for chapters 3 through 6, the exercises that I built dealt with translating code from Java to Kotlin. These exercises went decently well:

Chapter 3: Exercises and Answers

Chapter 4: Exercises and Answers

Chapter 5: Exercises and Answers

Chapter 6: Exercises and Answers

For chapter 7 through 11, I changed strategies, and simply had a problem definition to solve without any code to translate. These went much better:

Chapter 7: Exercises and Answers

Chapter 8: Exercises and Answers

Chapter 9: Exercises and Answers

Chapter 10: Exercises and Answers

Chapter 11: Exercises and Answers

In addition to this, after finishing the book, I was asked present many of the concepts from the book in a series of trainings to a larger group of developers that were unfamiliar with the Kotlin language, along with some help from the other developers that were part of the book club. In addition to doing the training, I created the following outlines of the trainings so that attendees could have something to reference following the training:

Training Outline Part 1

Training Outline Part 2

All in all, I would say that this book club experience was very successful, with the participants getting a lot out of it and enjoying the process. I will look to reuse and build upon this experience as I help groups tackle technical books and topics moving forward.

Accelerate Chapter 11 Discussion Points

Chapter 11 of Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, covers leaders and managers:

• Transformational leadership
• Leadership has a powerful impact on results
• Being a leader isn't about having people report to you on an organizational chart
• It's about inspiring and motivating those around you
• A good leader affects a team's ability to deliver code, architect good systems, and apply Lean principles to how the team manages its work and develops products
• Transformational leadership is essential for:
• Establishing and supporting generative and high-trust cultural norms
• Creating technologies that enable developer productivity, reducing code deployment lead times and supporting more reliable infrastructures
• Supporting team experimentation and innovation, and creating and implementing better products faster
• Working across organizational silos to achieve strategic alignment
• Engaged leadership is essential for successful DevOps transformations
• Leaders have the authority and budget to
• Make the large-scale changes that are often needed
• Provide air cover when a transformation is underway
• Change the incentives of entire groups of technical professionals
• Leaders are those who set the tone of the organization and reinforce the desired cultural norms
• The five characteristics of a transformational leader are:
• Vision: Has a clear understanding of where the organization is going and where it should be in 5 years
• Inspirational communication: Communicates in a way that inspires and motivates, even in an uncertain or changing environment
• Intellectual stimulation: Challenges followers to think about problems in new ways
• Supportive leadership: Demonstrates care and consideration of followers' personal needs and feelings
• Personal recognition: Praises and acknowledges achievement of goals and improvements in work quality; personally compliments others when they do outstanding work
• What is transformational leadership?
• Transformational leadership means leaders inspiring and motivating followers to achieve higher performance by appealing to their values and sense of purpose, facilitating wide-scale organizational change
• Teams that report leadership in the bottom one-third of leadership strength are only half as likely to be high performers
• Transformational leadership is highly correlated with employee Net Promoter Score
• Leadership helps build great teams, great technology, and great organizations - but indirectly
• Transformational leaders act as an amplifier to the effectiveness of the technical and organization practices discussed thus far
• The role of managers
• We see that leaders play a critical role in any technology transformation
• When those leaders are managers, they may have an even bigger role in affecting change
• Managers play a critical role in connecting the strategic objectives of the business to the work their teams do
• Managers can do a lot to improve their team's performance by
• Creating a work environment where employees feel safe
• Investing in developing the capabilities of their people
• Removing obstacles to work
• Taking measures to make deployments less painful
• Making performance metrics visible and taking pains to align these with organizational goals
• Delegating more authority to their employees
• Knowledge is power, and you should give power to those who have the knowledge
• How can technology leaders invest in their teams?
• Ensure that existing resources are made available and accessible to everyone in the organization
• Create space and opportunities for learning and improving
• Establish a dedicated training budget and make sure people know about it. Also, give your staff the latitude to choose training that interests them. This training budget may include dedicated time during the day to make use of resources that already exist in the organization
• Encourage staff to attend technical conferences at least once a year and summarize what they learned for the entire team
• Set up internal hack days, where cross-functional teams can get together to work on a project
• Encourage teams to organize internal "yak days," where teams get together to work on technical debt. These are great events because technical debt is so rarely prioritized
• Hold regular internal DevOps mini-conferences. We've seen organizations achieve success using the classic DevOpsDays format, which combines pre-prepared talks with "open spaces" where participants self-organize to propose and facilitate their own sessions
• Give staff dedicated time, such as 20% time or several days after a release, to experiment with new tools and technologies
• Allocate budget and infrastructure for special projects
• Tips to improve culture and support your teams
• The most valuable work they can do is growing and supporting a strong organizational culture among those they serve: their teams
• Three things are highly correlated with software delivery performance and contribute to a strong team culture:
• Cross-functional collaboration
• A climate for learning
• Tools
• Enable cross-functional collaboration by:
• Building trust with your counterparts on other teams
• Encouraging practitioners to move between departments
• Actively seeking, encouraging, and rewarding work that facilitates collaboration
• Help create a climate of learning by:
• Creating a training budget and advocating for it internally
• Making it safe to fail
• Creating opportunities and spaces to share information
• Make effective use of tools:
• Make sure your team can choose their tools
• Make monitoring a priority

Accelerate Chapter 10 Discussion Points

Chapter 10 of Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, goes over employee satisfaction, identity, and engagement:

• People are at the heart of every technology transformation
• Employee loyalty
• To understand employee engagement in the context of DevOps, we look at it through the lens of a broadly used benchmark of customer loyalty: Net Promoter Score (NPS)
• High performers have better employee loyalty, as measured by employee Net Promoter Score (eNPS)
• Measuring NPS
• Net Promoter Score is calculated based on a single question:
• How likely is it that you would recommend our company/product/service to a friend or colleague?
• Net Promoter Score is scored on a 0-10 scale, and is categorized as follows:
• Customer who give a score of 9 or 10 are considered promoters
• Promoters create greater value for the company because they tend to buy more, cost less to acquire and retain, stay longer, and generate positive word of mouth
• Those giving a score of 7 or 8 are passives
• Passives are satisfied, but much less enthusiastic customers. They are less likely to provide referrals and more likely to defect if something better comes along
• Those giving a score from 0 to 6 are detractors
• Detractors are more expensive to acquire and retain, they defect faster, and can hurt the business through negative word of mouth
• In this study, two questions were asked to capture employee Net Promoter Score:
• Would you recommend your ORGANIZATION as a place to work to a friend or colleague?
• Would you recommend your TEAM as a place to work to a friend or colleague?
• Companies with highly engaged workers grew revenues two and a half times as much as those with low engagement levels
• Employee Net Promoter Score was highly correlated with:
• The extent to which the organization collects customer feedback and uses it to inform the design of products and features
• The ability of teams to visualize and understand the flow of products or features through development all the way to the customer
• The extent  to which employees identify with their organization's values and goals, and the effort they are willing to put in to make the organization successful
• NPS is calculated by subtracting the percentage of detractors from the percentage of promoters. For example, if 40% of employees are detractors and only 20% are promoters, the Net Promoter Score is -20%
• Changing organizational culture and identity
• People are an organization's greatest asset, yet so often they're treated like expendable resources
• When leaders invest in their people and enable them to do their best work, employees identify more strongly with the organization and are willing to go the extra mile to help it be successful
• In return, organizations get higher levels of performance and productivity
• To measure identity, people were measured on the following statements:
• I am glad I chose to work for this organization rather than another company
• I talk of this organization to my friends as a great company to work for
• I am willing to put in a great deal of effort beyond what is normally expected to help my organization be successful
• I find that my values and my organization's values are very similar
• In general, the people employed by my organization are working toward the same goal
• I feel that my organization cares about me
• In today's fast-moving and competitive world, the best thing you can do for your products, your company, and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it
• How does job satisfaction impact organizational performance?
• People do better work when they:
• Feel supported by their employers
• Have the tools and resources to do their work
• Feel their judgement is valued
• Better work results in higher software delivery performance and a higher level of organizational performance
• How does DevOps contribute to job satisfaction?
• Job satisfaction depends strongly on having the right tools and resources to do your work
• The measure of job satisfaction looks at a few key things:
• If you are satisfied in your work
• If you are given the tools and resources to do your work
• If your job makes good use of your skills and abilities
• The study found that good DevOps technical practices predict job satisfaction
• Automation matters because it gives over to computers the things that computers are good at: rote tasks that require no thinking
• This allows people to focus on the things they're good at:
• Weighing the evidence
• Thinking through problems
• Making decisions
• Being able to apply one's judgement and experience to challenging problems is a big part of what makes people satisfied with their work
• Diversity in tech - What our research found
• Diversity matters
• Research shows that teams with more diversity with regard to gender or underrepresented minorities
• Are smarter
• Achieve better team performance
• Achieve better business outcomes
• It is also important to note that diversity is not enough
• Teams and organizations must be inclusive
• An inclusive organization is one where "all organizational members feel welcome and valued for who they are and what they  'bring to the table'"
• Women in DevOps
• Women are drastically underrepresented in DevOps currently
• Underrepresented minorities in DevOps
• This group is also drastically underrepresented
• What other research tells us about diversity
• There is a great deal of research that links greater diversity to higher organizational performance
• What we can do
• It's up to all of us to prioritize diversity and promote inclusive environments