3 min read

Through the Stack / 01-08 (Week 12)

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.‌
Through the Stack / 01-08 (Week 12)
Photo by Christopher Burns / Unsplash

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 organisations. This publication is aimed at sharing thoughts and content that are relevant to such profiles.
If you have comments or content to suggest please reach out to us by email through-the-stack@imfiny.com .


As the main programming language at Imfiny is Ruby we tend to read a lot about Ruby. This week both while working with our clients and browsing through feeds we were reminded of the tedious (and sometimes risky) task of upgrading RubyOnRails applications.While sites like FastRuby.io publish some content specialised in this (https://www.fastruby.io/blog) regularly. There is a fresh post from Gelsey Torres in that blog specially targeting "the first Rails upgrade". While the  RubyOnRails guides contain a specific section on upgrading RubyOnRails, it's always good to hear about hands on experience with the process.

For those of view out there starting with Ruby, you can find great content to help you :

We (Imfiny) also publish content regularly in different places :

Engineering culture

The daily work of Staff engineers and Lead Tech people is also filled with management and working on the engineering culture. This week we enjoyed reading on this topic too.
As we are big fan of asynchronous communication our eye was caught by an interesting piece from Stepanie Emma Pfeffer on Toptal's blog : "The importance of written communication for engineering teams".
We often advise teams to get better automated testing suites for their services and products so Lev Yastrebov's article "8 automated testing best practices for a positive testing experience" was also quite interesting. It's a good reminder of why and how to test.
In the same manner we are involved with helping teams create or improve their on-call strategy. Molly Struve's post "How to fix a terrible on-call system" is a good food for thoughts on this. Molly Struve describes how their on-call system wasn't great, how they improved it and the result from the change. There are some great nuggets in there that will be helpful for anyone involved with on call duties and incident management.
We have all been involved in hackathons. Some startups make sure one happens in their company every year, at least. I have seen good and bad ones. It's often difficult to get started and find a good structure for it right away if you have never been involved in one.

Hackathons can be great to spin up new ideas and test out features quickly in the product for example, but how do you get that to happen ?One great example I remember is the hackathon I was part of at Lyst. They published, some time ago, a post on how they ran their first virtual one.

Anthony Meyer also shared is opinion and experience through a post on LeadDev : "Running your first internal hackathon".

Both are great reads and full of helpful tips.

Imfiny ?

This content is written and published by Imfiny, a consulting company based in France. We do Ruby software engineering and devops in the Cloud (AWS, GCP and others) as well as training and supporting teams in their journeys to grow code, infrastructure and practices (production engineering, incident management, retrospectives, ...).
We are available for 3 to 18 months contracts, contact us.

We have courses available on https://learn.imfiny.com/ .

Illustration by https://unsplash.com/@hendrikpeter