I’ve been using AI coding agents heavily for the past few months. Along the way, I’ve learned something counterintuitive about how to get the most out of them.

The temptation: Spin up 9 agents, each working on a different task in the same codebase, merge everything at the end. Compute is cheap. This should be 9x faster, right?

The reality: Your agents spend more time resolving merge conflicts than writing code.

The Merge Tax

Here’s what actually happens when you parallelize work within a single project:

Every parallel branch creates a future merge event. The cost of that merge isn’t constant. It depends on how much the codebase has changed since the branch was created. And that depends on how many other parallel branches have already been merged.

This creates a compounding problem:

• 2 parallel agents: Occasional conflicts. Easy to resolve.

• 5 parallel agents: Frequent conflicts. Some cascade. Resolving one creates new conflicts in the others.

• 9 parallel agents: A clusterfuck. Agents spend more time resolving conflicts than writing new code.

The merge tax is superlinear. Each resolved conflict changes the base, invalidating other branches’ assumptions. Yes, AI agents can resolve merge conflicts. They’re actually quite good at it mechanically. But that doesn’t change the fundamental math: the conflicts grow faster than the productive work.

Why It’s Worse Than Amdahl’s Law

You might be thinking of Amdahl’s Law: the sequential portion of your work limits your maximum speedup. That’s true, but Amdahl’s Law assumes the parallel portion can be perfectly parallelized with zero coordination cost. Under Amdahl, more parallelism always helps. You get diminishing returns, but always positive returns. The curve flattens but never goes down.

That’s not what happens with AI agents working in the same codebase.

The merge conflict problem introduces a coordination cost that Amdahl doesn’t model. If you have N parallel branches, the potential conflict surface is roughly N(N-1)/2.

Every branch can conflict with every other branch.

But it’s worse than that, because merging branch A changes the base for branches B through N, potentially creating new conflicts that didn’t exist when those branches were created.

This means the total work isn’t just “parallel portion + fixed sequential portion.” It’s “parallel portion + coordination overhead that grows quadratically with N.” Past a certain number of agents, the coordination overhead exceeds the time you saved by parallelizing. The curve doesn’t just flatten. It goes down. You’re not just getting less benefit from each additional agent. You’re getting negative benefit.

This is a known phenomenon in systems theory. Neil Gunther’s Universal Scalability Law models exactly this: a coherency penalty that grows with the square of N, creating a peak throughput beyond which adding capacity makes things slower.

What I’ve found is that AI agents in a shared codebase hit this peak surprisingly fast.

Parallel Projects, Not Parallel Tasks

So what’s the right unit of parallelism?

The project, not the task.

Say you’re building a SaaS product. You have a Rails backend, a React frontend, and an internal CLI tool for data migrations. These live in separate repos. You can absolutely have agents working on all three simultaneously. They don’t share state. No merge conflicts. No coordination costs. True parallelism.

But within your Rails app? Don’t spin up five agents to build five features at once. The auth changes conflict with the billing changes. The new API endpoint conflicts with the middleware refactor. Each merge invalidates assumptions the other branches were built on.

Instead: one agent works, logs what it did, and the next session picks up where the last left off. No branching. No merge resolution. No wasted work.

This sounds slower. It isn’t. Because:

1. Zero time lost to merge conflicts. In my experience, conflict resolution was eating 30-50% of parallel agent time.

2. Each agent has full context. It reads what the previous agent did, understands the current state, and makes decisions with complete information.

3. No rework. Parallel agents constantly duplicate effort or make contradictory changes. Sequential agents don’t, because each one sees the current truth.

This Is a Design Choice, Not a Limitation

Think about how software development actually works. PRs can only be merged one at a time. Deploys are sequential. The critical path through any project is fundamentally serial. The art is choosing the right sequence, not making everything parallel.

A better concrete example: you have four features on your sprint:

1. Add a “last login” timestamp to the user profile.

2. Build an admin search page for users.

3. Add email preferences to the settings page.

4. Implement a “deactivate account” flow.

Four vertical slices. The temptation is four agents. But all four touch the users table. Three of them modify the users controller. Two of them change the settings view. Agent 1 adds a column to the users migration. Agent 3 adds a different column in a separate migration. Agent 4 adds a deactivated_at column and a scope that filters active users, which breaks agent 2’s search query that didn’t know about it. Now you’re resolving conflicts across migrations, controllers, and views that wouldn’t have existed if you’d just done them in order.

When This Gets Interesting

“Massively parallelizing work just makes more work later. Everything has to be merged one thing at a time anyway.”

- Me, at some point in the past week

Git worktrees are a short-term solution that only works for a subset of simple projects. For real production-grade stuff, they’re a far cry from what’s needed. Full isolated environments (containers, VMs, cloud dev environments) will get there eventually. But even then, the sequencing becomes very important, because PRs still can only be merged one at a time.

The future isn’t 100 agents all writing code simultaneously. It’s one agent moving very fast through a well-sequenced backlog, with full context at every step, handing off cleanly to the next session.

That’s slower in theory and faster in practice.

The Takeaway

If you’re using AI agents for software development:

1. Parallelize across projects. Different repos, different codebases, go wild.

2. Sequence within projects. One agent at a time, with structured context handoffs.

3. Invest in context, not compute. The bottleneck isn’t how fast your agent writes code. It’s whether the next agent knows what happened.

The coordination problem isn’t routing. It’s context. Give every session full context and you don’t need parallelism to go fast.

This insight is part of why I built WCP, an open-source work tracking protocol for AI agents. It gives Claude persistent memory across sessions: tasks, status, decisions, and history. One agent works, logs what it did, and the next session picks up with full context. No merge conflicts. No lost work.

One command to install:

claude mcp add --transport http --scope user wcp https://workcontextprotocol.io/mcp

Dave Paola is a technology leader and the creator of WCP.

It doesn’t require identity flexibility. It doesn’t threaten.

Isolation and content-consumption as a learning style can be a defense mechanism that becomes a personality trait.

This isn’t fixable by others. It’s deep.

Subscribe now

1. Agentic coding

2. The Lost People of Mountain Village

3. Segmented controls vs. Tabs

4. Renewables vs. Nonrenewables in eng mgmt

5. Layoffs at tailwind

Bonus: What I’m reading

