06 September 2018
GopherCon Denver 2018
On the first day, we attended a workshop titled Advanced Ultimate Go that was taught by Bill Kennedy from Ardan Labs and it was excellent. Not only is Bill incredibly knowledgeable with Golang (he has years of experience not only in Golang but also in C++) but he is also an extremely good teacher. I learned a lot in a single day and I would have loved to have this class extend for another day or even two.
Coming from a background of mainly Java for 20+ years, the Java community has an amazing piece of engineering in the JVM that handles most performance related concerns for us. We design Java classes however we please and we make use of any data structures we please and never really give it a second thought simply because the JVM handles all the real mechanics for us. With Golang, this is not the case. Although Golang has garbage collection (which is really nice, I hated using malloc() and free() in C) it's very different than what JVM does. Also, in many ways, the Go language is very succinct compared to Java. Both in terms of the amount of code you must write (Golang requires a lot less boilerplate code) to the ease of deployment with Golang (you have a single binary to deploy, no dependencies or CLASSPATH to manage). That being said, I'm still not sure that I would completely switch all web development away from Java to Golang. While the Golang learning curve is a lot easier than Scala, the issue I see are the implications on performance with the code you write. Whereas with Java, while there are performance concerns, as I said above the JVM handles a tremendous amount of things under the covers so that we don't have to care nearly as much.
Having spoken at many, many conferences over the years, I was very pleasantly surprised by the number of female attendees and speakers! I saw more talks delivered by women than I saw delivered by men which was excellent! The community seemed very open and engaging to everyone which I really liked. Being in the software industry for so long, it's still shocking to me how much of it is dominated by males. Anyway, I really enjoyed the cultural and gender diversity at Golang.
There is one minor change that I would like to suggest to the organizers of the Golang conference. Many years ago, I spoke at a conference in Denmark where I first saw this. On tables next to the doors at the back of a room where talks are taking place, there are big glass bowls with three piles of Post-It size paper, each pile a different color -- red, yellow and green. As attendees exit the room, they are asked to grab a single piece of paper in the color that represents how you felt about the presentation/talk. When the talk completes and the room is empty, the conference organizers gather the papers from the bowl, tally them up and provide the stats to the speaker. It's basically like a quick rating of what attendees thought of the talk. This small system does not replace the comment cards that organizers always ask of attendees because this is how attendees elaborate on they rated the talk the way they did. Both systems of rating are important because they deliver two different but equally important types of data to the organizers and the speakers. Anyway, this my two cents.
I really enjoyed GopherCon for a variety of reasons and I would love to attend again. Since the conference I have written a lot more Golang code and the more I write the more I like it. In my mind, Golang should be the goto language for systems programming, DevOps type stuff. While it can easily handle general web development tasks, I'm not sure yet if I would drop Java in favor of Go. I guess I need to keep coding away in both.
29 July 2018
Vacation and Hiking in Crested Butte
12 April 2018
Forming Scrum Teams
The tongue-in-cheek fable of the chicken and the pig is frequently referenced in Scrum literature to distinguish between people who are committed to the Scrum (the pigs) and people who are only involved (chickens). The reason pigs are committed is they must be sacrificed for the meal whereas chickens are simply involved. When I was software engineer, we used to say, 'It's just us pigs here' when it was a group of software engineers together. Having transitioned to management several years ago, now I say, 'It's just us chickens here.' But I digress.
The Agile Manifesto
- The highest priority is to satisfy the customer via early and continuous delivery of software
- Welcome changing requirements
- Deliver working software frequently with a preference to the shorter timescale
- Business people and developers must work together daily throughout the project
- Build projects around motivated individuals
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes promote sustainable development
- Continuous attention to technical excellence and good design enhances agility
- Simplicity is essential
- The best architectures, requirements, and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
While these 12 principles define much of Agile in the broadest sense, there are variations in different Agile methods such as XP, Scrum, Lean, Kanban, etc. These methods are not meant to be followed dogmatically, instead practices within a particular method are meant to be guidelines. In this post, I will be focused on Scrum, specifically on some of the aspects of team formation. But keep these principles in mind as you read this post.
What Does Scrum Recommend?
The Scrum literature discusses team formation a lot. From this literature, it's easy to learn that there are some key principles in Scrum focused around forming small, cross-functional teams. But Scrum best practices don't end there. There are many other aspects to building Scrum teams. In this post, I will elaborate on the following:
- Autonomous and self-organizing
- Team composition must be cross-functional
- Ideal team size
Autonomous and Self-Organizing
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I work very hard to build trust with my engineering teams as I believe this is the basis for building great teams. I always say that I hire talented individuals who are experts and then I give them room to get the job done. The bottom line is the team is accountable for delivering value every sprint and I have found that building trust is a requirement. I extend trust to them to get the job done and they teach me to trust them by consistently delivering value every sprint.
Team Composition Must Be Cross-Functional
- Scrum Master
- Product Owner
- Front end engineers (developers)
- Back end engineers (developers)
- DevOps engineers (developers)
- QA engineers (developers)
- Tech writer (developers)
- Manager
Tech writer: I include a tech writer in my teams whenever I can because I do not consider the product to be Done until everything is actually done including the coding, testing, documentation, performance considerations and operational requirements.
Ideal Team Size
I have seen Scrum teams with three engineers and Scrum teams with 30 engineers. The goal should be to find an ideal size that works for the products being developed, but I do believe smaller teams are better. According to the experience of many Scrum practitioners, the ideal team size should be 6-8 engineers (give or take one or two) not to exceed 10. From my nearly 20 years of experience practicing Agile, the larger an engineering team grows, the more difficult it becomes to meet, to scope work, to keep track of work, etc. Basically, the larger the team the more complex and time consuming communication becomes. It's not called Agile for no reason -- software engineering teams practicing Scrum are meant to be nimble and iterate quickly. This cannot take place when too many people are involved.“Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them… This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.”
This is further elaborated by examining the lines of communication for teams of different sizes. As explained in a blog post titled, Lines of Communication and Team Size: Applying Brooks’ Law:
Most teams in large enterprises have between 10 and 20 members. Even at the low end of that scale, a team has so many lines of communication that progress is bound to be slow.
(source: Lighthouse) |
Note the increasing number of lines of communication as a team grows. This is essentially the root cause of why teams beyond the Scrum recommended size become more and more ineffective as they grow. The drag in trying to develop a shared understanding of anything simply becomes more and more complex the larger a team grows. This is typically when people start to complain about there being too much administrative overhead.
Conclusion
To summarize, if you want to set up your teams for success, then they must be autonomous, self-organizing, cross-functional and sized appropriately for the software being built. This is at least part of the recipe that has helped me to build what I mentioned above that Google calls effective teams.
Resources
23 March 2018
More Muscle Movement Discovered Recently
The anterior tibialis muscles are what allow you to flex your feet upwards (this is called dorsal flexion). So far, I have only been able to press my feet down (this is called plantar flexion) because this is controlled by the calf muscles. But now that the anterior tibialis muscles are moving ever so slightly, I can begin to rebuild these as well. Just like my calves are taking time, these muscles will also take time to rebuild as well.
I am still working to rebuild my calf muscles and this is slow. My physical therapist reminded me that I'm not just strengthening my calves. I literally had no calf muscles left. So I am rebuilding my calves from nothing which is much more difficult. She also said that at this point, we have no idea if the calves are fully firing or not. In situations where there is nerve damage, you never know if you are getting a full squeeze from the muscle or if the whole muscle is firing yet. This makes the work much, much more difficult. She also told me that this is why most people give up.
My calves are increasing in size and strength, but they are very far from 100% functionality or strength. I still have a long way to go. But I still feel lucky to be where I'm at today with my body still healing.
04 September 2017
New Braces and Hiking in Colorado
27 April 2017
Three Years After
Gratitude
As I look back at all the photos and videos Janene has taken over this three year period, read through the Caring Bridge posts and my blog posts, the progress I have made is pretty amazing to me. Believe it or not, I actually have a lot of gratitude for the fact that this experience happened to me. Yes, I just said that I am thankful for the experience. I did not arrive at this place easily or lightly, so stop and consider that statement for a moment. After three years of pondering every aspect of this entire situation, I feel that I am a better person for it in many ways. This whole experience forced me to get myself in order and I'm now a better person for it.From the beginning of this experience three years ago, I have been lucky enough to be surrounded by people who provided me a constant stream of positive support. From the folks I worked with at the hospitals to all of my family, friends and co-workers, the positive vibes are what have inspired me to keep going. There were also a couple of notable things that two people told me that I have hung on to that have kept me going to this day:
- My wife Janene has always taught our girls that no matter what you're doing in life, you need to 'fake it 'til you make it'. This catchphrase helps you to feel confident and optimistic about something until you gain the necessary experience to actually feel genuinely assured that you have reached a successful point. Although she has always intended this for the benefit of our daughters, I have been able to internalize it and use it to my own benefit in my recovery. Repeating this statement in my head has taken me quite far and I continue to use it to this day. Thank you so much, Janene. I love you!
- My friend Greg, who has had two spinal cord injuries in his life (can you believe that?!), told me something very early on in my journey, that I held in my head to help me get through the first year and beyond. He said something like, 'I know you you are not in a place where you can understand what this means yet, but you will get there in time. Just do everything you can to make it through the first year and everything will seem 1000% better. You won't be totally healed in one year, but you will feel much, much better.' Ironically, I saw Greg the week of my first year anniversary and I told him about this and he didn't even remember telling me this. I think he was quite surprised that I held on to it for so long, but it was truly a lifeline. Thank you, Greg.
Lesson Learned
I have learned a lot in three years as this experience has taught me a lot, especially the way that you handle an experience. Most importantly, I've learned that when you are faced with a horribly painful experience (emotionally, mentally, physically) that changes your life, you can choose to one of two paths:- Either, you can be angry, resistant, resentful and stuck on the fact that something was taken from you. I have met plenty of people on my journey who were here and until they change their outlook, they won't be able to move on.
- Or, you can acknowledge that it sucks but still feel gratitude for the positive aspects and for being able to be alive to experience it all. I haven't met any people who can say that they feel thankful for their experience with a spinal cord injury, but I have read about some. It was not easy for me to get to this point.
On that note, singer-songwriter Ryan Adams who I have listened to for years summarizes my whole point best in the following interview:
He says it best by summarizing it this way: Pain helps us learn who we really are.
Reminders Along the Journey
Just recently, one of my colleagues from our Munich, Germany headquarters visited my office in Boulder. I have not seen this guy in person since before the accident so he was really shocked to see me walking and to see how well I am doing now. He said he was so surprised because the last he heard from me I was still in the wheelchair (the look on his face was priceless!). It's moments like this one that remind me of how far I've come and continue to drive me forward.Thank you to everyone who has helped me in any way along this journey.