Akhil's Blog Thoughts, Ideas, Essays & Views

I-Shaped Learning

This is a post on I-Shaped learning framework to build expertise


Generally for building technical & engineering expertise, the learning framework which has worked well is something like an I-Shaped Learning where there are three important components of the learning plan which are explained in the diagram below.

There is a lot of debate going on with regards to breadth focus vs depth focus. Even the popular saying “Jack of all trades is a master of none” is misrepresented today as an insult to people who are focusing on the breadth while ignoring the depth but the original full quote “Jack of all trades is a master of none, but often times better than master of one” was in fact a complement.

General guidance for the plan would be to spend equal time on each of the three components (minimum 4 weeks each) in the first iteration & repeat again for deeper learning. The plan is basically a checklist, create a copy & update each of the checklist item with specific details, artifacts like docs, mind-maps etc and individual learning.

Breadth On Fundamentals

Learning a wide range of fundamentals (computer science, coding, design & language) is very important to build mental muscle to understand different nuances & comfortably handle technical complexity as well as building a good grip on systems.

CS Fundamentals

This should be covered by any CS fundamentals MOOC course in references, follow one course & complete it, instead of spreading thin across many information sources.

Data Structures

  •    Basic Data Structures

    Understanding & practicing problem solving using the basic data structures - arrays, linked lists (singly & doubly), lists, stack/queues, min/max heaps, maps, trees. Also various data structure considerations - space, time complexity (read/write).

  •    Advanced Data Structures

    Understanding & practicing problem solving using some of the advanced data structures considerations (memory hierarchy with caches, hashing techniques, immutability, large data sets) and examples (priority queues, binary trees, bloom filters)


  •    Basic Algorithms

    Fundamental concepts - space & time complexity, asymptotic notation, basic algorithms - sorting & searching, algorithm design - iterative/recursion, memoization/dp, divide & conquer, greedy, branch & bound, optimizing algorithms (removing bottlenecks, unnecessary operations, duplicated operations)

  •    Advanced Algorithms

    Understanding & knowledge of a couple of advanced algorithms from any domain like - parallel (matrix multiplication), streaming (count-min sketch), randomized algorithms (quicksort), string (suffix trees), graph (DFS, BFS), mathematical (linear programming).

Coding Fundamentals

The clean code book & the examples link in references can be a good start as it covers many of these things.

Code Design

  •    Code Constructs

    In-depth understanding of common code constructs (variable/constant, conditions, loops, functions, type/class, try/catch, thread safety, annotation) and knowledge of advanced constructs & concepts (macros, currying, trait/aspect, symbolic tree)

  •    Code Structuring

    Learn various code structuring mechanisms (modular decoupled structure, convention based structure, domain driven design based structure, tech vs functional oriented, frontend/backend structure, framework vs library structure) & list examples for each.

Coding Practices

  •    Coding Best Practices

    Learn & list down coding best practices - language independent like general (naming, readability, indentation etc), design (low coupling, don’t repeat yourself) & language specific like syntax (standard linting, using obvious not obscure constructs, nuances of constructs), semantics (exception handling, concurrency, built-in types behavior).

  •    Code Review Best Practices

    Learn & list down code review best practices - code review checklist (readability, security, structuring, test coverage, reusability), code review metrics (inspection rate, defect rate, defect density), code review automation (danger.js), code review diligence (400 lines at a time, nitpicks %), code review etiquettes (suggestion instead of command, conversation instead of fault finding)

Design Fundamentals

Design Patterns

  •    Solid Principles & OOP Design Principles

    Go through & practice some of the important design patterns like observer, strategy, adapter, facade by implementing them. Common design principles like SOLID, OOP (composition over inheritance, container structure using core + extensions / modules / plugins - for inversion of control & dependency injection)

  •    Distributed System Patterns

    Go through and learn various distributed design patterns like single node patterns (side-car pattern, adapter, ambassador), multi-node patterns (discovery, cluster management patterns - consensus algos, leader/master election, data/control plane), batch computational patterns (work queues, event based processing, coordinated workflows), distributed transactionality patterns (2-phase commit, saga pattern etc.)

Design Anti-Patterns

  •    Code & Design Anti-Patterns

    Learn some of the common coding anti-patterns (spaghetti code, god class, cyclic dependencies, copy/paste, golden hammer, dead code, scattered code, boat anchor) and code smells (duplicate code, large functions, lazy/large class, mysterious naming, unsafe type handling, side-effects)

  •    Distributed System Anti-Patterns

    Learn some of the common distributed system anti-patterns - microservice anti-patterns (distributed monolith, shared database, dependency disorder, entangled data, improper versioning, missing api-gateway) & list down reasons why these result in bad design.

Language Fundamentals

Language Independent

  •    Programming Languages Landscape

    Look at various programming language families (procedural. object oriented, declarative, functional, logic), operating model (interpreted, compiled), abstraction level from machine to humans (machine, assembly, high level), origin (academy, industry)

  •    Programming Languages History

    Many of the languages have evolution paths where sometimes in the new language, fundamental changes are introduced while other times its only incremental new constructs. Go through a couple of these like c -> c++, java -> scala, erlang -> elixir.

