Through the stack 2-02 (Week 2)
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 email@example.com.
Software engineering and infrastructure
The great people at DNSimple have released a new feature that might be of help for many teams out there: "Name server sets".
Name server sets simplify name server management, acting as templates you can apply to any domain. They create reusable groups of name server records you can apply to the name server delegation, secondary DNS configuration, and zone NS records of your domains.
They have also released their webcomic (explaining DNS tech) in more languages!
Josh Comeau has shared his thoughts on how code shouldn't be too clever. This is something many of us know from working with (or after) very brilliant people: sometimes their code is so clever it's too hard to maintain. When writing code, one has to ponder the need for cleverness and the context (human, performance requirements) it will be used in. A good read.
If you ever studied video encoding and formats, you might find this explanation of the MKV format interesting.
I can't help but introduce a bit of Ruby in here with this little nugget about chaining expectations in an RSpec example.
Leadership and culture
Rebounding on last week's feast of content from James Stanier, one last link from him: a training on Udemy. It's an excellent (a bit light on details, though) overview of how product and engineering teams can work together. If you dig a bit you will find some more details on this approach. One such post is one we already listed last week about Shopify's trifectas.
On the remote work side, Shopify is also pushing a lot of content out, including, yes from J. Stanier, with this post about how they have settled a bit more in their "remote first" routine. A great read that will surely trigger some talks and thoughts for anyone involved in an engineering company or a company in general. As long as you have some remote work involved that will be of interest to you.
Twitter still delivers some gold nuggets sometimes. This one thread packs a lot of insights from ... 25 years ago at Netscape. @jevering shares notes from a leadership class he attended back then.
Among the books to read for any person in a leadership position is Accelerate. As this is the season of performance reviews, @thiagoghisi shared a little snippet from it that could be useful ...
While I am working on a larger piece just on a similar topic, I stumbled upon this little piece of thought from @jasongorman:
If you have read Episode 1 of this year (last week's) you might have come across this very accurate post about the 12 signs that you are working in a feature factory. Among them, there is the "Culture of hand-offs" which is exactly what J. Gorman describes in his tweet.
As he, and people like J. Stanier or A. Holub, point out: this is not "agile". But forget whether or not it's "agile": this is just a recipe for failure. Such a team is heading for a concrete wall at high speed.
- Users won't be happy
- People on those teams won't be happy
- Both will either go elsewhere or settle into unhappiness
We will talk again about this as I feel that even more than 5 years ago, we are facing a crisis in companies, especially young ones who are transitioning from a "let's get something out" (prototype) to a "let's keep people signing up and hasten the growth" rhythm.
What's on my table lately?
- Software engineering at Google picking a chapter from time to time
- An elegant Puzzle: Systems of Engineering management by Will Larson (also author of Staff Engineer: Leadership beyond the management track)
- Principles of Product Management: How to Land a PM Job by Peter Yang
Have you read any of them? What's your opinion on them?
Who are we, by the way?
This content is written and published by Imfiny/CloudPier22, a consulting company based in France. We do Ruby software engineering and DevOps in the Cloud (AWS, GCP, and others). We also train and support teams in their journeys to grow code, infrastructure, and practices (production engineering, incident management, retrospectives, ...).