In 1995, Watts Humphrey handed every developer a personal process.

It failed.

His Personal Software Process (PSP) let a single developer run a defined, measured, continuously improving process. It worked, but the bookkeeping killed it. Time logs, defect logs, forms after every task. Almost nobody could sustain it. Humphrey moved on to team processes, and for thirty years the smallest unit of process design has been the team.

I think that just changed.

Look at what an AI coding assistant actually gives you:

→ Skills: reusable SDLC activities such as analysis, design, testing, review
→ Subagents: roles with responsibilities
→ Hooks: quality gates that run every single time
→ Memory files: your standards, written down

Put these together and you have a full process, with you as its designer.

To be clear, this is not the “army of agents” story. The agents were never the point. The point is that the machine now absorbs the overhead that killed PSP: the constant logging, measuring, and enforcing. Humphrey was right. He was just thirty years early.

I call it the Process of One. It’s what I’m building now.

I’m designing my own process: the activities, the roles, the quality gates, the retrospectives. Everything I once designed for teams, I now design for a team of one. And this time, the machine carries the bookkeeping that defeated Humphrey.

The first rule of AI engineering applies at this level too: if you don’t measure it, you’re guessing. So I hold my own process to the same standard I hold the AI systems I build, and I keep asking: does it actually work?

You are a team of one now, with a process of one. How would you design yours?


Comment:
I’ve also started a catalog of these patterns: 19 so far, researched and organized together with the very assistant they describe. Each one written the same way: the situation, the problem, the solution, the source. Link on GitHub.



Quote:
Nothing that exists in the world is outside of you.
Seek within yourself whatever you want,
for that you are!
Rumi

If you use AI for coding every day, you may have noticed something strange: Your AI coding assistant gets dumber the longer you talk to it.

Most developers feel it but can’t name it: you start a chat, it’s brilliant. An hour later — same model, same task — it’s forgetting your instructions and repeating bugs it already fixed. You blame yourself. Don’t.

Matt Pocock calls it the smart zone and the dumb zone. A model is sharp early in a session, then quality slips well before the chat feels “full.” And here’s the surprising part: those huge new context windows everyone is talking about? They don’t give you more smart zone. They just give you a bigger dumb zone.

(Technically: a model’s effective context length is much shorter than its advertised window. As the thread grows, attention spreads thinner across more tokens, mid-context detail gets underweighted — “lost in the middle” — and the model keeps conditioning on its own earlier mistakes still sitting in the history.)

So the fix isn’t a better prompt. It’s a shorter memory. One task. One conversation. Then start fresh.

For larger work, move the memory outside the conversation: define the destination in a a shared specification, break the journey into small independent tasks, and give each task a clean context. The goal isn’t to give the AI everything it could possibly know. It’s to give it exactly what it needs for the task in front of it.

Your assistant was never getting tired. It was getting full.

Highly recommend Matt Pocock’s “Full Walkthrough: Workflow for AI Coding.” I learned a lot from this workshop.

Source:
Matt Pocock’s “Full Walkthrough: Workflow for AI Coding” (AI Engineer). The smart zone / dumb zone section is worth the watch if you use an AI assistant daily: Link

One practical tip from it: keep a token counter visible in your setup, and clear the chat when a task is done rather than stacking the next one on top. A fresh session beats a smart prompt.

Excerpt:
Every breath, the world is made new — and we, unaware of our renewal, endure.
Rumi, Masnavi

Almost everything I’ve ever built has been retired, replaced, or shut down. Except one. It has no users to please, no metrics, no roadmap, no deadline. And next month, it turns twenty.
It’s a weblog.

I started it on a Friday in the summer of 2006 — جمعه سیزدهم مرداد 1385 — in Persian, on one of the old blogging platforms, with no plan and no audience. I called it Somamos, after the highest peak in Gilan, in the green north of Iran. My family’s village, Bibalan, sits on the plain below, with Somamos rising on its horizon. The name was how I kept home in sight.

There was never a topic. There was only a rule I didn’t know I was following: if I loved it, it went in. A line of classical poetry. A book, a film. A thought about language. A knot in some code I’d finally worked loose. An idea in AI I was still turning over. A memory I refused to lose.

A public notebook, written for my friends.

It outlasted jobs. It outlasted cities. It crossed the ocean with me to Canada and didn’t miss a beat. Twenty years of software came and went around it — platforms died, formats changed — and the notebook just kept filling.

