Showing posts with label work. Show all posts
Showing posts with label work. Show all posts

No posts for a wee while

Mike's Notes

I was on holiday for the last few weeks and am back now. There will be no blog posts, newsletters or meetings until Pipi Core is back up and running.

Update 27/05/2026

Lots of surprises. Making rapid progress. The peace and quiet are bliss.

Update 31/05/2026

The problem and solution are how things are named. Pipi auto-generates thousands of code names using multiple pattern languages, and all the naming conventions require many minor fixes for several unexpected reasons after migrating from a developer laptop to a production server environment. Everything else is absolutely fine.

Other naming problems are also being solved now, including:

  • The rapid development of Boxlang by Ortus has brought forward another challenge. Pipi 10 will be migrated to run on top of Boxlang in 2027 to support multiple languages, including C++, CFML, COBOL, Go, Java, JavaScript, PHP, Python, Rust, etc.
  • Future integration with cloud-based LLMs.
  • Future integrations with Office365, Google Workspace, Zoho, LibreOffice, etc.

The common solution is to create standardised naming systems that are simple, stable, robust, schema-based, versioned, self-documenting, and extensible to meet unanticipated future needs.

This is done by replacing code-based naming rules with database-driven ones that can be easily edited in the future via an admin UI.

90% of these names are internal, hidden in the closed core, and how they work and what they are will not be discussed here. The rest will be publicly and fully documented as part of the open-source workspaces for developers to work with.

Update 02/06/2026

I'm changing the disclosure boundary between the Pipi closed-core and open-source workspaces. Previously, "disclose everything unless there is a security reason not to". This is now changed to "disclose on the basis of need to know".

Closed-core accounts for 90% and open-source workspaces for 10% of lines of code, databases, etc.

This will reduce the documentation burden, given Pipi's vast scale. So, the open-source workspaces will be fully shared and documented on GitHub, etc, without restriction. This includes;

  • Standards schema
  • Ontologies
  • Parameters
  • Laws of physics
  • HTML + CSS
  • Algorithms
  • Module DDD models
  • Workflow diagrams
  • Documentation
  • API schema
  • UI code
  • etc

This also means some existing technical documentation about the closed-core will become hidden and only available internally.

Update 07/06/2026

Pipi Core is the IDE used to edit Pipi Core (AKA: which came first, the chicken or the egg?). Temporary UIs have been created and are being used across multiple engines to edit the names in use. This is much faster than directly editing data, which had to be done initially. The next step will be turning auto-generation back on. Once that's done, temporary UIs will be used to build permanent UIs. More automation will then be enabled via the UIs, and so on, as Pipi Core builds itself with a human in the loop.

Update 08/06/2026

The list of code cases available to use now for auto-generated naming, I/O translation, etc with examples, includes;

  • camelCase: userProfilePicture
  • kebab-case: user-profile-picture
  • PascalCase: UserProfilePicture
  • snake_case: user_profile_picture
  • SCREAMING_SNAKE_CASE: USER_PROFILE_PICTURE
  • Train-Case: User-Profile-Picture
  • flatcase: userprofilepicture
  • UPPER-CASE-KEBAB-CASE: USER-PROFILE-PICTURE
  • Sentence case: User profile picture
  • Title Case: User Profile Picture
  • middot·case: user·profile·picture
  • dot.case: user.profile.picture
  • UPPER CASE: USER PROFILE PICTURE
  • lowercase: user profile picture

Update 12/06/20026

Checking that these changes to variable names and internal messaging do not clash with the GΓΆdel Machine.

Update 17/06/2026

The DevOps Engine (dvp) has unexpectedly proven to be critical to solving this puzzle. Mostly fixed last night. Watching the rather excellent live Google talk, Beyond the GPU: Maximising goodput with self-healing AI infrastructure, this morning has given me valuable insights into how to fix the remaining issues by reviewing Google HPC YAML files. 😎😎 Sometimes insights come from the strangest places.

Update 01/07/2026