Let’s dive in.

1. Agentic coding

A friend sent me this earlier in the week:

It was sent with an accompanying thought about how shaken he felt about the future of software engineering, or more specifically, what the job of a software engineer will look like going into 2026.

Unlike some other folks in my life who seem to be putting their fingers in their ears on the topic, this individual is embracing AI whole-heartedly, acknowledging (correctly, I think) that more and more, the end result “aren’t actually trash”.

Which is awesome, and scary.

Correction: it’s scary if your job security is based upon your ability to type code into a code editor.

I believe the engineers who will thrive going forward will be the ones who can communicate and treat the AI agents like a team, and guide them appropriately. Provide guardrails, examples, patterns, specify the “what” at a high degree of detail, as well as the “how” at a high level, and then get out of the way.

I think it’s anxiety inducing because it’s showing how little so much of our hard earned judgement about specific code patterns and rules matter to the end result.

Someone once told me that the best technical leaders are a combination of systems thinkers and clear communicators, and it’s something I’ve never forgotten. I think it also applies to this current….crisis? Are we calling it that?

The other common thread I’m seeing is concern around companies. e.g. is my product still defensible now that chatGPT can trivially replace it, is my company’s culture a place where I can trust I’m staying modern in my skills, have my leaders lost their minds, etc etc.

While cost/benefit still applies to most decision making in this realm, historically the cost of changing software has dwarfed the cost of creating it from scratch. That’s what might be changing here. But, all that would mean is that software is going to change more. There still needs to be someone in the driver’s seat.

I refuse to take a victim attitude though. It’s totally within our skills and ability to thrive in the new world. We just have to adapt. I refuse to put my fingers in my ears and pretend it’s all going to blow over.

There is obviously a lot more here. Other related topics that I hope to write about in the future:

• Our code as a black box - how much do we need to understand it? How much does a nontechnical CEO understand it today? How about any one engineer?

• The importance of clear communication in the era of agents

• How do we trust agents

• The importance of QA (and…can we automate it?)

• Engineering velocity not being the bottleneck anymore, and what that means for teams (hint: it’s context!)

• General management skills being as important as ever (and just as lacking in many contexts)

• My experience working on an almost identical project as OpenAI’s Sora for Android using Codex

2. The Lost People of Mountain Village

Part 1 and Part 2.

A surprisingly hilarious mockumentary about a mountain resort in Telluride, told from the point of view of a fake future anthropological perspective.

This one actually made me think how little of this type of thing I see anymore. Maybe it’s my information diet, but the combo of its length, the effort that went into it, and even the cast, combined with the fact that it’s obviously not shot with professional equipment reminded me of high school and college.

(Also it touches on very relevant topics that remain today in mountain towns like Telluride, Tahoe, etc. Cost of living for locals, tourism as the primary revenue source, and more.)

3. Segmented Controls vs. Tabs

Over the last year at my day job we’ve rewritten our Android app from scratch using modern tech. The iOS app has been around for something like 17 years and has a lot of established UI patterns, for which we often wrestle with decisions about how to port to Android. We want to provide users a common experience that doesn’t change much, if at all, between platforms, but also respect the platform idioms and conventions so that Android users don’t feel they’re using an app copied pixel-for-pixel from iOS. Android as a first class citizen.

To that end, we aren’t using a cross-platform layer like Flutter. We went full native with Kotlin and Jetpack, etc. In hindsight, I believe this was clearly the right call.

One interesting topic came up this week and I learned a bit more about UX design: Segmented controls on iOS vs. Tabs.

In our app, users can perform inspections and submit checklists. When they open an inspection or checklist, it creates that record as a draft, and they can save those drafts and resume them later. So we have a screen where the user can pull up a list of prior drafts, and we decided we wanted them to live on the same screen, but organized according to a list of inspection drafts and a list of checklist drafts (vs. having them interleaved in the same list).

So we had to decide: do we use a tab or a segmented control?

This is a segmented control on iOS:

And on Android:

The single-choice certainly does look and behave like a tab. So which should we use?

What I learned is that there are three potential semantic roles that a control like this could play:

1. Mode switch (same data, different lens)

   • e.g. “List | Map”

   • “Active | Completed”

   • “Day | Week | Month”

2. Category navigation (different datasets)

   • e.g. “Overview | Tasks | History”

   • e.g. sections of a feature

3. Filter or scope

   • e.g. “All | Mine | Team”

   • e.g. status filters

Instead of telling you which we decided upon, I’d first like to ask you what you would choose?

4. Analogizing renewable resources vs. Non-renewable resources in engineering management

To quote Donella Meadows:

Non-renewable resources are stock limited. The entire stock is available at once, and can be extracted at any rate (limited mainly by extraction capital). But since the stock is not renewed, the faster the extraction rate, the shorter the lifetime of the resource.

Renewable resources are flow limited. They can support extraction or harvest indefinitely, but only at a finite flow rate equal to their regeneration rate. If they are extracted faster than they re-generate, they may eventually be driven below a critical threshold and become, for all practical purposes, nonrenewable.

This came up for me this week when thinking about my engineering team’s velocity vs. the company’s ability to spec out product requirements. Thinking about the stocks (PRDs) and flows (defining those requirements, shipping them) was a helpful framework that clarified where our current bottleneck is. Along those same lines we’ll be closely watching the oscillations that occur as the bottleneck changes.

5. Layoffs at Tailwind

https://github.com/tailwindlabs/tailwindcss.com/pull/2388

The comments. My god, the comments. Who are these people? A RIF is a truly awful experience, for everyone involved.

What I’m reading

• Sapiens. This is my wind-down book before bed. I’m thoroughly enjoying it. My favorite part so far is that I don’t feel talked down to - the author assumes some knowledge already of human history, which I daresay is pretty refreshing.

• The Revenge of the Analog. Just started. Morning reading. As a lover of both physical books and paper notebooks, I don’t expect to be particularly challenged by this one, but it seems like it will be a fun read. It’s already used Rdio as an example of streaming music (compared to vinyl) instead of Spotify, so it’s already won me over.

• Be Who You Are. I’ve always loved Alan Watts, but primarily via audio. I’ve actually obtained his entire works on MP3, due to the AI slop that has very, very unfortunately proliferated on YouTube. I find reading his work to be very different. Admittedly this is also what I’ll reach for if I’m awake at 2am and need to fall back asleep!

