New release, 28 September 2026

The Conduct of Code

The Art of Writing Effective & Efficient Code

The easier it becomes to produce code, the more important it becomes to understand the code being produced.

Yashavant Kanetkar, from the foreword

Paperback and hardcover. 298 pages, 6 x 9 in. ISBN 9798907637993. Published by Notion Press.

Paperback cover of The Conduct of Code by Angad Kulkarni and Prajakta Mogare, with a foreword by Yashavant Kanetkar

You learned to code. You can write functions, debug errors, and push to production. But somewhere along the way, you started wondering: am I actually getting better, or am I just getting faster?

This book is for that moment.

The Conduct of Code is not a syntax guide. It is not a list of rules. It is a conversation about what it means to write code that is thoughtful, readable, and built to last: code that reflects the person who wrote it.

Through bite-sized concepts, honest analogies, and hard-won lessons from real engineering experience, it walks you through the ideas that separate good programmers from great ones. Not because great programmers know more, but because they think differently.

Programming is not a skill. It is a tool to express your skills. This book is about sharpening what you bring to the tool.

Who it is for

  • Programmers who can codeand now wonder whether they are improving or just getting faster.
  • Students at the startwho want the thinking behind the syntax, with everyday analogies instead of jargon.
  • Developers meeting real softwarewhere maintainability, testing, security and working with other people start to matter.

Yes, there is a chapter on who should not use this book.

Get your copy

Hardcover edition of The Conduct of Code
HardcoverNotion Press
Buy
Paperback edition of The Conduct of Code
PaperbackNotion Press and Amazon.in
Buy

Ordering for a college, library or team? Write to me about bulk or institutional copies.

What's inside

Eight sections, from "what is a program?" to "how do I write code I can trust?"

  1. Hello World
  2. Grammar
  3. Logic
  4. (Not Very) Advanced Concepts
  5. Towards Better Code
  6. Designing for Your User
  7. Secure Code
  8. Beyond Code
Front matter
  • Foreword by Yashavant Kanetkar
  • Preface
  • Acknowledgements
  • About the Book
  • Who Should "Not" Use This Book
  • How to Use This Book
Section 1. Hello World
  • What is a Programming Language
  • The Computer
  • The Program
  • The Language
  • The Grammar
  • Types of Languages
  • Compiled vs Interpreted
  • Low Code & No Code
  • Who Should Learn Programming & Why
  • How to Start Learning to Code
  • Which Language Should I Select?
  • Understanding Computer Hardware
  • What is a Bug?
Section 2. Grammar
  • Keywords
  • Variables
  • Data Types
  • Type Casting & Coercion
  • Identifiers
  • Scope
  • Operators
  • Arrays & Collections
  • Conditional Statements
  • Loops
  • Break & Continue
  • Functions
  • Recursion
  • Classes
  • The Four Pillars of OOP
  • Exception Handling
  • Comments
  • Indentation & Whitespace
Section 3. Logic
  • Algorithms & Flowcharts
  • How to Think Logically
  • How to Break Down a Problem
  • Reading Documentation
  • SDLC
  • System Architecture
  • APIs
  • Decision of Tech Stack
  • DB vs Excel
  • Coding Style & Approach
  • Regular Expressions
Section 4. (Not Very) Advanced Concepts
  • Why 8 Bits Make a Byte
  • Binary Arithmetic Errors
  • Integer Overflow
  • Encoding (ASCII, Unicode, UTF-8)
  • Software, Firmware, Middleware, OS & Drivers
  • The Compilation Process
  • Working of an Interpreter
  • From Code to Execution
  • CPU, GPU, TPU & NPU
  • Networking Basics
  • Time & Space Complexity
  • Memory vs Processor Optimised Code
  • Design Patterns
Section 5. Towards Better Code
  • SOLID, one chapter per principle
  • DRY, KISS, YAGNI, ACID
  • Separation of Concerns
  • CAP Theorem
  • 12 Factor App
  • Least Astonishment
  • Least Knowledge
  • Low Coupling & High Cohesion
  • Naming Conventions
  • File & Folder Structure
  • Hardcoding vs Flexible Code
  • Writing Systematic Code
  • Comments Are Not a Substitute
  • Do One Thing
  • Using Exception Handling Correctly
  • Warnings
  • Modularity & Maintainability
  • Async, Multithreading & Multiprocessing
  • Zombie & Orphan Processes
  • Logging
  • Debugging
  • Software Testing
  • F.I.R.S.T.
  • Four Rules of Simple Design
  • Code Reviews
  • Technical Debt
  • Version Control
  • Environment Management
  • Documentation
Section 6. Designing for Your User
  • UI vs UX
  • UI Principles
  • Golden Ratio, Silver Ratio & Rule of Thirds
  • 8pt Grid & 12 Column System
  • Geometric Progressions in Design
  • Hick's Law
  • Fitts' Law
  • Jakob's Law
  • Miller's Law
  • Tesler's Law
  • Doherty Threshold
  • Pareto Principle
Section 7. Secure Code
  • The 7 Pillars of Cybersecurity
  • Know Your Enemy
  • The Attacker's Mindset
  • Input Is the Enemy
  • Encode Your Output
  • Authentication vs Authorisation
  • Secrets Don't Belong in Your Code
  • The Classics
  • Least Privilege
  • Dependencies & the Supply Chain
  • Secure Defaults
  • Encryption
Section 8. Beyond Code
  • Programming Ethics
  • Fair Use of Software
  • Open Source
  • Building in Public & Communities
  • AI and the Future of Programming
  • Vibe Coding
  • The Never-Ending Learning

Read a page

Chapter 5.25, Technical Debt (pages 212 and 213).

Technical Debt

Shortcut takenDebt incurredCost if ignored
Hardcoded valuesConfig changes require code changesGrows with every new environment
No tests writtenChanges made with no safety netEvery change is a risk
Duplicate logicBug fixed in one place, not the otherBugs multiply silently
Quick fix over proper fixWorkaround on workaroundSystem becomes unmaintainable
No documentationOnly the author understands itKnowledge leaves with people

"Technical debt is borrowed time. The interest always comes due."

212

Technical debt is like financial debt. You take a shortcut today: you borrow against the future. And just like financial debt, it accumulates interest.

The shortcut is usually made with good intentions. The deadline is tomorrow. The quick fix works. We will clean it up later. And in the moment, that is often the right trade-off.

The problem is later. Later, there is another deadline. And another shortcut. The debt grows. Each shortcut makes the next one harder, because you are building on an unstable foundation.

Features that should take days take weeks. Bugs that should be simple to fix take hours to trace. New developers cannot understand the codebase. Nobody is confident changing anything.

The solution is not to never take shortcuts. It is to take them consciously and pay them down deliberately. Track the debt. Set aside time to refactor.

Technical debt is not a sign of bad programmers. It is a sign of programmers under pressure. The failure is not in making the trade-off; it is in forgetting it was made.

Borrow consciously. Pay back regularly.

213

Angad Kulkarni

Entrepreneur, founder and CEO of a software company, and a visiting professor at institutions including Symbiosis International University and the Indian Institute of Information Technology, Nagpur. He has spent years at the intersection of building software and teaching the next generation of engineers, and believes the best code is written by people who understand why before they write a single line.

Prajakta Mogare

Software engineer, CTO and systems architect with deep experience leading engineering teams and designing software at scale. She has spent her career turning complex technical problems into elegant, maintainable solutions, and knows firsthand what it costs when code is written without care.

Together, they wrote the book they wished someone had handed them early in their careers.