Jon Sykes

Rebuilding my blog from the Wayback Machine

2026-11-06T00:00:00Z

I stopped writing at jon.sykes.me around 2009. My home page at the time said "For fun I used to blog", which was fair. I kept the domain, but the blog and its posts didn't survive.

Last night I sat down to put a big grey "sykes.me" on a page. By this morning I had 62 posts going back to 2007, a blog to put them in, and a comment section. I did it with Claude, which still feels a little ridiculous.

Finding the old posts

I pointed Claude at a single Wayback Machine snapshot of jon.sykes.me from December 2008, and asked it to pull across anything that wasn't broken links or low value. Rather than just crawl that page, it asked the archive for its full list of captures, which turned up far more than the snapshot linked to.

The archive knew about 163 posts from 2006 to 2009. About 100 still had recoverable text. Roughly 60 are simply gone.

The best find came from inside one of the posts. A link pointed to jpsykes.com, where the blog had lived before, and that's where the best early material was. CSRF write-ups, CSS performance tests, IE6 memory leaks, Dojo porting notes, How to explain JSON to your mum. That one I asked for by name, it was a good one.

From there it kept pulling threads. Nomeist turned up, my monome and Arduino blog from 2008 to 2012, which added nine posts. LinkedIn added 14 more, although nearly everything there before 2026 was work news.

Nothing went up automatically. Claude sorted everything by value and gave me a shortlist, I drew the line, and it drafted the posts for me to read first. The text stayed in my original words, typos included, with new titles, summaries and tags to fit the format. Each one ends with a line saying where it first appeared.

It wasn't all clean:

The Wayback Machine rate limited us, then flagged the requests as bot traffic. We stopped there rather than work around it, so 11 posts I'd like to check are still in there.
17 old images came back, some in better quality from my old Flickr account. Five are lost, and those posts say so.
Old links are old. Some now point to archived copies, and plenty of the rest are probably dead.

Why static

The brief I gave was short: no database, all static content, generated at build and deployed when I push.

I've just spent a night digging my own writing out of an internet archive, so the reason is not hard to find. My old blogs lived on servers, in databases, on software that needed looking after, and when I stopped looking after them they disappeared. If someone hadn't crawled them years ago, those posts wouldn't exist.

A Markdown file in a git repo doesn't need looking after. There is no server to patch, no database to back up and nothing to log in to. The whole site can sit untouched for ten years and still build, and the posts are readable without any of it.

How it's built

Every post is one Markdown file in posts/. The name sets the date and the URL, and the front matter holds the rest:

---
title: Title of the post
subtitle: One sentence saying what the post is about.
date: 2026-11-05
tags:
  - first-tag
---

One Node script, build.mjs, turns those files into the whole site: home, index, tag pages, the Atom feed, the sitemap, robots.txt, llms.txt and the structured data for each post. It has two dependencies, one for front matter and one for Markdown. There's no framework, and the JavaScript on a page is a Light / Dark toggle and the comments loader.

The build is also the editor. A missing subtitle, a wrong date or a stray heading level fails the build, and Vercel keeps the last good version live. Publishing is adding a file and pushing to main.

The look comes from a small design system: tokens for colour, type and spacing, and one stylesheet of about 8KB. One white sheet on a grey canvas, ink with no accent colour, one line weight, and an index that reads like the index of a book.

Why GitHub comments

I wanted comments, but I didn't want to manage them, deal with logins or fight spam. Substack was my first thought, but it has no public API or comment embed, so I looked for someone else to carry that work.

I'm trialling giscus, which stores each post's comments as a GitHub Discussion in a small public repo. GitHub handles the accounts, and the sign-in does most of the work on spam. I own no database, and the comments stay in a place I can export or walk away from.

The catch is that you need a GitHub account to comment, which is a real filter. A lot of what I write here is for engineers, so it's a fair trade for now. If it's too quiet, I'll try something else.

It arrived looking like GitHub, in a site that's trying very hard not to look like anything. So the build now generates its theme from the same design tokens as the site, and the comment form sits flat on the sheet.

If you've read this far, there's a box just below. Let me know if it works.

When the whiteboard becomes the thing you build from

2026-07-13T00:00:00Z

The best engineering tool I have ever had was a room full of engineers and a whiteboard. Every attempt to digitise it produced diagrams that were fiction within a fortnight. This weekend I tried to fix that, and it turned into something bigger than a tool.

Chad Fowler's "Regenerative Software" essay finally gave me a framing that helped rationalize why I felt that way. AI has inverted the economics of code, implementation is becoming cheap and disposable, and the durable assets are the boundaries, the definitions of correct, and the captured intent, this is where the value has always been, it was just buried behind lines of code you had to type by hand to make it real.

I spent a weekend with Claude exploring what happens if the whiteboard becomes the thing you actually build from, rather than a picture of what you built.