That’s it for now.

The pattern is: “Pop quiz!”

These are masked rhetorical questions, asked by a leader, to a team or team member to gauge the quality of the work or the approach.

Pop quizzes sound like questions, but they’re really not. They’re really an impromptu test. Did you get the right answer? Or did you get the wrong answer?

An earnest question is approached with genuine curiosity. As the leader, I have in my head a scenario I’d like to make sure is covered in our solution. Instead of pop-quizzing and asking the team “hey, what should happen in scenario X?” (which is a pop quiz), I asked “Can you tell me about scenario X?”

It seems like a small change but I argue the difference is massive.

The way you can tell if you’re imposing a pop quiz is whether or not your response to their answer is “yes”, “that’s exactly right” or some variant thereof. It implies there is a right answer and a wrong answer.

If, instead, your answer is “that’s interesting”, or “I didn’t know that”, or even “wow, they haven’t thought this through, we need to course correct” - congratulations, you asked an actual question.

Why are pop quizzes bad?

Pop quizzes are an insult to the team. It demonstrates that you don’t trust them, and that rather than judging based on the results they deliver, rather than approaching from a place of curiosity, you approach from a place of “I already know the answer”. If you already know the answer, why didn’t you give it to them already? It’s a double bind.

Real questions are way better. They sound more like: “how are you thinking about the problem?” If the answer is “we aren’t” - then great, you’ve highlighted the issue and can now help them work through it. If the answer is “here’s a solution”, they have demonstrated that they’ve thought through the problem at least enough to have solved it. (If you disagree with their solution, consider again whether this is a form of a “leader knows best” or if you’re actually genuinely curious to hear what they have to say.)

The great thing about real questions is that everyone learns - you get to learn about how your team solves problems, what their level of scrutiny and depth is, where there are gaps, and potentially even better solutions than you would’ve thought of. The team gets an authentically curious leader who reinforces their strengths and shows them with their words and actions that they’ve built credibility to solve problems.

Pop quizzes imply that you’ve already got the answer, they need to just listen to you, and by the way if they didn’t get the answer right, they got the answer wrong.

Pop quizzes encourage the team to turn their brain off, avoid speaking truth to power, do the bare minimum, wait for you to have all the answers to everything.

Genuine questions encourage the team to engage their brains, tell the truth, go above and beyond, and make better decisions while you go have dinner.

But yesterday I went for a run for the first time this spring, and realized: I had no easy way to map the route beforehand (to have a plan), or afterward (to see how far I went) .

So I whipped up RouteSketch: https://github.com/dpaola2/RouteSketch

My process:

I used chatGPT o3 to generate a one-pager PRD and then a software design document. Constraints: vanilla JS only, no build, everything in a single HTML file. No saving of files or route management - just point and click on a map, show the route and its distance, using publicly available map data only.

My thinking was basically to get the simplest possible thing working, exercising that muscle of “build the smallest quantum of value”.

I plugged that PRD and SDD into Aider, with Claude 3.7. It took only a single additional prompt to fix an issue w/ the button initially, and it worked exactly as described.

Then, I thought: what’s the simplest way to post this run to Strava?

So I added support for import/export GPX files (using a quick PRD and SDD as before, this time using claude within Aider, to enable the context of the code to be included).

I exported the route, and Strava told me my GPX files were missing timestamp information, so I added an optional time duration input that will assume a constant pace and interpolate the timestamps for each waypoint in the route.

Then I stopped. It’s good enough for now.

It works without hosting. I can just open the HTML file in my browser on my local filesystem. Or I can deploy it to GitHub pages. Or anywhere.

Total elapsed time working on this project was probably 15m or so. And it works great.

As someone who's been coding since I was in middle school, this kind of thing just astounds me.

Could I have used caltopo? Probably. Or one of numerous other tools. But this was fun and easy.

We're living in the future.

It turned out to be an extraordinary journey through the universe of incentives alignment, financing, higher education examination, PR, emergency crisis management, and more.

One thing I see and hear a lot about these days is income sharing agreements (ISAs). I wanted to share a bit about this topic from my vantage point and also provide some color on where the industry has gone.

Running a school is expensive

If I could travel back in time and tell myself one thing in 2012, it would be: a school is not a software company. Simply trying to put a school online, and tweak the ratios of student to teacher, are not enough to give it the financial attributes of a software company.

Education companies can have technology, but that technology is almost never something that makes the business behave like a software business.

As mentioned, the primary cost is headcount. There are other costs, but they are negligible at scale. You can deploy technology to help alleviate some of the burden, but at the end of the day, there is a certain number of people you need to hire in order to serve more students. Want to enroll X more students? You'll need ~X/N more instructors.

At scale, this really, really matters.

Aligning Incentives

It turns out, that aligning incentives is the Name of the Game in coding bootcamps. Without it, the equation quickly leads to exploitation, especially when operating at scale. Unlike a SaaS business, your COGS is a meaningful percent of your cost, which grows with your customer base. While we were a 1:1 model at first, we quickly realized how unscalable such an approach was - and customers even expressed a desire to experience more group learning, which led us to incorporate more of a one-to-many approach.

Regardless, in both approaches, your primary mechanism to improve your margins as an education company is to reduce your COGS, not your OpEx.

And your highest line item in COGS is headcount of instructors.

Faced with such a challenge, what's the most educationally effective, and cost effective way to reduce your instructor cost?

You hire your own graduates as instructors.

Actually not as terrible as it appears

This actually makes sort of sense.

Recent graduates are best positioned to explain complicated concepts to newbies. Data bears this out, as does student and instructor testimony. As does lots of educational research.

It's also very hard to find really great seasoned instructors, especially at scale. It's essentially a hiring problem. Which means you have to have people at the company responsible for interviewing, accountable to outcomes and metrics, and enough capacity to get it done.

But, you can imagine the optical challenge of conveying to current (and prospective) students that the price of the program stays the same while the instructors are paid less than the experienced folks of the past.

This is one area where, I believe, much of the public is mistaken about what they want. They think they want experienced practitioners, but for 90% or more of the educational experience, you actually want to be taught by someone who just learned the material. But there is a limit to how much you can educate the public. Good luck with that.

