• Design and implement

    Unmesh Joshi talking about how software engineers discover design during implementation. In my opinion, this is the primary reason using AI in software development is not as straight forward as makers of coding assistants project it to be.

    In most mature engineering disciplines, the process is clear: a few experts design the system, and less specialized workers execute the plan. This separation between design and implementation depends on stable, predictable laws of physics and repeatable patterns of construction. Software doesn’t work like that. There are repetitive parts that can be automated, yes, but the very assumption that design can be completed before implementation doesn’t work. In software, design emerges through implementation. We often need to write code before we can even understand the right design. The feedback from code is our primary guide. Much of this cannot be done in isolation. Software creation involves constant interaction—between developers, product owners, users, and other stakeholders—each bringing their own insights. Our processes must reflect this dynamic. The people writing code aren’t just ‘implementers’; they are central to discovering the right design.

    Filed under
  • Out of distribution humans

    This thought provoking article from Ahmed on the current state of AI’s onslaught on the job market.

    This is where I keep coming back to a phrase that has been rattling around my brain for the past month: out of distribution humans.

    Most work lives in the fat middle of a bell curve. Tasks repeat with small variations. Most graduate schemes are built around that fact. You take reasonably bright people, give them a handbook and a mentor, and let them climb a well mapped gradient. Shared service centres, call centres, warehouses, junior consulting rotations, entry level software roles, even a lot of legal and accounting work, all sit in that comfortable hunk of the curve where yesterday’s data is a very good guide to tomorrow’s tasks.

    Models feast on that part of the curve. That is what they are trained on: logs, emails, historical cases, recordings of someone else doing the job, code repositories, scanned documents. If your work looks a lot like a large pile of past episodes, it is a short hop from playing them back to imitating them. The central question for future labour markets is not whether you are clever or diligent in some absolute sense. It is whether what you do is ordinary enough for a model to learn or strange enough to fall through the gaps.

    An out of distribution human, in my head, is someone whose job sits far enough in the tail of that curve that it does not currently compress into training data. Maybe they work with genuinely novel problems. Maybe they operate at small scales or in messy physical situations where we do not yet have enough sensors. Maybe they have taste that is not easily reduced to click logs. They are not safe; nothing is. They are simply late on the automation curve. The system needs them until it can watch them for long enough and in enough detail that it can flatten what they do into data.

    This reminds me of Zara Zhang’s observation.

    Filed under
  • Entry level jobs

    Zara Zhang sharing her thoughts on entry level jobs.

    A Harvard student told me something I can’t stop thinking about. When they go to the library, every single screen has ChatGPT open. Homework that used to take hours now takes minutes.

    But then they talk to alums who say entry-level roles are basically gone. The jobs they planned their entire college trajectory around don’t exist anymore.

    AI made homework easier but made proving you deserve a job exponentially harder.

    Scary.

    Filed under
  • Swiss cheese

    Swiss cheese always had holes in it. The holes from which Jerry would emerge. But some time back Swiss cheese started losing holes. This video by Tim Scott explains why and how they managed to get it back.

    The bacteria that are responsible for making these holes produce propionate, acetate and carbon dioxide, and this carbon dioxide is produced in the cheese and aggregates all around impurities. The more the bacterium produces this carbon dioxide, it accumulates and builds these holes. These impurities capture the carbon dioxide, and then a bubble forms and grows.

    They found that the milk was too clean, so we didn’t have any dust in it, and this was because we had closed milking systems, so the dust could not get into the milk. Everything improved the last decade, so the milking process is hermetically closed now. And then, in former times, in the barn, you had always this hay dust everywhere, and it came also into the milk. We tried different particles to put into the milk to see if the holes are growing again. Hay powder is the best one, and we really could see that the whole formation was dependent on the concentration of the hay powder.

    Somehow this reminds me of a dialogue from Tron: Legacy.

    The thing about perfection is that it is unknowable, it’s impossible, but its also right in front of us, all the time

    Filed under
  • Minimise collaboration between teams

    Jade Rubick explaining why we should strive to maximise collaboration within teams and minimise collaboration between teams.

    To the maximum extent possible, teams should have what they need to succeed within the borders of their team. And where that is not true, you need some structure to ensure the team can get what it needs in a way that will scale with the organization’s growth.

    As companies grow, communication and dependencies proliferate. Companies start out with many-to-many communication. As they grow, the communication patterns within the company must necessarily switch to being segmented and defined. Otherwise, the communication burden on teams will grow at an exponential rate, and the increasing complexity will degrade the effectiveness of the company.

    Filed under
  • Pilots, probes and experiments

    Andi Roberts explaining the difference between pilots, probes and experiments. He then goes on share guidance on how to manage each of them.

    Pilots: A pilot is a small, time-bound test to determine whether a product, process, or service can work in practice. It is used when an idea appears promising but remains unproven.

    Think of a bank that tries a new mobile feature in one city before a national launch. The trial exposes what could not be seen on paper: user confusion, system issues, or compliance gaps. The value of a pilot lies in its realism. It bridges the space between concept and operation, letting leaders see what truly happens when an idea meets the world. From this, they can refine and strengthen the design before committing at scale.

    Probes: A probe begins with curiosity, not certainty. Drawn from complexity thinking, probes are small, safe-to-fail actions that explore what might work when the path ahead is unclear.

    A city struggling with congestion might try three different approaches: a cycling subsidy, staggered work hours in one district, and AI-driven traffic lights. None is guaranteed to succeed, and that is the point. Each test offers a glimpse of how the system responds. The power of a probe is its capacity to uncover patterns that analysis alone cannot reveal.

    Experiments: An experiment is a structured test designed around a hypothesis. It is used when a leader wants clear evidence about cause and effect.

    An online retailer, for example, may compare two website layouts to see which converts more visitors into buyers. Experiments are precise, controlled, and measurable. They do not explore the unknown in the same way that probes do, but they provide reliable evidence where outcomes can be quantified. Their strength lies in giving leaders grounded answers to specific questions.

    Filed under
  • Choosing a programming language

    Steve Francia talking about why engineers can’t be rational about choosing a programming language. He ends his post by highlighting that choosing a programming language should be reframed to an economic debate. What is programming language going to cost us?

    Instead of asking “which language is best?” we need to ask “what is this language going to cost us?” Not just in salaries, but in velocity, in technical debt, in hiring difficulty, in operational complexity, in every dimension that actually determines whether you survive.

    Reframe it from a technical debate to an economic one. And unlike identity, economics can be measured, compared, and decided without anyone’s ego being threatened.

    Choosing a programming language is the single most expensive economic decision your company will make. It will define your culture, constrain your budget, determine your hiring pipeline, set your operational costs, and ultimately dictate whether you can move fast enough to win your market.

    Filed under
  • To farm the sea, we strip the sea

    John Steele highlighting the irony of how farming sea food strips the sea itself.

    In the cold waters of the Pacific, the anchoveta once shimmered in swarms so vast that sailors described them as turning the sea into a river of quicksilver. They were small, unassuming fish, yet the abundance of the ocean rested upon their delicate bones. Seabirds wheeled overhead in their millions, sea lions and whales dove into their depths, and predatory fish rose through the blue to feed on them. In those shoals lived the vitality of the sea itself. But in our age, the anchoveta, along with sardines and menhaden, have been transformed from living threads in an ancient web into bags of meal and casks of oil. Ninety percent of the forage fish caught by human hands are not eaten by us but ground down to feed salmon being raised in the cold fjords of Norway and shrimp and fish in the tropical ponds of Southeast Asia.

    It is one of the great ironies of our time. To farm the sea, we strip the sea. We take from the ocean’s foundation to build its surface anew, and in the process we imperil both.

    But all is not lost. There are some innovative solutions in the horizon.

    Filed under
  • Outreach

    This comment by th explains how DEI is essentially an outreach program. This is on the news of Python Software Foundations’ decision to withdraw from $1.5 million proposal for US government grant program.

    It seems like a number of the “DEI is anti-merit discrimination” messages in this thread are overlooking how DEI work usually works.

    A relevant tweet from 2016 (https://x.com/jessicamckellar/status/737299461563502595):

    > Hello from your @PyCon Diversity Chair. % PyCon talks by women: (2011: 1%), (2012: 7%), (2013: 15%), (2014/15: 33%), (2016: 40%). #pycon2016

    Increased diversity in communities usually comes from active outreach work. PyCon’s talk selection process starts blinded.

    If 300 people submit talks and 294 are men, then 98% of talks will likely be from men.

    If 500 people submit talks and 394 are men, then ~79% will likely be by men.

    Outreach to encourage folks to apply/join/run/etc. can make a big difference in the makeup of applicants and the makeup of the end results. Bucking the trend even during just one year can start a snowball effect that moves the needle further in future years.

    The world doesn’t run on merit. Who you know, whether you’ve been invited in to the club, and whether you feel you belong all affect where you end up. So unusually homogenous communities (which feel hard for outsiders to break into) can arise even without deliberate discrimination.

    Organizations like the PSF could choose to say “let’s avoid outreach work and simply accept the status quo forever”, but I would much rather see the Python community become more diverse and welcoming over time.

    Filed under
  • Subconscious processing

    There’s a spirited discussion on the research paper A Definition of AGI on Hacker News. This comment by fnordpiglet caught my attention.

    Try this exercise. Do not think and let your mind clear. Ideas will surface. By what process did they surface? Or clear your mind entirely then try to perform some complex task. You will be able to. How did you do this without thought? We’ve all had sudden insights without deliberation or thought. Where did these come from? By what process did you arrive at them? Most of the things we do or think are not deliberative and definitely not structured with language. This process is unobservable and not measurable, and the only way we have to do so is through imperfect verbalizations that hint out some vague outline of a subconscious mind. But without being able to train a model on that subconscious process, one that can’t be expressed in language with any meaningful sufficiency, how will language models demonstrate it? Their very nature of autoregressive inference prohibits such a process from emerging at any scale. We might very well be able to fake it to an extent that it fools us, but awareness isn’t there – and I’d assert that awareness is all you need.

    Filed under