Two Lines of Code, Two Days of Headaches – Here's Why
Stephan ?? Schmidt
Building Inkmi only for CTOs ? #1 book "Amazing CTO" ? CTO Coach ? Keynote Speaker ? ex-eBay ? ex-ImmoScout ? Helping CTOs accelerate
?
?? Subscribe here?for emails every Sunday - Get it FIRST
by Stephan Schmidt
Happy ?? Sunday,
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 you only read one thing
A classic. Why did it take so long? Because?“the issue was reported with a vague description of how to recreate it.”?and?“Because the reported issue was related to functionality, I’m not familiar with”?and?“Because I took the time to investigate the real cause of the issue”?and?“Because I investigated if there were other ways of getting to the same problem”?and?“Because I took the time to verify if there were other parts of the code that might be affected in similar ways.”?and?“Because when I found the cause of the issue, I looked to find the simplest way of fixing it”?and?“Because I tested the change thoroughly”. Yes, dear CEO, I know you have no clue about software engineering, first thanks for asking, second that’s why I’m here.
Video of the week
Great talk, 1982 (!), many nuggets,?“We have a very bad tendency to base our plans for computers on the equipment we have inhouse and the things we’re doing now”?The biggest problem I see when I read tech visions of CTOs. Visions are for the future, the things ‘you will be doing,’ not the things you’re doing or going to do next quarter (that’s OKRs for you, not a vision). If you, the CTO, are not a tech visionary, who in the company can be one? Work on the vision, if you need help, I’m there?for you. Another one:?“One of the major difficulties is the difficulty of changing peoples minds”?Watch it.
??
Stories I’ve enjoyed this week
“A Kobayashi erupts immediately. The swift response starts with someone raising their hand virtually or otherwise and what they say or type immediately differentiates this situation from your unexpected daily developments. You think, but do not say, “Oh. Shit.””?Even better, I like the article because how it suggests implementing change. Go read it!
Everyone talked about this one.?It’s about a talk to founders, by AirBnB founder Brian Chesky (note: AirBnB did a lot of awful things, but this is another topic about VC money). Now me, what can I add? First, I’m a great admirer of Steve Jobs. As a founder (and CTO) you should run the company as he did (except perhaps be more polite). You decide what is a good product. You’re the visionary, not some product guy you’ve hired. Back to the article, founders get misleading advice because?“what they were being told was how to run a company you hadn’t founded”?But then, not everyone is Steve Jobs, even if they think they are. Founder mode needs excellent people, “manager mode” just needs average people. The mistake founders made when loving the talk they listened to. They thought they are Steve Jobs and feel vindicated (also to be frank, AirBnB isn’t the Steve-Jobs-era Apple either, neither is it Pixar or NeXT, it’s a private-hotel-website, sorry to digress again). But some nuggets,?““Skip-level” meetings will become the norm instead of a practice so unusual that there’s a name for it.”?I’ve heard about that idea the article talks about some years ago by one of the best CTOs there are, Christian von Hardenberg. If I recall correctly, in a talk at a CTO conference he said he doesn’t manage in layers. He jumps up and down the hierarchy, sometimes confusing engineers why the group CTO shows up in an architecture meeting. He shows up where he thinks he can contribute crucial things. Since then, I tell my clients about this mode. Now Paul Graham some years later writes about it.
Good tips how not to work asynchronously and remotely and what to do instead. No “Hello”, then waiting for attention, just ask the question, this gets rid of the handshake. Also:?CONTEXT!?What did you do, what did you expect to happen, what happened instead. No “quick call” (only when really necessary, like website down), “quick call” just tries to pull asynchronous interaction into a synchronous mode. It tries to safe your time at the expense of your coworker or report. And yes, don’t go to meetings without an agenda. Neither should your reports.
领英推荐
There was the Joel Test?https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/. Mucho important back in the days, then forgotten (sadly, as is Joel). I like the new engineering culture test. And the results of the survey! How do you score?
Don’t. No, don’t. Seen this over and over again,?“that your much anticipated launch will be greeted by a vast, echoey silence”, CTOs anticipating a wave that doesn’t come. And when it’s coming, always in surprising ways. Premature scaling not only costs time and money, it makes your app inflexible, complex and rigid. Then it will break if you need to pivot or adapt to the market. So,?don’t.
A destroyer crashed into another ship. The reason? A checkbox in a graphical UI wasn’t checked that coupled two ship drives. So the ship was unsteerable. $100M lost. Reminds me of that nuclear missle attack alarm UI, where the test button was next to the?real?button, and therefor a nuclear attack warning for Hawaii went out and people thought their lives would end because someone misclicked. UI!
One of the biggest mistakes from engineering managers and developers moving into the CTO role. You’re there to make things happen on your own, not ask permission. Once a CEO told me,?“Only ask my permission if your action could ruin the company”
What if the database was the OS? I’m still unconformable with that idea, but I have been raised that way as an engineer. Perhaps others will embrace the idea,?and it’s the future. Some of my clients do REST and GraphQL directly from Postgres.?Radical Simplicity?indeed.
Not that you need to hire a CTO. Or you might, in the form of a successor. But in the end, the article is interesting for how to get that next CTO job. Another nugget in a newsletter of nuggets,?“Increasingly (~15% of the time) we see CEO/founders looking to delegate all of product development to one executive who needs to be skilled balancing customer relationships and what needs to be built (prioritization) with how the product is built (engineering). The Chief Technology & Product Officer (CTPO)”?Many have tried, many have failed, I still believe it’s the way to go. So it seems does 15% of the market.
Many of my clients skip product market fit (PMF), then try grabbing money in opportunistic mode, run for more financing, waste money on marketing, fire people. Just to avoid working on PMF. PMF is hard, I get it. Working on PMF is hard work, slow progress, no grand features. Spending money on ad campaigns is more fun. Or going to startup events. Also people confuse PMF with traction (channel market fit). There are many frameworks for PMF, Superhuman used?“What if we take our product away from you?”?Work on PMF, don’t skip it, don’t work on the easy stuff. Don’t pivot.
Want to know what a ‘system prompt’ is? How it affects your interaction with every AI??There you go.
It’s important to have a mix of juniors and seniors. I see companies with too many seniors (one senior, ten juniors), and companies with too many seniors (where does the next wave come from when the seniors move on??)?So juniors are important?But ouch!?“Are juniors still available? For my experience interviewing, no they are not. Even when the organization wants to hire them, they are so below the bar that the organization has set for itself, that those juniors cannot be hired.”?I hire juniors: 1. They need to be able to code, I can’t teach them that (and they might not even be able to code with the best teaching, ever!) 2. They need to have joy and discipline (aka motivation) 3. They need to be able to own things and feel responsible. Those will grow fast and become excellent.
Want the newsletter one day early? ?? Free to your Inbox every Sunday???https://ctone.ws
?