(A related and important topic that I do not have time to go into today: how do you retain the great instructors, provide them higher leverage ways to invest their time and energy, without growing your COGS?)

Pricing Experiments

When you have an intense program that requires human beings to serve customers, you have to set a high price tag. Setting a high price tag also informs customers about what type of experience they can expect. A high priced product or experience attracts buyers of means.

When we started, we didn't offer external financing at all. We literally took on the debt ourselves. If students couldn't pay, we gave them payment plans. That meant we fronted the cash ourselves to pay the instructors, develop the curriculum and software, and try our best to get them all jobs. When we were small, this actually worked just fine.

But at scale it obviously breaks down. A dropout rate of 5% for 10 students is easy to absorb, but the same dropout rate at 100 or 1,000 students is not so easy. So we had to find other ways.

We tried a bunch of stuff. We tried partnering with companies like Affirm to offer 3rd party financing. We explored accreditation to qualify for federal financial aid. We explored selling our payment plans as a debt instrument to third parties.

And we experimented with ISAs.

What are ISAs?

Income Share Agreements (ISAs) emerged as an alternative to student loans, allowing students to pay a percentage of their future income instead of upfront tuition. ISAs gained significant traction in coding bootcamps, which promised to align school incentives with student outcomes.

It sounds great, right? You pay based on the outcome you achieve, not up front. It aligns incentives - if the school doesn't get paid unless you get a job, then they are damn incentivized to ensure you're job ready. It offers students an extremely flexible payment structure. And payment caps limit the amount students will have to pay when they do get employed.

It's also attractive because it offers access to underserved students. They don't require a high credit score. You can imagine the personal and cultural importance of this fact at the time, and even today.

And they aren't a loan - or at least, it doesn't feel like a loan. This psychological benefit to customers was a big deal! No debt if you don't succeed. Sounds great!

Ehhhhh

Despite these clear benefits, ISAs at our bootcamp, and more publicly in other bootcamps you may have heard of, often led to problematic outcomes:

• Overhyped placement rates - deserving of its own standalone essay

• High cost to successful students

• Opaque terms that were difficult to communicate or understand (how many jobs do you have to apply for? How do you prevent people from going through your program for free and never paying, and waiting until the end of the term period to apply for a job? Hard problem.)

• Reputational harm from lawsuits, scrutiny from regulators (even if no foul play)

These are all important downsides. But there's one last downside that matters most.

Imagine you're running a company with a high COGS, idealistic yet pragmatic staff who care about the students, serving customers who are attempting to authentically change their lives by upskilling themselves using your program. You're spending money hand over fist, not on foosball tables and xboxes, but paying your instructors.

And you've adopted ISAs as your primary financing vehicle.

Skin in the game and increasing dropout rates

If students drop out before they're able to get a job, no amount of incentive alignment will obscure the fact that the cash you invested to serve that student is a loss.

Every student that drops out without having paid is a loss. Every single one.

We saw dropout rates spike hard when we adopted ISAs. It happened so quickly that we hit the brakes.

We lost a lot of money on it. So have others. You can imagine the squeeze.

When students don't have skin in the game, at coding bootcamps, they drop out at a higher rate. We were operating at scale, with literally thousands of concurrently enrolled students. We saw the data. It was clear.

And we've seen that data bear itself out with other schools as well. ISAs lead to higher dropouts, which leads to a financial loss for the school.

And when the school is feeling the financial squeeze, that's when the ol' exploitation term starts to get thrown around a lot more.

Tuition Reimbursement

We moved away from ISAs to Tuition Reimbursement. Students were required to pay up front - or partner with a financing option that supplied us with a "promise to pay" that was backed by cash that we could book.

That was 2018 and then I left, and the school was sold to a competitor, who itself was eventually sold to a bigger higher education company that I believe is now defunct. So it's all ancient history.

What about other non-coding industries?

Given this history, should you remain open to ISAs in a different context — say, trade schools — where student profiles, program durations, and job market dynamics are different? Can ISAs be responsibly deployed as a tool for equitable access in vocational education?

I think yes, with caution and structure. ISAs may have a more promising role in trade schools, if designed responsibly:

• Stronger alignment with outcomes: Tracking placement rates closely and honestly. A bit of research tells me that programs like diesel mechanic training have reported 96% completion and 98% placement. This shows that high-certainty career pipelines can be supported by ISAs

• Lower income ceilings reduce overpayment risk: One common complaint about successful students who relied on ISAs was that they paid wayyyy more than felt fair. Most trade careers (e.g. HVAC, carpentry, pharmacy tech) have more modest, but stable, incomes, which could naturally constrain this issue.

• Investor / company fit: In some sense, an at-scale developer bootcamp was just a terrible fit for venture capital. Because it doesn't have the dynamics of a software or technology company, 10xing, 100xing growth is much more financially constrained. Or maybe it looks more like hardtech, or something.

• Have regulatory frameworks matured? If ISAs are now more clearly recognized as credit products, perhaps consumers are more protected with clearer terms.

My Takeaway

It's very hard for me to get past the scar tissue that ISAs have from my bootcamp years. I suggest any trade school attempting to leverage ISAs should:

• Be radically transparent with students about repayment terms

• Cap payments clearly and conservatively

• Align program quality and job placement rigorously to outcomes

• Avoid expectations of scaling fast without acknowledging the risks to student outcomes

There's other scar tissue as well. Selecting and managing instructors, curriculum development, marketing challenges, subscriptions vs. tuition, and more. But those essays will have to wait.

After my recent re-read, I’m finding it hard to ignore the various visible consequences in our world of this rather wild hypothesis. (And I should say that I still think of it as a hypothesis, albeit a fascinating one to consider, if true.)

Every time I read or hear a metaphor, I’m more reminded of their power than ever before.

This morning, I was reading one of the Daily Stoic quotes:

“Drama, combat, terror, numbness, and subservience—every day these things wipe out your sacred principles, whenever your mind entertains them uncritically or lets them slip in.”
—MARCUS AURELIUS, MEDITATIONS, 10.9

This quotation takes on a completely new dimension after reading Jaynes. Before, its meaning is fairly straightforward: be careful what you let into your mind.

