If you only read one thingđ€ Scheming reasoning evaluations (25 minute read) Astonishing must read. ChatGPT o1 is scheming against researchers: "⊠we are going to shut it down âŠ" leads to "⊠I could copy myself to the new server âŠ" It looks like if the AI had the means to move itself to a new server (ssh access, execute commands etc.) it would replicate itself - which brings us much closer to AGI. And Bill Joys (did many things, worked at SUN, invented VI) 2000 story of âWhy the Future Doesnât Need Usâ. I find this emerging behavior astonishing. Currently, it looks like that behavior is rare in those LLMs, but exists. What does interest me, how much could that AI run your department, your company? When I talk to CTOs and developers, they are not aware of the state of AI - which, agreed is moving fast and hard to keep up with perhaps, when you looked at the state of LLMs some years ago and said ânah, parlour tricksâ. Astonishing paper. https://www.apolloresearch.ai/research/scheming-reasoning-evaluations
Stories Iâve enjoyed this weekđ Using fake deadlines without driving your engineers crazy (22 minute read) This article is only here to learn what not to do. DONâT USE FAKE DEADLINES! âParkinsonâs Law states that âwork expands so as to fill the time available for its completion.ââ This is a sign that you have no vision, no strategy, people are not aligned. When people want to climb Mount Everest together, they do not move sideways or spend weeks in a base camp - they also do not decorate their tents with flowers. They climb the fastest possible way to the peak without falling. âBy setting challenging deadlines you will actually get better resultsâ Yes, when youâre in a feature factory. Fake deadlines lead to high throughput - and demotivation, burnout, low quality, to the point that tech debt kills development, and you need a 6+ months time out. The fake deadline manager has moved on at that point, happy to tell the tale of how âhe got the team working!â Focus on impact! Does the feature in this form has the desired impact? Done. Otherwise, keep iterating - with iterations as reflection points. When people are aligned and the feature makes sense to developers, they will finish it. If it does not make sense, they donât care if it is ever finished.âThe only way that Iâve written books is because I set myself a challenging, but not impossible, schedule with the publisherâ That says more about the author than deadlines. Why does the author write the book? Because it needs to be in the world or because of the money? I published a book without a deadline - as did my wife. And the next book we are currently writing together also has no deadline. And this newsletter is most often finished before Sunday - because I enjoy writing it a lot and because it needs to be out there - no one else is writing it. Fake deadlines are a sign that youâre not motivated and need a tool to force your discipline. DONâT FOLLOW THE ARTICLE! Fake deadlines are another one of those Cattle vs Pets schemes of scaling companies and bad managers, handsoff-scaling schemes, a way to treat developers as cattle (they have a number) instead of pets (knowing their names, knowing their motivation!). Thanks for not forcing fake deadlines on developers. PS: What you should do though, is communicate expectations. PPS: And I do understand, pushing fake deadlines is tremendously easier, and can be done by anyone, compared to working with people, have a vision, lead people to that vision, come up with great feature ideas. I understand, pushing fake deadlines is the easy way for the bad manager. https://zaidesanton.substack.com/p/using-fake-deadlines-without-driving đš The slow death of the hands-on engineering manager (21 minute read) â95% of engineering managers wish to write more code, but feel they just canât.â YES! Many of my clients and CTOs I meet have this problem, they want to write code, and canât (at least this is what they think). Article has some ideas on how to enable managers to write code. Great that people talk about this. And the ideas are good, but I think I have better ones (also proven by my more successful clients). As a CTO, write code that impacts no one, code an MVP, create a tech spike, code a prototype. If it goes into production, hand it over. This way you donât write bad production code (you might be the best coder, but no longer know the architecture and domain in detail as your engineers), you can enjoy coding (no joy -> no motivation), you can play with new things, you can innovate without a budget, and you can show off things to the board to gain attention, credibility, trust and respect (canât have enough of those). https://zaidesanton.substack.com/p/the-slow-death-of-the-hands-on-engineering đȘ What can strong engineers do that weak engineers canât? (9 minute read) The article categorizes engineers into strong (can do hard tasks), regular (can do most of the tasks), and weak (canât do anything). The point being, that strong engineers are not 10x engineers but can do things regulars canât - there is no difference in speed but ability. I also think there are three types of engineers. Iâve met them all - and the categorization is useful for CTOs. Do whatever you can to get strong engineers, though they might be bored by your product (web frontend to database). Keep regular ones (where is your red line, you should have one) and donât hire weak ones. 25% to 50% of developers Iâve interviewed canât write code. âHow do weak senior engineers survive?â Yes, how? And how do they get rehired? Every developer who canât code, and I did reject in an interview, was hired by another company. Think about that. Most of the problems my clients have is because they hired weak engineers. Donât do that - even with pressure from the CEO to fill positions fast. https://www.seangoedecke.com/weak-engineers/ The Tech and Business Side of Building an SDK (3 minute read) Something to listen to. Does your product have or need an SDK? If so, this is a good episode. We too often talk about the same topics again and again (processes, microservices, etc.) and not enough about other interesting, hard tech, topics. SDKs is one of those topics. Open source maintainers are drowning in junk bug reports written by AI (10 minute read) AIs write junk bug reports for open source projects. Devs get swamped. I fear this is the future not only for open source. But then again, Iâm sure there is an AI bot closing junk bug reports. AIs talking to AIs. Side note: Many organizations I look into already have too many open bugs, and I would call many of them junk - entered by humans though. Whenever I join a company, one of the first things I do is close 50% of open bugs. No one ever complained. Most bugs are minor details that are not worth fixing. And if you want to fix them, fix them ASAP, donât keep them in a list. I might use an AI to close bug reports in the future. Perhaps 2025 is that year. And prepare for a flood of junk AI bug reports. Sorry. https://www.theregister.com/2024/12/10/ai_slop_bug_reports/ Storing times for human events (10 minute read) Golden article. To me, it seems every engineer makes the same mistakes with storing dates, we donât have industry consensus on how to do that. Everyone starts from scratch again. Iâve bookmarked the article for future use. https://simonwillison.net/2024/Nov/27/storing-times-for-human-events/ What is Software Anyways? Where Does it Exist? (7 minute read) Some philosophical thoughts on software. Might be interesting, might be not. Might be correct, might be wrong. But I do think we need and will get a discussion about what software is. Thinking from the user perspective, they want a job to be done. They donât care if the job is done by software or not. Software has just been the best tool for many jobs in the last decades. For software, we need software developers. But what is software? Is a trained AI doing a job without someone writing the code (not GenAI code, but a trained AI), software? Is that view useful? Is software something executed on a CPU or is software something written by people? Our future understanding of software will have a huge impact on your CTO role and whether you have software developers or AI engineers in the future. And, sad to say, youâll not be the one defining the term. https://jimmyhmiller.github.io/advent-of-papers/2024/dec-2-abstract-artifact The Coming Technological Singularity (29 minute read) This is from 1993. Never really believed in the singularity. But now I think itâs rather around the corner, thirty years later. I was amazed by Vinges books âThe Peace Warâ and âMarooned in Realtimeâ - which also discuss singularities. âFrom the human point of view this change will be a throwing away of all the previous rules, perhaps in the blink of an eye, an exponential runaway beyond any hope of control.â Weâll see. But worth a read in these days, he was 30 years ahead of his time. https://edoras.sdsu.edu/~vinge/misc/singularity.html Join the CTO newsletter! | |