The surprise wasn't the code we generated, it was that the idea refused to stay confined to just an engineering tool: it kept pulling in how product defines done, how design holds coherence, how work could be intentionally delegated between agents and humans so people stay genuinely close to a craft that machines increasingly perform, where human ingenuity could still contribute flourishes of genius to an outcome.

Somewhere in the middle of it, Claude offered a sentence "The craft doesn't shrink so much as move up a level, onto exactly the skills that have always distinguished strong senior engineers."

None of this exists yet beyond MD documents, and an MVP plan I have been burning free Fable credits on all weekend. Half of it is probably wrong, but it has me in solid agreement that the craft is not shrinking it is moving up a level, to the skills that always separated the strong engineers. Drawing the boundaries. Defining what correct means. Adjudicating the diffs.

Who else now builds the things you used to just imagine, so you can brainstorm and work through an abstract idea?

The Phoenix Architecture

First posted on LinkedIn.

Budgeting your change capacity

2026-06-10T00:00:00Z

"The only people who can keep up with AI product rate of change are the unemployed."

Saw that on X the other week and it's been rattling around my head since. The pace really is unrelenting, and the labs ship faster than any of us can properly absorb.

So the question isn't really whether to adopt. It's how much of your change capacity you spend, and where you point it.

Take any single change. A new tool, a new model, a new feature. Two things are moving over its life. How stable it is, which climbs as it stops breaking under you. And how much value you actually get from adopting at that particular moment, which isn't a straight line at all, it's a curve.

Adopt at the bleeding edge and the value is low, because it's brilliant and broken in roughly equal measure, and you're paying full price for the instability
Adopt just as it stabilizes and the value peaks. The churn is behind you, it holds still long enough that you can build on it, and you're still early enough to have an edge
Adopt once it's established and everyone else has it too, and the value drops off again. Safe and stable, but you've paid for that with your lost edge over the competition

Then the bit I think gets missed. This isn't one decision you make for the whole org and then live with. Manage it as a blend so your change capacity budget isn't spent on 1 type of change alone.

Something like: 15 percent of your change capacity pioneering the bleeding edge, because you need scouts out there finding the thing that turns into a winning bet. 65 percent on the stuff that's stabilizing, where the value concentrates. 20 percent holding the proven core steady so the lights stay on. I'm not going to pretend those numbers are science, they're roughly where I've landed today, tomorrow who knows and I'd expect them to move a lot depending on what business you're in.

Get the mix wrong in the obvious direction, all in on the bleeding edge because standing still feels like losing, and your average value just collapses. You pay for instability everywhere and compound nothing. It becomes an exhausting whack-a-mole of new features every day.

The teams I see getting somewhere with this aren't necessarily the fastest movers, they're the ones who worked out they had a budget in the first place.

Curious whether anyone is doing this deliberately, and what your split looks like. Or whether 15/65/20 is miles off for your world.

First posted on LinkedIn.

Two WWDC predictions

2026-06-08T00:00:00Z

WWDC keynote later today. Two predictions I'm putting on the record before Tim walks out.

1: MCP becomes a first class citizen on iOS and macOS. Siri stops being a parlour trick and starts doing whatever app developers expose to it. "Hey Siri, order me a DoorDash." "Hey Siri, what's the surf conditions tomorrow?" "Hey Siri, book me a flight on United." App's become a set of tools, and Siri becomes the agent that calls and orchestrates them.

2: Real inference models running on the device in your pocket. Not a round trip to someone's data centre. On Apple silicon, local, private, fast. If they pull it off they could flip the whole hyperscale inference economics on its head, and the moat everyone assumed lived in the cloud moves into your hand.

The consensus says the opposite on that second one, more reliance on Google's cloud models, not less. Which is exactly why I think it's a fun bet. At some point Apple needs another iphone "we made a phone with no buttons" moment.

What do you think Apple will announce today?

First posted on LinkedIn.

Token burners

2026-06-07T00:00:00Z

We were discussing an agent workflow last week, then L.D. Salmanson used the phrase "token burner", I've not been able to unhear it since, and have spent all weekend processing it.

For about a year we've all been running agents in a world where tokens were cheap, heavily subsidized, we were actively encouraging the wild experimentation that leads best to the adoption of new tools. Tokenmaxxing was a real tactic many had adopted (I was never 100% convinced on that one).

That era is slowly coming to an end. Copilot went usage-based last week, the frontier labs intro deals are expiring, and the new tooling/harnesses will cheerfully spin up hundreds of subagents in a single run. The meter just came on.

A token burner isn't just an expensive agent. It's one whose cost isn't attached to anything you can point at and call value. If you can't measure the outcome how do you know it's worth investing in. Some of our priciest agents are the opposite, a big migration that clears months of work over a weekend is worth every token it eats. The trouble will likely be the ones quietly spending all day and producing something nobody really needed.

The question I'm starting to ask is not "can we spend less on an agent", it's traditional ROI questions. For each agent that matters, what's the actual denominator? Tokens per resolved entities, per merged pull request, per hour of someone's time we actually gave back. If you can't name the thing the cost divides into, that's the smoke, and as they say where there is smoke...