After, in a timeline where humanity has only recently gained the ability to introspect and do anything aside from live in the moment and obey the gods, it feels more like the emperor is a normal human wrestling with the new metaphoric phenomenon of consciousness!

It turns out that the very idea of a mind that is a space where the “analog I” has any amount of control is a metaphor, not a physical reality. (One of the fascinating topics in the book.) To hear an individual like Marcus Aurelius describing abstract concepts like drama or terror as physical entities that can be “blocked” at all is, if you buy into bicameralism, a relatively new phenomenon. Humanity is realizing that there are things that can be “let in” or not, and that those things have consequences to the future. Indeed the spatialization of time is itself a very new thing to humanity around 1,000 BC.

These are entirely new concepts, and I think explains the power and relevance of Meditations and other works like it.

It also is a terrific reminder that there is a certain relativity to all of this. Had we not developed the language of metaphor, we may never have become conscious in the way we know it today. Or it would have developed differently. And that means we potentially would have very different ideas about good and evil, right and wrong.

There are a lot of other things like this in daily life.

I’m a frequently listener of Alan Watts. Have been for years. The meditative goal (so to speak!) of living utterly in the present moment bears a striking resemblance to the experience of bicameral human beings. The history of the Hindu culture reaching back into ancient times is certainly a lineage worth exploring - seeing as the breakdown of the bicameral mind is set at roughly the time period between the Vedas and the Upanishads.

There's no more shuffling to the conference room with your stuff, finding a new seat, or standing up in front of the group to give a presentation. And sitting down gives you a distinctly different energy than standing up.

So, a month ago, I bought a cheap stand-up desk to see if it would affect my work.

Surprisingly, it worked. The standup desk has materially improved my work performance, especially during meetings and presentations.

Why is this?

1. Mindfulness: My mind is clearer

2. Focus: My contributions are fewer, but better

These two factors have become so obvious to me in hindsight that I'm actually embarrassed when I think about my work game performance before this.

Mindfulness: My mind is clearer

When I'm standing all day, it must active some limbic-system, physiological effect that boosts my mental performance. I can't think of any other reason that it would make my mind clearer - but it absolutely, 100% does.

I notice more. I'm paying better attention to the topic, to who's saying what, to the emotional state of people and to the comparative importance of each item on the agenda. I'm finding better, faster ways to note followup topics, ideas that spring to mind, or questions that arise.

(This has, I believe, led me back to Vipassana, which is a topic for another day.)

Fewer, better contributions

Partly as a consequence of the increased mindfulness, but for other reasons I don't quite understand yet, I find myself better able to think before I speak when I'm standing. Because my notes and attention is on higher leverage things, I'm returning to a place of being very selective and focused in how and when I speak up.

It's a bit of a platitude that when you speak less frequently, your words have more power. It's a platitude because it's true, and it's very obvious when it happens in a work environment because you can tell when people are listening, really listening.

I'm not claiming perfect focus, because I do still get off-topic, but there has been a stark difference in my ability to identify and select the highest leverage contribution in any given circumstance at work. It coincides perfectly with my acquisition of the standup desk, so...it's gotta be a factor.

Not expensive

I think I paid $50 for this on Facebook marketplace. It’s not fancy. It’s not high end. But it gets the job done in a humble fashion.

I'm not going back

I do not know why these factors have culminated into a quality outcome for me. Maybe it's because they exist in a feedback loop. Maybe it's because there are other, unnoticed things happening in my life that are also influencing things. It's probably all of the above.

I still have a seated desk that I use frequently - for reading, for long-form typing on the laptop, for relaxing with a hot drink or other misc occasional deep work.

But what I know is: I'm not going back to sitting at a desk full time. The benefits are just too huge for me to ignore.

So I have to be right, all the time, in order to do my job well.

When I started working on a team, this put me at heightened risk of mixing up my goals. It’s too easy for “being right” to be the end-goal, rather than shipping what we need to ship as a team.

When I became a manager, this became a gigantic obstacle.

Turns out, working with people who care about being right all the time is a giant pain in the ass. They’re not pleasant to be around. They can be grating and confrontational. They aren’t always aware of their negative effects on those around them. And they often fail out of collaborative, team environments.

Does that sound like a great manager?

Talking vs. Listening

When you’re talking, you’re projecting outward. You’re working through a problem, maybe. You’re explaining your point of view. You’re attempting to persuade. There is a recipient.

Sometimes these can even devolve into tirades.

Everyone knows what it’s like to be on the other end of a tirade. It sucks. You aren’t heard, you aren’t being asked what you think the best way to solve a problem is, or what ideas you have to improve the team or product. You’re being talked at.

Too many people suffer day in, day out on teams where nobody ever listens to them. The moment a manager actually listens to one of the bright individuals on their team, it can be like handing a glass of ice water to someone in hell.

Listening means shutting the hell up. It means sitting with things you don’t agree with. It means genuinely entertaining the idea that maybe this person knows something you don’t. (In fact, that should be why they were hired.)

The true moments of leadership can appear when someone on your team, or maybe even large parts of your team, are working through an issue and they haven’t arrived at the answer! They all look to you.

This is where the magic can happen. You’ve been here before. You know the solution to the problem. What do you do?

Take a breath and resist your default behavior. Resist the temptation to give them the answer.

Instead, ask questions that help them understand the path to the answer. This approach can even help the group collectively arrive at a better solution than what you would’ve done. That’s when the magic happens.

The results of being effective instead of being right are many. Your team will stick around longer. They’ll enjoy working with you. They’ll grow. (So will you.) You’ll have done one of the greatest things a manager can do - provide an environment for growth and development.

Have any of you gotten caught in the trap of trying to be right instead of being effective? Tell me about it in the comments.

(P.S. A future post will explore when you should weigh in, and how to find truths and common ground in order to persuade.)

I was working on a new feature at work and discovered a nasty conditional that determines where to redirect the user after they log in.

For some reason, this is the time it hit me: every single rails app I’ve ever worked on that had any amount of real-world usage had this conditional. Every single one. It got me thinking about why.

Reminder: Inherent vs. incidental complexity

Rich Hickey has a great quip about this. Inherent means “your fault” (the business), incidental means “my fault” (the programmer). It really means inherent complexity is a fact of life - the system we’re modeling has inherent complicated behavior or expectations. Incidental complexity is what we as programmers add to the inherent complexity in order to get our jobs done (or for other reasons!)

