Boxes.
Arrows.
Layers.

Controller → Service → Repository.

But most real problems in software are not caused by missing layers.
They happen because boundaries are unclear.

Architecture is mostly about boundaries.

Not patterns.
Not frameworks.
Not folder structure.

Boundaries.

What is a boundary?

A boundary is simply a line that answers this question.

Who owns this responsibility?

If that question is unclear, the system slowly becomes harder to change.

Code starts to leak into places where it does not belong.

Logic spreads.

Dependencies grow.

Soon every change touches five different files.

A simple example

Imagine a screen that shows a user profile.

You fetch the user and pass the whole object to another screen.

Navigator.push(context, ProfilePage(user))

It works.

But now the profile page depends on how the previous screen fetched the user.

If you want to open that page from a deep link, you cannot.
If you refresh the app, the screen breaks.

The problem is not navigation.

The problem is a broken boundary.

The profile page should own the responsibility of loading the user.

Instead of passing objects around, the screen should receive an id.

/profile/:id

Now the page is independent.

The boundary is clear.

P.S: Read more about this principle here.

When boundaries are weak

Weak boundaries create hidden dependencies.

Consider a common backend example.

A service function:

createOrder(user, items, payment)

Inside it:

• It calculates prices

• It writes to the database

• It sends an email

• It updates analytics

At first it feels convenient.

Later every change becomes dangerous.

Changing pricing might affect analytics.
Fixing email logic might break order creation.

Everything is coupled.

The boundary is gone.

Boundaries reduce fear

Good boundaries make code safe to change.

If a module has a clear responsibility, you know where changes belong.

For example:

Pricing module
Order module
Email module

Each module has one job.

When pricing rules change, you go to one place.

This reduces cognitive load.

You do not need to hold the entire system in your head.

Boundaries are about ownership

Good architecture answers questions like:

• Who owns business rules?

• Who talks to the database?

• Who handles external APIs?

• Who controls navigation?

When these answers are obvious, the codebase feels calm.

When they are unclear, every file starts doing a little bit of everything.

Folder structure is not architecture

Many teams confuse folders with architecture.

controllers/
services/
repositories/
models/

This looks organized.

But boundaries might still be weak.

A service might call another service that calls another service that touches the database directly.

The structure exists.

The boundaries do not.

Architecture is not where the files live.

It is who is allowed to talk to whom.

Good boundaries limit communication

In a healthy system, most parts should not talk to each other.

This sounds restrictive.

But it actually makes systems simpler.

If every module can call every other module, the system becomes a web of dependencies.

Soon nothing can change safely.

Boundaries act like walls in a building.

They limit how things connect.

And that limitation creates stability.

Boundaries evolve

You rarely get boundaries right on the first try.

Software grows.

Requirements change.

New concepts appear.

Architecture should adapt.

But if the system already has clear boundaries, these changes become easier.

You can move things without breaking everything else.

A small test

A simple way to check architecture is to ask this question.

If I change this rule, how many places will I need to touch?

If the answer is one or two places, the boundaries are probably good.

If the answer is "I am not sure", the boundaries are weak.

Final thought

Architecture often sounds complicated.

It is not.

Most of it comes down to one simple idea.

Clear ownership.

Clear responsibility.

Clear limits on how parts of the system interact.

Architecture is mostly about boundaries.

When the boundaries are right, the system feels easy to work with.

When they are wrong, even small changes become painful.

double price = 10.25;

It compiles.
It runs.
The UI looks correct.
QA passes it.

So what's the problem?

The problem is that double was never meant to store money.

And one day, usually when your product grows, that decision quietly comes back to hurt you.

The Problem Nobody Sees at First

In Dart (like most languages), double uses floating-point representation.

Here's something simple:

void main() {
  double a = 0.1;
  double b = 0.2;
  print(a + b);
}

Output:

0.30000000000000004

That extra 4 at the end?

That's not a bug in Dart.
That's how floating-point numbers work.

Most decimal numbers cannot be stored exactly in binary.

And double stores numbers in binary.

Why This Doesn’t Break Your App Immediately

Most traditional fiat currencies use only 2 decimal places:

• 10.25

• 99.99

• 1.50

