The book Clean Code talks about how to write code that is understandable and maintainable. It seems like a next step after Leetcode. Let's see an example from a mine sweeper game. Could you understand the example on the left? Was the right one easier to understand?

The first 3 chapters of this book is introductory, covering 1. Clean Code, 2. Meaningful Names, 3. Functions.

FOREWORD

Philosophy of Clean Code

• Small things matter. And their value is nonetheless far from small. Attentiveness to detail is the critical foundation of professionalism. Through practice of the small, one gains proficiency and trust for the large.
• One lifetime, many masters. Everyone's perspective on what makes good code differs. What is important is to improve judgement.
• Put it into practice. Like riding a bike, even with all the physics equation of how to work, you'd still fall the first time you ride. Practice, make mistakes, and learn.

Splitting of the Book

Part 1 is on the good practices, Part 2 is on the case studies (you should work through these!), Part 3 is the intuition gained.

Chapter 1: Clean Code

Bad code usually happens because we try to develop too fast. When we say we'd go back to clean it up later, it usually does not happen. The code becomes twisted. Each new feature needs more twists to fix things. Over time, the mess becomes so big that it becomes incredibly difficult to clean it up.
As developers, we are important to tell PMs to slow down development if we need time to keep things clean. Else, we set up bad expectations that we can deliver too fast.

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem. - Ward Cunningham, inventor of Wiki

Why clean code matters? From playback of Emacs, reading : writing code time was in the ballpark of 10:1

The Boy Scout Rule

Leave the campground cleaner than you found it.

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.

Chapter 2: Meaningful Names

Use Searchable Names

Method & Class Names

Class Names should be nouns, for example Customer, Account, AddressParser. Method Names should be verbs, for example postPayment, deletePage, or save.

Avoid jumping "level of abstraction"

Chapter 3: Functions

Functions could be 3000-line, 100-line, but should hardly be 20-lines long. And they should only do one thing.
How to determine?
See below code, it's easy to tell it does 3 things:

1. Determining whether the page is a test page.
2. If so, including setups and teardowns.
3. Rendering the page in HTML.

Notice that the 3 things are one level of abstraction below stated name of function. Thus function is doing one thing.
Another way to know that a function is doing more than “one thing” is if you can extract another function from it with a name that is not merely a restatement of its implementation.

Indent levels should not be greater than two.
Arguments are best kept at zero. More than three (polyadic) requires very special justification.
See two-argument function:

assertEquals(expected, actual)

See how easy it is to mix up the expected and the actual.

How to reduce argument objects:

// Dont use this
Circle makeCircle(double x, double y, double radius);
// Use this
Circle makeCircle(Point center, double radius);