DEV Community: Rajasekar Elango

How to Create Diagrams Directly in ChatGPT

Rajasekar Elango — Thu, 02 Apr 2026 00:06:54 +0000

You can have a genuinely useful architecture discussion in ChatGPT, get the idea clear in your head, and then immediately hit the annoying part: now you need to turn it into a diagram.

That is usually where momentum drops. You leave the conversation, open another tool, start dragging boxes around, and spend the next twenty minutes formatting instead of finishing the thought.

This tutorial shows a cleaner workflow. You will connect AI Diagram Maker to ChatGPT with MCP, generate your first diagram from a plain-English prompt, and then make a few quick visual edits only if you want them.

MCP in plain English

MCP stands for Model Context Protocol. The simplest way to think about it is USB for AI tools.

USB gives your computer a standard way to connect to external devices. MCP gives ChatGPT a standard way to connect to external tools. In this setup, the external tool is AI Diagram Maker.

That is the whole reason this workflow works. Instead of explaining an idea in chat and then rebuilding it somewhere else, ChatGPT can call the diagram tool directly.

What this integration gives you

The benefit is straightforward: you can create diagrams without leaving ChatGPT.

For this tutorial, the setup happens in the OpenAI platform chat because that flow supports the MCP connector configuration we need right now. Once it is connected, the workflow is simple:

get an API key from AI Diagram Maker
connect the MCP server in the OpenAI platform chat
prompt ChatGPT to create a diagram
open the result in AI Diagram Maker if you want to refine it

If you want the full written setup guide alongside this walkthrough, start with the AI Diagram Maker MCP setup guide.

Step 1: Get your API key

Open AI Diagram Maker, go to Settings, then Integrations -> API Keys, and create a new key. Give it a label like ChatGPT so you can recognize it later.

Copy the key as soon as it is created. You will use it in the next step, and it will not be shown again after that.

If you want a slower, screenshot-by-screenshot version of this part, the API key guide is useful to keep open in another tab.

Step 2: Open the ChatGPT setup screen

Go to OpenAI platform chat and sign in.

This is where you will add the MCP server and use it in chat.

Step 3: Add the MCP server

Click Create, then Add tool, then choose MCP server.

On the next screen, choose Other developers, then Server.

Now enter the server details:

URL: https://mcp.aidiagrammaker.com/mcp
Label: ai-diagram-maker or any name you prefer
Description: optional
Authentication: Custom headers
Header key: X-ADM-API-Key
Header value: paste your API key

Then click Connect.

Step 4: Enable the tools and guide ChatGPT

Once the connection succeeds, you will see the available AI Diagram Maker tools. Add them to the chat.

After that, add a short developer message so ChatGPT knows when to use the connector. Keep it simple:

Use AI Diagram Maker to create diagrams when I ask for a flowchart, sequence diagram, ERD, UML diagram, or architecture diagram.

At this point, the setup is done. You can start prompting like normal.

Step 5: Create your first diagram

Start with something practical and easy to check. A good first example is a business flow:

Diagram the steps from finding a customer to getting paid.

Because the MCP server is connected, ChatGPT recognizes that it has a diagram tool available. It generates the content, calls AI Diagram Maker, and returns the result in the conversation.

In this OpenAI platform flow, you will usually get a link to the diagram rather than a fully rendered visual inline. That is normal.

The important part is that you stayed in the same workflow. You did not switch to a separate diagramming app just to get the first draft.

Step 6: Open the diagram and make quick edits

Click the diagram link to open it in AI Diagram Maker.

This is where you can make small visual improvements without needing to be especially design-heavy. For example, you can change the layout direction, clean up labels, adjust spacing, or remove one or two unnecessary nodes.

I like this split. ChatGPT handles the fast first draft. AI Diagram Maker handles the last bit of polish when you actually want it.

Wrap up

That is the full setup:

create an API key in AI Diagram Maker
connect the MCP server in the OpenAI platform chat
prompt ChatGPT to create a diagram
open the result in AI Diagram Maker for quick edits

The real win is that you stop breaking your thinking flow. No tool switching, no dragging boxes around, and no spending extra time on layout before you even know whether the diagram is right.