Language Specific

  •    Constructs & Language Design

    Language constructs starting from syntax to semantics, then looking at the overall language design. Constructs for different programming paradigms - declarative (macros, annotations), procedural (first order functions, loops, conditions), oop (type, inheritance, polymorphism, generics, reflection), functional programming (closure, higher order functions, pattern matching, list comprehensions) etc. Do this for any one language.

  •    Language Evolution & Philosophy

    Language evolution and philosophy are important to know and understand, this builds the context in which programming language has been developed. Most being open-source helps in looking at the evolution of the language & learning.

  •    Compiler & Virtual Machine Internals

    The way language and various constructs operate or are implemented in the VM, this gives a good view of the VM for doing tuning, optimisation and knowing internals like scheduling, memory management helps in debugging & troubleshooting issues.

Depth On Single Tech Stack

Important thing to keep in mind for this section is to reduce context switching & have deeper thinking to understand the journey of a tech stack well, so that the learnings here can be extrapolated quickly for any tech stack, whenever required on demand.

Tech Stack

Stack Selection

  •    Select Tech Stack

    Based on interest, select one of tech stack for deep dive (like data stack - any sql or nosql data stores or messaging stack - kafka, rabbitmq or functional stack - elasticsearch, neo4j or infra stack - docker container, kubernetes)

  •    Tech Stack Mind-map

    Mind-map for covering the breadth of the tech stack - pros/cons, high level design, when to use this tech stack, comparative analysis with competition, use-case mapping (popular use cases with understanding of why this tech stack was preferred)

High Level Design

  •    Component / Block Diagram

    Create the component or block diagram based on the HLD understanding of tech stack, iterate over it couple of times and then compare with the existing component or block diagram from tech stack developers

  •    Data & System Architecture

    Create the data & system architecture of the tech stack based on the HLD understanding of tech stack, iterate over it couple of times and then compare with the existing data & system architecture diagram from tech stack developers

Deep Dive

Low Level Design

  •    Schema & API

    Go through & list down the data schema (for meta, master & transaction data models) and various APIs (type - sync/async, protocol - rest/grpc, format - xml/json, security - authn/authz, contract - sla/limits, robustness - idempotency/degradation)

  •    Tech Stack Components

    Go through & list down the important components like language, base libraries (like lucene for Elasticsearch), abstraction layers - data, logic & api layer, underlying storage mechanism, concurrent processing mechanism (threading vs lightweight processes)

Code Level Design

  •    Data Structures & Algorithms

    Go through & list down the important DS/Algo used in the tech stack, need & rationale behind using those, what optimisation (space or time or both) these DS/Algo bring, review the space/time complexity, are there better alternatives & why.

  •    Data/Compute, Code, Read/Write Flows

    Go through & list down the important flows in the tech stack - from different point of views - data & compute, read & write flow, code flow. Create the flow diagram for the listed flows along with their inter-relationships like cross-dependencies, pipelines etc.


Design Tradeoffs

  •    Fundamental Resource Tradeoffs

    Go through and list down the fundamental resource tradeoffs (compute, storage, memory, network, time) that are applicable to the tech stack, why these tradeoffs are important for the success of the tech stack

  •    Distributed System Tradeoffs

    Go through and list down the distributed system tradeoffs (consistency - serializability & linearizability, availability, partition tolerance) that are applicable to the tech stack, why these tradeoffs are important for the success of the tech stack.

Decision Log

  •    Critical Design Decisions

    Go through & list down the critical design & architecture decisions from inception, look at the anatomy of each of these decisions (3 fundamental parts for each decision - problem - approaches - solution) and the retrospective of decision - impact, pitfalls etc

  •    Important Design Decisions

    Go through & list down the important (non-critical) design & architecture decisions, look at the anatomy of each of these decisions (3 fundamental parts for each decision - problem - approaches - solution) and the retrospective of decision - impact, pitfalls etc

Breadth On Tech Stacks

This section is the last and open-ended, it is more like understanding the landscape of tech stacks based on various needs & use cases, mainly to be able to judiciously choose the appropriate tech stack whenever needed based on various parameters.


Tech Stack

  •    General

    Create mind-map for the important things to consider when evaluating any tech stack - pros/cons, high level design, when to use which tech stack, comparative analysis, use-case mapping, functional/non-functional & ecosystem related evaluation criteria

  •    Non-Functional

    Go through & list down the non-functional considerations (security, robustness, stability, resilience, scalability, performance) which are important for selecting any tech stack for a given problem, why they are important & how to measure each of these considerations.


  •    Support, Community & Management

    Go through & list down the ecosystem considerations like support (sponsors, core contributor activity etc), community (size, involvement) & management (managed service, paid support) which are critical for operability & sustainability of tech stack.

  •    Benchmark & Independent Evaluations

    Go through & list down the various benchmark & independent evaluations to be reviewed to be able to take more data driven & well researched decisions. For example - https://jepsen.io/ is the de-facto standard for distributed system evaluation.