I don't have a neat dashboard for any of this yet, so I'm half thinking out loud. But if you've run agents through these cheap years without watching the meter, it's worth picking the few that matter and asking the question. What does the cost actually divide into? The ones with an answer are earning their keep. The rest are likely just burning tokens.

First posted on LinkedIn.

Your graph is not a commodity

2026-06-05T00:00:00Z

Everyone seems to be building AI harnesses these days, but that market is about to become a commodity play. Agent runtimes are converging fast, the systems that decide where an agent runs, how it holds state, and how it recovers when it crashes.

The three big cloud providers each shipped one inside two quarters of each other. When major vendors converge that quickly, it is a signal, the layer is becoming a utility.

Utilities are not where moats live.

The runtime decides where an agent runs, it does not decide what the agent can trust. Those are different layers, and only one of them is rapidly commoditizing.

An agent that runs flawlessly for twenty four hours on fragmented, unresolved data does not produce better answers. It produces confident, well formatted errors faster.

So if the data matters more than the runtime, why not point the agent straight at the source? Skip the middle. Let it read the records directly. This might work for some data sets, but try that in real estate...

The same building exists as a different entity in every system that touches it. One identifier in the asset manager's portfolio. Another in the insurance file. A third across public records and tax data. Point an agent at that directly and it does not find the truth. It finds the fragmentation, and reasons confidently on top of this dissonance.

And that is just 1 entity: "property". The harder problem is not the entities, it is the relationships between them. A resident owes rent on a lease. The lease sits in a unit, in a building, held by an SPE, owned through a fund, backed by investors. Obligation, ownership, title, capital. Each link in its own system, owned by a different team, using a different system, with their own data model, resolved by no one. But mapped and combined they answer almost every question worth asking. Who bears the risk on this unit? What does this investor actually own? That chain is a graph, and the graph is the thing no runtime can resolve for you.

Your graph is not a commodity, it's a compound.

Canonical entities, reconciled records, lineage you can audit. The slow, unglamorous work of making one building one building, and one owner one owner, across every system that ever touched them. It is exactly the work nobody puts in the keynote.

A dollar of rent and a dollar of return are the same dollar, eleven relationships apart.

Resolving those relationships is the moat.

First posted on LinkedIn.

Wittgenstein and family resemblance

2026-06-01T00:00:00Z

Define "game."

Board games, card games, ball games, video games, peekaboo. What do they share? Some are competitive, some are not. Some have rules, some are improvised. No single feature is shared by all of them.

Yet everyone knows what a game is.

This was Wittgenstein's challenge, in his 1953 book Philosophical Investigations. And his answer demolished two thousand years of philosophy. Categories work by family resemblance. Your eyes, your sister's nose, your brother's chin. Features overlap across a family without any single one shared by all.

Now let's apply this to real estate data. Not "multifamily." Yes it's vague, but also too broad. "Workforce Housing." Everyone uses the term, but it's definition is inconsistent and often view point driven.

The Urban Land Institute (ULI) says households earning 60 to 120 percent of area median income. The National Multifamily Housing Council (NMHC) tax-credit proposal says 100 percent and below. Brookings says 80 to 120, and calls the term imprecise and controversial. Others drop income entirely and define it by occupation: teachers, nurses, police. Same two words. No two parties draw the same line.

Billions get allocated against a category no one agrees how to define.

Most data dictionaries try the other way. Define the category. List its features. Validate every record. It never works. Edge cases multiply. The dictionary grows and the team trusts it less.

Modern AI does not categorize by definition. It does not sort things into boxes. It places them in a space where similar things sit close together and different things drift apart. Nobody writes the rule for what counts as similar. The model learns it from the patterns, and the closeness becomes the meaning.

That space is a set of embeddings. The position of each thing is a vector. Hundreds of dimensions, no definitions, just proximity. Wittgenstein's family resemblance is embeddings just three decades before the math existed to build them.

The rigid databases of the last fifty years are becoming legacy. We are returning to family resemblance, now made computational. That is the shape of the next decade of data infrastructure. Not better definitions. Better similarity.

Klaus, Aristotle, Wittgenstein. Three weeks of dead philosophers explaining your AI data strategy.

First posted on LinkedIn.

Two models, one property

2026-05-26T00:00:00Z

Two AI Models. Same property. Confidently disagreeing about who owns it. Both have credible-sounding answers. Neither is technically wrong.

They just read different sources.

I was just reading a McKinsey article from April and their framing of the "Agentic Mesh" stuck with me:

"The agentic mesh prevents that fragmentation by acting as a coordination fabric, enforcing business rules and maintaining a shared source of truth... Without such a mesh, incremental modernization risks devolving into chaos."

Models and Agents need to be grounded in context. You have to start with the shared truth they'll all read from.