If you want to try it on your own workflow, start at AI Diagram Maker.

The Real Reason Architecture Diagrams Go Stale

Rajasekar Elango — Wed, 01 Apr 2026 00:03:11 +0000

What diagram-as-code teams change in their workflow to keep diagrams useful, current, and easy to review.

Most engineering teams have architecture diagrams that were accurate once and then slowly drifted away from the system they were supposed to explain.

A service gets split. A queue is introduced. An API boundary changes. The code moves first, and the diagram follows later if anyone remembers. That pattern is usually described as a documentation problem, but the better explanation is workflow friction.

The teams that keep diagrams useful are not more disciplined than everyone else. They changed where diagrams fit in the work. Their diagrams are cheap enough to update during decisions, not after them. That is why diagram as code matters. Version control helps, but it is not the whole story.

TL;DR: diagram as code is valuable because it turns architecture diagrams into working artifacts inside the engineering loop. Text-based diagrams are reviewable, diffable, and easy to update in the moment, which makes them useful for design reviews, async discussions, and onboarding. Teams succeed when they treat diagrams as communication tools, not documentation deliverables.

Why Architecture Diagrams Die: The Real Pattern

Architecture diagrams usually die for a simple reason: updating them sits outside the normal path of engineering work.

If the diagram lives in a design tool, a slide deck, or a wiki page, changing it feels like a separate task. You make the system change in code. Then, if you still have energy, you open another tool and try to redraw the system you just changed. That second step is where momentum dies.

This is why stale diagrams are not really a motivation problem. They are a cost problem.

When the effort to update a diagram is higher than the value the team gets from that update today, the team delays it. A few delays become a month. A month becomes a diagram nobody fully trusts. Once trust drops, usage drops with it.

So the problem is not "teams forgot documentation." The problem is that the artifact is too expensive to keep close to reality.

What Does Diagram as Code Actually Change?

Diagram as code is the practice of defining diagrams in text instead of drawing them manually in a visual editor. Tools like Mermaid, D2, and PlantUML all fit this model.

First, a diagram becomes reviewable. A pull request can show that a service was split, a dependency was removed, or a queue was added.

Second, a diagram becomes diffable. You can see what changed instead of re-reading a screenshot and guessing.

But the bigger shift is not storage. It is timing.

When diagrams are text, they become cheap enough to create in the middle of a conversation. Someone can open a file, add a message broker, rename a boundary, or remove a dependency while the team is still discussing the change. That is very different from saying, "we should update the diagram later."

That is why teams that adopt diagram as code often talk about flow, not just version control.

Where This Shows Up in Practice

1. During design reviews

The clearest difference shows up in live design conversations.

With static diagram workflows, the diagram often arrives as a snapshot of a decision that already happened. The discussion moves forward, but the diagram stays fixed.

With diagram as code, the artifact can change while the discussion is still active. A dependency can be added, a boundary renamed, or a queue introduced without leaving the engineering workflow.

2. In async architecture communication

A lot of architecture discussion now happens in pull requests, design docs, and chat threads. Without a good visual artifact, those discussions turn into long paragraphs explaining relationships that would be obvious in a simple diagram.

Diagram-as-code teams can attach a small diff instead. The discussion becomes easier to review because the change is explicit.

3. When the code keeps evolving

The third place this shows up is after the first change is already done.

A diagram usually does not become stale in one big moment. It drifts through small follow-up changes. A service gets renamed. A new dependency is added. A temporary workaround becomes permanent. If updating the diagram means leaving the code workflow and redrawing everything by hand, the team delays it.

If the diagram lives in the repo as code, those small corrections can happen in the same pull request as the code change. That is what keeps the system view believable over time.

What Do AI Tools Add to Diagram as Code?

For many teams, syntax is the last piece of friction.

Mermaid, D2, and PlantUML are all easier to maintain than screenshots, but they still ask engineers to learn a small syntax. That is fine for people who use it often. It is a blocker for people who only need diagrams occasionally.

This is where AI-assisted tooling becomes useful. Instead of starting with syntax, teams can start with intent and refine from there.