Data Stores & Messaging

  •    SQL & NoSQL Data Stores

    Go through different sql databases (mysql, mssql, pgsql, oracle) and nosql datastores like key-value stores (redis, aerospike), columnar stores (cassandra), document stores (mongodb, couchdb), graph stores (neo4j, dgraph), search store (elasticsearch, solr)

  •    Generic vs Specialized Data Stores

    Look at the datastores from generic vs specialized functionality point of view - generic (sql db, in-memory, key-value, columnar, document) or a bit more specialized (graph, search, time-series, analytical). Mind-map for considerations for a few categories.

  •    Messaging Frameworks

    Look at the popular messaging frameworks (like kafka, pulsar, rabbitmq, activemq), messaging considerations like functional (delivery guarantees), performance (throughput, latency), consumption model (pull, push), storage model (log, index)

Processing & Application

  •    Stream & Batch Data Processing

    Go through & list down the open-source stream & batch data processing frameworks like storm, spark, flume, flink, skoop) & commercially available (redshift, athena, snowflake, big-query, synapse)

  •    Application Frameworks & Libraries

    Go through & list down the application framework & libraries which are relevant for current work - backend(django, flask for python, gin, gorm for go), frontend (react, vue, angular), other framework & libraries (grpc, graphql, rule engine, workflow engine)


Breadth On Fundamentals

Breadth On Tech Stacks

Depth On A Tech Stack


Design Tradeoffs

Decision Log



Important Courses

Decentralized Decision Making

This is a post for helping in decision making


As the organization scales & in general also, the biggest challenge is that of decentralized decision making, these are some thoughts on how to enable this. It can also encourage deeper participation, experimentation, innovation and keeping the team driven.


The biggest challenge in the growing organization is around decision making, how to enable decentralization of decision making. When the organization is small, context is limited and most of the time centralized decision is what works well and not much alignment needed, sometimes the divergent views are not present while other times time is limited.

But as the things scale, context increases & decision making becomes more complex as well as nuanced. Teams need a framework which can enable them to take decisions without being too dependent on the leadership or experts.


Transitioning from How to What to Why or Doing to Knowing to Understanding becomes a stepping stone in moving from centralized decision making to decentralized decision making allowing people to choose what based on why and how based on what. The why (understanding) inspires & motivates the what while the what (knowledge) guides & aligns the how (doing).

The difficulty comes as there is no standard way to define these and even though the idea of moving from how to what to why seems good on paper but operationalizing it is not easy. Below is the framework to define & evolve the How to What to Why over time.


Core flows in working through anything can be done at three levels - how, what & why. The decision making is also required at each level & the most important thing for decisions in the fast changing world is the flexibility & agility to change the decision in response to new information or dynamic circumstances, for this we need to move to higher order thinking by pushing the decision to the next level. Basically when the focus is shifted to “what”, “how” becomes flexible & open-ended, similarly shifting focus to “why” makes the “what” flexible.

How / Doing / (Solutioning + Execution + Operation)

This is the implementation or in general terms tactical level which covers end to end roadmap to get somewhere by doing. It involves problem solving which itself can be divided into 3 phases - solutioning (problem definition -> exploring approaches -> finalizing solution), execution (planning, implementing & delivery), operations (production support, maintenance & evolution). This is the most important level to bring anything to life, but this level is a lot more focused on doing & lacks seeing the bigger picture of whether something is relevant for a larger goal or not.

The decisions here tend to be much more tactical in nature as getting something done is more important than to introspect/retrospect/prospect on whether it is good in the long term or not, whether it moves us towards the larger goal or not. Also, this level is more input or effort oriented instead of outcome oriented which means focus will be to think of how to do something rather than what to do, which also makes it less future proof as even if the result or outcome is not getting achieved, the decision need not be changed.

What / Knowing / (Success Metrics + Objective + Key Results)

Defining what has a lot to do with knowing deeply about the problem which is critical to define the success metrics for any solution. Once the success metrics is in place, what needs to be done becomes clear but the objective along with key results quantifying & slicing the what based on time (different quarters) & space (various teams). Decisions to do “what” are completely focused on outcome & will help in making the “how” flexible as it doesn’t matter which solution brings the outcome as far as it is achieved.

Why / Understanding / (WorldView + Hypothesis + Experiment)

Why is the highest level in the framework with focus on the reason, intention & rationale behind doing something. This is the level where civilisational & cultural lens matters, based on the environment & upbringing of the person, team & organization, the worldview will be formed which will then drive the hypothesis & experiments to make decisions based on the “why”.

  • WorldView - This is generally not discussed in detail and also lot of times abstract & not defined concretely as its subconsciously built in form of learnings from environment.
  • Hypothesis & Experiments - The hypothesis helps in making some prediction based on the world view & doing experiments to evolve the hypothesis.

General Concepts Around Decisioning

Problem vs Solution Focus

