Skill Frameworks, Maker’s Schedule, Ship/Show/Ask reviews💡

Monday 3-2-1 — Edition 47

Hey, Luca here! Welcome to the Monday 3-2-1 ✨

Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.

You will also receive the regular long-form one on Thursday, like the last one:

• How I Write and Grow Refactoring in 2023 ✏️

To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!

p.s. you can learn more about the benefits of the paid plan here.

---

---

💻 New Relic

I have used New Relic at my startup for years, and it’s been the cornerstone of our observability stack. I am happy to promote it today in the newsletter 👇

New Relic has the most generous free tier in the industry — you get, for free, the same cloud-based observability used by some of the best software teams in the world:

• 👤 One full platform user — with the ability to visualize, analyze, and troubleshoot your entire stack and access to all 30+ platform capabilities, such as APM with distributed tracing, infrastructure monitoring, error tracking, log management, serverless monitoring, AIOps, and more.

• 👥 Unlimited basic users — with access to data ingest, querying, dashboards, and alerts.

• 💽 100 GB data ingest — per month, including New Relic Vulnerability Management.

• 🕰️ Data retention — of at least 8 days.

• 🥷 Logs obfuscation — automatically masks known credit card and Social Security number patterns in logs.

• 🩺 Unlimited ping monitors — and 500 synthetic checks / month.

• 💳 No credit card — to get started.

Back to this week’s ideas 👇

---

1) 🪜 Developing an Engineering Skill Framework

A couple of weeks ago I interviewed Andy Scheff, CTO and Founder at Practica, in a community event.

Andy and his team recently created an industry-standard framework for the skills and careers of software engineers. They built it using input from successful companies like Square, Dropbox, Kickstarter, Etsy, and more.

Here is the full video interview 👇

During the chat we talked extensively about such frameworks, how to create them, roll them out, keep them updated, the role of coaching in engineering, and more!

We are going to run more of these events in the future, held as interviews + live Q&A with community members. If you like them and want to join, you can subscribe to the full version of Refactoring to get access to the community! 🤗

I also wrote about career frameworks myself, in a recent Refactoring article 👇

Career Frameworks — Part 1 🪜

---

2) ⚖️ Maker’s Schedule / Manager’s Schedule

My favorite Paul Graham essay is probably Maker's schedule, Manager's schedule. In it, he explains the radical difference between the two types of work:

• 🔨 As a Maker — you benefit from long, uninterrupted streaks of time where you do your focus work.

• 👔 As a Manager — your schedule is run by meetings and interactions where you make decisions that drive the work of your team forward.

This difference is experienced sometimes brutally by folks who move from IC to management roles. These schedules, in fact, are not only very different — they are incompatible.

As a Manager, you won't ever benefit again from such streaks of focus time to do your maker work. Likewise, as a Maker, you shouldn't be bothered with too many meetings, because that would come at the expense of your productivity.

I wrote more about the duties and skills of managers and engineers in a previous Refactoring article 👇

How Technical Should Managers Be? 🧑‍💻

---

3) Ship / Show / Ask 🚢

Should code reviews be always blocking and mandatory? 🤔

If reviews are for 1) improving quality, and 2) sharing knowledge, do all changes have room for improvement, or bring new knowledge to share?

I am a fan of the Ship/Show/Ask framework, by Rouan Wilsenach, which considers three cases 👇

1) 🚢 Ship

You make the change directly on your mainline, without asking for a code review. This works when you fix unremarkable bugs, add features using established patterns, or do collateral changes like improving docs.

2) 🔍 Show

You create a PR, run CI, merge it without anyone’s approval, and then ask for feedback. This way you deploy quickly but still create space for discussion.

It works when you want to share knowledge but don’t need much feedback, or the feedback may not be blocking.

3) ❓ Ask

You make changes to a branch, open a PR and wait for the review before merging. This is the standard process most companies adopt nowadays.

This framework is about choosing every time what is the best strategy, based on the type of change you are making. It encourages active reflection instead of adopting always the same pattern.

In my professional life I have pretty much always worked in Ask mode. I am not comfortable with Ship mode unless we are talking of really small, negligible changes. However, I see how the Show pattern is a good way to get the best of both worlds in many scenarios.

You can find more ideas about good code review processes in this Refactoring article:

Code Reviews 🔍

---

💻 Typo

Last week we talked about Typo, which is a smart tool to help engineering teams code better, deploy faster, and stay aligned with their goals.

If you missed it, as a Refactoring reader, you can still get 30% off any Typo plan 👇

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.

2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

I wish you a great week! ☀️

Luca