Why you need a macro architecture - The CTO Newsletter
Stephan ?? Schmidt
CTO ⊕ AI Coach ? #1 book "Amazing CTO" ? Podcast Guest ? Keynote Speaker ? ex-eBay ? ex-ImmoScout ? Helping CTOs with everything - just ask!
Happy ?? Tuesday,
Welcome to my opinionated newsletter. This week’s insights
Good reading, have a nice Sunday ?? and a great week,
Stephan CTO-Coach and CTO-veteran
??
If y
Architecture is so difficult. Either CTOs don’t give guidance, or they give too much guidance. Either there are no architects and planned architecture, or they are micromanaging developers. The way out is a macro architecture. Enough guidance to make systems work, not too much guidance for developers to lose ownership and responsibility.
Yor inner nerd
This is the most amazing tech thing I’ve encountered the last weeks. You might know the “Game of Life” where the life of pixels depends on their neighbours. I wrote a Game of Life simulator in the 80s as a kid and watched patterns for hours. The Game of Life brings up patterns and blinking things and gliders that move across the matrix. The OTCA metapixel is a very complex game of life pattern, consisting of thousands of pixels, which acts just like one pixel, a meta pixel. It sends a train of spaceships around itself to detect the number of neighbouring pixels and then changes state depending on the number of alive neighbours. This is so amazing. And you can build an OCTA metapixel out of OCTA metapixels, and you have a meta-meta pixel. You can see the metapixel running here: https://oimo.io/works/life/. You can spot the train of spaceships running around the metapixel (clockwise). More explanations here https://blog.amandaghassaei.com/2020/05/01/the-recursive-universe/ This was for your inner nerd.
??
Stories I’ve enjoyed this week
The Doom Loop: Reduced Performance → Monitoring by Employer → Loss of Trust → Perform to Metrics → Reduced Performance. The Boom Loop: Engaged Employees → Focus on Outcomes → Flexibility → Increased Trust → Engaged Employees. Go for the Boom Loop.
You might be tempted to hire brilliant jerks. On rare occasions (very rare!) this makes sense. Mostly, don’t. They’ll disrupt the teams, make everyone miserable, leave broken code when they lose interest and can lead to rebellions amongst developers (Once a developer told me, “I will not work with that person anymore”—ouch). Read “The problems caused by brilliant jerks” and “Dealing with brilliant jerks”. And when to hire one.
On the distinction between the “innovation challenge” and the “execution challenge” in startups. Many startups I have seen, think they have an innovation challenge but have an execution challenge — you’re not doing rocket science! “Innovation challenges are rare. Most startups want to believe — or want their investors to believe — that they’re tackling these kinds of problems, but don’t believe the bullshit.” This misunderstanding often leads to the wrong decisions, sometimes for the systems chosen by the CTO. (It doesn’t mean you should not innovate, do it, push it!) What sometimes bothers me, is when a CEO tells people they are a tech company with innovative products, then 10 out of 80 people are developers. You’re not a tech company, obviously. Probably a marketing machine.
Changing code during an interview. In this case for memcached. Show them the tool and ask the candidate to add one feature. Make the developer log into a system with SSH and change the code (in a VM). This should make it much more difficult for the candidate to use ChatGPT. And it tests for code reading and understanding, something most interviews miss, although much of development work is reading your (old) code and other peoples code to form a plan what to do.
Kent Beck, one of the forgotten masters. A deep exploration of system design as an island. Interesting to read, not sure if the metaphor is stretched too much, but it is an interesting perspective. Given that many companies have self-emerging, chaotic system designs, every guidance is good in my book.
领英推荐
“Ah, but the audience booed the loudest at this statement: ‘I actually think that AI fundamentally makes us more human.’” Someone didn’t read the audience well, I guess. Is this the first backlash? Not that it matters, AI drives down costs so much, that nothing can stop it. But, for starters, people are booing (and others are destroying self-driving Waymo cars). This will get much uglier. And everyone is unprepared.
On one hand, I rewrite my Python scripts into Go, because I know Go and because it Go easier to execute, without libs and virtual environments. It might be easier if everything is in one language. Once in a large company, one small part was written in Ruby. The one Ruby developer out of dozens of developers leaves the company and the code has a bug. Me and another manager then tried to fix the code! On the other hand, some of the arguments go (ha!) away when you use ChatGPT to update and change the scripts—you don’t need to know Python then. The scripts for this newsletter are mostly written by ChatGPT.
Company is in a difficult situation, so we reorg. “New operating model aims to reduce hierarchies, eliminate bureaucracy and accelerate decision-making processes” But of course this will not work. There are no magic wonders. Too often I see this with CTOs, “if we do this, everything will change”, or CEOs, “if we release this feature, everything will change”. No, it won’t, and the reorg will not bring the benefits Bayer hopes for. Or needs.
I wonder if this is the future. Moving development to the cloud. More powerful compiler systems than your desktop. Logging in from wherever you are with whatever device you have. Faster onboarding of new developers. Easier interviewing. A friend of mine has been doing this for years. Is this for you? But I struggle with the concept, as I see downsides. Perhaps I need to run https://www.octobench.com to see Go compilation speeds in the cloud.
As I’ve said, there will be no more developers or software at all. The future is more like Star Trek with one software “We can get a report every single day, or you know, top of the hour that has something to do with a build plan, or some forecast, or some customer alert, or some bugs database or whatever it happens to be” A big data lake and an LLM that answers questions, send emails, by itself or on command. “What should we do to increase revenue?” “Upsell to our best customers.” “Make it so!” No code written.
“The Reitoff principle gives us permission to ‘write off’ a day and intentionally step away from achieving anything.” I stepped away from writing my book ( https://ctobook.dev ) and it felt great! Add nothing to your schedule works. And the world does not stop if you do. Too often CTOs think the world stops if they don’t hand hold everyone and everything all the time. It doesn’t (and if it does, you haven’t delegated enough). This most often comes to light, when CTOs want to go on a two-week vacation for the first time.
Prepare for incidents. It’s much easier to go into an incident prepared than unprepared (I know!) An interesting piece about silence in incidents “Silence can mean different things to different people in different situations. In this post, I’ll present a few incident scenarios and explore the role of the incident commander in breaking (or simply abiding in) dead air.”
This is the future lever of many companies for RTO (return to office) policies. You work remotely now, but if you don’t come back, you’ll not get promoted. And salaries. A company I’ve worked for used salaries and promotions every year to get employees to sign new contracts. You don’t sign the contract, you don’t get more money. Now RTO.
A long long text. With “The macro point that you started with is: programming isn’t just thinking; it’s thinking plus tactical activities like editing code.” to challenge the notion, that it is irrelevant to optimize some things, in this case typing. Though I don’t know, writing these lines, that I could write faster, because it is limited by my thinking. But who knows?!
No. But if you start, and you have only a few developers, go with a Monolith. Make it modular, each module responsible for something, like checkout, containing all database code and web UI code. Modules communicate with a message bus. A “Modulith.” This way you get the easy setup, debug, deployment benefits of a monolith with some benefits of microservices, like developers not getting in each other’s way. More details in the article.