The problem & solution focus many times becomes important to be flexible towards solutions and not become rigid with a solution. It will also enable us to move from deterministic thinking to hypothesis thinking (where solution is seeked using hypothesis + experiment).

Deterministic vs Probabilistic (Hypothesis) Thinking

The hypothesis approach towards defining problem & solution is by default adaptive while a more deterministic approach might be appropriate for situations where being right is critical (even if it means to delay decision & wait for sufficient information). Probabilistic thinking enables incremental decision making by refining & evolving the hypothesis with more experiments (gathering relevant information).

Assumption Blinds vs Hypothesis Guides

Assumption is basically an implicit unknown & unproven point taken as truth while hypothesis makes that unknown explicit which is important to understand the gaps that can be there in the decision being made due to imperfect knowledge & understanding of the world around us. Sometimes facing ignorance explicitly is a lot better than implicitly claiming knowledge, which is probably the reason for many decisions being incorrect & that coming as surprise too.

Progress vs Perfection (Incremental Thinking)

In most of the decisioning cases, progressive decisions are better than aiming for perfect decisions, incremental thinking helps in evolving decisions which is more future proof.

Acknowledging Ignorance vs Claiming Knowledge

Focusing on ignorance & acknowledging it will result in seeking more knowledge & understanding of the world around us needed to make better decisions while claiming knowledge when its not there, will only result in decisions with of lot of faulty assumptions that can not only make the decision wrong but also result in incorrect learnings from those decisions.

Journey vs Destination vs Intention

The decisioning framework of how -> what -> why is also closely related to the thought process of moving from journey (process of getting somewhere) -> destination (knowing somewhere to go) -> intention (reason to be thinking of a destination). Generally people who understand intention will not be fixated on a destination and definitely will not be bothered to take a journey to any destination based on the larger intention.

Making Right Decision vs Making Decision Right

Most of the time the focus is on making the right decision which pushes us to think a lot, gather as much information as possible, create mental models & decisioning frameworks. But we need to give a lot more importance on how to make the decision right once that decision is made as it’s not always possible to see the correctness of a decision in the short run & many times as it takes a long time to see the truth of the decision. The approach to decision making should involve a good amount of effort & thinking on both aspects - what will be the right decision & what will it take to make the decision right.

Will be writing another post soon to look at some of the examples for using this framework & the learnings from that, it may not be the best framework but can help in steering to the shore.


Individual Development Plan

This is a post for thinking about individual development plan


Individual development has many facets to it, sometimes we may get right opportunities & environment to grow & learn while many times we have to seek or create those opportunities based on individual aspirations & situations. The aim in the post is to put together a template to help anyone who is starting with outlining a development plan for oneself or someone else, these are just ideas to help think about career in more structured way.

There are many different point of views when it comes to approaching self development, whether it should be goal oriented or journey focused, many times the goals create too much pressure & sets an artificial boundary while journey focus gives relaxed growth & also provides flexibility to explore. But this problem with goals is more due to the way goals are defined, if the goals focuses too much on how instead of what & why. Basically instead of steps to reach the goal, we should be defining it crisply first & then overtime think of ways to achieve it.

One of the important learning has been that everyone has some aspirational & concrete goals, in fact most people don’t spend too much thinking time on aspirations & even when some people have clear aspirations, generally they will not share their aspirations unless there is high trust environment. Just for example if there is an aspiration in person to

Planning in general means that you are putting together some kind of projection in future to guide the journey & bring focus on the goals from time to time, it can be done in either forward looking (more suitable for short term oriented plans) or backward looking (suitable for long term oriented plans). The forward planning is basically building on things incrementally based on current situation & competency while backward planning is basically to backtrack the journey to plan for the end goal which is far enough in future to enable anyone to change the situation & competency as required.

If the forward & backward planning converges, that means the work being done today is aligned with individual’s long term aspirations, which means chances are that individual will get more job satisfaction. But if they are not aligned, there will always be a feeling that working on something else may enable the person to achieve those aspirations.

Generally there are few of the themes where “WHY” a person is doing something is clear, people might have different targets based on personal preferences but theme wise it is similar. First theme is the financial theme - basically everyone wants to ensure stable future for oneself & family, next are the becoming & doing themes which are closely related but can result in very different choices in the career. The last theme is around learning which acts as lever or leverage to enable a person to move from current role or work or domain etc to something which the person aspires to do.

Aspirational Goals - Act as a compass

Aspirational goals are basically larger than life goal which many times will be something abstract or open ended, it doesn’t need to be practical or achievable based on current competence & situation, these are meant for much longer duration & scope of these should reflect that.

Next 10 years

  • Financial Theme - Achieve financial freedom for next 10 years, this is more inline with the FIRE movement, it is an important aspect but generally not sufficient to define the journey individual needs to take.
  • Becoming Theme - To become someone, mostly this translates to taking some role may be as engineering leader, product leader or business leader - for example - Technical Architect, Engineer Manager etc, more can be read on engineering ladders
  • Doing Theme - To do something like build world class product, open source contribution, or to work on new (0-1) product, growth (1-10 or 10 -100) product, mature product (scaled)
  • Learning Theme - To learn some skill - tech (design/architecture), domain, non-tech (product, finance), management (project, people)