Resolve your entities (ours are properties and owners), what counts as the same property, owner, transaction, etc before you resolve your workflows, because an agent that doesn't know what's the same thing fails in ways evals won't catch.

And put real engineering into the unglamorous layer: canonical IDs, lineage, reconciliation. That's the layer that makes the impressive stuff actually work.

Models and the Agents that run on them are only as smart as the grounded truth beneath them.

Read the McKinsey article

First posted on LinkedIn.

Aristotle and your data dictionary

2026-05-24T00:00:00Z

Today's post is about Aristotle.... Stay with me. (As promised.)

Quick disclaimer: I am really not a philosophy expert. Barely an amateur. What follows is the cartoon version of an argument with two thousand years of refinement behind it. Corrections welcome.

Since Plato and Aristotle, philosophers have been arguing about whether categories are real.

Take "building." Is there a real thing called building that every actual building is an example of? Or is it just a word we use for stuff that happens to look similar?

This is the Problem of Universals, and its extreme opposites are two classic answers:

Realism: categories are real. Instances are imperfect copies of them. The Platonic version of "building" exists somewhere, and each real building is more or less a faithful copy.

Nominalism: only individual things are real. Categories are convenient labels we invent to group things that resemble each other. There is no Platonic building. There are buildings.

Two thousand years later, every data dictionary in real estate is written on the realist answer. Class A office. Active deal. Stabilized asset. Multifamily. Each one written as if there is a true Platonic version of the category in the sky, and every record either belongs to it or doesn't.

Then the meeting starts.

Is a building in lease-up Class A or not yet?
Is a deal still active if the LOI expired but discussions continue?
Is an asset stabilized at 92% occupancy if the underwriting assumed 95%?
Is a building with twelve residential units above ground-floor retail multifamily, mixed-use, or both?

The answer is always: it depends on who is asking and why.

That is nominalism showing up uninvited. The category was never a real thing in the sky. It was a definition someone wrote down, a set of cases that mostly fit, and a long argument about the edges.

Most data governance fights are really fights between the realist surface of the system and the nominalist reality underneath. The dictionary says the category is fixed. The data says the category is negotiated, every quarter, by humans with stakes in the answer.

The most valuable move a data leader can make is to stop pretending the dictionary settles the question, and start documenting how the edges actually get decided. Edge cases are not exceptions to the rule. They are the rule, recorded honestly.

Aristotle could not solve this. Neither will your data warehouse.

Next week: Wittgenstein on 'family resemblance', and why your category definitions never quite hold. (then I promise I'll be done with philosophy for a while)

First posted on LinkedIn.

Georg Klaus and the four layers of data quality

2026-05-18T00:00:00Z

Today's post is about a 20th-century East German philosopher.... Stay with me.

Semiotics is the study of signs.

How they work, what they mean, how meaning gets transmitted from one mind to another through the things we use to stand for ideas. Words, symbols, gestures, charts AND database fields. Anything that points at something other than itself is a sign, and the rules governing how signs do that work are what semiotics tries to explain.

Charles Morris defined 3, Syntactics (the structure of signs), Semantics (what signs mean), and Pragmatics (how signs get used).

In 1963 an East German philosopher (and Marxist-Leninist epistemologist) named Georg Klaus argued there should be 4: sigmatics, the study of what a sign actually points at in the real world.

These 4 definitions make a useful framework for Data Quality.

Syntactics is the schema. property_id is a string. square_footage is an integer. The foreign key from a unit to a building resolves. The row loads. This is the layer most data tooling was built to govern.

Semantics is the definition. square_footage denotes the idea of usable interior area. The team has a data dictionary. The dictionary has an entry. The entry says what the field means in the abstract. Whether that abstract definition is rentable area, gross area, or carpet area is a separate question most organizations are honest enough to admit they have not answered.

Sigmatics is the referent. APN 123-456-789 used to point at a single ten-acre parcel. After subdivision, three parcels exist where there was one, and the old APN no longer points at anything that exists in the world. Or consider the row in your data for a building that was demolished in 2019. The sign is still there. The referent is gone. This is the layer where entity resolution lives, and almost no governance program covers it.

Pragmatics is the use. The same occupancy field means something different to a leasing team chasing renewals than to a valuations team modeling NOI than to a lender testing covenant compliance. The data is identical. The interpretation is not. Most "the dashboard is technically correct but no one trusts the number" problems live here.

Every data quality issue in real assets lives at one of these four layers.

A schema mismatch is syntactic. Easy to spot, easy to fix.
A definition disagreement is semantic. Harder. Requires conversation.
A broken or duplicated property identifier is sigmatic. Often invisible to the team that produced it.
A misuse in context is pragmatic. The data is fine. The interpretation is wrong.

Most data quality programs operate at the first layer and call it governance. That is why so many of them ship clean rows that produce wrong decisions.

The shape of the next decade of real asset data infrastructure is the layers nobody took time to build.

Next week: Aristotle on the Problem of Universals, and why your data dictionary is secretly a nominalist, pretending to be realist...seriously :)