The main work now is rapidly configuring Pipi for production and full autonomous automation. Using Google Search AI Mode (Gemini) and then Grammarly Pro makes the work easier and 100x faster.

  • I have decided to have Pipi re-render the many Ajabbi draft public websites with the new and missing developer information. (20K pages)
  • The website's .robot.txt file will then be unlocked to enable search engines.
  • The HTML will be updated to make it easier for AI to read.
  • This blog will be imported into Pipi, cleaned up, re-exported from Pipi, and published to Blogger via the API.
  • The new posts created in Pipi will return to A Sandy Beach to discuss something already built rather than being built.

Update 02/07/2026

The DevOps and IaC engines are getting rapid data model overhauls. The IaC engine is a great test for the variable names. I'm building a capability into Pipi to autonomously and automatically run OpenTofu and Ansible, initially targeting the Pipi Data Centre, then GCP and AWS for deployments. It's going very well and making rapid progress.

Update 05/07/2026

Pipi will initially run the open-source enterprise applications on Google Cloud Run and Google Cloud Storage (GCS). The code is complete and will be very low-cost to run, giving Ajabbi, a bootstrapping-purpose startup, a very long runway.

Update 18/07/2026

The job has now shifted to configuring, networking and deploying many physical servers. Installing software, including Pipi, labelling cables and rack gear, throwing out junk, tidying, etc., leaving nothing to chance. Shipping delays are holding up part deliveries.

Update 23/07/2026

On the basis of open collaboration and credits for experimentation, I was going to offer Google exclusive use of Pipi for a period (as a thank you) before Pipi open-source is donated to the Cloud Native Computing Foundation for all to use.

Make money to provide a service.

