This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
So just a big smh so far for part 2 about having dedicated rooms for developers merging code. I have never (thankfully) experienced this level of merge disfunction. It’s a an obvious sign that the various pieces of Phoenix are way too tightly coupled (which I have experienced!). Loving the book btw. It’s TPP, but for developers.
Hi all - this is the first time I've been able to participate in the book club, and I apologize if others have made these points previously. The First Ideal reminds me of Dominica Degrandis's "Thief Unknown Dependencies" (https://twitter.com/dominicad/status/951569460908969984) from Making Work Visible. In the book she indicates how the chance for success is cut in half every time a new dependency is present. In TUP the lack of locality is presented as the need for changes to be coordinated across front- and back-end systems. The big miss I can think of is the centralization of network routing on to common services: Erik refers to this example when he explains the meaning of the word "complect" the first time toward the end of Part One. It makes me think about when "complected" and "tightly coupled" could be used interchangeably (and when they cannot).
Does anyone have a diagram of the system used in the book? Unikitti, Narwhal, Orca, Panther etc...
We have been using Azure DevOps since inception and its a fantastic tool, helping us at every step of our DevOps journey.
We are now scaling Azure DevOps to our whole enterprise, feel free to ask if you have any specific question(s) about AzD. @w0nders
every time there is discussion about DevOps tools, this is a good reminder 😉 https://www.youtube.com/watch?v=gsjCWrCUjNg
every time there is discussion about DevOps tools, this is a good reminder 😉 https://www.youtube.com/watch?v=gsjCWrCUjNg
@ansh.lalit i planning to implement Azr DevOps onprem, i think its optimal solution for MS develop stack
@ansh.lalit i planning to implement Azr DevOps onprem, i think its optimal solution for MS develop stack
We use ADO every day and it's great for what we need it to do. I like their CI/CD tools. A lot of their built in dashboards aren't that great though, and their REST API is a mess if you need to add some custom functionality or create your own dashboards. I've found it's generally easier to use OData and Power BI for that. One example is a board we used for mapping a value stream segment by measuring the amount of time different work items spent in a specific state. They have some examples if you explore the menu on the left in their docs: https://docs.microsoft.com/en-us/azure/devops/report/powerbi/odataquery-connect?view=azure-devops
We use ADO every day and it's great for what we need it to do. I like their CI/CD tools. A lot of their built in dashboards aren't that great though, and their REST API is a mess if you need to add some custom functionality or create your own dashboards. I've found it's generally easier to use OData and Power BI for that. One example is a board we used for mapping a value stream segment by measuring the amount of time different work items spent in a specific state. They have some examples if you explore the menu on the left in their docs: https://docs.microsoft.com/en-us/azure/devops/report/powerbi/odataquery-connect?view=azure-devops
For me joy comes from collaborating with others to solve problems. I think Maxine does this although she is hampered by the system. Flow comes from being able to focus on the work, which I find challenging in today’s always connected world. I find saying no to meetings and some invites is helpful in carving off time for focus and flow. I’ve also found pair programming to be conducive to these ideals. Pairing causes you to focus as you’re focused on the code with another person. So you’re less likely to check email or get sidetracked with slack, etc. the book “Joy Inc” Is a good case study in this.
Bringing focus, flow and joy is a little bit comparable to the Marie Kondo approach: eliminate what doesn't bring you joy and hapiness. In a business setting, I often sit down with the team to discuss points that are blocking them in their daily work. Most of the blocking issues can be resolved either by a member of the team or by a sponsor from the business which ensures flow is not interrupted. That's why a standup should be participated by all stakeholders, not just the "tech" folks. Another thing I learned is that transparency, how scary it might be, is actually beneficial for the joy of all those involved. People can see immediately positive results of their work and are notified immediately when things are not working out as planned resulting in quick team efforts to solve the issue.