Even if the internal number is slightly wrong, we usually format it like this:

value.toStringAsFixed(2)

And the UI shows:

10.25

So everything looks correct.

The error is still there.
It's just hidden.

When Things Start Breaking: Crypto

Now imagine your app starts supporting:

• Bitcoin - 8 decimal places

• Ethereum - 18 decimal places

• Tether - 6 decimal places

Now precision really matters.

Example:

0.00000013 BTC

That last digit is real money.

If you use double:

• Adding values can shift decimals.

• Multiplication introduces rounding.

• Conversions between currencies create tiny mismatches.

• Formatting hides precision loss.

• Parsing user input mutates values silently.

And the worst part, its a bug hidden in plain sight but still goes away unnoticed.

Issue entrypoint: UI & Backend Round Trip

This is where things actually break.

Imagine this flow:

1. Backend sends: "0.00000013"

2. You convert it to double

3. User edits the amount

4. You format and send it back

Somewhere in that round trip, the value changes slightly.

You expected:

0.00000013

You send:

0.00000012

In financial systems, that is unacceptable.

Small rounding issues lead to:

• Ledger mismatches

• Transaction validation failures

• “Amount does not match” backend errors

Floating point errors are small.

But money systems require exactness, not approximation.

Why double Is the Wrong Tool

Floating point numbers are stored like this:

sign × mantissa × 2^exponent

They are optimised for:

• Scientific calculations

• Graphics

• Physics simulations

They are not optimised for:

• Accounting

• Trading systems

• Ledger calculations

• User-entered currency

Money is decimal.
Floating point is binary.

That mismatch is the root cause.

So what's the right way?

1. Store the Smallest Unit

Instead of:

double amount = 10.25;

Do this:

int amountInCents = 1025;

For crypto:

• 1 BTC = 100,000,000 satoshis

• Store satoshis as int

No rounding.
No precision loss.
No floating point.

2. Create a Proper Money Type

Instead of passing raw numbers everywhere, define a safe structure.

class Money {
  final BigInt amount;   // smallest unit
  final int scale;       // decimal places
  final String currency;

  Money({
    required this.amount,
    required this.scale,
    required this.currency,
  });

  String format() {
    final divisor = BigInt.from(10).pow(scale);
    final whole = amount ~/ divisor;
    final fraction = (amount % divisor)
        .toString()
        .padLeft(scale, '0');
    return "\(whole.\)fraction $currency";
  }
}

Now:

• Precision is controlled.

• Each currency defines its scale.

• UI formatting is deterministic.

• Math operations stay exact.

This is how robust financial systems are built.

Example: Showing Safe Values on a Transaction History Screen

Let's say your backend sends smallest unit values.

Transaction model:

class TransactionModel {
  final String title;
  final BigInt amount; // smallest unit
  final int scale;
  final String currency;

  TransactionModel({
    required this.title,
    required this.amount,
    required this.scale,
    required this.currency,
  });

  String formattedAmount() {
    final divisor = BigInt.from(10).pow(scale);
    final whole = amount ~/ divisor;
    final fraction = (amount % divisor)
        .toString()
        .padLeft(scale, '0');

    return "\(whole.\)fraction $currency";
  }
}

UI:

ListView.builder(
  itemCount: transactions.length,
  itemBuilder: (context, index) {
    final txn = transactions[index];

    return ListTile(
      title: Text(txn.title),
      trailing: Text(
        txn.formattedAmount(),
        style: const TextStyle(
          fontWeight: FontWeight.bold,
        ),
      ),
    );
  },
);

Notice what's missing?

No double.
No toStringAsFixed.
No floating point math.

Just exact numbers.

One Rule You Should Never Break

Never do this for currency:

double.parse(userInput)

Instead:

• Keep input as string

• Validate format

• Convert manually to smallest unit

• Store as BigInt or int

Money should never pass through floating point.

The Lesson

Using double for money is easy.

It works in prototypes.
It works in demos.
It works when you only support 2 decimal currencies.

But products evolve.

They add:

• Crypto

• Micro-transactions

• Fractional trading

• High precision calculations

And that's when floating point becomes a silent production bug.

It doesn't crash your app.

It just slowly corrupts your numbers.