I'm getting exasperated with XWF. They are the external sales contractors to Google, and since 2021, they regularly contact me.

  • Selling GCP products (No need; I'm already convinced).
  • Acting as gatekeepers to any contact with Google Engineers to discuss novel integration options, which is the actual issue. How to combine Gemini (an LLM) and Pipi (non-LLM) to make something much better.
  • They are all very nice, but a complete waste of my time. No more XWF meetings, folks.

So, I have decided to target integration with OpenRouter (and its alternatives) instead of Gemini and open up the Pipi developer platform (it is big and coming 😎) to enable developers from Alibaba, Alice AI, Anthropic, AWS, Azure, ByteDance, DeepSeek, Google, IBM, Meta, Mistral, Moonshot AI, Naver, OpenAI, Oracle, Palantir, Sarvam AI, xAI, etc, and anyone else, to enable integrations that are optimal, 100% secure and vetted, with everything publicly verifiable.

Pipi closed-core will never be for sale; this year it's getting a non-profit foundation behind it, a bit like Patagonia. I'm open to all genuine offers of assistance, collaboration and experimentation with no strings attached. Contact me.

Don't send sales engineers

Send a senior, highly experienced engineer/architect/chief scientist who loves a big fat problem and has time for an open chat without a pitch or an agenda, and just see where it goes.

If you want to meet in person, expect to work collaboratively at a whiteboard or blackboard like a real mathematician. Plus coffee, of course. 😎 To see how this works, watch the seminars at the London Institute of Mathematical Sciences, or the recorded physics seminars at Perimeter.

Pipi is rooted in biology and the laws of physics, so you need a very solid background in advanced sciences (microbiology, biochemistry, mathematics, philosophy, particle physics, thermodynamics, complex adaptive systems, etc).

Please, no venture capitalists or private equity. You're wasting your time. Go find something else to plunder. Pipi is a gift to humanity.

Being very high-functioning Asperger's (autism) with hyperphantasia, plus multiple synesthesias, I think visually at lightning speed and output solutions as fast as I can draw. I love solving very hard problems that matter. I can only write very slowly with the help of assistive technology, so I prefer video meetings with good spoken English, slides and time for trading quick engineering drawings.

Pipi is designed to run massive enterprise systems for socially useful critical infrastructure on every platform in many languages and writing systems.

The intention is to make life better for all of humanity by destroying waste, failure and crippling bureaucracy in;

  • Health systems (hospitals)
  • Transport systems (rail, road, air, shipping)
  • Sewerage
  • Drinking water
  • Land drainage
  • Nature conservation
  • Built infrastructure
  • Electricity networks
  • GLAM (galleries, libraries, archives, museums)
  • Farming (agriculture, forestry, aquaculture, horticulture
  • etc
Infant mortality rates will be the KPI

Pipi makes these systems self-assembling, self-managing, resilient and adaptive. I had to solve hundreds of very big, hard, complex problems in parallel to make this work. Some of them were abandoned research by others, who couldn't make them work, so I solved them. The answers were there, hidden in plain sight. Invisible due to a lack of imagination or courage.

Easy for me, because I can do it visually in my mind, run simulations of thousands of components while sleeping, including the testing, then wake up and just build; it always works 100% (been doing it for decades). That's why no one else has cracked this problem. I can remember everything I have designed this way since age 4 in great detail. Curiosity-driven learning turns everything I read that's interesting into a moving 4d model in my mind; there are tens of thousands of these shimmering mental models, and they self-assemble when I shut my eyes to solve a problem. Each model grows in detail and size as I learn more. I can fly through the models, exploring and touching them. Really cool.

Ahaa moments most days

Some days, I wake up, and the insights and designs pour out of my head like a firehose, and I can barely keep up even after outputting 20+ drawings on A4 paper in a day. Now, there are many thousands of colour-coded drawings in ring binders.

I turn the growing backlog of these designs into data models, code, and documentation with references by giving simple, direct instructions to Google Search AI Mode (Gemini), which teaches me new skills and gives me a response to edit, test, correct, and use. I'm going 100x faster, like a bat out of hell, the equivalent of a crack team of pre-AI developers. 😎 And I'm getting a lot faster.

I rely 100% on intuition when surfing a sea of 4D visual mental models. I really don't understand how the rest of you can only think in words, because I can't.

I have been very lucky

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

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

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

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

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

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

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

My blind friend Grant, who cut down bushes with a chainsaw and made and gave away $60 M, teaching me quiet courage and human decency.

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

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

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

The future is open, at the edge of chaos

Update 28/07/2026

Most of the equipment has arrived, and the small data centre setup is coming together. More deliveries later this week. It's already running a lot better and is much more productive.

Update 30/07/2026

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

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

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

These changes are made possible because of the detailed work done over the last few months removing barriers, including modifications to Pipi, reorganising space, equipment, and routines.

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

Now to execute very fast.

Resources

References

  • Reference

Repository

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

Last Updated

30/07/2026

No posts for a wee while

By: Mike Peters
On a Sandy Beach: 15/05/2026

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

I was on a no-coding holiday for the last few weeks to clear my mind, and it has been great. I am back on the job today.

Suspended

Until the closed-source Pipi Core is back up and running 100% on autopilot, 10x faster, the following are suspended.

  • New posts "On a Sandy Beach
  • All newsletters, including the weekly Friday Report and the monthly Ajabbi Research Newsletter.
  • The fortnightly online Open R&D meeting.

Rapid refocus

  • A new developer area with five coding screens, designed to be more productive for hypervisual learners.
  • A better library has been set up for my A4 drawings in ring binders, the many reference books I use, and more bookshelves are on the way.
  • The server rack has been moved to a better location.
  • The light levels have been adjusted.
  • A big office tidy is almost done. An office-work-only desk has yet to be set up with a cat bed included.
  • A separate area with no screens for the happy cat, coffee, music, reading and drawing.

Less is more

Minimise screen time to be more productive at work. The new setup is also much less tiring.

Get the job done

The good thing is that, with a holiday and lots of drawing, I now have mental clarity about what needs fixing and how to fix it. Mainly, quite delicate changes here and there, organised into a list of steps. Now, I need to concentrate on one thing only: go as fast as possible, without meetings, post-deadlines, phone calls, or other distractions.

How

1. Use an AI workforce

Be the architect, and AI fills in the dots to make it happen.

Use Google Search AI mode (Gemini) to generate 99% of the code in one-page chunks (including references) to copy and paste, then manually change the variable names and SQL. Careful, test everything, resulting in 100x faster progress. Know how everything works and rapidly raise personal skill level.

2. Then build a cathedral

Make a wooden scale model of a cathedral for the builders. Google Search AI mode (Gemini) makes each brick, and Pipi Core assembles the bricks into floors, arches, walls, and vaults...

Speed is king

With the 100x coding productivity gains from Google Search AI mode (Gemini), plus the 10x10x10x speedup of Pipi Core currently underway over the next few months, what previously took a year will be done in hours and better.

Phase transitions

Once these initial migration issues from laptop to server are resolved, further transitions can be anticipated as the number of engines rapidly increases beyond 20. Increasing the number of engines slowly changes the whole system's behaviour from deterministic to probabilistic and adaptive.

Here is a partial list of transitions expected as the number of engines increases from 0 to 200. The actual numbers are a bit of a guess.

  • 20 engines enable Pipi 9 Core in a simple, deterministic structure.
  • 40 engines enable a workspace with a UI for administering Pipi Core.
  • 60 engines enable self-generation of user documentation.
  • 80 engines enable REPL and IAC (infrastructure-as-code).
  • 100 engines enable Workspaces for different user accounts.
  • Different Pipi 9 editions are made with the same engines, which recombine differently in response to the external environment.
  • And so on until...
  • 200 engines self-organise into a multi-layered complex fluid structure with probabilistic behaviour and emergent properties, as engines also act as agents.
  • 200+ engines enable Pipi 10 to interact with externally cloud-hosted LLMs, combining the very different strengths of both.
By , 2 comments:
Tags , , , , , , , , , , , , , , , ,

Thinking Like a Data Engineer

Mike's Notes

Great read here. It takes humility to write this. Thanks, Ananth.

Data Engineering Weekly is an excellent newsletter to subscribe to.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

30/10/2025

Thinking Like a Data Engineer

By: Ananth Packkildurai
Data Engineering Weekly: 23/10/2025

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures.

I thought becoming a data engineer meant mastering tools. Instead, it meant learning how to see. I thought the hardest part would be learning the tools — Hadoop, Spark, SQL optimization, and distributed processing. Over time, I realized the real challenge wasn’t technical. It was learning how to think.

Learning to think like a data engineer — to see patterns in chaos, to connect systems to human behavior, to balance simplicity and scale — is a slow process of unlearning, observing, and reimagining. I didn’t get there through courses or certifications. I got there through people.

Four mentors, in four different moments of my life, unknowingly gave me lessons that shaped how I approach engineering, leadership, and even life. Each taught me something not about data, but about thinking systems.

What follows isn’t a tutorial. It’s a map of how four people — and their lessons — rewired how I think.

#1. “Chasing Knowledge.”

One of my friends recently asked why you are constantly reading and writing. It all started with an internship. A family friend of mine helped me find an internship. He was the person who taught me Java — patiently explaining not just syntax, but how to think through logic, abstraction, and design.

When I called him after getting my first full-time job, I expected congratulations or career advice. Instead, he said something that I only understood years later:

“Don’t chase money. Chase knowledge. Money will follow.”

The advice struck a chord with me forever. In technology, everything changes — languages, frameworks, stacks, even paradigms. But curiosity compounds. The more you learn, the faster you learn. The more you focus on mastering fundamentals, the easier it becomes to adapt when the next wave arrives.

That advice became a quiet compass throughout my career. Every time I faced a decision — whether to take a higher-paying role or a role that stretched my skills — I thought back to his words. And every single time I chose learning, the money eventually caught up.

It taught me that data engineering is not a sprint to expertise, but a lifelong apprenticeship in curiosity.

#2. “Modeling the World.”

It was in my early days of career as a data engineer that I met another mentor — an industry veteran, family friend, and one of the most grounded data people I’ve ever known.

One day, I asked him a question I thought was simple:

“How do I become a data engineer?”

He didn’t answer directly. He just said, “Go to Walmart and tell me what you see.”

I didn’t get it. But I went.

I walked through aisles, looked at shelves, and bought a few things — shampoo, snacks, and batteries. I came back and said, “Okay, I went. I bought x, y, z. Now what?”

He smiled and said, “Now tell me — how would Walmart model this data?”

That’s when I stopped seeing stores — and started seeing systems. I started describing the data model — a shelves table, a products table, a users table, and an events table. I started seeing not a store, but a database. Every product placement was a joint. Every checkout was an event stream.

That exercise reshaped how I saw the world. Data engineering wasn’t about ETL jobs or pipelines. It was about modeling reality.

When you can take something as ordinary as a store and translate it into entities, relationships, and flows, you start to think like a data engineer.

That mental model helped me immensely later. During one of my interviews at Slack, I was asked to design a data warehouse for Netflix. I didn’t start from schemas or metrics. I started by thinking: what’s the store? What are the products? What are the customers?

That grounding in observation and modeling helped me move fast and think clearly.

That day at Walmart was my real introduction to data modeling — not through theory, but through the physical world.

#3. “Thinking in Systems.”

When I started my career in the U.S., I worked on a loyalty analytics system — one of my first end-to-end data design projects.

I spent weeks sketching, refining, changing, and rebuilding the system. Every week, it looked different. One day, as I stepped into the elevator, my boss turned to me and said,

“I saw your design. You changed it completely from last week. That’s good. It means you’re thinking. Keep it going.”

That short elevator ride changed the way I viewed iteration. Until then, I thought redesigning meant I’d made a mistake. But his words reframed it — evolution is the process of engineering.

I started seeing every design review not as a checkpoint, but as a conversation.

Every new diagram was not a failure of the previous one, but an iteration toward clarity.

As we worked together more, he became my go-to mentor — not just for technical guidance, but for how to think. One day, over coffee, I asked him a question that had been on my mind:

“How do you cultivate architectural thinking?”

He smiled and gave me an unusual exercise.

He said, “Every day you walk from Montgomery Street to the Caltrain. It’s what — fifteen minutes? During that walk, observe how the city works. Watch how people who don’t know each other coordinate. Notice how traffic lights, signs, and signals function without central control. You’ll start to see the same patterns in our system design from emergent behaviour to the leader-follower model.”

It sounded odd, but I did it.

Each evening, I walked through downtown San Francisco — watching the rhythm of people, cars, and crosswalks. I noticed how one signal turning green in one intersection triggered waves of motion down the street. I saw bottlenecks at corners, retries when people crossed late, failovers when lights malfunctioned, and officers took control.

And suddenly, distributed systems weren’t abstract anymore. They were everywhere.

Humans, too, were part of a system — loosely coordinated, mostly independent, but connected through protocols, feedback, and flow.

That was the moment I truly understood system thinking — the ability to look beyond components and see interactions, dependencies, and evolution.

It also taught me humility: a good architect doesn’t impose order; they design for emergence. They build for change, not for perfection.

To this day, when I review a data platform design or a data flow diagram, I still imagine that walk from Montgomery Street to Caltrain. Systems are just cities — made of processes instead of people. Once you see it, you can’t unsee it.

#4. “Believing You Belong”

After I moved to the USA, I spent more time doubting myself than writing code.

Every meeting felt like an exam I hadn’t studied for. Every question felt like a test of belonging. I carried a quiet imposter syndrome — that whisper in your head that says you just got lucky.

One afternoon, my boss noticed my hesitation during a design review. After the meeting, he stopped me and said something simple that stayed with me forever:

“If you’re sitting here, you’re already good enough.”

It was a short sentence, but it landed deeply. There was no lecture, no performance review, no pep talk — just a fact. If you’re in the room, it’s because you earned it.

That moment changed how I carried myself. I realized confidence doesn’t come from knowing everything; it comes from recognizing that you’ve earned your seat — and you can grow from there.

I’ve repeated that same line to dozens of people since then — junior engineers, interns, even peers who were struggling to see their worth. Because the truth is, the data world can be intimidating. There’s always a new framework, a new paper, a new “modern” stack. You’ll never feel fully caught up.

But you don’t need to.

You need to keep showing up, keep learning, and keep thinking.

That sentence became the foundation for something else — it taught me that data engineering, at its core, is a confidence game. You’re constantly making decisions under uncertainty: what schema to use, how to partition data, how to handle scale. Doubt will paralyze you faster than a bad design.

Good engineers are not fearless; they just keep thinking despite fear.

Looking Back

When I look back now, I realize that everything I learned about data engineering started with a mindset shift, not a technical one.

  • Don’t chase money — chase knowledge. → Focus on curiosity; mastery compounds faster than rewards.
  • You’re thinking — keep it going. → Iterate relentlessly and observe systems beyond code.
  • Go to Walmart. → Learn to model the world in data.
  • If you’re sitting here, you’re good enough. → Believe in your ability to learn and grow.

The tools, frameworks, and clouds will keep changing. The mental models won’t.

Those mentors taught me that thinking like a data engineer is not about syntax or pipelines; it’s about curiosity, observation, and humility.

It’s about realizing that the best engineers don’t just build systems — they listen to them.

They watch how systems behave, evolve, and sometimes break — and they design with that reality in mind.

These lessons stayed with me — not as quotes to remember, but as ways of seeing the world.

So, if you’re early in your career or doubting your place in the data world, remember this:

You don’t need to know everything to think like a data engineer. You just need to keep observing, iterating, and thinking.

Because in the end, data engineering is less about moving data — and more about understanding how the world moves.

Closing Thoughts

If I had to summarize years of learning into one sentence, it would be this:

“Thinking like a data engineer is not about data. It’s about systems — human, technical, and everything in between.”

The world around you is the best classroom. Every store, street, and signal is a distributed system waiting to be understood. Every mistake is a feedback loop waiting to be improved. Every mentor is a node in your network of thought.

Keep learning. Keep thinking. And most importantly — keep observing.

Once you start seeing the world as data, you realize you've always been engineering it.

By , No comments:
Tags , , ,

Structured Procrastination

Mike's Notes

Bravo!

This is kind of familiar. Go visit John's blog, it's cool.

Resources

References

  • Reference

Repository

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

Last Updated

25/10/2025

Structured Procrastination

By: John Perry
Structured Procrastination: ?

John Perry is an emeritus professor of philosophy at Stanford. His office is Cordura 127 at CSLI, Stanford University, where he conducts several research projects. He is also a professor of philosophy (half-time) at the University of California, Riverside, on leave 2012–13.


Author practices jumping rope with seaweed while work awaits.

``. . . anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment." -- Robert Benchley, in Chips off the Old Benchley, 1949

I have been intending to write this essay for months. Why am I finally doing it? Because I finally found some uncommitted time? Wrong. I have papers to grade, textbook orders to fill out, an NSF proposal to referee, dissertation drafts to read. I am working on this essay as a way of not doing all of those things. This is the essence of what I call structured procrastination, an amazing strategy I have discovered that converts procrastinators into effective human beings, respected and admired for all that they can accomplish and the good use they make of time. All procrastinators put off things they have to do. Structured procrastination is the art of making this bad trait work for you. The key idea is that procrastinating does not mean doing absolutely nothing. Procrastinators seldom do absolutely nothing; they do marginally useful things, like gardening or sharpening pencils or making a diagram of how they will reorganize their files when they get around to it. Why does the procrastinator do these things? Because they are a way of not doing something more important. If all the procrastinator had left to do was to sharpen some pencils, no force on earth could get him do it. However, the procrastinator can be motivated to do difficult, timely and important tasks, as long as these tasks are a way of not doing something more important.

Structured procrastination means shaping the structure of the tasks one has to do in a way that exploits this fact. The list of tasks one has in mind will be ordered by importance. Tasks that seem most urgent and important are on top. But there are also worthwhile tasks to perform lower down on the list. Doing these tasks becomes a way of not doing the things higher up on the list. With this sort of appropriate task structure, the procrastinator becomes a useful citizen. Indeed, the procrastinator can even acquire, as I have, a reputation for getting a lot done.

The most perfect situation for structured procrastination that I ever had was when my wife and I served as Resident Fellows in Soto House, a Stanford dormitory. In the evening, faced with papers to grade, lectures to prepare, committee work to be done, I would leave our cottage next to the dorm and go over to the lounge and play ping-pong with the residents, or talk over things with them in their rooms, or just sit there and read the paper. I got a reputation for being a terrific Resident Fellow, and one of the rare profs on campus who spent time with undergraduates and got to know them. What a set up: play ping pong as a way of not doing more important things, and get a reputation as Mr. Chips.

Procrastinators often follow exactly the wrong tack. They try to minimize their commitments, assuming that if they have only a few things to do, they will quit procrastinating and get them done. But this goes contrary to the basic nature of the procrastinator and destroys his most important source of motivation. The few tasks on his list will be by definition the most important, and the only way to avoid doing them will be to do nothing. This is a way to become a couch potato, not an effective human being.

At this point you may be asking, "How about the important tasks at the top of the list, that one never does?" Admittedly, there is a potential problem here.

The trick is to pick the right sorts of projects for the top of the list. The ideal sorts of things have two characteristics, First, they seem to have clear deadlines (but really don't). Second, they seem awfully important (but really aren't). Luckily, life abounds with such tasks. In universities the vast majority of tasks fall into this category, and I'm sure the same is true for most other large institutions. Take for example the item right at the top of my list right now. This is finishing an essay for a volume in the philosophy of language. It was supposed to be done eleven months ago. I have accomplished an enormous number of important things as a way of not working on it. A couple of months ago, bothered by guilt, I wrote a letter to the editor saying how sorry I was to be so late and expressing my good intentions to get to work. Writing the letter was, of course, a way of not working on the article. It turned out that I really wasn't much further behind schedule than anyone else. And how important is this article anyway? Not so important that at some point something that seems more important won't come along. Then I'll get to work on it.

Another example is book order forms. I write this in June. In October, I will teach a class on Epistemology. The book order forms are already overdue at the book store. It is easy to take this as an important task with a pressing deadline (for you non-procrastinators, I will observe that deadlines really start to press a week or two after they pass.) I get almost daily reminders from the department secretary, students sometimes ask me what we will be reading, and the unfilled order form sits right in the middle of my desk, right under the wrapping from the sandwich I ate last Wednesday. This task is near the top of my list; it bothers me, and motivates me to do other useful but superficially less important things. But in fact, the book store is plenty busy with forms already filed by non-procrastinators. I can get mine in mid-Summer and things will be fine. I just need to order popular well-known books from efficient publishers. I will accept some other, apparently more important, task sometime between now and, say, August 1st. Then my psyche will feel comfortable about filling out the order forms as a way of not doing this new task.

The observant reader may feel at this point that structured procrastination requires a certain amount of self-deception, since one is in effect constantly perpetrating a pyramid scheme on oneself. Exactly. One needs to be able to recognize and commit oneself to tasks with inflated importance and unreal deadlines, while making oneself feel that they are important and urgent. This is not a problem, because virtually all procrastinators have excellent self-deceptive skills also. And what could be more noble than using one character flaw to offset the bad effects of another?

By , No comments:
Tags , ,

Ten Things You Need to Know About Your Autistic Employee

Mike's Notes

Note

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > Teams > Disability

Last Updated

17/05/2024

Ten Things You Need to Know About Your Autistic Employee

By: Dr. Michelle Garnett and Professor Tony Attwood
Attwood & Garnett: 18/06/2024

By Dr. Michelle Garnett and Professor Tony Attwood

In today’s dynamic and diverse workplace, it is crucial to recognize the unique strengths and perspectives that neurodivergent individuals bring to the table. Autistic employees can be a tremendous asset to any organization, provided they are understood, supported, and valued. Here are ten important considerations for employers to keep in mind when interviewing and employing autistic individuals, grounded in research and a strengths-based approach.

Focus on Strengths, Not Stereotypes

Autistic individuals often possess exceptional abilities in various areas, such as single-minded focus, attention to detail, pattern recognition, and ethical and creative problem-solving. For example, many autistic people excel in roles that require precision and analytical thinking, others excel in the visual and dramatic arts, and others in the caring professions. They often have a strong moral compass, and are loyal, hard-working, committed, and compassionate. Recognizing and valuing these strengths in your autistic employee raises the bar for all employees.

Clear and Direct Communication

Clear, direct, and unambiguous communication is often the most effective way to interact with autistic individuals. Some autistic people find it challenging to interpret non-verbal cues or implied meanings, whilst others have made an art of it. Others find auditory information a struggle to quickly interpret and later remember. To enhance communication further for some, make it visual. Providing clear instructions and feedback will enhance understanding, performance and motivation.

Structured and Predictable Environment

Many people dislike change and uncertainty, but it is important to know that for an autistic person these are significant stressors. Thus, a structured work environment with predictable routines can help autistic employees thrive. Sudden changes or chaotic settings can interfere with work performance because they are so stressful. When possible, give advance notice of changes to schedules or tasks, and maintain a consistent work environment.

Sensory Considerations

Many autistic individuals are sensitive to sensory stimuli such as bright lights, loud noises, or strong smells. Be mindful of the sensory environment and make accommodations as needed. This might include offering noise-cancelling headphones, adjusting lighting, or providing a quiet, uncluttered workspace. Offering a retreat space where there is a very minimal sensory load can go a long way to assisting an autistic person to re-calibrate as needed throughout their working hours. Conduct a sensory assessment of the workplace with your employee and regularly check in to ensure that any adjustments are working.

Inclusive Interview Techniques

Traditional interview processes tend not to showcase the strengths of autistic candidates. Consider alternative interview methods such as practical assessments, work trials, or having an autistic interviewer on the panel. This allows candidates to demonstrate their abilities in a comfortable setting. If a candidate has disclosed their autism prior to interview, reach out to ask about any adjustments that help them feel more at ease, including sensory adjustments for the setting, like wearing a visor, or providing interview questions in advance.

Support for Social Interactions

Social interactions in the workplace can be challenging for both the autistic and non-autistic employees. Offer support, such as a mentor, to your autistic employees and organise training in autism for your nonautistic employees. Co-discover team-building activities that are inclusive and respectful of neurodiversity. For example, an autistic employee may not enjoy a weekend away with work colleagues with no space to recharge their battery in solitude, especially if the expectation is nonstop socialising.

Reasonable Accommodations

Under different legislation in different countries, employers are required to provide reasonable accommodations to autistic employees. These might include sensory accommodations as above, flexible work hours, remote work options, or specific tools and technologies. However, any accommodations are severely undermined when there is workplace stigma for asking for them or seeing them implemented. Organise training in autism for staff to debunk common myths and misconceptions and to teach about the realities of autism to directly fight negative stigma. Discuss openly with the employee to determine what accommodations are necessary for their success. Check in with other employees about their needs also, many accommodations for autistic people work very well for humans in general.

Focus on Connection and Well-being

Autistic individuals may be more prone to anxiety or stress, especially in a work environment that is not accommodating. A non-accommodating work environment tells the person that their concerns are not important, and even worse, not valid. Autistic people are very perceptive of emotional atmosphere. If they feel unsupported, they are likely to feel unsafe, and their well-being will be affected. Promote a culture of connection and well-being by offering resources such as a focus on healthy relationships at work that are driven by caring and respect, access to stigma-free counselling services as needed for all employees, stress management programmes, and creating a supportive, flexible work environment. All employees will benefit.

Professional Development Opportunities

Invest in the professional development of autistic employees. Provide opportunities for further training and career advancement. Recognize their potential for growth and offer pathways for them to enhance their skills and advance within the company. Autistic employees, like all employees, suffer stress when there are too many demands or too few. Many autistic people are driven, achievement-oriented, thrive on being challenged and love learning.

Create an Inclusive Culture

Fostering an inclusive workplace culture benefits everyone. Educate all employees about neurodiversity and the value it brings to the organization. Encourage empathy, respect, and understanding. Celebrate the contributions of autistic employees and ensure they feel valued and included.

Conclusion

Employing autistic individuals is not just about compliance with legal requirements; it is about embracing diversity and reaping the benefits of a diverse workforce. By understanding and accommodating the unique needs of autistic employees, employers can create a more inclusive, productive, and innovative workplace. This approach not only benefits autistic individuals but also enhances the overall organizational culture, leading to greater success and fulfillment for all employees.

Where to from here?

We have prepared a half-day training on autism, Autism Working, for employers, autistic and non-autistic employees, autistic people looking for work, and parents and family members. We will be discussing the advantages of autism in the workplace, common challenges, and ways to navigate the challenges successfully.

By , No comments:
Tags ,

Dogfood anyone

Mike's Notes

Ajabbi "eats its own dog food".

It runs on Pipi 9. I use it every day to do real work.

I designed it so that I could use it to solve complex problems first. Soon, you will be able to use it, too.

So, I get to experience any bugs, which motivates me to fix them fast.

Any SaaS worth anything also eats its own dog food. Many don't, so don't use those ones.

Resources

References

  • Reference

Repository

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

Last Updated

17/04/2025

Article

By: Mike Peters
On a Sandy Beach: 10/06/2024

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

words

By , No comments:
Tags ,
Subscribe to: Posts (Atom)