Tools like AI Diagram Maker let you describe a system in plain English, generate D2 code and a rendered diagram, and then iterate on the output. It does not remove the need for architectural judgment. It gives you a usable first draft fast, which is often all a team needs to keep the conversation moving.

For example, you could prompt it like this:

Draw a checkout flow: user places an order, it goes through the API, 
then hits the payment service and the order service. 
Show Stripe as an external dependency.

That kind of prompt is specific enough to produce a diagram the reader can understand at a glance.

The important point is not that AI replaces diagram as code. It makes the practice easier to start and easier to use while the conversation is still happening.

The Practical Shifts That Actually Change Things

Adopting diagram as code is not about switching tools. It is about changing specific habits. Here is where the real difference shows up day to day:

Stop updating diagrams after the fact. Start sketching during the decision.
If the diagram cannot change during the discussion, it usually will not stay current.

Stop keeping diagrams in a separate tool. Start keeping them next to the code.
When the diagram lives in the repo, updating it becomes part of the same workflow as the code change.

Stop treating diagram reviews as optional. Start reviewing diffs like you review code.
Text-based diagrams make structural changes visible, so teams can review them instead of guessing from screenshots.

Stop thinking of diagrams as deliverables. Start treating them as thinking tools.
A rough diagram that reflects the current system is more useful than a polished one that is already outdated.

Taken together, those shifts point to the real issue: the problem was never diagram quality on its own. It was the workflow around it.

The Workflow Was Always the Problem

Architecture diagrams do not go stale because engineers stop caring. They go stale because the tools that produce them exist outside the workflow where the system actually changes.

Diagram as code closes that gap. It makes diagrams cheap enough to create during a discussion, easy enough to update in the same pull request as the code change, and structured enough to review like any other file.

The teams that get the most out of it are not the ones with the strictest diagram rules. They are the ones that stopped treating diagrams as deliverables and started treating them as part of how the team thinks together.

If your team is adopting diagram as code, that is the useful question to ask: is it part of the real workflow yet, or is it still something everyone plans to do later?

Want to become a Happy and Productive Programmer? Use these 5 techniques from Psychology

Rajasekar Elango — Thu, 04 Apr 2019 15:35:21 +0000

How Ideas from Human Psychology can help Programmers?

Do you want to program at your peak performance? Do you want to enjoy programming job? What are the tricks to get unstuck from hard problems? How can you push your cognitive capabilities? Turning into Psychology can tell us answers.

Like a hero of a movie, the programmer’s life has villains, diversions, fights, and emotions. Are you ready to become a programming hero?

1. Achieve Flow State

In the famous book Flow: The Psychology of Optimal Experience, Psychologist Mihaly Csikszentmihalyi reveals that the secret for achieving Peak Performance is doing work in an optimal state called flow.

Flow is optimal state of consciousness where we feel our best and capable of performing at top level. During flow, people typically experience deep enjoyment, creativity, and completely involved in an activity for its own sake.
Flow also happens when a person’s skills are fully involved in overcoming a challenge that is just about manageable, so it acts as a magnet for learning new skills and increasing challenges.

To achieve a Flow state, you got to balance between the difficulty of the activity and your skills.

Learn the skills in advance ✅

If your work requires a new skill (may it be a new language or technology etc..), don’t try to learn and do the work simultaneously. Being familiar with it would avoid anxiety and help attain flow state. So, learn skills in advance to ensure you have the right level of skills for the challenges in the project.

Make it work first, then make it perfect ✅

The challenge will be harder if you try to write perfect code and you might get stuck. So to reduce the challenge, just write the first version of the code that works without worrying about it being bad. Then, it will be easier to refactor and make it good.

Divide and Conquer ✅

Another trick is to break up your complex work into small manageable tasks so that you will have control.

So the idea is to level up your skills or decrease the challenge to attain flow state. Game designers use this technique to keep the players hooked. They make the difficulty of game levels appropriate to the player’s skill so that players neither feels frustrated and nor bored. In the flow state, programming will feel like playing a game.

💡 If you achieve flow state you will be the hero. But wait, there is a villain.

2. Win Focus

Flow experience may not occur in the first few moments and you will need to stay focused to get immersed in the work. Cal Newport takes about the importance of focused work in his book Deep Work: Rules for Focused Success in a Distracted World