Final Thought

Floating point errors are invisible in the beginning.

But in financial systems, invisible errors become very visible money.

And systems involving money don't forgive approximation.

At first, it’s just:

• show login

• push home

• present details

But as features increase, flows start crossing each other:

• Splash → Auth → Home

• Auth → Forgot password → OTP → Reset

• Home → Profile → Edit → Back

• Deep links

• Logout from anywhere

If navigation logic lives inside views, things quickly become hard to reason about.

That’s where the Coordinator Pattern helps.

What Is the Coordinator Pattern?

The coordinator pattern is a way to move navigation logic out of views and into dedicated objects called coordinators.

Instead of views deciding:

“When button is tapped, push this screen”

They say:

“Hey coordinator, user tapped login”

And the coordinator decides what happens next.

In short:

Coordinators control navigation flow.
Views describe UI only.

Thinking of Navigation as State

In SwiftUI especially, navigation is just state.

Instead of saying:

• push screen A

• present screen B

We say:

• currentRoute = .login

• currentRoute = .home

• authMode = .signup

UI simply reacts to that state.

So coordinator becomes:

• A state holder

• A flow controller

• A source of truth for navigation

High-Level Flow

Here’s a simple app flow:

This is a very simple app:

• Splash screen checks login

• If logged in → Home

• If not → Auth

• Auth switches between Login and Signup

• After login → Home

Now let’s see how this was done in UIKit and how it differs in SwiftUI.

Coordinator Pattern in UIKit

In UIKit, coordinators usually:

• Own a UINavigationController

• Push and present view controllers

• Directly decide what to show

Example idea:

class AppCoordinator {
    let navigationController: UINavigationController

    func start() {
        showSplash()
    }

    func showSplash() {
        let vc = SplashViewController()
        vc.onFinish = { [weak self] isLoggedIn in
            if isLoggedIn {
                self?.showHome()
            } else {
                self?.showAuth()
            }
        }
        navigationController.setViewControllers([vc], animated: false)
    }

    func showHome() {
        let homeVC = HomeViewController()
        navigationController.setViewControllers([homeVC], animated: true)
    }
}

Key Point in UIKit

Coordinator decides:

• What view controller to create

• When to push

• When to present

• When to replace stack

It fully controls navigation stack.

UIKit = Imperative navigation

“Push this now.”

Coordinator Pattern in SwiftUI

SwiftUI works differently.

Navigation is state-driven.

Instead of pushing screens, we change state and SwiftUI updates the UI.

So in SwiftUI:

Coordinator does NOT push views.

Instead, it:

• Exposes @Published state

• Exposes methods to modify state

• Root view decides what to render

UIKit coordinator:

“Show Home”

SwiftUI coordinator:

currentRoute = .home

And the view reacts.

SwiftUI = Declarative navigation

“When route is .home, show HomeView.”

Folder Structure for a Large SwiftUI App

Let’s imagine this simple app:

• Splash

• Auth (Login / Signup)

• Home

A clean structure might look like:

App/
 ├── AppEntry.swift
 ├── RootCoordinator.swift
 ├── RootView.swift

Features/
 ├── Splash/
 │    ├── SplashView.swift
 │
 ├── Auth/
 │    ├── AuthCoordinator.swift
 │    ├── AuthView.swift
 │    ├── LoginView.swift
 │    └── SignupView.swift
 │
 ├── Home/
 │    └── HomeView.swift

Notice:

• Root has its own coordinator

• Auth has its own coordinator

• Features are separated

This scales well for large apps.

Step 1: Root Coordinator (SwiftUI Version)

Root decides between:

• Splash

• Auth

• Home

enum RootRoute {
    case splash
    case auth
    case home
}

final class RootCoordinator: ObservableObject {
    @Published var route: RootRoute = .splash

    func decideInitialFlow(isLoggedIn: Bool) {
        route = isLoggedIn ? .home : .auth
    }

    func didLogin() {
        route = .home
    }

    func logout() {
        route = .auth
    }
}

This coordinator does not create views.

It only changes state.

Step 2: Root View Decides What to Show

struct RootView: View {
    @StateObject var coordinator = RootCoordinator()