First posted on LinkedIn.

The math is correct, the total is meaningless

2026-05-14T00:00:00Z

The math is correct. The total is meaningless.

The New Cuyama, California population sign is syntactically valid and semantically incoherent.

Tama Huang posted this image the other day in slack and it resonates so well with what AI will do to your data.

Ask any production agent to roll up "total portfolio exposure" or "total active deals" or "total square footage under management" across a real operating business. You will get a number. The number will be precise to two decimal places. The number will be wrong in the same way 4,663 is wrong.

What was your last "4,663" moment?

Photo via Wikimedia Commons

First posted on LinkedIn.

$6 billion in 30 days

2026-05-12T00:00:00Z

$6 billion in 30 days. Frontier labs just stopped trying to 'direct sell' models to enterprises.

April 21. Microsoft launches its Frontier Transformation partner program. Sits on top of Avanade, the JV they started with Accenture in 2000 to implement Windows in enterprises.

April 22. Google commits $750M to its consulting partner ecosystem. Embeds engineers alongside Accenture, Capgemini, Deloitte. Strikes deals with CVC and Vista.

May 4. Anthropic launches a $1.5B AI services firm with Blackstone, Hellman & Friedman, and Goldman Sachs.

May 11. OpenAI launches The Deployment Company at a $10B valuation with TPG, Brookfield, Advent, and Bain Capital. Acquires Tomoro and 150 forward-deployed engineers from day one.

Same problem. Two structures.

Google and Microsoft are betting horizontal. Finance the existing consulting ecosystem. Let the SIs do the work. License the model.

OpenAI and Anthropic are betting vertical. Build your own consulting arm. Acquire engineers. Distribute through PE portfolios.

We've seen this movie before. Microsoft and Accenture launched Avanade in 2000 to put Windows inside enterprises. It is still operating today. This approach is not new, it's 25 years old. The product is just different.

The consistent theme of the last 30 days is that everyone seems to agree the bottleneck is institutional change, not actually capability. The model might be the product, but the deployment is the business.

Two questions I am left pondering:

Will the vertical model actually scale, or does it cap at Palantir's customer count?

Will the horizontal model actually work for AI, or does it dilute model differentiation into a partner credentials race?

First posted on LinkedIn.

Excel 2.0

2026-05-08T00:00:00Z

The Reinhart-Rogoff paper. The London Whale. Fidelity Magellan losing $2.6 billion to a missing minus sign.

All Excel errors.

For 30 years, the global financial system has run on spreadsheets passed by email, edited by analysts, and trusted because the cells looked right. No audit trail. No governance. No version control. Just vibes, formulas, and seniority.

I keep thinking about that as I watch the diffusion gap widen.

Foundation models are advancing on a curve enterprises can't absorb let alone control. New capabilities every week. New providers every month. Meanwhile most companies are still arguing about which pilot to greenlight.

But here's what the hype keeps glossing over: putting raw model access in front of every user without governance is just Excel 2.0. Same pattern. Same risk. Same eventual blow-ups.

Anaplan built a multi-billion dollar business doing exactly this for spreadsheets. Their entire pitch was that Excel needed friction. Governance, audit trails, structured workflow. So they sold the friction. AI is about to need its own version of that company.

The winners in the diffusion gap won't be the ones who hand users the most powerful model. They'll be the ones who wrap it in the most defensible workflow. Audit trails. Consistent context. Versioned prompts. Provenance. Approval flows. The boring stuff.

Excel isn't to blame, as much as AI won't be. They just shouldn't have been left alone with the world's finances.

References:

First posted on LinkedIn.

Lingua franca

2026-05-05T00:00:00Z

I’ll admit it, I saw “lingua franca” in a Sequoia deck this week and had no idea what it meant.

So I looked it up.

It’s the trade language of the Mediterranean from roughly the 11th century. A pidgin language cobbled together from Italian, Spanish, Arabic, Turkish, Greek, and French. Used by sailors and merchants who needed to do business across borders.

The part that resonates: it was deliberately simplified. Stripped of grammar. Just enough vocabulary to close the deal. Not enough to write poetry or argue philosophy.

Sequoia Capital’s framing is that natural language is becoming the lingua franca or “shared language” of computing through AI.

Whilst this might work for pure computing, it often doesn’t for business or data.

When I say “property” and you say “property,” do we mean the same thing? When my agent says “active deal” and yours does, is that the same status? Probably not.

Many industries are full of this. Real Estate it’s particularly prevalent. Every firm, every department, every team can have its own definitions, its own ontology, its own quiet conventions about what a field actually means. The words look identical. The semantics are not.

LLMs paper over that gap. They sound fluent. They produce confident output. But without a consistent semantic layer underneath, they’re doing exactly what the original lingua franca did, closing simple deals on a thin “pidgin” of context, while the deeper meaning stays trapped in each side’s local deeper context.

