If you only read one thingOur CTO and co-founder on how to scale a start-up (24 minute read) The most important article for some time. âIn principle terms, you should prioritise shipping the most important thing as fast as possible over optimising the total number of features shipped.â Oh, what simple sentences, oh how hard it is to follow. I call the second watering can principle. Everyone gets a little bit of the watering and no one is happy. Prioritising the most important thing means saying no to many other things. And weak CEOs and CTOs are not very good at saying no. So they prioritise wrong: A, then B, then C, instead of only A, nothing else. So we end up with the need to optimise the total number of features shipped instead of shipping the most important thing. Many other great nuggets in the article. âWe should all make decisions faster.â YES! Donât take three months to decide what to build, then be unhappy if it can be build in a week. Decide faster! How decide what to build? Have a long term vision, and then make incremental progress towards that vision." - most founders confuse their idea for the startup with a vision, itâs not. And then they donât have a vision, and again we donât know what to build, so we build the stuff from people who shout the loudest or cook OKRs best. Plus âDetermine the ideal first, ignoring all constraints such as money or timeâ. I often tell people, if you had a genie in a lamp, would your customers really ask for this? Wouldnât they ask for something different? This is what your customers want. Try to make it happen. And finally âIf you can optimise revenue without building new features, you should do thatâ I see startups left and right that have bad sales departments that can only sell things with new features - free software development - or with features customers demanded. Make money without new features! Donât âsellâ free software development. https://griffin.com/blog/scaling-a-startup
Stories Iâve enjoyed this weekHow Shape Up enables Remote Empowered Product Teams (and Why I Disagree with Marty Cagan) (5 minute read) There has been a lot of talk about âAgile is deadâ for years now. But nothing new has materialized. Perhaps Scrum is good enough. Perhaps there is nothing better. Personally I do think âShape Upâ is the better process. This excellent article argues itâs a better fit for Remote. Should I ever start as a CTO again, Iâd choose Shape Up not Scrumban. https://www.v01.io/posts/2024-shape-up-remote-empowered-product-teams/ Google Uses AI to Discover 20-Year-Old Software Bug (18 minute read) âRecently, OSS-Fuzz reported 26 new vulnerabilities to open source project maintainers, [âŚ] each was found with AI, using AI-generated and enhanced fuzz targets.â I personally have high hopes on AI finding and fixing bugs. I started a small Github project to compare AI IDE abilities. One of them is to find bugs. I do believe, AIs will be able to find and fix most of the bugs in your codebase, drawing requirements in from their deep knowledge and not just your company. https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html đ Why Polyworking Is The Future Of Work And How To Become A Polyworker (15 minute read) Havenât heard of polyworking? Polyworking is just a nice term for having two jobs. Some years ago I encountered people in our startup that had two full paying jobs. We had to let them go. I wonder how many more people in the age of remote have two jobs - or are âpolyworkersâ. âHow Companies Benefit From Polyworkingâ not so sure about that one. Let Them Fail or The Art of Delegating (8 minute read) âThe second issue is that no one really learns by watching. They learn by doingâ Donât tell, let people learn by doing and help them along. One of the big problems with delegation, people do not invest enough time to delegate. For them delegation is throwing something over the fence and then being unhappy what comes back. âAt the end of the day, I hired these engineers believing in their promise, itâs high time I trust them to do their job.â Indeed. Companies claiming to hire the best and then not trusting them to do their job. Are you one of those people? I hope not. Probably not as you read this newsletter ;-) https://www.codingrequired.com/post/let-them-fail đ Elon Muskâs Engineering Principles â The 5 Step Process (12 minute read) Some good points in there. âItâs particularly dangerous, if a smart person gave you the requirements, because you might not question them enough.â The five steps are:
https://www.christianscheb.de/archives/893 Weekends were a mistake says Infosys co-founder Narayama Murthy (10 minute read) There are many studies that show that knowledge worker productivity peaks at ~35 hours per week. If they are forced to work much more, productivity will drop the following weeks. Still, startup founders and tech giants push for longer working hours. Yes, if you only sit in meetings and had no creative thought for the last decade, 80 hour work weeks are no problem. If you need to write creative code and not make bugs along the way, like type a long novel without a typo, 35 hours is the limit. When I worked much more, half of the time I had to fix bugs I did create the previous day. âWeekends were a mistakeâ said the Pharaoh. https://www.theregister.com/2024/11/18/infosys_workaholic_founder/ Against best practices (15 minute read) The argument in the article against best practices is that you need the context and a judgement. And I would agree. "âDonât use globalsâ is obviously good, but ânever use globals under any circumstancesâ is just silly." Judgement is what you pay the senior developer for, not for applying best practices. Which brings us to AI. The problem with AI today (will go away) is that you need to understand the results and judge them. If youâre a senior, great. If youâre a junior, itâs like best practices, you follow the AI because you have no handle to make a judgement. Iâm for standards, in the way they reduce the things that are open for discussion at all time (the reason why we have processes). But too many organizations I have seen no longer know why they follow some process or follow some âbest practiceâ. With turnover in your startup, Iâd bet half of your developers donât know the reason why things are done the way they are done. Explain more. https://www.arp242.net/best-practices.html Fast and Lossless BitNet b1.58 Inference on CPUs (8 minute read) So there researchers work on LLMs with 1bit quantization on CPU that are faster, use less memory and are more energy efficient. No longer is the world going to end because of AI energy consumption it seems. When you want to predict the future of some technology, it needs to have stabilized first. LLMs havenât. Otherwise, all bets are off. Thatâs why I like the philosopher Karl Popper. In his opinion the future canât be predicted from the past, as new things are invented. Steve Jobs is famous for targeting a market several years in the future. Which is hard, LLMs havenât stabilized yet. In Jobs days, the computer hasnât stabilized, and he had the vision of everyone having one. Thatâs why you are a visionary. If you only think of the next quarter you are not. If you only see what everyone sees, youâre not. Today startups target a market that exists next quarter. And then wonder why they donât become Apple. What tech are you targeting? https://arxiv.org/abs/2410.16144 How I use Erlang Hot Code Updates (8 minute read) Decades ago there was this exiting technology in Java called OSGi. It allowed you to hot swap code in production. But it never took off. Same here with Erlang. Both solve a problem, changing code in a mainframe while it is running that no longer existed with the rise of the internet and later the cloud. You just run dozens of servers and change their code one by one. Itâs also cleaner and has no long term side effects. So while there is exiting technology, and Iâm all for it, it often not useful. Developers though are drawn to it. Be careful. https://underjord.io/how-i-use-erlang-hot-code-updates.html How stress can disrupt memory and lead to anxiety (17 minute read) âResearchers have long known that stress or trauma can lead people to fear harmless situations.â Something I see with many CTOs. If things crash and burn, itâs their head that gets the beating. So they overreact and take fewer risks to the point of âNo, no, noâ. If you are aware of the psychology, you can work around it. https://www.nature.com/articles/d41586-024-03724-4 Swiss cheese model (10 minute read) Sometimes we can learn from other industries.
What is the Swiss cheese model of disasters? Itâs from airplane
security. When you have a slice of Swiss cheese, you can see through
the holes. If you hold up two slices, probability goes down that you can look through.
With a third slice probability goes down again. If there is a
chance that something goes through one hole, there is less
chance something goes through two slices - for that the holes
would need to align. Every process, checklist, 4-eye principle,
code review etc. is like a slice of Swiss cheese. The more you
have, the less likely is something gets through the holes. Take inspiration https://en.wikipedia.org/wiki/Swiss_cheese_model Youâre bored by all the off-the-shelf tech that is used by our developers? Thatâs not why youâre a tech geek? What I found most interesting over the last few years are âProbabilistic Data Structuresâ like Cuckoo Filters, Count-Min Sketch, Bloom Filters and the like. They enable you to store âStephan has seen this articleâ. Well I can store this in a database youâd say! Yes, the difference: 1. Probabilistic data structures use less memory - you can store billions of facts in a small amount of memory. 2. They are privacy-friendly - while you can ask them âHas Stephan seen this article?â they canât tell you which other articles Stephan has seen or give you a list of all people who have seen this article - privacy by design instead of privacy by law. And they are very, very cleverly done, which should pick the interest of the tech geek in you. They filled me with a sense of wonder. The book to read is: âProbabilistic Data Structures and Algorithms for Big Data Applicationsâ by Andrii Gakhov https://www.amazon.com/Probabilistic-Data-Structures-Algorithms-Applications/dp/3748190484 Join the CTO newsletter! | |