Next 5 years

  • Financial Theme - Achieve financial freedom for next 5 years, this is more like stepping stone towards the 10 year goal
  • Becoming Theme - To become someone - Principal Engineer
  • Doing Theme - To do something - Take 1 product to customers - internal or external customer, paying or not paying customer
  • Learning Theme - To learn some skill - tech (distributed systems), design (micro-services), product (success metrics), management (agile methodologies, effective feedback)

Concrete Goals - Act as a roadmap

Concrete goals are basically more detailed & are like a roadmap of what a person aims to do in next 1 year, this again can be growth & learning oriented when looking at longer 1 year timeline while competency & outcome oriented in the shorter 6 month timeline. The goals here should have opportunities mapped to ensure that the plan to achieve those goals is in place, also these need not be abstract or open ended instead should be immediately actionable.

Next 1 year

The next 1 year timeline is focuses on linear & possibly non-linear growth, the linear is incrementally doing better & progress to next role while non-linear is either creating multiplier effect by solving cross cutting concerns (breadh) or solving complex concerns (depth).

  • Non-Linear Growth (large impact taking the person leaps ahead in career) - mostly by addressing some cross cutting concerns which will have multiplier effect in the org or solving complex problem having long term impact
  • Linear Growth (current role to next role) - understanding the role delta in terms on increased expectations, mostly focusing on incrementally taking more responsibilities

Next 6 months

This should be based on expectations for the next role & also previous review, many of these things are in geneeral already in progress.

  • Improving the system design by keeping in mind the bigger picture of the system.
  • Increasing the tech breadth which will enable him to make better tech choices while working on the designs. - I-Shaped learning paradigm (breadth on fundamentals & first principles along with depth on one tech stack / area and finally breadth on many tech stacks/area) - Example - Distributed System Design & Algorithms

General Aspects

There are few important general aspects which are mostly common but should find some place in everyone’s individual development plan.

Time & Energy Management

  • Everyone has limited amount of time & energy, it is important to manage these well to accomplish more, the time management will be very different based on different roles, have been using a generic framework - role responsibilities framework which uses a simple approach of understanding the responsibilities of a role, give some percentage to each responsibility based on importance. Example - For engineer role, the responsibilities (execution, solutioning, operational, mentorship, idp) & a sample time allocation for ideal situation may look like this - execution-35%, solutioning-35%, operational-15%, mentorship-10%, idp-5%. In the equilibrium state, time allocation should be like that which means that the focus is to ensure time management comes back to this equilibrium state every few weeks or months depending on the skewness created due to situational factors.
  • Plan for the week and keep the day open - generally have seen that very granular planning at a day level creates more pressure as either adherence will not happen due to some unplanned activity or unnecessarily mind space will be taken to ensure adherence, it is better to plan for the week, keep track and review things by end of the week.
  • For any kind of deep work, continuity of thought & focus is critical which is basically the maker schedule while when the focus is more on delegation & breadth of knowledge, context switching is required & many times good, this is basically the manager schedule. Good article on this - Maker vs Manager Schedule
  • Energy management is equally important, sometimes only optimising on time will drain the person of energy required to perform and may result in slowness of mind, burnout or even feeling exhausted quickly. The best way to keep up with the energy needed is to take breaks (within day, month, quarter & year), taking enough rest.
  • While the time is more continuous in flow, it automatically brings rhythm & consistency but energy is generally non-continuous with many bursts (up and down) which is where chances of mismanagement is much higher and mostly it’s not even talked about unless someone starts feeling very low.