It lives at bibalan.com now, and recently it learned a second language: I’ve started making it bilingual, Persian and English side by side. I’ll be sharing some of these pieces here on LinkedIn too — so they reach not just the friends I wrote for in 2006, but the ones I haven’t met yet.

Twenty years ago I shared what I loved with people I knew.
Now I’m sharing it with you.

Preface:
In the world of software development, coding is only part of the story. The human side of the work is no less—perhaps even more—influential in a project’s success than the technical side. The human side of software development becomes far harder and more complex when we move from “coding side by side” to “occasional glimpses of each other from a distance, from behind a screen,” and then to “teammates we’ve never met.”

A while ago I came across a very instructive guide on the website of the SQLModel project. The lead of this project, Sebastián Ramírez (known as @tiangolo), is the creator of FastAPI, one of the well-known web development frameworks in Python. Below I’ve included part of the guide that Ramírez himself wrote for Repository Management Tasks. The goal of the non-technical part of this guide is not only to promote professional behavior, but also to build a lasting culture within the software developer community—a culture in which, even in challenging moments and technical disputes, the priority is respect for people and appreciation of their efforts.

The Guide: Be a Good Person!

Above all else, be a good person. If you were added to the team, it means you’re probably an exceptionally good person already, but it’s worth reminding ourselves of it again.

For when things get difficult!

When things are going well, the work is easier and there’s no need for long lists of instructions. But for the difficult times, here are some guidelines.

Try to see the positive side. In general, if people aren’t behaving unkindly, try to thank them for their effort and interest—even if you disagree with them on the matter at hand (a technical discussion or a PR). Thank them for caring about the project or for the time they spent trying to get something done.

Expressing emotions in text is hard; use emojis to convey your feelings.

In technical discussions and PRs, people often express their frustration directly and unfiltered—they frequently exaggerate, complain, act entitled, and so on. These behaviors really aren’t right, and when someone does them it lowers our priority for solving their problem. Even so, try to take a deep breath first and then give calm, polite replies. Try not to be sarcastic or passive-aggressive. If something is wrong, instead of being sarcastic, it’s better to say what you mean directly and openly (while staying calm and polite).

Try to be as precise and fact-based as possible, and avoid sweeping generalizations.

For the harder conversations—such as rejecting a PR—you can ask me to handle it myself.

Source (SQLModel guide): https://sqlmodel.tiangolo.com/management-tasks/#when-things-are-difficult

Introduction: Picking Fruit from the Orchard

There are fruit orchards you are allowed to enter, pick the fruit with your own hands, and, after paying the grower, take home the fruit you have hand-picked yourself. As far as I have learned, these are called U-Pick orchards. A few days ago, after a long period of staying home because of COVID, I got the chance to see one of these orchards up close. For me, someone for whom trees have always been a part of life, the experience carried a nostalgic feeling and reminded me of Bibalan.

You enter the orchard from the right side of the little cabin, and after picking fruit you leave from the left side. Naturally, the scale sits on the left side of the cabin, and the cash box is placed in the middle of the cabin, closer to the scale.

On the way in, you are handed a metal bucket—like the old water pails—to put your picked fruit in. Besides a metal handle, these buckets also have a metal hook designed for hanging them from a branch. When you enter, one of the orchard staff shows you how to detach the fruit from the tree in a way that causes the least harm to the tree. When we wanted to use a stepladder, another staff member came and explained the correct way to set it up! I wanted to tell them that I don’t need a stepladder or a ladder—if you’ll allow me, I’ll just climb the tree. It was a familiar experience!

Managing Service Capacity

Up to this point, as I said, our visit felt very familiar, and picking oranges was the closest thing that came to mind. On the way into the orchard, a kind, elderly woman on the staff guided us to grab buckets and head in. Since there were several of us, we told her that just one bucket would be enough and that we didn’t want to pick more than a single bucket of fruit. She smiled warmly and said: “Oh! Yes, I understand! But these buckets aren’t just for picking! We use them to count the number of people inside the orchard!”

I was stunned! Wow! What a clever idea! Managing the orchard’s admission capacity with buckets! What an amazing little lesson!

It reminded me that David J. Anderson, in the introduction to his book on Kanban, gave an example of the Imperial Gardens in Tokyo. He wrote that the museum staff use a simple yet effective Kanban system to manage visitors. On entry, they give each visitor a card (like a playing card or a student ID), and take it back on the way out. Whenever these cards ran out (the garden’s capacity was full), visitors had to wait behind the entrance gate until cards were returned. How wonderful!

