January had a ton of good content and I'm excited to share the best of it with you all.
Dan Luu (@firstname.lastname@example.org) talks about why it's so hard to buy anything quality. Spoiler, it's due to market inefficiencies.
I've personally experienced this, buying software products from firms that are reputed to be best in class, yet unable to deliver their basic products working as they should. This has led to reversing the decision buy rather than build.
The other piece that resonated is something other author's I've read have touched on with the importance of trust. Trust is what actually enables organizations to move effectively.
Another from Dan Luu - courtesy of me following all the great links to his other articles while reading Why is it so hard to buy things that work well?
This one about the importance of culture, what the means, and what that does for organizations. Though if you're looking for examples of how to change it, this one doesn't have it. I think this is a must read for company leaders, because I believe firmly in people's performance being constrained by the system they are in, and culture is a huge part of that system.
This one was another branching link off of Why is it so hard to buy things that work well?. (If two other articles coming recommended based of it isn't endorsement enough, I don't know what is.)
People can read their manager's mind is about the difficulty experienced by most manager-employee relationships. Employees see any and all discrepancies between the behavior management says they want, and what they actually reward, and so they'll work towards what the organization actually rewards.
This is further complicated by the fact that most managers aren't self-aware enough about the discrepancy (present company likely included). The author goes on to state that that there are really only 3 ways to solve this:
- Have an employee willing to go against the grain and do the important but unrewarded work, until eventually it's rewarded.
- When a manager realizes that this is important and ought to be valued, not just paid lip-service to.
- A manager realizing they can't bring themself to value all important work, but work to align their goals and employee goals.
All of this seems easier said than done, but more managers being exposed to this seems like it would help reduce the amount of friction in organizations.
A followup was written here, that I also think is worth reading, but can be summarized as:
When I’m not able to get alignment with my stated goals I’m going to pretend the team is reading my mind, and that they are heeding my hidden thoughts rather than my words. From that mindset, what does that suggest about my own values?
In the words of the author:
The results aren’t likely to be flattering.
Becoming an Engineering Manager Can Make You Better At Life And Relationships
Charity is always worth reading, and this one is no exception. A canonical read for folks considering engineering management, why it's valuable, why it's challenging, and what you might be able to get out of it.
I found the section Why should you (or anyone) be a manager? an especially good summary of why you should consider engineering management if you're considering starting your own company as well. Things like:
It gets you closer to how the business operates, and gives you a view into how and why decisions get made that translate eventually into the work you do as an engineer
and some of the highlights in lessons you'd learn that make you better at life and relationships like:
- Sensitivity to power dynamics
- Hard conversations
- The art of being on the same side
These have all been lessons I've been learning, and continue to learn that help me as both a leader and a parent.
Measuring Developer Productivity: Real-World Examples
While not comprehensive, a really interesting survey of the state of engineering productivity metrics.
Like the author I'm surprised to see DORA and SPACES not used more, as those are the gold standard to me, but the section on LinkedIn also highlighted a few really interesting metrics that I'd like to instrument for my team, including the following:
Developer Build Time (P50 and P90) measures in seconds how long developers spend waiting for their builds to finish locally during development.
Post-Commit CI Speed (P50 and P90) measures how long it takes, in minutes, for each commit to get through the continuous integration (CI) pipeline.
Becoming Data Driven, From First Principles
This fantastic blog post by Cedric Chin on Commoncog goes over both the how and why to become data driven as an individual and organization. It also does this in a way that showcases how the how steps can lead you to creating a data driven culture, rather than having a handful of individuals in the organization that are data literate and care about using data.
Finally, it also explains some of the rationale between why the XmR chart is useful and the reasoning behind picking the limits imposed, which was something that was initially really confusing and offputting to me that the information wasn't centralized in one place.
Tidy First? - Kent Beck
Kent Beck is responsible for the proliferation of some of the more interesting ideas in software development, and Tidy First? is a great additional text I'd recommend for software folks, along side works that are usually recommended like The Pragmatic Programmer.
It moves between a concrete advice about how to improve code, such as:
- Using guard clauses
- Removing dead code
- New interfaces for old implementations ease migration,
Along with how to practice continuous integration with these little tidying.
Most interestingly it ties all this into how it's linked to the you, the business, and your peers.
Didn't end up getting around to any conf talks this month, despite queuing up many of them.
Unfortunately, similar story for podcasts.
A great thread from Jason Gorman (@email@example.com) on where he (and I) would advice new software engineers to look to get experience if they'd like to start their own company one day.