Deep Work: Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.

Set aside time for Deep Work ✅

You can set aside some time for focused work. To avoid distractions, turn off all notifications on your computer and phone. If you are not good at self-control, try Pomodoro technique.

Pomodoro Technique ✅

Pomodoro technique provides a system to perform deep work.

Source: https://name-fame.com/motivation/pomodoro-technique-boost-study-work/

Basically, you work on a task for 25 minutes with zero distractions. Then, you take a short 5-minute break and move on to next Pomodoro. After 4 pomodoros, you can take a long break. You can easily find Pomodoro apps on the internet.

💠 Don’t be too strict with Pomodoro schedule. If you are in a flow state, you don’t have to force a break when the 25 minutes is up. But there are other good times to take a break for a walk which I will discuss later in this post.

This is great for external distractions. what about internal mental distractions?

Commit your thoughts ✅

Our mind usually gets distracted by thoughts of unfinished tasks, regardless of their importance. Because open tasks tend to occupy our short-term memory until they are done.

But thanks to Zeigarnik’s follow-up research. We now know that,

We don’t actually have to finish tasks to convince our brains to stop thinking about them. All we have to do is to write them down in a way that convinces us that it will be taken care of.

After your work, you should not only commit your code to source control — But also write down your thoughts (e.g next steps, todos etc ) in a good place.

💡 A programmer’s journey not only has villains but also diversions and interruptions.

Source: https://www.big-red-digital.com/news/general/the-paradox-of-choice-why-the-choosing-a-website-partner-neednt-be-stressful

3. Minimize Choices

The life of a programmer involves making a lot of decisions and it interferes experiencing the flow state.

In his book The Paradox of Choice, Barry Schwartz describes how more choices lead to anxiety. He used numerous examples, from shopping to career options to romance, to show that less choice can not only increase our productivity but also our freedom and make it easier to be in the moment and enjoy it.

Source: http://vpcoder.com/index.php/2016/03/13/how-to-start-learning-coding-effectively/

He was primarily studying the behavior of shoppers but the same principle applies to programmers. We can use some techniques to reduce the number of decisions we have to make.

Think about it when picking a language or framework ✅

Many people admire the Go language because there is only one way to do something (like writing loops). Also, one of the reasons that people hate the Perl language is there are too many ways to do the same thing.

So consider the benefits of flexibility vs restriction when choosing a language or framework. If there is the only way to do something, you don’t need to worry about enforcing best practices.

Collect essential materials up front ✅

Programmers often have to look up code examples or documentation to do the work. This not only causes context switching but also creates a burden to pick a right example or API.

So, collect the necessary materials in advance so that you don’t have to look through the numerous google results and decide the right one.

Have a design before writing code ✅

Try to make the important decisions and design before you begin writing your code. This will help you focus on solving the problem at the hand instead of wasting your energy in making decisions.

💡What If I have procrastination or got stuck on a problem? Do you need a fight?

4. Don’t fight against Willpower

Studies on highly successful people have proven that success is not the result of strong willpower and the ability to overcome resistance, but rather the result of smart working environments that avoid resistance in the first place.

There some techniques to avoid the fighting against willpower.

How to avoid Procrastination?

Instead of forcing ourselves to do something we don’t feel like doing, we need to find a way to make us feel like doing what moves our project further along.

Have well-defined tasks ✅

The primary reason for procrastination is defining your goal at high level. Writing down specifics of what will you do, when and where to do it provides far more chance for actually doing it. Also, your brain thinks it’s too hard if there are not enough details. So having a meaningful and well-defined task beats willpower.

Head start on next task ✅

People usually take a break or call it for the day when they are done with a task. But, it's a good idea to begin or make slight progress on the next task. Because you would have a better idea of what to do when you start your work on the next day. This will help you avoid procrastination since you are not starting something new.

The same idea can be used while reading a book. Instead of closing a book when you are done with a chapter if you just read the first page of next chapter, you are likely to pick up the book again.

How to Get Unstuck in solving hard problems?

Similar to willpower, you don’t have to think hard to solve a tough problem. You can tune your mind so that solutions can come automatically to you in surprising ways!

Break for a Walk ✅

