Amazing CTO Newsletter
by Stephan Schmidt
Happy ☀ Sunday,
This week’s insights
- 🍹 The retreat to comforting work and the impact on development
- ☁ Cloud Development Environments Tame Complexity By Reducing State
- 🥅 My take on why goal cascades are harmful and what to do instead
Good reading, have a nice Sunday afternoon ❤️ and until next week,
If you only read one thing
Reminiscing: the retreat to comforting work.
I do think Will is the most important thinker in software development, the Joel Spolsky of the 2020s. Another nugget with great insights here:
“Beyond snacking, which can be valuable when it helps you manage your energy levels, there is a similar pattern that happens when a business or individual goes through a difficult moment: under pressure, most people retreat to their area of highest perceived historical impact” (Also read all his books!)
Stories I’ve learned something this week
My take on why goal cascades are harmful and what to do instead
Excellent excellent article about finding goals. It adresses the point I often make, on how top down goals are often too specific.
Variability, Not Repetition, is the Key to Mastery
I’ve enjoyed this one as a weekend read. Often people argue mastery is from repetition. I haven’t thought about it yet, but thinking about it the article might be right, that mastery is from variability. My mastery of coding comes from writing code in 20+ programming languages. When I teached coding a long time ago, I did the same problem in several programming languages with the students. After the third time they saw the picture and said “Everything is the same, Python, C and Java”. Yes! You see the differences, then everything is the same, then you see the differences again.
For your hiring: Better codes might be those with more programming languages, not the one with 10 years of Python
Cloud Development Environments Tame Complexity By Reducing State
Are cloud development environments the next big things? The do decrease complexity and onboarding and setups are much faster. Kent Beck thinks “More important, I suspect, will be all the programs that folks will try writing because they are no longer afraid of wasting another 4 hours before giving up. One of those programs that wouldn’t have been started will turn out to be exceedingly valuable.”
Code Red: the Business Impact of Code Quality
My take on quality: Everyone is responsible and developers drive quality. As a CTO never compromise on quality (which is not gold plating) - “No shortcuts” is an engineering value I had to learn the hard way and which is with me for a long time now.
Good article, but never use the word “technical debt” outside of technology
If you want to read the paper the article is based upon, here it is.
Doing what you love when the money won’t follow
The article argues to do what you love even if money doesn’t follow. My advice to CTOs is do the things they love and structure their CTO job around it. And money will follow. Too often I see CTOs struggle with things they don’t like. Why not hire someone to do these things? A coachee loves R&D and is a genius. Why not make this am asset and hire a VP of Engineering to keep the department running while doing what he is good at and loving? “And so, the advice I would give to young people is this: structure your life so that you have the time and money to do what you love.” Amen. It took me 50 years to arrive at that point.
Ephemeral DB, a sacrificial database line for high-throughput data
Interesting concept, haven’t heard it articulated that way before, worth a read.
Phylum Discovers Dozens More PyPI Packages Attempting to Deliver W4SP Stealer in Ongoing Supply-Chain Attack
Formalizing our Engineering Principles
While I do endorse formalizing engineering principles, and the article makes some good points, I’d argue against “We decided to create a working group to discover and formalize Cash’s Engineering Principles” To me engineering principles need to come down from the top, from the CTO with input from all developers. Without that your side is often not reflected in them and top management loses interest. And their principles are leaving out important points. But I would be curious to listen in and see how these principles are followed.
Things your manager might not know
Your manager might not know some things, I’d argue most things. I always argue for managing up, for managing and helping your CEO. The article makes some great points “Here are the facts your manager might not know about you and your team […] What’s slowing the team down, How to help you get better at your job, What your goals are, What issues they should be escalating” Also: Explain to your direct reports that you don’t know things! I’ve experienced this to be a super power by saying “I might be wrong, tell me”
Events: Fat or Thin
I’ve been wondering about this for 20+ years and still have no answer. 20 years ago I wrote some articles about the domain of a shared bus, who ownes it?
On Feeling Competent
Read this and think about it as a reason why some people do not apply to your job offers. Change the job offers.
👻 All your old tech is haunted, actually
“You own a haunted bit of technology. I guarantee it.” 👻👻👻👻👻👻👻👻👻
WHAT IS CODE?|
Still a funny read. Thinking about developers and CTOs from a business perspective.
Layers of Change: How Buildings and Software are Alike
“In effect, you were buying a lot with a building to demolish. So it wasn’t a $500k house. It was a multi-million dollar and multi-year project.” Just like software.
The Most Important Partnership
I though it was only me! “One of the most common complaints I hear when coaching and advising tech executives is about Product.”