.NET
Stop Using the Worst Way to Loop Lists in .NET! (via Nick Chapsas)
- The test conditions are to create 1M random numbers stored as strings (to prevent optimization with integers) in a List<string>.
- The loops tested: for, foreach, List<T>.ForEach(), while, do-while, goto.
- All options except .ForEach() are about the same for CPU and allocate no memory. .ForEach() is 4 times slower and allocates some memory.
- An even faster way is to do CollectionsMarshal.AsSpan(). Warning: This is effectively a copy of the list, so any changes that happen to the list during enumeration will not be in the span. This approach is about twice as fast as the other loops.
Forget Grafana And Prometheus! Start With This. (via Nick Chapsas)
- Nick believes this is a good tool if you’re getting started with OpenTelemetry. For C# projects, this is configured in the Program.cs file.
- There are other tools — Grafana, Prometheus, Datadog — but they tend to be expensive and tricky to get running.
- The dashboard comes from .NET Aspire. You run this from Docker.
Conflict
4 Common Types of Team Conflict — and How to Resolve Them (via HBR)
- Conflict surrounds one individual. Don’t just dismiss, because alternate viewpoints increases divergent thinking. For major friction, intervene 1:1 and in private.
- Two people within a team disagree (i.e., dyadic). If problematic, use mediation (in private) and consider if they need to be on the same team. Small debates can be healthy for the team.
- Two subgroups in the team disagree. This ends up being “us vs. them,” and even voting doesn’t make people feel any better. Instead break the deadlock by introducing new ideas or goals to come up with a solution both sides can support.
- The whole team is in disagreement. Reaffirm the common goals and team identity. Address poor performance collectively without blaming individuals.
Estimation
#1 Reason Your Projects Are Late (via Mountain Goat Software)
- Reasons initial estimates are wrong
- Products evolve — the longer it takes to go from learning their needs to delivering them, the more those needs will evolve
- Emergent requirements — features no one would have thought of until they experienced the partial product or system
- All teams overlook some requirements
- Some objectives are harder than expected to achieve
- Accounting for product unknowns
- Realize team members will not think of everything.
- Inform stakeholders about the realities of unknowns.
- Avoid making promises without a buffer.
- The author proposes having the team provide a percentage of the ultimate solution they things they see — e.g., 50%, 80%. Examples: If 50% is known, then double (1 / .5) the current size. If 80% is known, then it’s 1.25 (1 / .8) the current size.
- Problem: This calculation’s fundamental tenant is that the team knows what that percentage is. In the first part of the article the author says we can’t think of everything, so how would the team know how far along they are to an unknowable destination?
Productivity
A Useful Productivity Measure? (via LinkedIn)
This article describes how one VP of Engineering was asked about this metric and how to improve it. The author references the original post that software productivity is unmeasurable. There are several other measures that could factor in — actual ROI, estimated ROI, and value-add capacity — but those may not be accurate, or are amalgamations of other metrics that the engineering org has no control over (e.g., an valuable feature sold poorly). The article mentions the TPS muda concept (i.e., waste) and that it’s valuable to know what kinds of that you have in your organization. I also enjoyed the quotation: “Turns out leadership teams like accountability more when it’s other people who have to be accountable.” The last sentence summarizes a productive engineering org: “Deliver valuable software. Do it often. And write it well.”