Letting thoughts linger without focusing on them gives our brains the opportunity to deal with problems in a different, often surprisingly productive way. While we have a walk or a shower or clean the house, the brain cannot help but play around with the last unsolved problem it came across.

So you will likely get an idea if you simply walk away from your computer.

Sleep on it ✅

Go home with an unsolved problem. Don’t try to force yourself to solve it, instead just sleep. Your subconscious mind will work on it and you will likely have a solution in the middle of the night or when you wake up in the morning. Many times solutions for my problems appeared in middle of the night or first thing in the morning or during my shower.

Try to work on different problem or project. ✅

Sometimes solutions to problems come automatically when you are not thinking about it. So, instead of pushing against a hard problem, redirect your energy towards another productive goal. With this method, to work on different things simultaneously, you never encounter any mental blockages.

💡 There is still something missing. Life becomes beautiful only if there are also emotions. Similarly programming too.

5. Practice Empathy

Empathy is an important skill that will lead to greater success and happiness in personal life and profession. Practice empathy in programming too. Programming is not just logic. It is expressive like an art.

Write maintainable code ✅

Keep in mind that the code you write will be read and maintained by others.

Programs must be written for people to read, and only incidentally for machines to execute ― Harold Abelson, Structure and Interpretation of Computer Programs

Follow the best practices of coding style like meaningful variable names, smaller methods etc. You shouldn’t program look like in this comment 😃

//When I wrote this, only God and I understood what I was doing
//Now, God only knows

Make sure code you write has a low cognitive load for other developers so that it’s easy to maintain. Write useful comments. Here is a funny comment I came across 😆

// 

// Dear maintainer:

// 

// Once you are done trying to 'optimize' this routine,

// and have realized what a terrible mistake that was,

// please increment the following counter as a warning

// to the next guy:

// 

// total_hours_wasted_here = 42

//

Use simplicity in design ✅

Whether you are designing an API or user interface, make it easy for your users. The basic principle you can follow is

Simple things should be simpler. Complex things should be possible.

Practicing empathy will not only help you but also make your team productive and users happy.

Summary

You may be already using these techniques. But knowing reasoning behind them using psychology can help you do them productively.

If you hate programming or considered quitting, using these ideas from psychology might transform you as a happy programmer.

When you see programming through the eyes of psychology, you will appreciate it’s beauty and enjoy the art of programming.

Thanks for reading.

Java is too old, What should you learn in 2018?

Rajasekar Elango — Wed, 10 Oct 2018 13:51:23 +0000

Java is too old, What should you learn in 2018?

Java has become legacy. It can’t evolve in to a modern language while keeping its backward compatibility. But it has given us a wonderful JVM ecosystem and lead to creation of many good languages Groovy, Scala, Clojure, Kotlin.

Welcome the newest baby Kotlin

Kotlin was born in 2011, But it gained popularity last year after google announced it as official language for Android. Kotlin has brought powerful features from many other JVM languages. Let take a quick glance at benefits of Kotlin for a Java developer.

Never worry about NPEs

Every Java programmer hates Null Pointer Exceptions thrown at Runtime. Kotlin provides first class support to avoid null references at compile time. All objects are non-nullable by default and you have to use ? operator to define nullable types. Compiler will force you to use safe call operator ?. to access nullable objects. You can also use elvis operator ?: to assign default values.

No need to provide explicit type declaration.

Kotlin automatically infers types, so you don’t need to declare it explicitly. You can simply define variables using val for final variables and var for non-final variables. Note type can be inferred only if both declaration and assignment is done in single statement.

Avoid convoluted String formatting.

In Kotlin you can use String templates for easier formatting of Strings. $is used to reference a variable and you can use ${} for complex expressions

No boiler plate code required to create simple POJOs.

Kotlin provides data classes for objects used to simply hold values. It automatically generates equals , hashCode , toString , copy , getters and setters ( for properties defined as var) methods for data classes. You can also do object deconstruction of data class to extract properties to variables.

You can avoid Builder classes and redundant method overloads.

Kotlin supports named method parameters so you don’t need to create builders in most cases. Also, Kotlin supports default method parameters so you don’t need to create redundant overloaded methods to pass default values.

