Monday 3-2-1 – stalled growth, staging vs prod, the cycles of docs 💡
Edition #30
Hey, Luca here 👋 and welcome to the Monday 3-2-1 ✨
Every Monday I 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:
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.
1) 🦥 Signs your growth has stalled
The tech space moves at crazy speed, and people know it.
Growing your skills and staying up to date isn’t only the right move for your career — it is a big source of motivation, too.
Mastery, defined as the desire to improve our craft, is one of the pillars of engagement at work:
Conversely, when your learning stalls, chances are you will also get progressively less and less engaged, in a vicious cycle that handicaps your growth.
How do you know that your learning is stalling? Here are a few signs:
This year looks suspiciously similar to last year 📅
Instead of thinking about your skills, which might be a bit of an abstract exercise, just think about what you did last year, compared to this one. How did you spend your time?
Sometimes, five years of experience is just the same year… five times over.
You can predict your emotional state 🩺
This is a great tip I learned from Aadil, former Technical Program Manager at Apple:
Has my learning stalled? How do you know this: you know precisely what time of the calendar year you will experience what kind of emotion. At Apple, by my 5th year, I knew when in the release cycle I was going to have extreme anxiety, slow work, sudden ramp up etc.
You are learning coping mechanisms rather than skills 🩹
This is taken again from this fantastic article by Cate.
All companies have quirks, sacred cows, and politics you may need to work around. Which is fine to some extent.
Just ask yourself how much effort you are spending on those. How much of what you do (tech, processes, practices) makes you proud? How much of that would be good and reusable in another job?
More ideas about signs you should quit your job 👇
2) 🔨 Most real-world staging envs are bad
For staging to be useful, it has to catch a special kind of issues that 1) would happen in production, but 2) wouldn’t happen on a developer's laptop.
What are these? Think of problems with data migrations, database load and queries, and other infra-related issues.
To make staging catch these, you need to keep it at parity with production on data and infrastructure. This is hard and expensive — think about it, if it wasn’t so, you would just spin dev environments that look like prod.
The whole point of having a single, shared environment for testing instead of many individual ones is that the latter would be too expensive to maintain 👇
The way I see it, fundamentally, this is a resources management problem. If I wouldn't be looking at costs the dev environments could be designed and made powerful enough to satisfy all needs.
— Alex Stoia, CTO at Innertrends
In my experience, however, most companies cut corners on this and end up with staging setups that look nothing like production. For example, they may hold a small fraction of the database, or run on totally different instances.
This defeats the purpose of staging and makes it unable to do its job.
More ideas about staging and release setups 👇
3) 📖 The two cycles of docs
In my experience, most companies have either a good workspace for docs, reasonably updated, where everyone contributes to, or basically no docs at all, or just very outdated ones.
There is hardly ever a middle ground.
Why is that? Because documentation naturally leads to either a virtuous or a vicious cycle.
When future value is higher than writing effort, you get a 🟢 virtuous cycle:
People write more docs because they feel they are valuable
Knowledge grows larger, more insights are discovered, and decisions are taken faster and better
People read more and more docs instead of having meetings
When future value is lower than writing effort, you get a 🔴 vicious cycle:
People stop writing docs because no one reads them
Docs become partial and outdated
People don't trust and read docs anymore
Writing docs is a bit like writing tests — people do it if the value of future use is perceived as superior to the writing effort. Wherever you stand on this, to improve you can either (or both):
Increase future use — by embedding them in processes, turning meetings into shared notes, etc.
Reduce writing effort — with processes, templates, and clear structure.
More ideas on writing good company docs 👇
📣 Join the Refactoring Talent Club
If you’re looking for a new gig, join to get personalized opportunities from hand-selected companies. You can join publicly or anonymously, and leave anytime.
The Talent Club launched just a couple of weeks ago and there are already 50+ candidates and 12 companies hiring remotely from there.
If you’re hiring, join the Refactoring Talent Club to start getting bi-monthly drops of world-class hand-curated Engineering people who are open to new opportunities.
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