Showing posts with label culture. Show all posts
Showing posts with label culture. Show all posts

The real cost of living, city to city

Mike's Notes

Got this from reading Vitaly Friedman (Smashing Mag) on LinkedIn. Will need to know what the cost of living is around the world. For contractors, staff, volunteers, interns, research grantees, etc.

Smashing Magazine is a fantastic resource for CSS, designing accessibility in web UX, design systems and much more. Has a ton of references to useful resources. I follow it daily to build Pipi UX so anyone can use it easily.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Smashing Magazine
  • Home > Handbook > 

Last Updated

10/06/2026

The real cost of living, city to city

By: Vitaly Friedman
LinkedIn: 03/06/2026

Vitaly is the founder and editor-in-chief of Smashing Magazine since 2006, an online magazine for designers and engineers, where he helps curate friendly, inclusive UX conferences (SmashingConfs).



Cost of Living and Quality of Life Comparison (https://cityparity.com), a lovely tool to decide if a move from one city to another is worth it — and compare cities against take-home pay, childcare, healthcare and social safety net. Designed to help answer one single question: "If I take this offer in another country, what salary do I need over there to keep my life roughly the same?"

1. Every City Can Be a “Perfect” City

Every city has its own advantages and disadvantages. Living in Europe, I sincerely appreciate the quality of healthcare and a social safety net. Of course it comes at a cost, but it doesn’t surprise me much that Scandinavian countries are happy to pay larger contributions to make sure that they don’t have to worry about anything — from kindergarten to hospital bills to recovery courses in case of accidents to retirement.

I’ve moved between 7 cities and countries in my life. And looking back, I keep thinking that for every period in life there is a “perfect” city — and that’s a city where you build strong and sincere relationships, where you meet incredible people, where you make memories and experiences for the entire lifetime.

It can be pretty much any city in the world. And usually it's just the one where you happen to be, and where life brings you to.

Really the perfect city is the one where you have incredible people around you, and where you can build relationships that will last your entire lif

2. Numbers Aren’t Everything

Of course numbers will tell you what you can afford, but not where you’ll love the vibe and the people. If anything, it’s always a good idea to travel and stay in a place for a while to really start feeling it. 

As time passes by, even within the same city you can find places to explore and get lost, but then also to relax and calm down, and then to build a family and spend time with children. Finances might matter significantly more in life early, but the chase for finances often fades away as we grow older.

And sometimes it might feel like just the right time to reshuffle things — and that’s a great opportunity to explore a very different city on the other side of the Earth. Even despite lower pay.

If you're looking for another quick tool to compare the quality of life between cities, you can also look up Numbeo (https://lnkd.in/e8yMXJFB), which is world's largest cost-of-living and quality-of-life database with millions of crowdsourced reports on living, housing, crime, healthcare, transport and other key indicators.

And if you already found a perfect place — please leave a comment and share where it is! I’d love to hear your story, and I’d love to learn just what place in the world makes you feel genuinely happy! 💚



I have been very lucky

Mike's Notes

A curious mix of chance and trying hard; who would have thought? I am very grateful to all those who helped me along the way.

I learn by the seat of my pants, making lots of mistakes, never repeating them. Being self-educated is great. So is listening, asking questions, reading print books, learning to use tools to make things, challenging every assumption, "strong opinions, weakly held", subject to change as factual evidence emerges via robust Science. We are all capable of doing this.

We are all smarter than we give ourselves credit for.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

09/08/2026

I have been very lucky

By: Mike Peters
On a Sandy Beach: 27/07/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I have been very lucky. I have had a lot of people in my life who were a good influence on me. (I get rid of anyone who sabotages or is a bad influence)

My grandmother Bessie showered me with attention and love, gave me endless things to pull apart to see how they worked, and took me to meet very clever people in a small-minded backwater town.

Family holidays in wild New Zealand, next to rivers, beaches, forests and mountains, which ignited a lifelong obsession with the patterns of nature, the why in my life.

My best friend right through school; he was the brightest kid in NZ.

My remedial "Cabbage Maths" teacher, Mrs Campbell, who took me from the bottom of a class to the top of the school with 98% by teaching me maths visually. That's when I learned the problem was not me; it was the way I was being taught, so from then on, I taught myself everything by reading 20 books a week, drawing notes, and having a go.

My high school science teacher, Mr Morgan, let me play in the chemistry lab, doing experiments after school unsupervised for several years, and taught me the scientific method on my very last day at school, the most important thing I learned in 12 wasted years.

The wise old tradesmen took a skinny kid from sweeping the floor to being able to make anything by learning on the job, trying hard, and having my butt kicked when I deserved it.

Nelson Mandela taught me to have the courage of my convictions and never give up.

The sculptor Neil Dawson and the set designer Tony Geddes taught me how to work authentically and in the flow.

My blind friend Grant, who made and gave away $60 M NZD, taught me, while he was cutting down bushes with a chainsaw, determination, quiet courage and human decency.

The magnificent 50,000 working people of South Christchurch, who trusted me to lead a volunteer residents' army doing recovery work for 3 years after the Christchurch Earthquake, teaching me humility, what honour is, and valuable leadership skills gained by trial and error in the moment.

My beloved Tracy, the bravest woman I have ever met, the only paraplegic to do the Coast-to-Coast Iron Man, who married an undomesticated autistic male and made me a much better man. Her unwavering devotion, encouragement and loyalty made all this possible.

They all shaped me; I can't thank them enough. May their memories be a blessing.

Demis Hassabis and DeepMind

Mike's Notes

Some useful background about Demis Hassabis, co-founder of DeepMind and a rare genius.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Turing Post
  • Home > Ajabbi Research > Library > Subscriptions > SemiAnalysis
  • Home > Handbook > 

Last Updated

07/08/2026

Demis Hassabis and DeepMind

By: Christian Dinar
The Next Web: 09/04/2026

Cristian Dina is the CRO at The Next Web. He has interviewed 300+ industry leaders and authored the book King of Networking, establishing himself as one of the most connected and respected voices in the ecosystem. At just 23 years old, Cristian was included in the Forbes 30 Under 30 2025 list, representing a new generation of tech builders, bold thinkers who move fast, build with purpose, and create real impact.

In short: Demis Hassabis, speaking on the 20VC podcast with Harry Stebbings in early April 2026, described how Google DeepMind has accelerated its pace over the past two to three years by merging Google Brain’s compute resources with DeepMind’s research culture and returning to what he called a “startup or entrepreneurial” way of working. He also disclosed that he runs Isomorphic Labs, the group’s pharmaceutical AI spinoff, as a “second workday” beginning around 10pm, ahead of expected human trials in oncology later this year.

Assembling the ingredients

Google DeepMind’s formal merger of DeepMind and Google Brain completed in 2023. Hassabis described the period since as one of deliberate acceleration: aligning talent “from around the company, sort of pushing in one direction,” gaining access to the compute infrastructure that DeepMind had previously lacked at scale, and driving what he called “relentless sort of focus and pace.” In his characterisation, the transformation required a cultural adjustment as much as a structural one: the organisation had to “come back to almost our startup or entrepreneurial roots and be scrappier, be faster, ship things really quickly.” The current competitive environment, he said, was “ferocious.” Veteran employees with careers of 20 and 30 years were telling him it was “the most intense environment they’ve ever seen, perhaps ever in the technology industry.”

Hassabis said he speaks to Sundar Pichai, Alphabet’s chief executive, “every day,” reflecting the degree to which Google DeepMind now operates at the operational centre of Alphabet’s product and research strategy. That proximity is matched by a capital commitment of corresponding scale. Google’s compute build-out, developed in part through its custom chip partnerships with companies including Broadcom, is central to that positioning: Alphabet spent $91.4 billion on capital expenditure in 2025 and has guided for between $175 billion and $185 billion in 2026, a near-doubling, with supply constraints rather than capital availability described as the primary limiting factor.

The 90% claim

One of Hassabis’s more assertive statements in the podcast concerned DeepMind’s contribution to the history of AI. He said approximately 90% of the breakthroughs underpinning the modern AI industry were produced by either Google Brain, Google Research, or DeepMind. The claim is broadly consistent with the academic record on foundational developments, including the transformer architecture produced by Google Brain in 2017, early work on reinforcement learning from human feedback, and deep reinforcement learning techniques developed at DeepMind. The 2024 Nobel Prize in Chemistry, awarded to Hassabis and John Jumper and shared with David Baker, for the AlphaFold protein-folding system is the most formally recognised of those achievements. Whether 90% is accurate as a proportion is a matter of interpretation, and the industry has pluralised substantially since those foundational papers. The framing functions as a positioning statement as much as a historical claim.

The operational consequence of that legacy is a product release cadence that has accelerated sharply. Google’s open-weight model programme, most recently Gemma 4, now releases models built from the same research and training infrastructure as Gemini 3, closing a gap between frontier research and open-source contributions that previously existed. Gemini reached approximately 750 million monthly active users by the end of the fourth quarter of 2025, with Gemini 3 described in secondary reporting as having prompted an urgent internal response at OpenAI on its release in November of that year.

The second workday

Alongside leading Google DeepMind, Hassabis also runs Isomorphic Labs, the pharmaceutical AI spinoff that DeepMind established in 2021. He described his working arrangement in the 20VC conversation: a first workday at DeepMind, followed by a “second workday” beginning around 10pm dedicated to Isomorphic’s drug discovery programme. The dual commitment reflects a conviction that applying AI to drug discovery is both Hassabis’s most important long-term ambition and a project that requires sustained personal involvement rather than delegation.

Isomorphic raised $600 million in April 2025 and has existing partnership agreements with Eli Lilly and Novartis with combined milestone values of up to $3 billion. In February 2026, the company released IsoDDE, a drug design tool that Isomorphic says doubles the accuracy of AlphaFold 3 for generating drug candidates. Human clinical trials in oncology are expected later in 2026. The competitive dynamics in AI-driven drug discovery are intensifying across the industry: Anthropic’s acquisition of Coefficient Bio for approximately $400 million in April 2026, a stealth startup founded by former Genentech computational biology researchers, signals that general-purpose AI companies are now treating pharmaceutical discovery as a product category, not merely a demonstration of model capability.

The competitive framing

The 20VC podcast conversation, like Sebastian Mallaby’s biography of Hassabis, “The Infinity Machine,” published on 31 March 2026 and based on more than 30 hours of interviews, presents a researcher who has moved into the most commercially urgent phase of his career with a consistent thesis: that the most important research and the most important products are not separate activities, and that the organisation capable of doing both simultaneously at frontier scale will determine the shape of the industry. The year 2025 consolidated AI as a central strategic priority across the technology industry, with capital, talent, and institutional structure all reorganised around the question of pace. For Hassabis, the answer has been to bring the speed of a startup inside the resource base of one of the world’s largest technology companies, and to treat that combination as a durable advantage.

The scale of the capital flowing into the field makes that advantage harder to sustain. SoftBank’s $40 billion bridge loan to OpenAI represents a form of capitalisation that even Alphabet’s compute commitments cannot trivially match in kind. Hassabis’s account of a “ferocious” competitive environment is not rhetorical: it is a structural description of a race in which the resources of incumbents and the ambitions of challengers have converged to a point where institutional inertia is not merely a disadvantage but a disqualifying one. The startup mentality he describes at Google DeepMind is, in that context, a necessity rather than a preference.

How I work effectively

Mike's Notes

I found it helpful to get this down on paper, so the process I use is conscious and can be tweaked over time.

This process has slowly evolved over many years since I was 15, when I started by grabbing non-fiction public library books off the shelves each week based on intuition. Practising this visual learning method, getting better over time and adding more steps seems to have worked a treat.

Most important is testing all assumptions.

I'm happy to receive suggestions or feedback on this.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

03/08/2026

How I work effectively

By: Mike Peters
On a Sandy Beach: 30/07/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

My creative problem-solving and build process is evolving, and the loop is getting faster.

  • Understanding the problem starts with reading or talking with someone, watching a YouTube talk, or listening to the radio.
  • Do lots of research, mostly reading books (days to months).
  • Cheap thought experiments. What ifs.
  • Drink plunger coffee.
  • Print off a paper(s) or article(s) and file it in an indexed A4 3-hole ring-binder.
  • Drink Chamomile tea.
  • Daydream (solutions come within hours or months later).
  • Drink plunger coffee.
  • Draw the solution as many colour-coded A4 architecture drawing(s).
  • Drink more coffee (Cappuccino).
  • File the drawing(s) with the printed paper.
  • Use the drawings to prompt Google Search AI Mode (free) with detailed instructions on what to build.
  • Output teaches me, describes data model, code, documentation.
  • Print off and file with the rest.
  • Walk a dog. Plant a tree. Watch the sun rise.
  • Read the printed AI output, colour-code, add doodles, correct, test, edit names, build, use in Pipi, while listening to music. (I don't copy-paste. I manually type to copy, because it helps me learn and understand.)
  • Throw away all the paper except for the original research, which is moved from DevOps to the research library.
  • Pipi then generates self-documentation, including mermaid drawings.
  • Repeat.

Each loop cycle takes weeks to years. There are hundreds of cycles running in parallel at any one time. It's a pull system. I work on Pipi when something needs to be solved using my library of solutions. Totally intuitive, like an artist, not an engineer, and always fun like a kid playing with Lego.

Another important part of this process is writing up notes for this blog. As a slow writer, I need to allocate a regular slot each day to do this using Grammarly. I find it reflective; it makes me think a lot. A bit like teaching someone else a skill you have.

It's becoming more important to have regular habits (an autism strength) and replace personal deadlines with going with the natural flow (artistic strength). It's more productive in the long run.

These changes are made possible because of the detailed work done over the last few months, removing barriers, including modifications to Pipi, reorganising space, equipment, and routines. It's also been made possible by the rapid advances in LLMs in 2026.

I think I have now solved all major problems to get Pipi 9 Core (Loki) running 24x7x52. Anything else that pops up can be quickly solved along the way as part of maintenance.

Output has gone up 100x. Now to execute very fast.

The luxury of statistics

Mike's Notes

A great article by David Court lays out a fundamental truth about the business of filmmaking.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Compton
  • Home > Handbook > 

Last Updated

08/05/2026

The luxury of statistics

By: David Court
Compton: 03/05/2026

Founder of Compton School, the business school for creative people: ‘The movie industry is a crucible where money and talent are refined down to their essence. It has so much to teach us about business, creativity and human nature.’

Why filmmakers can never see eye-to-eye with movie studios.

When filmmakers and studio executives come together there is always a great display of bonhomie.

Hands get shook and backs get slapped. As though they were bound together in their mutual enterprise: the movie business. Perhaps there’s some argy-bargy about profit shares but basically they are on the same page.

Yet the truth is: there is a fundamental disjunct between filmmaker and executive.


It’s not just that one is on salary while the other is eating their savings. Nor is it the power imbalance between them, or the different pathways they have followed to arrive where they are. It’s that one is operating at 30,000 feet and the other is dug in at ground level.

If you’re making a film, it occupies your entire field of view. You can’t see past it. You don’t have time or bandwidth to think about anyone else’s film. You are all in on one thing — the film you are making.

This is true financially too. You have put all your chips down on one square and you can’t take them back. Whereas the studio executive is managing a slate of films. They’ve got chips on 20 squares.

Harvard professor Mihir Desai calls this the core of finance. He starts his book The Wisdom of Finance with a story about chance and pattern. Chance is what the world looks like close up: an arena of luck, accidents, flukes, coincidences, or what the ancients called fortuna.

Whereas pattern is chance viewed over time – statistically. It’s what we notice when we study the world and keep records. It’s the view from 30,000 feet.

‘Finance, ultimately, is a set of tools for understanding how to address a risky, uncertain world’ – Mihir Desai

The study of patterns is what gave us the insurance business (the averaging of bad luck), portfolio theory in finance (strategic diversification) and the studio slate (the search for a hit). These are all methods of managing risk, of taming fortuna.

But our filmmaker has wandered into a casino and bet everything on single spin of the wheel. Their risk is irreducible. They don’t have the luxury of statistics.

So for all the backslapping, the studio executive and the filmmaker are really two different species. Different stakes, different aims, different view of the world.

For our filmmaker, chance is the whole point. The risk is not to be managed but to be taken.

This post is the first in a series I plan to publish based on my reading – the insights I’ve gathered and think worth sharing.

Tim Cook is Leaving. Good.

Mike's Notes

The key takeaway of this copied article.

"make products you’d be proud to use yourself."

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

05/05/2026

Tim Cook is Leaving. Good.

By: Tony Mattke 
Router Jockey: 27/04/2026

I’m Anthony Mattke, aka Tony. I’m a network engineer, infrastructure architect, and general-purpose technology geek located amidst the endless cornfields of north central Indiana. I’m a husband and father, and I hope to have superpowers one day. Seriously.

Your AirPods just connected to the wrong device. Again.

iMessage is taking twenty minutes to sync a message between your laptop and your phone sitting six inches apart. HomeKit forgot the kitchen lightbulb exists, and will remember it again in three hours like nothing happened. System Settings, which used to be one of the cleanest preferences UIs ever shipped, now feels like a bad Electron app pretending to be macOS.

These aren’t dramatic failures. They’re worse than dramatic failures. They’re daily proof that somewhere along the way, Apple stopped caring about the texture of using its own products.

This is Apple in 2026. And this is the Apple that Tim Cook built.

Cook announced his departure last week, and most of the coverage you’ll see is going to be a victory lap. A lot of it is earned. Apple is a three-trillion-dollar company. Services revenue is at record highs. Apple Silicon is one of the great hardware bets of the last decade. He took a company already at the top of its industry and made it bigger than the GDP of most countries.

So why am I glad he’s leaving? Because somewhere in all that growth, Apple stopped making products it was proud of.

What Steve Actually Said

There’s a passage in Walter Isaacson’s biography of Steve Jobs that gets quoted less than the famous ones. Jobs talked about how great companies die, and his theory was that the rot has nothing to do with competition or markets or innovation cycles. The rot starts when the salespeople end up running the company.

He named names. He pointed at IBM under John Akers. He pointed at Microsoft under Ballmer. He even pointed at the Sculley era of his own Apple as the cautionary tale. The phrase Jobs kept circling back to was that the people running these companies eventually “have no conception of a good product versus a bad product.” They can’t tell the difference. They can run a supply chain better than anyone alive, but they couldn’t tell you whether the radius on a button looks right.

That’s not a small criticism. That’s the founder of Apple, on the record, naming the disease and warning the company against catching it.

Then, in 2011, Apple promoted its head of operations to CEO.

I’m not saying Cook was a bad pick at the time. He was the right person to keep the trains running while everyone caught their breath after losing Steve. But fifteen years later it’s worth asking the question Steve himself would have asked. What kind of products are we shipping now?

The Tenet Cook Forgot

Of all the things Steve Jobs believed about Apple, one of them stands out as the most quietly violated under Cook: make products you’d be proud to use yourself.

Not just sell. Not just ship. Use. Sit down at the Mac on a Tuesday night, put your AirPods in, fire off a Message, set up a HomeKit automation, and feel proud of every single one of those things working the way you wanted them to.

Today’s Apple doesn’t pass that test. And the failures aren’t dramatic ones. They’re the small, persistent, daily-friction kind that the founder used to personally drive teams to fix.

You know the list. The 2022 System Settings redesign managed to take a perfectly usable preferences app and ship it as something worse, then leave it that way for three OS releases and counting. Notifications have been re-architected three times in five years and still work inconsistently across iOS, iPadOS, and macOS. Mail rules have been broken since the Obama administration. The Photos library will quietly drop items, sync ghosts, and offer no diagnostics when something goes wrong. HomeKit loses devices the way a child loses socks. Spotlight returns stale results and pauses for seconds at a time on hardware that should make it instant.

Each one of these, on its own, is just a bug. Together, they’re a culture.

They survive because they don’t move metrics. They don’t reduce revenue. They don’t show up in the quarterly. But they’re exactly the kind of paper-cuts that would have annoyed Steve at 9pm on a Tuesday, and they would have been fixed by Wednesday morning.

That’s the difference. Steve used the products. Cook signs the budget.

Before Someone Says This Is Just Nostalgia

Yes, I know. Apple under Steve wasn’t perfect. MobileMe happened. Antennagate happened. The hockey-puck mouse happened. Plenty of bad calls happened. Nobody is arguing for some flawless golden age that didn’t actually exist.

The argument is about standards, not perfection. Old Apple shipped mistakes too, and it visibly hated them. The bad release, the launch-day disaster, the public mea culpa, the engineering re-org. The whole company would visibly recoil and try to do better.

Today’s Apple ships friction and treats it like background radiation. That’s not the same thing.

The Counter Argument (-ish)

Yes, Apple Silicon is incredible. Yes, the Watch saved lives. Yes, the iPhone got better cameras and better screens and better batteries. The hardware story under Cook is strong, and pretending otherwise would be silly.

But here’s the thing about hardware. You can grow it through operational discipline. You can squeeze a process node, you can negotiate a better deal with TSMC, you can lean on a thousand suppliers until they bend. That’s exactly the kind of work Cook is good at, and it’s exactly the kind of work that doesn’t require a product person at the top.

Software is different. Software lives or dies on judgment calls a thousand times a day. Should this preference go in this menu or that one? Should this notification fire silently or with a sound? Should this Bluetooth handoff be aggressive or conservative? Those decisions can’t be operationally optimized. They have to be made by someone who actually uses the thing and has an opinion. Cook is famously not that person.

And the rot follows that exact line. Apple’s hardware reviews are still glowing. Apple’s software reviews… are not. The number of “I’m switching to Linux” or “I’m switching back to Windows” essays from longtime Apple loyalists has gone from a trickle to something that should worry someone on Apple Park’s executive row.

The grumbling isn’t about features. It’s about the texture of using the products. Which is the thing Steve cared about most, and Cook seemingly cares about least.

The Era of *aaS

There’s a related thread here. Cook’s Apple has gradually rebuilt itself as a services company that happens to make hardware. iCloud subscriptions. Apple Music. Apple TV+. Apple Arcade. Apple Fitness+. Apple News+. Apple One. AppleCare+ tiers within tiers. The recurring monthly nudges that show up in apps that used to be one-and-done.

There’s a real argument that this was a defensive move, and it worked. The Services line is now bigger than the GDP of small nations. But there’s also a reason long-time Apple users are uneasy. The company that ran the iPod silhouette ad is now the company that nudges you to try Apple Fitness+ when you open the Watch app for an unrelated reason. The texture changed. The thing that made Apple feel different is, slowly, less different.

And here’s where it loops back to the bug list. When recurring revenue becomes the thing the company optimizes for, the tolerance for friction goes up. A slightly annoying subscription upsell is acceptable as long as the funnel still works. A weird Settings menu is acceptable as long as nobody actually leaves. That’s how product standards quietly erode. Not through one dramatic bad decision, but through a thousand tolerated ones.

Was that the right business call? Maybe. Was it the right product call? Different question. And it’s the question Steve would have asked.

Enter John Ternus

The honest read on Cook’s tenure: he was the right operations CEO for the post-Steve transition, and he stayed long enough to also become the wrong product CEO for the post-iPhone era. That’s not a damning legacy. It’s just a long career with two halves that needed different people.

So who’s getting handed the keys? John Ternus.

If you needed to pick someone inside Apple to course-correct away from the operations-CEO failure mode, Ternus is the right person on paper. He’s been SVP of Hardware Engineering for years. He came up working on the Mac, ran iPad development, and was a key player in the Apple Silicon transition. He’s the one Apple keeps putting on the keynote stage to talk about new hardware. By any honest read, he’s an engineer and a product person, not a salesperson, not an operator. That’s the pick Steve would have nodded at.

BUT…

The piece I just spent a thousand words complaining about isn’t a hardware problem. Apple’s hardware under Cook has been excellent. The thing that rotted is the software experience. The bug list. And Ternus, for all his strengths, has spent his career running hardware, not software. Whether his product instincts translate into fixing the software stack is the open question of his tenure.

The hopeful read is that an engineer-CEO will demand engineering rigor across the whole company, including from the software org that’s been getting away with shipping half-baked work for a decade. The cynical read is that hardware engineers and software engineers are different cultures, and you can lead one without knowing how to fix the other.

I’m cautiously in the hopeful camp. The fact that Apple chose a builder over another finance type or another operations type says they noticed the thing this article is about. That’s not nothing.

But the proof is going to be in the next macOS release. Does System Settings get rebuilt? Does AirPods routing finally stabilize? Does Mail get a rewrite? Do notifications get a coherent strategy across all four operating systems? If yes, this was the right pick. If we get another year of shiny new features with five new bugs and zero fixes for the old ones, then Apple just rearranged the deck chairs.

Because that’s what made Apple. The rest is supply chain.

So yes. Tim Cook is leaving. Good. And John Ternus is taking the keys at exactly the moment Apple needs to remember what it was supposed to be.

The Algorithm: SpaceX’s Five-Step Process For Better Engineering

Mike's Notes

I like solving impossible problems; everything else is boring.

I will apply this five-step method to Pipi and to Ajabbi's future internal culture. The method could be applied to discovering a cure for breast cancer, lowering housing costs, and building safer ships.

According to Google Search: AI Mode (Gemini).

The "Way": The Five-Step Algorithm

At SpaceX, engineers are trained in a specific "Algorithm" to tackle impossible technical hurdles. The process must be followed in this strict order to avoid the "expert's trap" of perfecting things that shouldn't exist:

    1. Question every requirement: Every requirement must have a specific person’s name attached—not just a department. Even those from "the smart guys" (including Musk himself) must be challenged to make them "less dumb".
    2. Delete any part or process you can: Engineers are encouraged to delete until they are forced to add 10% back; otherwise, they aren't deleting enough.
    3. Simplify and optimise: Only optimise after questioning and deleting. A common mistake is optimising a process that should have been eliminated entirely.
    4. Accelerate cycle time: Increase speed only after the first three steps are complete to ensure you aren't just "digging your own grave" faster.
    5. Automate: Automation is the final step, used only once the design is refined and proven.

The Culture: "Responsible Engineers" (REs)

SpaceX replaces traditional siloed management with a flat structure centred on Responsible Engineers.

    • Total Ownership: An RE owns their component from requirements and design through to manufacturing and flight.
    • Systems Thinking: Every engineer must understand the whole vehicle, not just their subsystem, to ensure local optimisations don't hurt the global mission.
    • Information Velocity: Direct communication is required; anyone can talk to anyone to solve a problem, bypassing hierarchical "chain of command" protocols. 

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

28/04/2026

The Algorithm: SpaceX’s Five-Step Process For Better Engineering

By: Garrett Reim, Guy Norris, and Irene Klotz
Aviation Week: 23/08/2024

Based in the Seattle area, Garrett Reim covers the space sector and advanced technologies that are shaping the future of aerospace and defense, including space startups, advanced air mobility and artificial intelligence.

Guy Norris is a Senior Editor for Aviation Week, covering technology and propulsion. He is based in Colorado Springs.

Irene Klotz is Senior Space Editor for Aviation Week, based in Cape Canaveral. Before joining Aviation Week in 2017, Irene spent 25 years as a wire service reporter covering human and robotic spaceflight, commercial space, astronomy, science and technology for Reuters and United Press International.

SpaceX uses 3D printers and a process of relentless refinement to streamline its Raptor engines. In the Raptor 3, plumbing and wiring that had been on the outside were fused into the motor’s metal structure. | Credit: SpaceX

What is behind SpaceX’s success? According to one former top employee, it is something called “The Algorithm.”

Tim Berry, head of manufacturing and quality at blended-wing-body startup JetZero, spent a decade at SpaceX leading the Falcon 9 and Falcon Heavy family of rockets upper-stage production team. Berry also led the Dragon Crew and Cargo integration team and was head of additive manufacturing.

How the Raptor 3 rocket engine was streamlined

“Your requirements are definitely dumb; You have to find a way to make them less dumb.”

The Algorithm was “drilled into our minds,” he said at the American Institute of Aeronautics and Astronautics Aviation Forum in Las Vegas in July. “It’s a five-step process for improving the design, making it ultimately easier to manufacture and finding ways to optimize along the way as well.”

Step 1 is: “Challenge the requirements,” Berry said. “Or as our benefactor used to say, ‘Your requirements are definitely dumb; you have to find a way to make them less dumb.’”

Step 2 involves deleting a part or a process step. “Really looking at the full value chain of what you’re working on and eliminating any unnecessary process steps while also finding opportunities to delete parts ultimately yields an overall optimization, whether it’s a reduction in labor or cycle time or anything like that,” he said.

Step 3: “Find additional opportunities to simplify the design or optimize it,” Berry said. “Make it easier to manufacture or eke a few more points of performance out of it.”

Step 4 is all about speed. “Find even more ways to go faster,” Berry explained. “You add more stations; you ramp up the manufacturing.”

And then, finally—Step 5—you automate. “Most people start with Step 5, and they automate a process that never should have existed in the first place,” said Berry. “It’s really important that you work the steps in order.”

After completing Step 5, rinse and repeat. “You’re never satisfied,” Berry said. “You’re constantly going back and finding opportunities to challenge your requirements, deleting more parts, simplifying, optimizing, going faster, and then finally, opportunities to automate, but only once you’ve really boiled down to the baseline process.”

SpaceX CEO Elon Musk is keen on reducing engineering to its basics via first principles thinking. Aristotle invented the first principles method some 2,400 years ago in his Metaphysics, describing it as trying to understand “the first basis from which a thing is known.”

“The normal way that we conduct our lives is we reason by analogy,” Musk explained in a 2012 interview. “We’re doing this because it’s like something else that was done, or it’s like what other people are doing. It’s mentally easier to reason by analogy rather than from first principles. First principles is a physics way of looking at the world, and what that really means is you kind of boil things down to the most fundamental truths.”

Musk often talks about competing SpaceX’s hardware against the laws of nature rather than other products on the market. That philosophy has driven SpaceX employees to simplify the Raptor rocket engine from something that looked “like a Christmas tree with how much stuff is on it” to a more spartan look, Berry said.

In August, SpaceX revealed the drastically streamlined Raptor 3 engine (see photo) and test-fired it. The company ditched a heat shield on the latest iteration of the methane-fueled engine by taking plumbing and wiring that was previously hanging on the outside and fusing it into the motor’s metal structure. To do so, SpaceX heavily relied on 3D printing, Musk wrote on the social media site X.

The sea-level variant of the Raptor 3 weighs 3,362 lb., compared with the 3,594-lb. Raptor 2, while generating 280 tons of force, compared with the current rocket’s 230 tons of force. The total weight of the Raptor 3 plus vehicle commodities and hardware is 3,792 lb. compared with the Raptor 2’s 6,338 lb.

“The amount of work required to simplify the Raptor engine, internalize secondary flow paths and add regenerative cooling for exposed components was staggering,” Musk said. “Getting close to the limit of known physics,” he added in another post.

Laws of Software Engineering

Mike's Notes

Dr Milan Milanovic has written a 300-page book about the laws of software engineering. It looks great. There is also a website, a newsletter and a printable poster. It is a very useful collection of 56 laws for future reference.

Missing Laws

  • Glass's Law: For every 25% increase in the complexity of the problem space, there is a 100% (fourfold) increase in the complexity of the solution space.
  • Session's Law: 
    • The Law of Exponential Complexity: As you add more components to a system, the complexity increases exponentially, not linearly.
    • Equivalence Relations & Partitioning: Sessions argues that the only way to manage massive IT complexity is through partitioning—breaking a large system into smaller, independent "Snowman" units that do not share state or data directly.
    • Mathematical Predictability: He uses these laws to calculate the probability of IT project failure based on the number of interconnected components.

Heuristics

While this name suggests rigid scientific "laws," it is more accurately described as a series of heuristic, or mental shortcuts or empirical observations that help teams understand.

Complex Adaptive System (CAS)

I knew about some of these heuristics and designed Pipi as a CAS to break many of them. 😎 Laws of Software Engineering gives me a clear target to smash.

Website

On the Laws of Software Engineering website, there is a link from each law to a page with sections covering;

  • Takeaways
  • Overview
  • Examples
  • Origin
  • Further Reading

I copied the 56 laws here from the website, subscribed to the newsletter, and printed off the poster. I must get the book. Very cool.

Thank you, Dr Milan Milanovic. 😎

From Amazon

"Conway's Law. Brooks's Law. Goodhart's Law. Hyrum's Law. If you've been writing software long enough, you've recognized these rules even before you knew their names. If you had an opportunity to see a failed rewrite, or a time that is getting bigger but slower, you hit into these rules.

These patterns have been showing up in software projects for over fifty years. Experienced engineers know them, but they learned them the hard way. These lessons were never in one place, where you could read them. They lived in academic papers from the 1960s, but also in some blog posts that get shared once and forgotten. I also found them in discussions and code reviews.

This book puts all of them in one place. 63+ laws and principles, each with its own chapter, with forewords by Dr. Rebecca Parsons (CTO Emerita at Thoughtworks) and Addy Osmani (Engineering Director at Google Cloud AI).

Each chapter covers where the law came from, how it actually works, what it looks like in the real world, and how it connects to other laws in the book. That last part matters. Some of these principles reinforce each other, and others directly conflict. The "Related Laws" sections throughout the book show you where those connections are. This is important because in practice, engineering is about tradeoffs, not rules.

The book is organized into seven standalone parts:

    • Part I: Architecture & Complexity. 8 laws, including Gall's Law, CAP Theorem, and Hyrum's Law.
    • Part II: People, Teams & Organizations. 10 laws, including Conway's Law, Brooks's Law, and the Peter Principle.
    • Part III: Time, Estimation & Planning. 6 laws, including Hofstadter's Law and Goodhart's Law.
    • Part IV: Quality, Maintenance & Evolution. 10 laws including Technical Debt, Lehman's Laws, and Testing Pyramid.
    • Part V: Scale, Performance & Growth. 4 laws, including Amdahl's Law and Metcalfe's Law.
    • Part VI: Coding & Design Principles. 6 laws including SOLID, DRY, and YAGNI.
    • Part VII: Decision-Making & Biases. 13 laws, including Occam's Razor, Dunning-Kruger Effect, and Pareto Principle.

Many chapters also cover companion laws within them: George Box's Law, The Spotify Model, Two Pizza Rule, The Dead Sea Effect, The Cobra Effect, Impostor Syndrome, and more. There's more in here than the table of contents suggests.

You don't need to read it front to back. Each chapter stands alone. Building a distributed system? Start with Part I. Team problems? Part II. Estimation problems? Part III. Codebase issues? Part IV. Or just start at page one. That works too.

Half the book covers people, organizations, and how we make decisions, not just technology. Remember that this is not a coding tutorial and it won't teach you a programming language or framework.

If you've been in the industry for a while, you'll probably recognize some of these laws. Here you will learn about other laws and how they are connected and affect each other. You will also learn to understand it in depth, so it becomes useful for your current or next projects. And if you're earlier in your career, this book gives you the vocabulary your senior colleagues already have." - Amazon

Resources

References

  • Laws of Software Engineering by Dr Milan Milanovic (2026).

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Ajabbi Research > Library > Subscriptions > Techworld with Milan
  • Home > Handbook > 

Last Updated

27/04/2026

Laws of Software Engineering

By: Dr Milan Milanovic
Laws of Software Engineering: 27/04/2026

I’m a software engineer and CTO with over 20 years of experience, from startups to large enterprises, including big tech as a contractor. I hold a Ph.D. in Computer Science, have authored over 20 scientific publications with 440+ citations, and am recognized as a Microsoft MVP for Developer Technologies.

With each new role, from developer to architect to CTO, I encountered the same patterns. The same struggles. The same failures. The same hard-won insights that engineers keep rediscovering, often at great cost.

I started collecting these laws and principles for myself, then for my teams. When I started my newsletter, I shared them with the world. Today, my writing on software, architecture, and leadership reaches over 400,000 engineers.

This book represents everything I wish I’d had when I started. I hope it spares you some of the pain I went through.

A collection of principles and patterns that shape software systems, teams, and decisions.

Part I: Architecture & Complexity (Architecture)

1. Gall's Law

A complex system that works is invariably found to have evolved from a simple system that worked.

2. The Law of Leaky Abstractions

All non-trivial abstractions, to some degree, are leaky. 

+ George Box's Law

3. Tesler's Law (Conservation of Complexity)

Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.

4. CAP Theorem

A distributed system can guarantee only two of: consistency, availability, and partition tolerance.

5. Hyrum's Law

With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody.

6. Second-System Effect

Small, successful systems tend to be followed by overengineered, bloated replacements.

7. Fallacies of Distributed Computing

A set of eight false assumptions that new distributed system designers often make.

8. Law of Unintended Consequences

Whenever you change a complex system, expect surprise.

9. Zawinski's Law

Every program attempts to expand until it can read mail.

Part II: People, Teams & Organizations (Teams)

10. Conway's Law

Organizations design systems that mirror their own communication structure. 

+ The Spotify Model

11. Brooks's Law

Adding manpower to a late software project makes it later. 

+ Little's Law

12. Dunbar's Number

There is a cognitive limit of about 150 stable relationships one person can maintain.

13. The Ringelmann Effect

Individual productivity decreases as group size increases. 

+ The Two-Pizza Rule

14. Price's Law

The square root of the total number of participants does 50% of the work.

15. Putt's Law

Those who understand technology don't manage it, and those who manage it don't understand it.

16. Peter Principle

In a hierarchy, every employee tends to rise to their level of incompetence.

17. Bus Factor

The minimum number of team members whose loss would put the project in serious trouble. 

+ The Dead Sea Effect

18. Dilbert Principle

Companies tend to promote incompetent employees to management to limit the damage they can do.

Part III: Time, Estimation & Planning (Planning)

19. Hofstadter's Law

It always takes longer than you expect, even when you take into account Hofstadter's Law. 

20. Parkinson's Law

Work expands to fill the time available for its completion.

21. The Ninety-Ninety Rule

The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.

22. Goodhart's Law

When a measure becomes a target, it ceases to be a good measure. 

+ The Cobra Effect

23. Gilb's Law

Anything you need to quantify can be measured in some way better than not measuring it. 

24. Premature Optimization (Knuth's Optimization Principle)

Premature optimization is the root of all evil.

Part IV: Quality, Maintenance & Evolution (Quality)

25. Murphy's Law / Sod's Law

Anything that can go wrong will go wrong.

26. Postel's Law

Be conservative in what you do, be liberal in what you accept from others.

27. Broken Windows Theory

Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired. 

28. The Boy Scout Rule

Leave the code better than you found it.

29. Technical Debt

Technical Debt is everything that slows us down when developing software.

30. Linus's Law

Given enough eyeballs, all bugs are shallow.

31. Kernighan's Law

Debugging is twice as hard as writing the code in the first place.

32. Testing Pyramid

A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests. 

+ The Beyoncé Rule

33. Pesticide Paradox

Repeatedly running the same tests becomes less effective over time.

34. Lehman's Laws of Software Evolution

Software that reflects the real world must evolve, and that evolution has predictable limits.

35. Sturgeon's Law

90% of everything is crap.

Part V: Scale, Performance & Growth (Scale)

36. Amdahl's Law

The speedup from parallelization is limited by the fraction of work that cannot be parallelized.

37. Gustafson's Law

It is possible to achieve significant speedup in parallel processing by increasing the problem size.

38. Metcalfe's Law

The value of a network is proportional to the square of the number of users. 

+ Sarnoff's & Reed's Laws

Part VI: Coding & Design Principles (Design)

39. DRY (Don't Repeat Yourself)

Every piece of knowledge must have a single, unambiguous, authoritative representation.

40. KISS (Keep It Simple, Stupid)

Designs and systems should be as simple as possible.

41. YAGNI (You Aren't Gonna Need It)

Don't add functionality until it is necessary. 

42. SOLID Principles

Five main guidelines that enhance software design, making code more maintainable and scalable. 

43. Law of Demeter

An object should only interact with its immediate friends, not strangers.

44. Principle of Least Astonishment

Software and interfaces should behave in a way that least surprises users and other developers.

Part VII: Decision-Making & Biases (Decisions)

45. Dunning-Kruger Effect

The less you know about something, the more confident you tend to be. 

+ Impostor Syndrome

46. Hanlon's Razor

Never attribute to malice that which is adequately explained by stupidity or carelessness.

47. Occam's Razor

The simplest explanation is often the most accurate one.

48. Sunk Cost Fallacy

Sticking with a choice because you've invested time or energy in it, even when walking away helps you.

49. The Map Is Not the Territory

Our representations of reality are not the same as reality itself.

50. Confirmation Bias

A tendency to favor information that supports our existing beliefs or ideas.

51. The Hype Cycle & Amara's Law

We tend to overestimate the effect of a technology in the short run and underestimate the impact in the long run.

52. The Lindy Effect

The longer something has been in use, the more likely it is to continue being used.

53. First Principles Thinking

Breaking a complex problem into its most basic blocks and then building up from there.

54. Inversion

Solving a problem by considering the opposite outcome and working backward from it.

55. Pareto Principle (80/20 Rule)

80% of the problems result from 20% of the causes.

56. Cunningham's Law

The best way to get the correct answer on the Internet is not to ask a question, it's to post the wrong answer.

"Collaboration" is bullshit

Mike's Notes

Hell, why does this remind me of innovation theatre? 😎

I love the writer's brutal honesty.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

13/04/2026

"Collaboration" is bullshit

By: J.A. Westenberg
Westenberg: 22/03/2026

I'm JA Westenberg. I publish a weekly column on technology, culture, philosophy and what it means to be a human being.

In 1944, the Wehrmacht launched into Hitler’s last ditch effort to save the Third Reich. The Battle of the Bulge was a doomed campaign and a doomed gamble from a doomed regime, but its brutality was a true second test of the US Army on the Western Front. During the battle, Army historian S.L.A Marshall began interviewing infantry companies who’d been baptised in combat. Published 3 years later in his 1947 book, Men Against Fire, Marshall’s research showed that just 15-20% of riflemen in active combat positions ever fired their weapons - most kept their heads down. They moved when they were ordered and they held their positions, and they mimicked the outward appearance of a soldier in battle - but shoot, they did not. By any standard organisational metric, the men were present and accounted for, but 4 out of 5 never pulled the trigger. 

You can debate the extent of Marshall’s numbers, and you can debate his methodology, but his ratio shows up, again and again. IBM stumbled onto it in the ‘60s when they discovered that 80% of computer usage came from 20% of the system’s features. The pattern recurs because it describes something real about how effort is distributed inside groups, where a fraction of the people do most of the work, and the rest provide what you might ~charitably call “structural support.”

Anyone who has worked in any large organisation knows exactly what I’m talking about. 

The modern tech industry looked at the problem of human coordination and participation and decided the solution was “collaboration.” If only 20% of us are operating with a “killer instinct” we need to be better at managing the shared instincts of the other 80%. And so collaboration became our shared obsession. We pursue “teamwork” as a holy grail. 

The teamwork revolution, if you can call it that, gave us Notion for our documents, ClickUp for our tasks, Slack for our conversations, Jira for our tickets, Monday for our boards, Teams for the calls that should been emails, emails for the things that we couldn’t squeeze in anywhere else, and now agents attempting to re-invent the whole stack. The average knowledge worker maintains accounts across system after system, switching between applications hundreds of times per day. And they produce, in aggregate, a staggering amount of coordinated and collaborative activity that never actually becomes anything resembling ~output. 

When you strip away the product marketing and the dev relations and the blog posts and the funding rounds and the fuckery-upon-fuckery of it all, we’re left with a simulation of collective engagement - but very little else. Transparency got confused with progress, visibility got confused with accountability, and being included in the thread became the same thing, socially and organizationally, as owning the outcome.

Once that confusion set in at the cultural level it became nearly impossible to dislodge. The feeling of collaboration is pleasant in a way that personal accountability can never be. Owning something means you, specifically and visibly you, can fail at it, specifically and visibly, in ways that attach to your name.

Collaborating means the failure belongs to the process.

So everyone chose collaboration, and we called it culture.

Marshall's riflemen were ordinary people responding to the diffusion of responsibility that happens inside any group. Maximilien Ringelmann measured the same phenomenon with ropes in 1913, long before there were Slack workspaces to offer an emoji-react to it. Individual effort drops predictably as group size increases. The presence of others dissolves the sense of personal responsibility in a way that feels, to everyone experiencing it, entirely reasonable. You're part of a team, you're contributing, you're also (measurably) pulling less hard than you would if the rope were yours alone. Every single person on the rope is doing this simultaneously, which is why the total force never adds up the way the headcount says it should.

Frederick Brooks identified the same dynamic in software development in 1975, watching IBM's System/360 project illustrate his emerging thesis that adding people to a late project makes it later. Communication overhead grows faster than headcount, coordination costs compound, and every new person contributes their capacity along with their relationships to everyone else. Those relationships require maintenance and produce misalignment and generate the need for more meetings to address the misalignment those meetings created.

Brooks might as well have described your company's Q3 roadmap planning cycle and your startup's sprint retrospective, all of which have gotten longer every year and produced, relative to their investment, less.

The collaboration industry has spent a fortune obscuring a dirty truth: most complex, high-quality work is done by individuals or very small groups operating with clear authority and sharp accountability, then rationalized into the language of teamwork afterward. Dostoevsky wrote _The Brothers Karamazov_ alone. The Apollo Guidance Computer came from a team at MIT small enough to have real ownership, hierarchical enough that Margaret Hamilton's name could go on the error-detection routines she personally designed.

Communication matters, and shared context matters. But there’s a huge difference between communication and collaboration as infrastructure to support individual, high-agency ownership, and communication and collaboration as the primary activity of an organisation. Which, if we’re honest, is what most collaboration-first cultures have actually built. They’ve constructed extraordinarily sophisticated machinery for the social management of work, without actually doing the work they’re socialising about. 

If and when it exists, ownership looks like an individual who deeply gives a shit, making a call without waiting for group-consensus. That individual will be right sometimes, and they’ll be wrong other times, and they’ll own it. They won’t sit around waiting to find out who has the authority to move a card from one column to another and post about it in the #celebrations  channel. 

But being that person sucks when “collaboration” is the reigning value, because every unilateral decision gets read as a cultural violation and a signal that you aren’t a team player. Collaboration-as-ideology has made ownership and responsibility feel antisocial, which is a hell of a thing, given that ownership is the only mechanism that gets anything across the finish line. 

You can see this excess everywhere. Standups where people announce their busy work and as long as everyone’s “on the same page” nobody changes course. Documents that are written to perform thinking so somebody else can perform thinking, with no decision in sight. Retros, and kickoffs, and WIP meetings that spawn their own retros, kickoffs and WIP meetings like cells dividing and re-dividing, with zero connection to the work that it’s nominally organising around. 

Every project now seems to carry more coordination overhead than execution time, and when it fails the postmortem just recommends more collaboration...

At some point (and I think that point was fucking yesterday) we have to ask ourselves - what are we actually producing and who is actually responsible for producing it? 

Because at some level, the answer for “who is responsible for X” has to be one single person, no matter how much the collaborative apparatus layered over modern work has been engineered to make that person invisible and dissolve accountability. 

We need to find some path back to trusting that individuals will do their jobs, without every responsibility being visible to an entire organisation, without follow-ups being scheduled by a cadre of overpaid managers with their overfed metrics. 

Maybe - just maybe - we could make our lives a little easier. Maybe we could let human beings keep their own lists of tasks, and we could let them sink or swim by how they manage those tasks, and we could assign blame to them and to them alone when they fuck up. Maybe we could do it without needing to have team-level views of every Kanban, calendar and task list. And maybe - if we let go of the warm, expensive fiction of collective endeavour - we could make it a little easier to see who among us are pulling the trigger and who are just keeping their heads down.