Learning & Thinking Structure

  • Breadth Vs Depth - There is lot of debate going on with regards to breadth focus vs depth focus. Even the popular saying “Jack of all trades is a master of none” is misrepresented today as an insult to people who are focusing on breadth while ignoring the depth but the original full quote “Jack of all trades is a master of none, but often times better than master of one” was in fact a complement. To avoid this dilemma, its better to use a combination of both breadth & depth in something like I-shaped learning paradigm - in this paradigm the focus is on breadth (for the high level) - depth (in one area) - breadth (for the low level). The
  • Strategy Vs Tactics - This is again highly debated topic and generally strategy is associated with long term deep thinking while tactics are short term shallow responses to situations or problems at hand. The learning needs to be on both levels, as if we can’t solve the problem at hand with variety of tactical responses, chances are the strategy may not even see the light of the day. Learning strategy is required for a lot of areas where thinking over doing is more important like design/architecture
  • Learning Agility - The Learning Agility for the VUCA world - The Organisational X-factor: Learning Agility - Korn Ferry Focus is a good framework to improve the learning agility with following five factors
    • Mental agility — embracing complexity, examining problems in unique ways, making fresh connections, and staying inquisitive.
    • People agility — being open-minded toward others, enjoying interaction with diverse groups, bringing out the best in others.
    • Change agility — willingness to lead transformation efforts, continuously exploring new options.
    • Results agility — delivering results in tough situations, responding to challenge, inspiring others to achieve more than thought possible.
    • Self-awareness — being reflective, understanding strengths and weaknesses, seeking feedback and personal insight.
  • Mental Models - One of the most important learning structure which can help in many situations is to study, form & evolve various mental models which basically enables a person in different kinds of thinking & decision making, many times the data driven approach to decision making is good enough of situations but sometimes data might not be in right form (as data needs to be refined, data -> information -> knowledge -> insights or wisdom), various mental models can help short circuit & make the decision making faster but its important to know when & why that model works to apply it appropriately.
  • Decision Making - One simple framework to improve decision making is to move from How (Implementation) to What (Definition & Scope = OKR) to Why (Reason & Motivation). This movement basically increases higher order thinking & bring lot of flexibility in decision making, basically when focus is on what, the how becomes flexible & similarly when focus is on why, the what becomes flexible. Another important way to improve decision making is by doing incremental decision making using Hypothesis (Non-Deterministic) instead of Deterministic approach. When we use hypothesis, the possibility of being wrong is stated explicitly along with other assumptions while when we do deterministic decision making, being wrong is hidden and there can be lot of implicit assumptions. Hypothesis based approach also enable person to do evolve decision incrementally by qualifying & refining the hypothesis as more & more knowledge is discovered & understanding deepens.


Core Accounting

This is a post to get someone started with core accounting concepts.


The blog post on core accounting will cover the basics for accounting with different concepts like chart of accounts, double bookkeeping, accounting equations etc. Providing a broader view on the financial, managerial and cost accounting, how these tie together.

It will also cover the money flows between different entities and how it is accounted for using the accounting entity & time period. Different accounting systems of cash & accrual basis, conventions around debit/credit & increase/decrease, account types of nominal & real accounts.

The core accounting concepts of journal, ledger and double bookkeeping, different financial reports, financial decision making, cost analysis & finally return on investment.


Accounting is primarily aimed at better financial health & planning, generally it can be understood as composed of the following activities which can be broadly classified into financial, managerial & cost accounting. The target is to use accounting information to do the budgeting & forecasting & finally do capital allocation based on the return on investment (ROI).

Financial Accounting Only MA Cost Accounting
Only FA Managerial Accounting Only CA
Transaction Bookkeeping Financial Reporting Analysis & Interpretation Decision Making Costing Control & Analysis Costing Bookkeeping
Transactions / Events / Occurrences

Financial Reporting (Equity Changes, Notes To Account)
Financial Statement Analysis

Costing Techniques (marginal, absorption)
Identifying elements of costs
Recording (Journal Entry) Primary Books

Financial Statement (Balance Sheet, P/L, Cashflow)
Financial Ratio Analysis & Interpretation

Capital Allocation
ROI (Return On Investment)

Cost Control (Standard Costing & Variance Analysis)
Classifying elements of costs
Classifying (Ledger Entries) Secondary Books

Summarizing (General Ledger, Trial Balance)
Relative & Comparative Analysis (Time & Industry)


Cost Analysis
(CVP & BE)
Cost determination (costing)


Various concepts that are important to understand before we get into the core accounting in general & for some of the products.

Accounting Cycle

The accounting cycle is the first important concept to understand which basically represents the scope of accounting in terms of activities bounded by time & entity. The cycle starts with identifying the transactions (during time duration for a set of entities), recording journal entries, classifying into ledger entries, summarizing into general ledger & trial balance, auditing & balancing the accounts, generating the financial statements and closing the books.

Account Types & Golden Rules

To understand the Golden Rules of Accounting we must first understand the types of accounts. The account classification applies to all the types of general ledgers. In other words, every account will fall in one of the broad classifications given below. There are three types of accounts:

  • A Real Account is a general ledger account relating to Assets and Liabilities other than people accounts. These are accounts that don’t close at year-end and are carried forward. An example of a Real Account is a Bank Account.
  • A Personal Account is a General ledger account connected to all persons like individuals, firms and associations. An example of a Personal Account is a Creditor Account.
  • A Nominal Account is a General ledger account pertaining to all income, expenses, losses and gains. An example of a Nominal Account is an Interest Account.

Accounting Rules

Account Type Rule
For Personal Accounts Debit the receiver, credit the giver
For Real Account Debit what comes in, credit what goes out
For Nominal Account Debit all the expenses, credit all the incomes

Chart Of Accounts

Chart of accounts is the general organizing technique used in accounting for structuring the transactions into various heads/buckets/bins which then roll up to general ledger & trial balance.

There are multiple different ways of structuring the chart of accounts and it is a very similar exercise like the data modeling exercise done whenever building any data application. The better schema design done for the database solves a lot of problems later, it is the same logic with a chart of accounts, we can consider this as data modeling for accounting data.