You no longer need guava library to statically initialize collections.

Kotlin provides concise way to initialize collections inline using listOf , mapOf , setOf methods. Maps also support intuitive syntax key to value for initialization. It also provides deconstruction of Map key, values for easy iteration.

You don’t need a complicated way to create Singletons.

Kotlin supports object declaration to create Singletons in single line.

You don’t need unnecessary local variables

In Kotlin, constructs like try and when are expressions that returns value. For e.g You can assign result of try to a variable instead of creating a local variable. Similarly for when can be used as expression. when is equivalent to switch in Java, but it is much more powerful.

You will avoid Class Cast exceptions.

Kotlin provides is operator (equivalent to instanceOf in Java) to check if object is specific type . Using is operator will automatically do casting for you. This will prevent Class Cast exception when you cast to wrong type.

You don’t need to repeat the variable name to call sequence methods in same object.

Kotlin provides with construct to easily call sequence of methods on same object without having to repeat the variable name. We generally use builder pattern and method chaining to that in Java. Kotlin makes it easy to do similar thing even for non-builder classes.

Kotlin also provides apply extension function to achieve the same thing.

You don’t need boilerplate code to use delegation or decorator pattern.

To favor composition over inheritance, we often use delegation or decorator pattern, but we had to duplicate every method of delegated class in wrapper class. Kotlin provides first class support to simplify delegation using by operator. It will automatically implement necessary methods to call methods of delegated class. Of course, you can override specific methods when need to.

You don’t need to a Class to create static functions.

Kotlin supports functions outside of classes, so you don’t need to create a class just for static utility functions.

You don’t need a hack to modify non-final variables in lambdas.

Java supports lambda by automatically substituting it with anonymous inner classes, but you can’t modify non-final variable inside lambdas. But in Kotlin you can also modify non-final variables within lambda.

Lazy loading doesn’t require hard work.

Kotlin provides very simple way to lazily initialize a property using lazy keyword.

You don’t have to totally switch to a new language.

Kotlin interoperates with Java seamlessly, so you can easily integrate with legacy Java code. You can continue to leverage third party Java libraries and frameworks. Unlike Scala, Kotlin doesn’t have it’s own collection library, but extends JDK collections. So you don’t need to write glue code to convert between Java and Kotlin collection types.

You can write concise and more readable code.

Kotlin uses method name convention to overload many operators for readability. For e.g method plus is used to overload + operator, minus for - operator, times for * operator, div for / operator and so on. It supports overloading many more operators like %, += , +- , ++,--

Kotlin provides concise way to define ranges using .. operator. It also provides until keyword for excluding boundaries and step operator for skipping items. It has in operator to check for something in range. We can also overload .. operator and in operator by implementing rangeTo and contains methods.

You can easily extend existing JDK classes.

Kotlin support easy way to add extension functions to existing classes. This is a very power feature that helps us to easily expand core language API.

Why should you use Kotlin?

It boosts your productivity by many fold

It’s statically typed language, so you will catch lot of bugs at compile time.
It has great tooling support. No doubt it’s created by an IDE company
It is created by JetBrains a IDE company which cares for developer productivity.
Avoid many of day to day frustrations of a Java developer.

You get benefits of many best practices (Principles from Effective Java Book) by default.

All classes are final.
Collections are immutable.
Override mandatory keyword instead of optional annotation
No Checked exceptions
No Raw types
Cleaner support for generics.

Non-JVM support.

Kotlin also compiles to Javascript for front end development.
They are also working on adding native runtime to make it run without JVM.

Should you switch to Kotlin?

Kotlin is awesome but it’s not yet perfect. It will take some time to evolve in to a great language. JetBrains and Google are actively behind Kotlin so you can sure be that it will only get better.

If you are an Android developer, you should start using Kotlin immediately.

If you are a Java developer, you might have to consider other factors like team members, company adoption etc. But even if you can’t use it immediately, you should definitely learn this modern piece of beauty.

Finally, As per thoughtworks technology radar, companies can adopt using kotlin in projects when appropriate.

References