    var body: some View {
        switch coordinator.route {
        case .splash:
            SplashView {
                coordinator.decideInitialFlow(isLoggedIn: $0)
            }

        case .auth:
            AuthView(
                onLoginSuccess: {
                    coordinator.didLogin()
                }
            )

        case .home:
            HomeView(
                onLogout: {
                    coordinator.logout()
                }
            )
        }
    }
}

Notice the difference from UIKit:

• No push

• No navigation controller

• Just a switch on state

SwiftUI handles rendering.

Step 3: Auth Has Its Own Coordinator

Inside Auth, we want to switch between:

• Login

• Signup

So we create an AuthCoordinator.

enum AuthMode {
    case login
    case signup
}

final class AuthCoordinator: ObservableObject {
    @Published var mode: AuthMode = .login

    func showSignup() {
        mode = .signup
    }

    func showLogin() {
        mode = .login
    }
}

AuthView Uses AuthCoordinator

struct AuthView: View {
    @StateObject private var coordinator = AuthCoordinator()
    var onLoginSuccess: () -> Void

    var body: some View {
        switch coordinator.mode {
        case .login:
            LoginView(
                onSignupTapped: {
                    coordinator.showSignup()
                },
                onLoginSuccess: {
                    onLoginSuccess()
                }
            )

        case .signup:
            SignupView(
                onBackToLogin: {
                    coordinator.showLogin()
                }
            )
        }
    }
}

Now Auth handles its own internal navigation.

Root doesn’t care whether Auth is showing login or signup.

This is separation of responsibility.

The Big Difference (UIKit vs SwiftUI)

UIKit:

“Push LoginViewController”

SwiftUI:

route = .login

This is the mindset shift.

I’ve seen this pattern again and again, especially with newer Flutter developers.

You build navigation using go_router.
You pass objects from one page to another.
Everything works perfectly during normal app usage.

Then someone refreshes the page.

Or opens a link directly.

Or lands on a URL from Google.

And suddenly:

• the page crashes

• or shows a blank screen

• or awkwardly redirects back to a list

At this point, most people start adding workarounds:
“if data is null, go back”
“if object is missing, fetch again”
“if state is gone, redirect home”

The router isn’t the problem here.
The page design is.

What’s actually going wrong

The root issue is tight coupling between pages.

A lot of pages are built with the assumption that:

“This page will always be opened from its parent.”

That assumption is no longer safe.

With Navigator 2.0, deep linking is not optional anymore.
On web, every page is already a deep link — whether you planned for it or not.

If a page depends on parent state to exist, that page is fragile by design.

One simple question that changes everything

Whenever I add a new route, I ask myself one question:

From a business point of view, should this page be able to exist on its own?

This question decides everything.

Standalone pages

Examples:

• /user/:id

• /order/:id

• /product/:id

These pages:

• should open directly from a URL

• should survive refresh

• should not depend on parent state

• should be able to load themselves

Flow-dependent pages

Examples:

• payment steps

• checkout confirmation

• OTP verification

• onboarding flows

These pages:

• only make sense inside a flow

• often should not be deep linked

• can depend on parent state

• usually redirect if opened directly

Not every page needs to be standalone.
But the ones that should be, must be designed that way from day one.

The common mistake: passing full objects through routes

Let’s look at a very common pattern.

Fragile approach

// From user list page
context.go(
  '/user-details',
  extra: user,
);

// User details page
class UserDetailsPage extends StatelessWidget {
  final User user;

  const UserDetailsPage({required this.user});

  @override
  Widget build(BuildContext context) {
    return Text(user.name);
  }
}

This feels convenient.
No extra API call.
No loading state.

But this page has one big problem:

It cannot exist on its own.

If the user refreshes:

• extra is gone

• user is null

• now the page doesn’t know what to do

So people start patching:

• redirect back to list

• show error

• refetch with hacks

All of this complexity exists because the page depends on navigation state.

A more resilient approach: routes as contracts

If a page is standalone, the route should describe what the page needs, not what the parent happens to have.

Better route definition

GoRoute(
  path: '/user/:id',
  builder: (context, state) {
    final userId = state.pathParameters['id']!;
    return UserDetailsPage(userId: userId);
  },
);