Account Identification

  • Generally speaking each account should be identified by the UUID but this alone is not useful in easily defining the ledger entries (which translates to governor rules & ledger config) without too much redundancy as well, we need another way of identifying accounts based on the identifying dimensions.
  • Account identification using identifying dimensions will require combining the identifying dimensions of the parent & identifying dimensions of the sub account.

Naming & numbering of the accounts

  • Account numbers are like the bin numbers in a warehouse. Five-digit base account numbers work well (four for a very simple setup). Best practice is to use the 10000s for asset accounts, 20000s for liabilities, 29000s for equity, 30000s for sales, 40000s-50000s for direct/indirect costs, 60000-70000s for operating/overhead expenses, and 80000-90000s for non-operations accounts such as interest and taxes.
  • Account naming can also be used to reflect both the hierarchy of accounts & identifying dimensions like [Account Id][Account Category][Account Type][Fund Account Type] - [Sub Account Id] which is basically a combination of parent identifying dimensions + sub account identifying dimensions.
  • Account Naming & Numbering are both for making accounts more readable for users & are not to be used by the system for identification purposes.

Account Hierarchy vs Account Dimensions

  • Hierarchy is in general very strict & restrictive (inheritance is always tightly coupled as it causes tight coupling between parent/child and that is the reason composition is preferred in object oriented data modeling), but it makes sense to use hierarchy when inheriting the parent attributes in the child is required (parent account acting as template for the child accounts)
  • Avoid more than 2 or 3 levels of child accounts. For example, 33000 Sales-Hardware could be further broken out to 33100 Sales-Hardware-Computers and 33200 Sales-Hardware-Printers. Hardware-Printers could be further broken out in 33210 Hardware-Printers-HP and 33220 Hardware-Printers-Canon. At that point, further detail may be more harmful than help and lead to inaccurate accounting.

Double Bookkeeping

Single Bookkeeping Example (Mostly useful for tracking cash in single account)

DateDescriptionTransaction ValueAccount Balance
Income (Credit)Expense (Debit)
01/01/2022Starting Monthly Balance₹100000
03/01/2022Invoice Paid (Excel Tech)₹50000₹130000
04/01/2022Supplies (Furniture)₹15000₹115000
05/01/2022Ending Monthly Balance₹115000

Double Bookkeeping - Same Example

  • Assets, Expense & Dividends (Debit means increase & credit means decrease)
  • Liability, Revenue & Equity (Debit means decrease & credit means increase)
DateDescriptionDouble BookkeepingCash Account Balance
01/01/2022Starting Monthly Balance₹100000
02/01/2022Rent[Expense][Rent] = ₹20000[Asset][Cash] = ₹20000₹80000
03/01/2022Invoice Paid (Excel Tech)[Asset][Cash] = ₹50000[Revenue][Product] = ₹50000₹130000
04/01/2022Supplies (Furniture)[Asset][Fixed] = ₹15000[Asset][Cash] = ₹15000₹115000
05/01/2022Ending Monthly Balance₹115000

Double bookkeeping is better for reducing financial errors, managing cash entries correctly (in accrual basis accounting), every transaction needs to have equal debits & credits, this can still result in deficit or surplus on aggregate level (for this the trial balance comes handy).

The debit & credit is the somewhat confusing nomenclature in accounting (due to different behavior for different account types), lot of new accounting standards are already moving to increase/decrease which remains the same for all account types.

Accounting Equation

The accounting equation is a critical concept to understand and use the double bookkeeping, whenever the entries are made on opposite sides of the equation, will be of the same type (credit or debit) while if entries are on the same side of the equation, it will be opposite to each other.

  • Balance Sheet Accounting Equation
    • Assets = Liabilities + Shareholder’s Equity
  • Expanded Accounting Equation
    • Assets = Liabilities + Share Capital + Retained Earnings
  • Fully Expanded Accounting Equation
    • Assets = Liabilities + Contributed Capital + Earlier Retained Earnings + Revenue - Expenses - Dividend
    • Assets + Expenses + Dividend = Liabilities + Contributed Capital + Earlier Retained Earnings + Revenue
DateDescriptionAccounting EquationCash Account Balance
Assets = Liabilities + Revenue -Expenses
01/01/2022Starting Monthly Balance₹100000
02/01/2022Rent[Asset][Cash] = -₹20000 (cr)[Expense][Rent] = +₹20000 (dr)₹80000
03/01/2022Invoice Paid (Excel Tech)[Cash] = +₹50000 (dr)[Product] = +₹50000 (cr)₹130000
04/01/2022Supplies (Furniture)[Fixed] = +₹15000 (dr)
[Cash] = -₹15000 (cr)
05/01/2022Ending Monthly Balance₹115000

Accounting System

The accounting system is quite different based on the recognition of revenue & expense as it has implications for a lot of things like balance sheet, income statement & cash-flow statement. The major difference comes with respect to taxes & cash-flow, some more detailing below.

Cash Basis Accounting