Afterword

I think to myself that the world is full of things to learn! I can learn from any phenomenon and from anyone—even from a visit to a fruit orchard! I hope I am a talented student.

“Kanban is neither a software development methodology nor a project management approach.” — David J. Anderson

Since last week, when the current university semester officially ended, I’ve found a little time to work on the things I love. Learning data science and machine learning—itself an endless journey—helps me think about new problems and prepare possible approaches for them in my mind.

One class of these problems is the application of machine learning to Persian literature. Those of you familiar with machine learning surely know how many fascinating problems can be defined in this area—problems that help us understand and expand upon it.

Last week I decided to start one of the projects I’d been wanting to do and devote part of my between-semester break to it. This project was a study of Rumi’s poetry. I downloaded the data from the Ganjoor website and began working on the Divan-e Shams. Understanding the database structure took a little time, but thanks to its simple and elegant design, I quickly figured out how to find the verses. The initial results were very interesting to me.

One of the significant problems I ran into was the lack of libraries and trained models for the Persian language. I hope the number of these libraries and models keeps growing day by day. I kept thinking about how many interesting interdisciplinary projects could be defined at the intersection of Persian literature and data science.

Though you have cut yourself away from me, I am not without hope;
Though you have chosen another beloved over me,
As long as I have life, I will grieve for you—
For within despair there lie many hopes.
— Rumi

Before I forget, let me mention that Ganjoor is one of my favorite websites. I’m grateful to its founder and to everyone who works on it. May you endure.

Selected verse:

As long as you seek the jewel of the mine, you are the mine;
As long as you crave a morsel of bread, you are that bread.
If you grasp this hidden secret, you will know:
Whatever you are searching for—you are that.
— Rumi

Preface: Calligraphy
When I was a student, I loved having beautiful handwriting. So I used every opportunity to make my writing more beautiful. In the second year of middle school (seventh grade), when I attended Shahid Bahonar School in Bibalan, Mr. Haghshenas was our English teacher. God rest his memory! He had very beautiful handwriting. As far as I remember, he would write the dictation tests in one student’s notebook, then another student would copy it onto the blackboard, and the rest of us would write from that and take the test. Since I sat in the front row, I would hand my notebook to Mr. Haghshenas—so that afterward I could practice from his handwriting and improve my own.

In my first year of high school (ninth grade), Ehsan, one of the older students, had very beautiful handwriting and wrote his notes in a lovely broken (shekasteh) script. Using the notes as an excuse, I would borrow his notebooks from the previous year and practice writing with them. Beautiful handwriting gave me a good feeling.

Later, at my wife’s suggestion, we took a pen-calligraphy class together. It was very instructive. The chance to be together (amid all the work commitments) alongside proper calligraphy instruction left me with a fond memory of that class. I wished I’d had the opportunity to take such a class when I was younger.

Whenever I talked with others about calligraphy, a point they’d make was: “If I write patiently and without rushing, my handwriting is good, but if I hurry, it falls apart.” But I would think to myself that your handwriting should be beautiful whether you’re in a hurry or not. Circumstances may reduce the quality of your writing a little, but not so much that it turns into a scrawl. It goes without saying that I’m no expert calligrapher—this is just my personal impression and experience.

Although in today’s modern world there’s no longer any need to write by hand, that modest calligraphy skill of mine was lost too, for lack of “practice.” Even so, I still get excited when I see beautiful handwriting, and I find myself examining it like a work of art.

When I look back at the past, I can describe my experience of learning calligraphy like this:

• Beyond simply loving beautiful handwriting, my motivation to learn was that I didn’t want my writing to be a scrawl.
• Seeing beautiful handwriting and trying to copy and reproduce it was very effective in my learning, and it worked for me.
• When I see beautiful handwriting, even though I can’t write that way myself, I recognize that it’s “beautiful,” I get excited, and it enchants me.

Now my love of calligraphy has crystallized in me in a different form: a love of code calligraphy!

This post is an introduction to writing about some of my experiences with “calligraphy” in the world of programming. I hope in future posts to look at programming through this window and write about my experience. It would be wonderful if I could hear about your experiences too.

Selected quote:

We are known in the world by three names: literature, carpet, and calligraphy. Calligraphy exists within the other two arts as well. The small difference is that the illuminator works with pen, ink, and color, while the carpet weaver works with wool and cotton. Illumination is the very design of the carpet.
— Mohammad Salahshour, master of calligraphy