Now the route itself answers one question clearly:

“What does this page need to load?”

Answer: a userId.

Move data responsibility into the page

The page should not care where it came from.
It should only care about what it needs.

class UserDetailsPage extends StatelessWidget {
  final String userId;

  const UserDetailsPage({required this.userId});

  @override
  Widget build(BuildContext context) {
    return BlocProvider(
      create: (_) => UserDetailsCubit(userId)..load(),
      child: const UserDetailsView(),
    );
  }
}

class UserDetailsCubit extends Cubit<UserDetailsState> {
  final String userId;

  UserDetailsCubit(this.userId) : super(UserDetailsLoading());

  Future<void> load() async {
    final user = await userRepository.getUser(userId);
    emit(UserDetailsLoaded(user));
  }
}

Now this page:

• works on refresh

• works with deep links

• works without parent context

• is easy to reason about

“But why make another API call?” — the hybrid approach

This is a fair question.

If I already have the user object, why fetch it again?

You don’t have to.

Hybrid page design

Let the page accept an optional object without depending on it.

class UserDetailsPage extends StatelessWidget {
  final String userId;
  final User? user;

  const UserDetailsPage({
    required this.userId,
    this.user,
  });

  @override
  Widget build(BuildContext context) {
    return BlocProvider(
      create: (_) => UserDetailsCubit(
        userId: userId,
        initialUser: user,
      )..load(),
      child: const UserDetailsView(),
    );
  }
}

class UserDetailsCubit extends Cubit<UserDetailsState> {
  final String userId;
  final User? initialUser;

  UserDetailsCubit({
    required this.userId,
    this.initialUser,
  }) : super(UserDetailsLoading());

  Future<void> load() async {
    if (initialUser != null) {
      emit(UserDetailsLoaded(initialUser!));
      return;
    }

    final user = await userRepository.getUser(userId);
    emit(UserDetailsLoaded(user));
  }
}

What you gain

• No unnecessary API calls

• Refresh still works

• Deep links still work

• Page is not tied to navigation history

This pattern scales very well as the app grows.

What about flow-based pages?

Not every page needs this treatment.

For example, a payment confirmation step:

• doesn’t make sense outside the flow

• probably should redirect if opened directly

• can depend on parent state safely

The key is being intentional.

Problems happen when we treat every page the same.

Why this matters long-term

Pages that can load themselves:

• are easier to debug

• are easier to test

• are easier for new developers to understand

• break less often on web

Most “navigation bugs” are actually page design bugs.

Final thoughts

Navigation is not just about moving between screens.
It’s about defining boundaries and responsibilities.

Before adding a route, ask:

Should this page survive refresh?

That one question will save you a lot of pain later.

Over time, lack of consistency slows everything down. Onboarding new developers takes longer than it should, moving code from development to production becomes frustrating, and the overall developer experience degrades—costing both productivity and money.

I’ve personally seen teams struggle with untraceable changes due to inconsistent commit messages, unnecessary merge conflicts caused by mismatched formatting, and blocked deployments because a single broken test brought the entire CI pipeline to a halt. Add to this the increased time from writing code to shipping it, and delayed timelines become inevitable.

But what if these issues could be prevented at the source? What if language, framework, and project-specific rules were enforced automatically—so code that didn’t meet the standards simply couldn’t be committed in the first place?

This is where Git hooks come into play.

Git hooks are configurable scripts that run at specific points in a code’s lifecycle—such as before a commit or before a push. They allow teams to automatically run checks and decide whether an action like a commit or push should succeed or fail, entirely based on predefined rules.

In this article, I’ll focus specifically on setting up a pre-commit hook for a Flutter project to enforce essential quality checks before any code is committed.

A commit will only succeed if:

• There are no compilation or linting issues

• The code is formatted according to Dart’s formatting guidelines

• All tests pass successfully

• Commit messages follow project-specific conventions

You can learn more about Git hooks and how to configure them here. (link)

Pre-Commit Workflow From a Developer’s Perspective

Setting Up the Pre-Commit Hook

Git hooks live inside the .git/hooks directory of a repository. These hooks are local to the developer’s machine, which means they don’t get committed to version control by default.