In the cash basis accounting system, every transaction is recognised only at the time of cash movement (when money changes hands). Many small businesses opt to use the cash basis of accounting because it is simple to maintain. It’s easy to determine when a transaction has occurred (the money is in the bank or out of the bank) and there is no need to track receivables or payables.

The cash method is also beneficial in terms of tracking how much cash the business actually has at any given time; looking at bank balance gives understanding of the exact resources at disposal.

Accrual Basis Accounting

Accrual basis accounting is a method of accounting where revenues and expenses are recorded when they are earned, regardless of when the money is actually received or paid.

The accrual basis gives a more realistic idea of income and expenses during a period of time, therefore providing a long-term picture of the business that cash accounting can’t provide.

But accrual accounting doesn’t provide any awareness of cash flow; a business can appear to be very profitable while in reality it has empty bank accounts. Accrual basis accounting without careful monitoring of cash flow can have devastating consequences on business operations. Comparison Between Cash & Accrual

  Cash Basis Accounting Accrual Basis Accounting
Revenues Recognizes revenue when cash has been received Recognizes revenue when it’s earned (eg. when the project is complete)
Expenses Recognizes expenses when cash has been spent Recognizes expenses when they’re billed (eg. when you’ve received an invoice)
Taxes Taxes are not paid on money that hasn’t been received yet Taxes paid on money that you’re still owed
Usages Mostly used by small businesses and sole proprietors with no inventory Required for businesses with revenue over $25 million

Examples of Cash & Accrual Basis

Transaction Cash Basis Accounting Accrual Basis Accounting
Revenue From Project Revenue accounted when billed amount for the project comes to the bank account Revenue accounted when invoice for the billed amount is raised
Expenses For Project Expenses accounted when booked amount for project expense deducted from bank Expenses accounted when amount for project expense booked
Tax Implication Tax implication is at the time of revenue collected & expense deducted Tax implication is at the time of invoice raised & expense booked

The accrual basis system is much more relevant today due to the dependency and popularity of the credit over cash. Almost everywhere you see the credit as a product (Debentures, Bonds, Overdraft for businesses while BuyNowPayLater, Credit Card, Credit Line like products for consumers) is becoming more popular than the cash.

There are a lot of other benefits of accrual basis accounting as it is much closer to real life situations where companies give customers credit (postpaid after order is delivered) and pay the vendors (after invoice is raised). The real complication comes with taxes particularly the GST which is based on recognition of revenue & expense (instead of realization).

Accounting Across

Many times accounting for one time period or one entity is not good enough, we need to incrementally do accounting for across time periods & across entities.

Accounting Across Time

Accounting can be done at different intervals of time - Day, Week, Month, Quarter, Year and the reason for doing accounting across time is to enable us to see or monitor financial health at different time granularities.

Accounting Across Entities

Accounting can be done across different entities like departments or business units, rolling up with entities like departments to organization. We can also do scoped accounting for an entity like accounting for another business upto the extent data is available and it makes sense.

With both time & entities, the accounting can be done at a granular level & also roll-up to provide both a granular & wider view of financial health for entities x times dimensions.

Money Movement

Various money movements in general from firm to stockholders, between firm & financial system but before we go into the details of the money movement, it is important to understand the interrelation between various statements.

Relationship Between Financial Statements

How different kinds of statements are linked to each other and how it helps in doing accounting for next week, month or year.


Chart of Accounts


Double Entry Bookkeeping

Accounting System

Foreign Currency

Accounting Equation


Udemy Courses

Introducing Blog


During college days, used to put some ideas on writing and then in my first job at Qwest, maintained a private blog for sometime to log ideas & feelings but never maintained it. This is an attempt to consolidate some of blog posts from past which are scattered at different places, also there are lot of incomplete ones which I am hoping to complete too.

Have been writing bits and pieces mostly on tech & product from the startup days while recently have been able to build some knowledge on finance particularly accounting and sanskrit which will also be interesting topics to write about.

Studying computer science from IIT Guwahati, my journey started with tech, lot of interesting work I remember, then moved to product, advertising & marketing during startups, finally settled in management & leadership which also seems the most challenging with much deeper learning.


The blog is based on the github pages using jekyll theme lanyon, great thing about this stack was that it took just few hours to set it up from buying domain to getting it ready with few posts pulled from past. Using git for blog will mean that the posts can evolve with new knowledge and become like wiki where it will be easy to look at how the thought has evolved over time.

Currently working in one of the best fintech company, learned a lot on tech, finance, product & management. The finance as a subject is something I wanted to get into but reading finance books is generally not very interesting, even when I was doing some investment related study it was always difficult to maintain focus beyond a month, and being in fintech company helps in maintaining that focus.

Want to also put some of the ideas I wish to work on in future to keep building the backlog of interesting problems to solve which can push me into doing the next start-up whenever that happens.


It is very tempting to write something before even knowing enough but that generally is the receipe for misinformation. My attempt would be to put things on which I am pretty knowledgable & confident but in case you find any incorrectness in any of the post, please do provide feedback on email, will correct it soon.

If any of the post seems interesting, plesae do contact for further discussion on those or related ideas.