The “everyone can finally talk to their data” future has a quieter prerequisite: whose definitions?

Because language isn’t actually shared until the meaning is.

First posted on LinkedIn.

Why body building changed how I work

2020-10-08T00:00:00Z

(Full disclosure, the banner above is not me, I'm middle aged and injure easily, I didn't get anywhere near that level of shred)

Those who don't know me very well, might be surprised to hear that from 2016-2019 I took up bodybuilding as a hobby. Now when I say bodybuilding, I wasn't planning to get on stage in a very small swimsuit and a spray tan, but I did fill my basement with torture equipment, followed various science backed training programs and drank all sorts of protein shakes. My goal was to become healthier and stronger than I'd ever been in my life; I'm confident that I met that goal. Last year I struggled with a few injuries and it's forced me to lower the weights and become much more realistic with my goals. I'm reaching an age where throwing around iron does have risks, and healing takes longer.

Now, you might ask how does building muscle relate to leading product engineering organizations?

If you want to grow muscles, you need to learn about Hypertrophy. This is how muscles get bigger, at its root is a very simple equation:

Stimulation + Repair = Growth

In any strength-based sport, stimulation comes from specific exercises that put strain on muscles under the ideal circumstances, not enough the muscle won't grow, too much you face fatigue or injury. The repair comes from specific rest, recover and feeding of the tissues (proteins, ammino acids, fluids).

Lifting Heavy Weights + Rest Days and Plenty of Protein = Muscles Grow

You become very aware of how much stimulation you need, it requires hard work, sometimes it hurts, but it shouldn't hurt too much. You become very in-tune with how much repair you need, rest and recovery become an active process not a passive one.

This same principle can also be equated to learning, personal development, growing as a person or a group of people.

Facing Challenging Situations + Taking time to learn from the challenge = You Personally Grow

If you encounter a situation that stretches your comfort and might result in some feeling of personal pain, as long as you apply the right level of recovery and learn from the pain, you will grow, you will become stronger.

Ray Dalio, hyper successful individual and author of an amazing book "Principles", documents this as one of his foundational principles.

The key to growth is ensuring BOTH sides of the equation occur and at the right levels.

If you don't stimulate enough, that is you don't put yourself in situations where you are pushing your abilities (heavier weights, more reps) you'll never grow. You'll stay the same.

More importantly, when you do put yourself in these situations if you do not recover from the situation you will also not grow. Recovery needs to be active, in personal growth it might be taking time to be introspective to learning from the situations that were challenging. In team growth, taking actionable outcomes from retrospectives, truly changing how the team operates to adapt to the new challenge you faced with make the team stronger. As an organization, we might generate root cause analysis for risks that materialized and presented the challenging stimulus, from those we could change processes to reduce the likelihood of it occurring again. All of these are the time taken after the stimulus to recover and grow. Below are some specific examples of opportunities to take pain and turn it into growth by embracing this learning culture:

Scrum Team Retrospectives

It’s one of the few scrum events that are the foundation of the process. It is however, often seen as an event with little teeth and teams go through the motions to just check the box, and there is no growth. If you are on a scrum team, you should bring at least one change or set of actions into the upcoming sprint as a story, plan it just like other scope, add tasks, add acceptance criteria, showcase the outcome and impact to the whole team, have pride in the growth you achieved from the pain.

Defect Root Cause Analysis, not just the code change, but the process change

Due to the nature of the impact, product teams tend to focus what needs to be done to directly resolve product defects (especially ones that progressed to higher environments). These are great opportunities to learn from that pain. As well as focusing on which piece of code needs to change to fix the issue, spend some time understanding what the team could do differently next time to ensure these types of issues won’t progress beyond dev. Ask yourselves the question “what could we do differently next time to ensure this never happens again”.

Managers, don’t make people/teams afraid of the pain, coach them to learn from it

Sometimes people or teams are so afraid of a possible management backlash from the pain (even if there isn’t one), that they want to make the pain go away as fast as possible, instead of embracing it and celebrating the opportunity to grow. As a manager, you pay a key role in focusing on what is learned from the pain then the pain itself. Celebrate individuals and teams who show they learn and change. Focus your support on the teams that seem to show patterns of pain with no obvious learning. Help to build that hypertrophic culture.

The three examples above all share a common theme. Unless you are already learning from the pain, it will feel hard, uncomfortable and will take effort. Just as with building strength or muscle, in personal growth there is a decision you need to make. You can choose the easy path or the hard one . The easy path means being the same person you were yesterday, or you take the harder path, you embrace the pain take time to recover and grow from it.

First posted on LinkedIn.

Omnichord CV trigger retrofit

2012-03-19T00:00:00Z

One of the projects I’ve been hankering to do for a while is retrofit my old omnichord for CV triggers.

It seemed like a prime candidate, all of the “play surfaces” are basically push buttons, so all I’d need to do is wire up some simple transistor/optocoupler CV controlled switches that on trigger short out the button pads.