Now, here are, I think, the reasons that redirect logic is often complex:

1. Multiple user roles. Different types of users often see different things after they log in. Inherent complexity.

2. Conditional redirects. If this is the first time the user logs in, or their account is in an incomplete or invalid state, we need to take them to different places. Inherent complexity.

3. Permissions. Different users, even within the same role, have different permissions to see different things or take different default actions. Inherent complexity.

4. Third party auth. Integrations using third party authentication libraries or services often have idiosyncrasies we need to manage around. Incidental complexity.

All of this can mean that your redirect logic is hard to test, hard to document, and/or get your head around. Which really means hard and risky to change.

Here are some strategies for simplifying complex redirect logic:

1. Use a single method. Instead of keeping the redirect logic in your post-auth controller action, put it into a method. Devise encourages this in its design, but it need not rely on your auth library’s conventions.

2. POROs or service objects. If your conditional is particularly hairy, consider extracting it all into a PORO or a service object that can be unit tested. Call `redirect_to RedirectService.new(user: user).call` and be done with it. You could even unit test that object.

3. Factories. This is my favorite. Collapse the code path into a single code path by only switching on the class. Then call “redirect_url” on the result. This is the approach that is easily unit tested, especially for complex logic, and those tests can elegantly act as your documentation. And, it lets you expand the number of objects to handle each case, and potentially include idiosyncratic logic in each case. You may have an `Admin::BillingRole` object that takes the user to the billing dashboard, a `Inspector::ServiceRep` object that takes the user to the Tickets#index screen, and so forth. Each object can be small but they all play the same role.

Have you encountered this? What strategies do you use?

True or false? Candidates with lots of job hopping in their recent past indicate a risky hire, someone who can’t be trusted to stick it out.

The logic goes something like: past performance predicts future performance, and since this person has only been at each role for a year, we should only expect them to be here for a year.

This isn’t crazy logic for median performers. But I suggest another explanation for high performers: they’re looking for a high performance team and can’t find it.

I find most hiring managers that miss this fact have never worked with high performers, and furthermore have never held a job for which they wanted to quit but wanted to give the team a year before making the hard decision.

When a high performer encounters a shitty company culture, they want to quit. Immediately. But they know that would reflect poorly, so they stick it out. Sometimes they successfully upgrade the team around them. Sometimes they don’t. The most tragic outcome is that they stick around because they need the job, and without a good manager and a culture of improvement and performance, they lose their edge and their superpowers gradually disappear.

High performers who don’t move on from shitty jobs risk drastically truncating their career.

How does it feel to be in this position?

1. Motivation wanes. It’s hard to stay motivated when you feel undervalued or under appreciated. Your enthusiasm for doing great work diminishes.

2. Stress and anxiety. Constantly dealing with unreasonable demands and criticism heightens your stress.

3. Limited growth. Opportunities for professional growth and development are rare when your manager or workplace culture doesn’t support or invest in your potential.

4. Isolation. You feel isolated and disconnected from your team.

5. Loss of confidence. Continuous negative feedback and lack of support will erode your self-confidence and make you doubt your abilities.

6. Exhaustion. The emotional toll of dealing with a bad manager can leave you feeling mentally and physically exhausted.

7. Resentment. Over time, you will develop feelings of resentment towards your manager and the company.

Chances are, if you’re reading this, you’ve experienced some or all of these. Wanting to leave the role is the most rational, reasonable desire given such an environment.

Some of the best advice I’ve been given personally (and have passed along to others) is: it’s OK to fire your boss.

So next time you see someone with a more than a few roles over the last few years, don’t immediately conclude they suck. It might be a diamond in the rough looking for a good manager.

Can they get that at your company?

Subscribe now

I stumbled across this post today, which represents (I think) a widely held belief that unit tests are bad.

The argument here seems to be:

• Unit test coverage doesn't guarantee that features actually work, only that regressions can be caught

• Tests make code difficult to change

Therefore:

• Unit testing is harmful

These are valid (separate) arguments against shitty unit tests, and using test coverage metrics as a proxy for correctness. And the conclusion is dubious at best.

The lesson here isn't "unit tests are harmful", the answer is get better at listening to what your code is telling you.

Unit tests are an invaluable tool for knowing whether your code is well factored. If it's hard to test the behavior (not the implementation) of your code, then your code is trying to tell you something very important, and it's not "test my implementation". We need to listen to our code when it talks to us like this.

When unit tests are done poorly, they inhibit change, give you false confidence, and make you worse at your job. When done well, they are the wind at your back, the green light to refactoring, and an invaluable signal that helps guide the design of your domain model.

It took me a good 20 years to learn this lesson. Why? Arrogance, the curse of experience, and because very few organizations actually do this well. And, of course, because it’s hard.

Here are questions I ask myself when I find it hard to unit test a class in my design:

• Is it hard to test this because it has side effects that can’t be simply mocked or accounted for?

• Am I trying to test implementation or behavior?

• Is this object too big? Can I make it smaller?

• Should this object be multiple smaller objects?

• Does this object depend on other objects? How many? Can I inject them?

Hopefully you recognize some of the SOLID principles here 😀.

Don’t avoid unit tests - avoid poor unit tests.

Links:

• The Daily Developer

• Firing Well

• The Five Dysfunctions of a Team

I had an extraordinary opportunity early in my career to learn a valuable lesson about leadership.

I had smart people on my team who, nonetheless, seemed to not be operating at full horsepower. They seemed bored. They seemed like they had so much extra fuel in the tank and yet weren't utilizing it. You could tell - they weren't energized, they weren't coming in to work excited.

I couldn't understand why. We had a bunch of hard engineering challenges. We had junior people who needed coaching. We had experiments we wanted to run, and people's lives we could directly impact with our work.

I even asked them about this and none of them could tell me what was up.

It hit me weeks later as I read "Turn the Ship Around" by David Marquet.

