Amazing CTO Newsletter
by Stephan Schmidt
Happy 🌞 Sunday,
This week only a small observation. In the past, I’ve already learned that no one knows Joel on Software anymore. A titan of practical software development insights 20 years ago, insights lost like tears in the rain. But this week DHH (inventor of Rails, huge impact with books like Rework ten years ago) released a new deployment tool called MRSK. And most comments on Hackernews: “Who is DHH?” Sigh. It’s like a physicist asking “Who is Einstein?”
This week insights
- 🦹 System design and the cost of architectural complexity
- 🤖 Understanding People Matters More Than Understanding Tech
- 💻 Directly Responsible Individuals
Good reading, have a nice Sunday ❤️ and a great week,
CTO-Coach and CTO-veteran
If you only read one thing
System design and the cost of architectural complexity
“Many modern systems are so large that no one truly understands how they work.”
Stories I’ve enjoyed this week
Understanding People Matters More Than Understanding Tech
Amen. “If there was only one piece of advice that I wish I had known early in my career as a software dev is that understanding people is more important than understanding tech, by a long shot.”
Directly Responsible Individuals
One of the problems every CTO I talk to has to some degree is: People don’t take the responsibility they should take. Have you tried DRIs? This is about projects but the same should be the case for quality, performance, etc. DRI is where you need to start, then with lots of experience, responsibility can be shared by a team. If you give responsibility to an inexperienced team, it’s like sending your kid to the Tour de France. Doomed to fail.
Self-Admitted Technical Debt
“Self-admitted technical debt (SATD) consists of annotations, left by developers as comments in the source code or elsewhere, as a reminder about pieces of software manifesting technical debt (TD), i.e., ’not being ready yet’” Do you have lots of FIXME in your code? As CTO, did you even look? If not, check now ;-)
One of the best podcasting apps you know is built by a single person
Our industry hasn’t reflected the changes in developer productivity from better tools, cloud, and SaaS services. It is astonishing what one person - or a small team - can do. Hire for quality, and keep your numbers small, as DHH the inventor of rails said “Small teams, small problems, large teams, large problems”.
Our production servers were suspended by Google Cloud
When I ask “Do you have BCDR (business continuity/disaster recovery) implemented?” I most often get the answer “We’re in the cloud”. Duh.
There’s a Good Chance You’ll Regret Quitting Your Job
Quite some of the CTOs I’ve met recently want to change jobs or quit executive work. Interesting take on the topic.
How I structure my teams for growth
Scale is one of the most important topics in a startup. I wonder why so few CTOs have a plan beyond vague ideas. I don’t agree with everything in this piece, but it’s a good read. With the eternal discussion of matrix vs. tree organizations (I prefer trees)
The Effective Decision
From Drucker. From 1967. And still, the biggest problem in startups having a bad decision process.