Since there are 3 rows of 9 buttons for the chord selector I thought I’d first look at the strum panel. I wasn’t entirely sure how it operated, the top surface looks like a simple physical short between multiple tightly spaced exposed pads.

After cracking the case open I discovered it was nice and simple. There strum panel connects to a 16 pin header area. 14 of those pins are the notes in the “strum”. 1 pin is the common ground. 1 pin is the kill switch pad.

So all that was needed was to wire 14 jacks up to transistors in such a way that when a trigger CV is applied to it, it shorts 1 pin with the common ground.

I was able to achieve this with a single note, but when I wired up the second jack, I found that I was now getting 2 notes for a trigger at either jack, not 1 note from each.

Something is wrong with my assumptions or my transistor wiring. So I’ve reached out to the good folks at Muffwigglers and Electro-music forums to see what they think.

First published on nomeist.com.

Touch Arc emulator

2011-01-26T00:00:00Z

(check the comments, I’m posting updates down there)

Touch Arc is a Monome Arc emulator for development purposes. It is very much not intended to be “nice” to use or a competitor to the hardware, so please don’t complain about that aspect (if you want a useable and ergonomic interface that’s a joy to use, buy an Arc).

Touch Arc comprises two parts, a TouchOSC template and a Max patch that works as the middle ware and converts the Arc OSC your app is transmitting into a format the touchosc template can interpret, and vica versa it takes the touchosc template interface input and converts it into fake Arc OSC format that your app can handle.

This way developers can work on proof of concept, sound in the knowledge that once the arc hardware is released their applications will function.

The touchOSC template initially replicates all the in and out points of the Arc 2 (I’ll do an Arc 4 one later if there is a demand).

This means there are two duplicated UI’s for each encoder, these are made up of:

64 slider ui elements, which can handle values of 0 – 15 (these are the LED’s)
4 momentary buttons, that output every 100ms either -2, -1, +1, +2 (these are the encoder turns).
1 momentary button that registers as an encoder press event.

