Through the stack 1.20 (week 40)

This is "Through the Stack," a weekly list of links relating to topics relevant to Lead developers (actual or aspiring) working with an internet-related product.
Many lead developers, tech lead, and staff engineers have their hands in many projects and influence many layers in their organizations. This publication aims to share relevant thoughts and content to such profiles.
If you have comments or content to suggest, please reach out to us by email through-the-stack@imfiny.com.

This also published on our parent company's blog

This week ...

We have a few posts about estimates and Agile in general and management. We also have a mix of posts around software engineering. For once it's not just Ruby. It's about Leadership and Software engineering mostly.

Leadership

I have been talking with several people in my network about Agile and the concept of estimates. Often misunderstood by all parties it's a source of confusion and difficulties in many teams.

Readers of previous episodes will know that I tend to be in favor of #NoEstimates. Yet, I do try to always focus on what is the main issue with estimates: having people using estimates as synonymous with deadlines.

@rhein_wein published a tweet on the topic recently and there were quite a few answers to it.

On the same topic there Tech Lead Journal episode #106 with Jutta Eckstein was a great listen. While it is focused on yet another framework to organize work Jutta Eckstein does a great job at reframing the discussion to what matters the most with such an approach or any Agile approach.

More on the topic of management I stumbled upon an interesting read on LeadDev by Alex Mooney: "Managing underperformance in engineering teams".

Security

A security thread based on a piece of malware running on both Windows and Linux on different architectures has been coming up on the radar of many. While several sites took some shortcuts in the explanations, I've found Lumen's treatment of it to be a bit deeper than most.

Software engineering

A small but interesting article landed on my feed: "Want cleaner code? User the rule of six" by David Amos.

While it does cover the rule of six it also explains a few points in the same line as that rule. All of it revolves around keeping things simple yet the examples and references make it worth the read. For one there is a reference to The programmer's brain (F. Hermans) an interesting book that will help you understand what makes code readable from the perspective of the brain. You can hear the author talk about the book on Tech Lead Journal episode 61.

For the Rubyists: I have talked a few times recently about monads in Ruby with some friends. One solution often considered is relying on the dry-monads gem. An introduction article can be found in Human Readable magazine.

For those of us working with containers, two articles pocked my eye these days:

• Thinking like containers: yet another article on how to use containers. Handy for a team to discover containers.
• Kubernetes since day zero?: a take on when or not look at Kubernetes

Extra

If you are also recording and publishing audio you might be interested by the episode 398 of the Ruby on Rails podcast.

Readings

I have turned to audible to get through books or at least get a first overview of them. Thanks to it I have listened to two books by Tim Ferris: Tribe of Mentors and Tools of titans. I hesitated a time before purchasing them. The first was interesting but I was left wondering about a few of the pieces of advice. I will revisit later to pick the bits that really caught my ear. I already talked about them last week.

This week I finished the second one: Tools of Titans. I will have a second read to extract specifics. It was far more interesting than the first.

Who are we, by the way?

This content is written and published by Pier22, a consulting company based in France. We train and support teams in their journeys to grow code, infrastructure, and practices (production engineering, incident management, retrospectives, ...).

Check our landing page on how to book a call during our office hours, a multiday assessment of your current engineering culture and strategy, or discuss your custom needs.