Should I learn Kotlin or stick to Java?
In GoogleIO 2017 Google announced Kotlin as an official language for Android development. Some famous developer…*medium.com](https://medium.com/mindorks/should-i-learn-kotlin-or-stick-to-java-3a73c3580ac3)
Kotlin in Action Book By Dmitry Jemerov (Author),‎ Svetlana Isakova (Author)

How knowing computer scheduling algorithms can help us to be productive?

Rajasekar Elango — Thu, 04 Oct 2018 10:14:59 +0000

We all want to get more things done efficiently and quickly. Computers are best at it. So Let's try to understand some computer scheduling algorithms to see how we can apply them to our daily lives to become more productive at our tasks.

First things first! You don't want to be late.

How to finish before the deadlines?

If you're servicing customers, you would want to serve each customer as quick as possible. Assuming servicing each customer takes almost equal amount of time, then you can help them in order they arrived. The ideal commitment or due time for a customer is as soon as they walk into your door.

Applying the same strategy to tasks:

You should start with the task due soonest and work your way toward the task due last.

This strategy, known as Earliest Due Date. which works best for minimizing lateness. But, we have a problem if each tasks takes varying amount of time to complete.

How to reduce pending task list?

Going back to cutomer servicing example, if serving each customer takes varying amounts of time, then you would want to service most number of customers. Let's say we can split customers by type of service and we know typical completion time for each type of service. Then, the best approach would be to pick customer who needs type of service with quickest completion time.

This strategy is based on Moore’s Algorithm which says,

We start out just like with Earliest Due Date— by scheduling tasks as they arrive, but when deciding which task to do next, choose the quickest one and repeat this process.

It’s like focusing above all on reducing the length of your to-do list. Also, each piece of unfinished task could be like a carrying a mental burden. Flying through the easiest items will bring some measure of relief.

It's not suprising that this approach is compatible with the recommendation in Getting Things Done Book to immediately perform any task that takes less than two minutes.

This is great way to get more things done, But all work can't be equally important.

How get most valuables work done?

Putting out an actual fire in the kitchen should probably be done before “putting out a fire” with a quick email to a client, even if the former takes a bit longer.

In scheduling, this difference of importance is captured in a variable known as weight. When you’re going through your to-do list, this weight might feel literal — the burden you get off your shoulders by finishing each task. A task’s completion time shows how long you carry that burden, so minimizing the sum of weighted completion times (that is, each task’s duration multiplied by its weight) means minimizing your total oppression as you work through your entire agenda.

The optimal strategy for this goal is a simple modification of Moore's algorithm:

Divide the weight of each task by how long it will take to finish, and then work in order from the highest resulting importance-per-unit-time to the lowest.

For eg: If you're a consultant, weight can be inferred from money you get. So simply divide each project's fee by its size, and work your way from the hightest hourly rate to the lowest.

It might be hard to assign a degree of importance to each one of your tasks, but there is a quick rule of thumb:

Only prioritize a task that takes twice as long if it’s twice as important.

But if tasks are dependent on other tasks, this will bring us new problems.

How to get unstuck?

We might get stuck sometimes because an important task can't be done until another less important task is finished. In computer science this problem is called priority inversion. ¹

The practical solution to this problem is Priority Inheritance. That is

To get unstuck is to treat the unimportant things as being as important as whatever it's blocking.

How to work through continuous incoming tasks?

Life could be easy, if we have finite list of tasks. In reality, it isn't. If assignments get tossed on you at unpredictable moments. The efficient approach is to swtich tasks which is known as preemption ² in computer science. It can be generalized as

Each time a new piece of work comes in, divide its importance by the amount of time it will take to complete. If the figure is higher than for the task you're currently doing, switch to the new one; otherwise stick with the current task.

But preemption isn't free. It comes at the cost of context switch.

How Job burnout happens?

Every time you switch tasks, you pay a price, known in computer science as a context switch. When a computer processor shifts its attention away from a given program, there’s always a certain amount of necessary overhead. It needs to effectively bookmark its place and put aside all of its information related to that program. Then it needs to figure out which program to run next. Finally it must haul out all the relevant information for that program, find its place in the code, and get in gear. The repeated rapid context switching would cause the performace of the computer to degrade or collapse. This phenomenon called as thrashing.

You can think of as being like juggling a set of balls. If the juggler takes one more ball than he can handle, he doesn't drop that ball; he drops everything.

Thrashing is a very recognizable human state. If you’ve ever had a moment where you wanted to stop doing everything just to have the chance to write down everything you were supposed to be doing, but couldn’t spare the time, you’ve thrashed. You are accomplishing nothing at all. You feel exhausted and burned out.

How to reduce burden of multitasking?

Some tips to reduce context switching burden

Don't keep your plates full.

The best strategy for getting things done might be, paradoxically, to slow down. One way to avert thrashing before it starts is to learn the art of saying NO.

Sometimes random order is better than perfect schedule

One of the biggest sources of metawork in switching contexts is the very act of choosing what to do next. So even doing tasks in the wrong order is better than doing nothing at all in thrashed state.

Thinking along the same lines, the Linux core team, several years ago, replaced their scheduler with one that was less “smart” about calculating process priorities but more than made up for it by taking less time to calculate them.

For eg: Instead of answering the most important emails first—which requires an assessment of the whole picture that may take longer than the work itself—maybe you should just answer them in random order, or in whatever order they happen to appear on-screen.

Commit doing single task for minimum amount of time

Computer Operating system schedulers typically define a “period” in which every program is guaranteed to run at least a little bit, with the system giving a “slice” of that period to each program.

To utilize this strategy, you should learn to balance between two principles responsiveness and throughput: how quickly you can respond to things, and how much you can get done overall.

The general idea is that:

Stay on a single task as long as possible without decreasing your responsiveness below the minimum acceptable limit. Decide how responsive you need to be— and then, if you want to get things done, be no more responsive than that.

The method to achieve this is Timeboxing i.e allocatea a fixed time period, called a time box, to each planned activity.

Another very useful technique is the Pomorado that uses a timer to break down work into intervals, traditionally 25 minutes in length, separated by short breaks.

Batch process similiar tasks

If you find yourself doing a lot of context switching, you can also employ another idea from computer science: interrupt coalescing. Computers do this by waiting until some fixed interval and check everything, instead of context-switching to handle separate, uncoordinated interrupts from their various subcomponents.

For eg: If you have five credit card bills, don’t pay them as they arrive; take care of them all in one go when the fifth bill comes.

Another example is — to avoid distraction caused by checking emails often, check it every 4 hours or so.

In workplace, holding office hours is a way of coalescing interruptions from co-workers. Regularly scheduled meetings are one of our best defenses against the spontaneous interruption and the unplanned context switch.

Summary

In addition to kind of scheduling problem you want to solve, you also need to choose right metric to optimize. Because the metric we pick will directly affect which scheduling approaches fare best.

In computer science: before you can have a plan, you must first choose a metric.

Here is the quick guide that summarizes when to choose each strategy based on metrics to optimize.

Metric to Optimize	When to choose?	Strategy
Minimize lateness	You have due dates, All tasks need similar amount of time to do.	Earliest Due Date
Maximize completed tasks	Tasks take varying amounts to time to complete.	Moore's Algorithm.
Maximize the value produced	Tasks are not equally important.	Weighed Moore's Algorithm.
Minimize stalling	Tasks depend on other tasks.	Priority Inheritance
Increase responsiveness.	Continous flow of incoming tasks.	Preemption
Increase throughput	Exhausted with multi-tasking.	Saying NO, Random order, Timeboxing, Pomorado, Coalescing interruptions.

Credits

This article is inspired from the wonderful book Algorithms to live by. If you enjoyed this article, consider reading the book which provides similar strategies for

Optimal stopping — When to stop looking?
Explore new things vs exploit what worked best.
Sorting
Caching
Bayers's Rule — Predicting the future.
Overfitting — When to think less.
Relaxation — Let it slide.
Randomness — When to leave it to chance.
Networking — How we connect.
Game theory — The minds of others.

Footnotes

Priority inversion is a problematic scenario in scheduling in which a high priority task is indirectly preempted by a lower priority task effectively "inverting" the relative priorities of the two tasks. ↩
Preemption is the act of temporarily interrupting a task being carried out by a computer system with the intention of resuming the task at a later time. ↩