To start, navigate to your project root and create a pre-commit file:

cd .git/hooks
touch pre-commit
chmod +x pre-commit

This pre-commit file is the script Git will automatically execute every time a developer runs git commit.

If this script exits with a non-zero status code, the commit is rejected.

That’s the only rule you need to remember.

Writing the Pre-Commit Script

The script can be written in Bash (most common), and its responsibility is simple:
run checks → fail if something breaks.

Below is a basic but production-ready example for a Flutter project.

#!/bin/sh

echo "Running pre-commit checks..."

# 1. Static analysis
echo "Running flutter analyze..."
flutter analyze
if [ $? -ne 0 ]; then
  echo "❌ flutter analyze failed"
  exit 1
fi

# 2. Code formatting
echo "Checking code formatting..."
dart format --set-exit-if-changed .
if [ $? -ne 0 ]; then
  echo "❌ Code formatting issues found"
  echo "Run: dart format ."
  exit 1
fi

# 3. Tests
echo "Running tests..."
flutter test
if [ $? -ne 0 ]; then
  echo "❌ Tests failed"
  exit 1
fi

echo "✅ All pre-commit checks passed"
exit 0

At this point, you’ve already eliminated:

• broken builds

• inconsistent formatting

• failing tests entering the repo

All before the code ever leaves a developer’s machine.

Enforcing Commit Message Conventions

Pre-commit hooks don’t receive the commit message by default.
For that, Git provides another hook called commit-msg.

Create it alongside pre-commit:

touch .git/hooks/commit-msg
chmod +x .git/hooks/commit-msg

Example commit-msg script:

#!/bin/sh

COMMIT_MSG_FILE=$1
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

PATTERN="^(feat|fix|chore|docs|refactor|test): .{10,}"

if ! echo "$COMMIT_MSG" | grep -Eq "$PATTERN"; then
  echo "❌ Invalid commit message format"
  echo "Expected format:"
  echo "feat: short meaningful description"
  exit 1
fi

exit 0

Now:

• commits without context

• vague messages like fix, temp, wip

never make it into history.

Making This Work in Large Teams

One important thing to address:
.git/hooks is not shared by default.

In real teams, you’ll want to:

• store these scripts in a versioned directory (e.g. scripts/git-hooks)

• add a small setup script that copies them into .git/hooks and probably add it to the Makefile with a simple setup alias

• document this as a mandatory onboarding step in the README

This keeps the rules consistent.

Why This Approach Scales

At scale, this setup does something very important:

• Developers get instant feedback

• CI pipelines stop failing for trivial reasons

• Code reviews focus on logic, not hygiene

• Teams stop arguing about formatting and conventions

• New developers ramp up faster without memorizing rules

Most importantly, it removes humans from enforcing things that machines are better at enforcing.

Closing Thoughts

Pre-commit hooks are not about control or restriction.
They’re about protecting focus.

By enforcing basic quality checks at the earliest possible point, teams avoid unnecessary friction later in the development lifecycle. When done right, these hooks become invisible—developers don’t think about them, because things “just work”.

If you’re working with a growing Flutter codebase and struggling with consistency, start small:
add one check, let the team feel the benefit, and evolve from there.

This approach closely follows the principles from Extreme Programming Explained by Kent Beck—particularly fast feedback and building quality in from the start. Pre-commit hooks bring those ideas directly into the local development workflow, long before CI or code reviews come into play.

1. Don’t criticise or condemn anyone. It’s far better (from a selfish POV and profitable as well) to fix your habits and condition first. If you really want to express something about someone, praise them for their good habits rather than pointing out the bad ones. If things are that bad between you and the other person that you don’t even want to talk then write all your frustration and complaints down and forget about it.

2. The big secret of dealing with people is real good appreciation and finding good about them rather than digging for flaws. We can do anything for our families so that they are not hungry, but the universal craving for appreciation gets hidden somewhere unnoticed.

3. If you really want to make someone do something, Instead of telling them how is it going to impact or profit you, tell them how it will benefit them. The core condition being it should be mutually beneficial.

4. Be genuinely interested in people. There’s no point in assuming that people are interested in you. No-one interested in anyone else apart from themselves. So if you truly want to be someone’s friend then show genuine interest.