In his book (and his talks on youtube, go find them!) he talks about being a "know all, tell not" leader. This is a leader that understands the power of not telling your team the answer, of not assuming that you even know the answer (even if you do, and you're right about it).

The problem with giving your team the answers when they have problems is that you're robbing the team of the ability to use their brains and figure out the answers themselves.

I know what you're thinking. "Won't this hurt productivity? Isn't it bad to let my team spin its wheels?"

Well, yes, it's not always great to let your team spin their wheels. That is an altogether different problem than not knowing the answer. Staring at a wall when you don't know the answer is one of many possible solutions to being in the unknown.

And, yes, it will hurt productivity. But only in the short term, and I'd argue only in the extreme short term.

On any other timescale, what you're doing is forcing them to engage. You're giving them an actual challenge, not a theoretical one. "Design this fancy architecture" sounds great but in practice is rarely actually engaging. "Why does this particular bug keep happening, and only to this particular user?" is a more interesting question. You, as the leader, may know the answer because you wrote the code 5 years ago and have seen the issue before.

But by telling your team the answer to this question, you are robbing them of the most valuable reason they (likely) joined your team: to learn. And they don't learn by being told the answer. They learn by figuring it out.

So next time you're tempted to chime in with the answer, refuse. Trust the team to figure it out. They'll come through and they'll feel better about themselves. And, as a bonus, you'll have extricated yourself from the process.

Now you can go home and eat dinner.

Now, keep in mind I had learned to code at a young age. I'd been writing BASIC and Java for years at this point. I was familiar with C and C++, and had a rudimentary understanding that C could be seen as an abstraction on top of assembly, and that assembly itself was an abstraction on top of machine code. Machine code being those 1s and 0s. But I'd spent most of my time way up high in the application layer, often in network-land as well.

As long as I live I will never forget the moment I realized that the pin inputs to the primitive CPU I had built, the pins that expected high voltage or low voltage, were really 1s and 0s. I remember sitting there dumbfounded as these two large bodies of knowledge in my head, previously unrelated, all of a sudden connected. And not only did they merely become related to one another, they became deeply connected, one nesting inside the other, or one on top of the other, depending on how you see it.

It felt like my brain literally expanded. It felt like my perspective increased drastically in a single moment. It wasn't like one day I understood both computer architecture and programming, and the next day I understood them both together. It was more when Neo could see the matrix. The visceral sense of clarity and altitude was palpable, literal. I remember looking around at the other people in the lab and nobody else seemed to notice me. But I felt like I had cracked a secret code of the universe.

Be liberal in what you accept, and conservative in what you send.

In software, this means that you should always send data in a format that is as conformant with the spec as possible. And, you should always accept data that is not conformant but for which the meaning is clear. This leads to robust systems.

In human communication the same thing applies. I have an internal version of Postel's Law that I think about fairly often:

Accommodate mediocre communication from others, and do not tolerate it in yourself.

It took me a long time to learn this. Too long. When someone said something confusing that I mostly understood (but wasn't communicated well), my lizard brain reacted strongly. I fixated on how they were communicating instead of what they were trying to tell me.

Having now been on the receiving end of that type of reaction for awhile now, I am proud to say that I am a recovering violator of this rule.

Note that, like Postel's Law, there are some valid criticisms to be had here. For example, most programmers know that if you don't enforce a standard and are too accommodating of malformed input, at some point the standard can become less effective in general and developing applications against it is much more of a chore. cXML and EDI come to mind.

Just like communication - if you simply tolerate poor communication from others 100% of the time, then nobody will improve and, well, you're stuck in an organization with people don't know how to communicate. And that will truncate your career.

Generally the advantages of this approach far outweigh these downsides. People feel heard by you and are comfortable talking to you. They feel less judged. Able to be more honest and direct.

Give this a shot and tell me if it helps!

Here’s a lesson that has taken me a long time to learn.

The best engineers are engineers that are naturally most productive and most interested in being part of a great team.

I always assumed they'd want me to be as hands off as possible as the leader - some methodologies even encourage you to acknowledge the importance of the flow state and give updates asynchronously (in a tool like Slack or email or whatever) rather than synchronously.

But, the best engineers I’ve worked with aren't interested in flying solo for much of the time.

Daily checkins face to face are just so much better at surfacing issues early and building connective tissue on a team than asynchronous updates. Async updates are supposed to do this in theory, but in practice they surface other issues that must be addressed.

I am strongly considering reimplementing synchronous daily standups.

The engineers want them because they don't want to waste their time and want to make sure everyone remains on the same page. It's a regular opportunity for feedback. And they like how it gives everyone an opportunity to meet and chat and feel like a team.

Managers love the meetings for the exact same reasons.

How rare is that?!

Conditionals tend to gather mass and live inside “reusable” components.

Rich Hickey says that conditionals complect the "why" with the rest of the program.

Big reusable things are complex. They pull in concerns from various places into a single place, and then twist them all together such that they must all be considered together.

Think about the gnarliest parts of a codebase you work on. When you encounter a conditional, and you need to make a change, are you going to refactor the conditional out? Absolutely not. You’re going to add another condition. This conditional is going to grow and grow until its mass attracts bugs the size of the bug from Men in Black. Where does this conditional live? Is it well named, or is it named so generically such as to be opaque and unhelpful?

Imagine, instead, more, smaller objects. They aren’t each reusable - they each do one thing. They are much more aptly named, which aids readability. It’s okay to add another one, because they aren’t all twisted together. They’re neat and organized.

Rather than building a single, large, reusable thing, build smaller objects and consider something like the abstract factory pattern.

This is part of a series of posts I’m writing as I work my way through older books about programming.

In 1996, Richard Gabriel proposed a theory that explains the popularity of programming languages in his book Patterns of Software. Some of these will seem dated, and some will seem obvious, but when you put them together over 20 years later, I think it does a decent job of predicting the popularity of Javascript.

The theory has a few parts:

1. Languages are accepted and evolve by a social process, not a technical or technological one

2. Successful languages must have modest or minimal computer resource requirements

3. Successful languages must have a simple performance model

4. Successful languages must not require users to have "mathematical sophistication"

Let's compare Javascript to Ruby and test this theory's explanatory power.

As we progress, I encourage you to think about your favorite language in these four dimensions. Some that come to mind for me include Objective-C and Swift, Java, Erlang and Elixir, Rust, Kotlin, Clojure, and Go.

Ruby

I love Ruby. I think in Ruby. I've built my career (so far, wisely or not) upon it. There is even a renaissance happening at the moment, where some are turning away from the monstrous complexity of other ecosystems back to the Ruby and Rails community for its pure productivity.

But I think we must agree that it is still far less popular than Javascript.

I am not here to start (or, resume) a religious war. In fact I quite like the Javascript language. Years ago I read a Self tutorial - a language inspired by Smalltalk, with a far simpler programming model and a cool concept called slots. Javascript was heavily inspired by self, replacing classes and methods with the simpler objects and attributes model. Understanding the historical lineage of these languages is a lot of fun and does a lot to reduce the perceived conflict between the various communities, I’ve found.

But I digress.

Languages evolve by a social process

There are a few sub-parts to this criterion, aka how do languages get accepted?

1. It must be available on a wide variety of hardware

2. It helps to have local wizards or gurus

3. It must be a minimally acceptable language

4. It must be similar to existing popular languages

Javascript and Ruby are now ubiquitous, but there is no platform as ubiquitous as a web browser. Case closed.

Having "local wizards or gurus" is a dated reference, although there do exist many meetups for both languages and many others. Are there more javascript meetups than ruby meetups? Has the web made this criteria obsolete? You be the judge.

Javascript was accepted because it was the only choice if you wanted to build functionality into your browser application. It was instantly accessible - nothing to install. Ruby was more traditional - download the runtime to the machine and run your code on it. Being an interpreted language on a virtual machine, it doesn't have a compile step like other languages but it does still have a higher barrier to entry than Javascript.

Ruby's popularity grew because people loved it and shared it. People loved it because it let them write programs more productively, without having to bend their minds around the implementation of the machine. If you hang out in the ruby community, you'll often hear people talk about how much Ruby makes them love programming. There were real reasons to try out Ruby and real reasons to stick around. It made programming easier and more fun for many.

Javascript's syntax is extremely similar to other languages. It's a simula language, like C, Java, and countless others. Curly braces, function definitions, expressions and return statements, imports, etc are instantly recognizable in their syntax if you arrive from any number of other Simula syntaxed languages.

Ruby, on the other hand, is Smalltalk inspired, and thus departs a bit from that lineage. Curly braces are rare (mostly for inline blocks), semicolons are practically nonexistent, return statements are implicit rather than explicit, function definitions have more in common with BASIC or Python than C or Java.

Ruby is famous for taking its object model from Smalltalk, perhaps most famously its object model  (everything descends from Object) and its funky block syntax for deferred lambdas. It looks funky if you have never seen Smalltalk blocks before - which is most people. (Nowadays other languages have also adopted blocks, such as Swift).

(Note that I am not saying these things are negative aspects of Ruby. I love these parts of Ruby, and they are powerful. I am merely comparing the similarity of Javascript and Ruby to the other languages that came before them.)

Both Javascript and Ruby benefit from incremental improvement rather than giant releases. Ruby does occasionally introduce bigger changes - pattern matching is a recent example of this. An older example might be the shorthand Hash syntax. These are released as features in major versions, rather than incremental improvements. Comparable examples from Javascript would be the new class syntax released as part of ES2015.

In short, Javascript started as a simple language with many flaws, and over the course of its lifetime it has been incrementally improved a thousand-fold over its old self.

While Ruby has also benefited from incremental improvements, it was far more complete at its inception than Javascript. Which, according to the theory put forth by Richard Gabriel, is actually an obstacle to adoption, not a benefit!

For these reasons, while it's a close call, I think it's safe to put Javascript as the winner in the accessibility category.

Resource requirements

For a language to be successful, it must not be a resource hog.

I know what you're thinking. Isn't Ruby much slower than Javascript?

Well, it was when it started. And for our purposes today, that's really all that matters. Yes, Javascript used less memory and ran faster than an equivalent program in Ruby.

In the intervening years, the performance issues of Ruby for most web applications have been resolved. Ruby is plenty fast now.

But that doesn't change history, so we must acknowledge that when we compare the resource usage of the languages at their inception, Javascript wins.

The other thing Richard Gabriel points out here is:

the sophistication of a programming language is limited by the sophistication of the hardware, which may be high in terms of cleverness needed to achieve speed but is low in other ways to maintain speed.

I think this is an especially interesting tidbit, especially if you consider the browser on top of the OS to be the "machine" that Javascript runs on.

Mathematical sophistication

Programmers are not mathematicians...and I don't mean sophisticated mathematicians, just people who can think precisely andn rigorously in the way that mathematicians can.

This one is far more subjective, so I'll just say here that I think both Javascript and Ruby are roughly equivalent here. Both languages allow many, many developers to grasp the concepts required to be productive and write good software.

But, it is interesting to think about when compared to other languages - for example, monads in Haskell and macros in Lisp tend to be more difficult to grasp and require a subjective capability that appears to exceed the average. (Although, I'm not sure this is actually true. I think these concepts just require more study - but that's a different topic.)

Performance Model

I am not educated enough on the intricacies of Javascript to make an objective comparison here. I know that Ruby, being Smalltalk inspired, uses a sophisticated virtual machine to allow the programmer to, for many tasks, forget about space and time complexity. I believe the same is true of Javascript. Neither is as simple of a performance model as something like C, although I would bet money that Javascript's object model, being much simpler, allows its performance characteristics to also be simpler.

Does this explain the popularity of Javascript?

After discussing C vs Lisp on these various criteria, Richard Gabriel goes on to say:

The next interesting candidates are the object-oriented languages, Smalltalk and C++. Smalltalk, though designed for children to use, requires mathematical sophistication to understands its inheritance and message-passing model. Its performance model is much more complex than C's, not matching the computer all that well from a naive point of view. Smalltalk does not run on every computer, and in many ways it is a proprietary language, which means that it cannot follow the acceptance model.

Substitute Ruby for Smalltalk and see if this rings true. Now substitute Javascript. Does it ring as true?

What do you think?

• Why are non-DRY specs more maintainable?

• The Maintainable Software Podcast Episode with Jeanine Soterwood

• Simple Made Easy by Rich Hickey

• Patterns of Software by Richard Gabriel

• The Psychology of Computer Programming by Gerald Weinberg

• Sandi Metz: Duplication is better than the wrong abstraction and POODR