For the LED side of things, due to the limitations in the TouchOSC interface, the LED UI is made up of 4 multisliders each made up of 16 subsliders. We could have used 64 single sliders, but they can’t go narrow enough to get 64 of them in a row, even in landscape mode, this means the LED handling middleware needs to do a fair amount of math converting 0-64 into 0-3 + 0-15 coordinates. For this reason (and mainly due to hitting a brick wall with the range wrapping round at 64, I used Javascript as the main math function handling.

The interaction conversion side of things is a much easier straight translation, so I handled that with just Max. The encoder rotation interface is faked by firing a value every 100ms for as long as one of the valued buttons is pressed in the UI. I could replace these with a slider the more you slide it from the center the faster it fires the +1 or -1 values, but i figured for ease and simplicity this approach worked.

Source code is available on google projects, so you can download it and try it out http://code.google.com/p/touch-arc/source/browse/#svn%2Ftrunk. If you can find bugs or better ways of approaching the problem, I’m very happy to update the code, or please feel free to use SVN and update the code or post other examples directly to the project.

I have spoken to Brian at Monome and he’s very happy for me to make this available, if it makes developers lives a little easier pre launch, hopefully that will be of benefit to everyone.

Update:

I’m working on a native Max UI, to see if that renders better without so many hicups. It could also be used in app patches where you’d like an onscreen representation of the Arc UI. Should be ready for testing very soon.

First published on nomeist.com.

Voltage controlled FM radio (CV radio)

2011-01-21T00:00:00Z

For a long time I have been toying with the idea of creating a Control Voltage tuned Radio that I can DIY and add to my Eurorack Modular Synth setup.

There are a ton of uses I can see in having easy access to the radio waves: random noise, strange sounds, fuzz and white noise.

But being able to control the tuning with CV so I can jump around the dial, or slew my way from one spot to another I think would be really awesome. If for no other reason than I like the idea of programming up a sequence and then every time it runs it will be different since the sound source is constantly evolving and changing.

So research began by looking at how radios work, and things didn’t look good to start off. It seems that radio tuning is all about capacitance, not voltage.

The simplest tuner consists of an inductor and capacitor connected in parallel. The capacitor is usually made to be variable (although the inductor can made variable it requires a more complex mechanism and is rarely used). This creates a resonant circuit which responds to an alternating current of one frequency

http://en.wikipedia.org/wiki/Tuner_(radio)

This means “most” of the time the tuning pot is not a pot but a variable capacitor type thing, which means you can’t just swap out the pot with a CV source (which was my initial hope, ignorance is bliss).

All seemed at a lose until I found out that some radios use what is called “varactor diode tuning” this is a diode that in essence replaces the capacitor bit, but the neat bit about the diode is that it’s voltage controlled. This means that the tuning pot will be handling voltage and suddenly we have somewhere we can bolt our CV into.

The next snippet of info, was that Ramsey (the makers of great electronics DIY kits) make a series of kits that all use Varactor Diode Tuning, include a $40 FM receiver kit.

So later part of 2010 I ordered one up, and it sat on a shelf for a few months whilst I tried to finish off other “higher priority” projects.

Then NAMM 2011 came around, and I was intrigued to see that Buchla, the makers of VERY high end modular synths was showcasing a new module the 272e which had 4 FM receivers that could all be referenced via CV. Now their concept is very different to mine, they have digital tuners that you tune and they then allow you to control the outage from each using complex envelopes, there is no CV control of the tuning – that said they do look really very nice indeed.

Buchla patch Model 272e through the 296e Spectral Processor. from Richard Devine on Vimeo.

But if nothing else it spurred me back into life. So earlier this week I soldered up the Ramsey kit.

With some awesome help over on the muffwiggler forums (MANY THANKS DAVERJ!)

I tapped into a couple of places on the PCB and hooked it up to a very low frequency Oscillator I had running a sine wave, and low and behold I had CV controlled tuning.

Now the tricky bit. I doesn’t work great. It doesn’t work with CV only with the Oscillator, so it needs a stack load more tweaking and testing. But my hope is in the next week to get it hooked up to Silent Way and have a fulling CV tunable radio incorporated into my modular synth.

First published on nomeist.com.

Arduino step sequencer

2010-03-24T00:00:00Z

Ever since buying a couple of modules, I’ve fallen in love with analogue modular synths, they are addictive beyond belief and I’ve yet to find anything as engrossing as standing in front of it twiddling knobs for no apparent reason generating all sorts of swirling modulating filtering noise. I can loose hours very easily. As always though I’m never satisfied and I want to tinker. One of my projects I’m most actively researching is the idea of an arduino based Step Sequencer.

There are a million threads online with people desperately trying to get their trusty arduino’s to generate control voltage. The problem you have is that the arduino doesn’t live in a real analog world, it’s all about the digital. The only smooth it can do is PWM, and even then it’s really not go lovely to listen to. There are huge threads about people applying filtering, or faking analog with complex software, or powering 8bit, 12bit 16bit DAC and the huge amount of arduino sketches needs to handle them, and to be honest it’s totally terrifying for something that is as easy as turning a pot. So I decided to take a different approach. (if you really want to make music with an arduino, go see midivox, I just got a couple and they kick ass)

I want to keep the analog signal pure, and only handle the step side of the equation using the arduino. So the initial idea would be 8 pots, 1 thru 8. a single CV in, a single CV out. The arduino would be hooked up, so that when messages are sent down the USB connection, current passes thru 1 specific pot and comes out the other side.

So I can set up my “notes” with the analog pots, and then just trigger which one, when, how long and what order they get “played”.

After this initial prototype, I’d shoot higher and aim for 3 or 4 rows of 8 each with their own dedicated CV in and out, and gate outs, and tempo outs, and LED’s flashing, and a front accessible USB port, and way to store sequences on a memory chip that is slotted into the front and sequences chosen using nothing but the power of the mind, etc etc etc.

It seemed like a no brainer DIY project, that maybe one day would lead to PCB’s and kits and open source and all that stuff I aspire to do.

Due to my limited real knowledge thought I’m already overflowing with questions. First of which is how I do this, and what’s the best “switching” mechanism should I use. Should I use relays, optoisolators, Voltage controlled resistors, transistors or just good old plain Jane relays. I have some open question on the arduino forums so hopefully I’ll get some validation for my madness. Any suggestions feel free to jump in.

First published on nomeist.com.

Casio SK1 MIDI retrofit

2010-01-11T00:00:00Z

Finally finished up my midi retrofit of the Casio SK1, and I’m very happy indeed with it. The HighlyLiquid UMR kits was a breeze to assemble, and if it hadn’t been for my initial soldering on the kit to the Sk1 board backwards it would have been an afternoon project.

For those repeating this process, triple check the numbers on the ribbon area of the SK1 that you solder the kit to, the 12 is on the left (depends on which way round you’re looking at it, so DOUBLE check).

I have some issues with the sample recorder, sometimes the SK1 needs to be turned on and off to get it to record again and it doesn’t seem to store the sample thru a power cycle (it might never have done this so I can’t fault anything there).

I can see this becoming a pretty useful part of a LIve improv type session, with a laptop, Monome and Sk1, running long Polygomé style midi from the Monome thru the Sk1 using samples recorded there and then.

I’m probably going to look at picking up another 2 or 3 of the SK’s this year, to expand the collection and have some for redundancy.

I’m also still toying with adding some bend points. Though I’m thinking I’ll take it one step further and use digital potentiometers to make the bends automatable from a computer. So it might take some time to work through.

In the meantime, my next Midi retrofit will be the Ace-Tone keyboard that I recently picked up. I’m hoping the 2 octave retrofit will be pretty simple with the MD24 kit from highlyliquid. If it becomes a nightmare I might step it back to retrofitting one of my stylophones instead.

First published on nomeist.com.