5. Carry a smile when meeting/greeting someone. That’s the best first impression anyone can create on anybody. It shows that you are really glad to see/interact with that person.

6. This one might be obvious, but really tough (at least for me 🥹), bring this into habit to remember people’s names. Only and the most pleasant word for a person is their own name. People like hearing their names, so it can bring a lot to the table if we follow this wisely.

7. Be a really really good and empathetic listener. Instead of listening what the other person is saying, most of the folks tend to think on the back of their heads that “What to say next?“ leading to lost focus and a disconnect from the conversation. Most of the people just want to get listened to rather than needing advice or sympathy or anything like that.

8. Before interacting with anyone, if you know or can know what they are or might be interested in, do a bit of studying around that if you don’t already know and talk to the person about their interests first and foremost, it makes you instantly likeable.

9. Make the other person feel genuinely important and being listened to.

10. Avoid unnecessary arguments, struggling through the unnecessary arguments is nothing more than pure waste of your energy and in most of the cases reputation as well. At the end of the day, you should have as many happy people around you as possible.

11. Never tell anyone that they’re wrong directly, deal with the situation diplomatically. If all goes well they’ll accept it themselves.

12. If you know you’re wrong, admit it ASAP and don’t let or wait for someone else to point it out.

13. Start every conversation in a friendly way, even the tough ones like raising a grievance. Even the toughest people can be melted like this.

14. Start the conversation in such a way which makes other person respond in Yes’es. Once through the initial opening conversation you get a couple of yeses, the probability of other person agreeing with you will be really high as it is psychologically easier for anyone to end a conversation in a affirmative direction if most of it was positive.

15. Let the other person do most of the talking, or else when you are boasting or speaking they will either be (not everyone but a few for sure) becoming jealous of you or they might start thinking in their brains whatever they wanted to tell you about, not paying attention to even a single bit you said.

16. Whenever you are selling or convincing someone for something, never try to push your ideas down their throats. Instead converse wisely in such a way which makes feel the other person that the idea is theirs.

17. Praise before you point out someone’s errors. It’s psychologically more probable that the person would listen to their faults or failures after hearing some genuine praise about them.

It has suggested me quite a good reads like “The Almanack of Naval Ravikant“, “Talking to Strangers“ and the one which I recently read “How to steal like an artist“.

This book changed my perspective of how I perceived creativity. This one quote which stuck with me from the same book

“You shouldn’t want to look like your hero, you should want to see like your hero“.

These are the few things which stuck with me and I have either already incorporated these in my life or I will soon. Here goes the list

1. Nothing in this universe is original, as also said in the Bible “There is nothing new under the Sun“.

2. Creativity = Pre-existing thoughts and ideas re-imagined or remixed.

3. A method which I learnt and am very curios to try out is, Think about who you superheroes are (people whom or whose work you look upon to), go as deep as you can and understand/observer each piece of their work and their thinking philosophy. Then create your own thought tree and see what if some of your heroes collaborated and made something. Think about that or build that and most probably this remix would be uniquely creative and somewhat your own.

4. Creativity is stealing and making it better, whereas Rip-Offs or de-graded products are just failed attempts of trying the same.

5. Garbage in - Garbage out: You might know this already, “Always surround yourself with people better than you” or simply put “If your are the smartest in the room, its high time to change the room“. As the environment reflects on one’s work.

6. Try engaging with your work as much emotionally as you can. If you’re an artist, there are tools nowadays where you just click, drag mouse or hit buttons on the keyboard and get stuff done. Same goes for most of the professions nowadays, separate out an analog and a digital setup (or just keep aside your laptop in separate table drawer) and scribble things out using pen and paper get the good old touch and feel of paper. For engineering backgrounds, use notebook for drawing flowcharts and charting out thought processes, you’ll feel much more deeply engaged with your work.

7. In this digital-era, where everyone is chasing cheap dopamine at the cost of lowered attention spans. Take a step back and embrace boredom. Book some time for yourself where you just get “bored“. Stare a random spot on wall, lay on your bed and look at the ceiling, stand in your balcony/garden and watch the trees. This is the mental state where you’ll encourage creative ideas to form.