0. Understanding a codebase:

0.0. Get to know the codebase:

0.0.0. Code distribution:

You can get an overall "idea" of the code distribution, or where the meat is, by using `cloc . --by-file`. This shows you a listing of files and their respective number of lines of code and comments. You instantly get an idea of the "big" files of the project you probably should get to know.

You also see the ratio comment/code and can start documenting and writing tests as you go. It will help you understand the project, and will be useful for everyone and in refactoring.

0.0.1. Structure:

0.0.1.0: Visualization

Drawing helps me. Conceptual blocks of the project. It can start as block names and boxes "Codec", "Streaming", "Persistence", "Dispatcher", etc.

Drawing on paper, whiteboard, etc. You can also use something like "Gliffy" to diagram for yourself and with someone when communicating. You can both change and make sure you're talking about the same thing.

And do it going down the abstraction scale. Higher abstractions to lower abstractions.

I also found a quick automatically generated "UML" diagram helps. I don't write them necessarily, but I use a tool that tells me about the structure of a project.

pyreverse for Python, scaladiagrams for Scala, are just a few examples that generate an image you can save and glance over after the `cloc` stuff.

0.0.1.1: Grep

I use `git grep` on the classes found in the biggest files I found with `cloc`. I can see how they "disseminate" through the project and how they get around and are used

0.0.1.2: Tests

I look at unit tests (if any) to get a sense on what the different parts do and how they're used. You learn a lot about "intent" from the tests if you're lucky to have them. I add tests as I get acquainted with the project.

If there's a CI config file, I'll check it out and it tells me how to deploy the project. It's often more accurate than the readme or else the builds would fail.

0.0.2: Musing

I maintain a separate "musing" file, sometimes called "refactoring" where I'll put a comment with the path to a file and the part it's about (say a function, or a class), and rewrite it. It is separate in the beginning as I don't know if the refactoring is relevant or if there's any Chesterton's Fence and I don't want to pollute the repo. It is my way of grappling with the code. Several rewrites. Often when I'm in a quiet place and my juices are flowing.

0.1. Taking notes for project:

One of my habits from the beginning was taking notes. I can now pull my notebooks at my current job and see the chronology (dated by month) and ordered. I can walk through the different difficulties, conceptualizations, drawings and schematics, sequence diagrams, re-architectures, refactorings, etc.

As you embark on your journey in a project, your fresh eyes are valuable. You're seeing a lot of what has become "normal" for other developers. Note everything. The idiosyncratic build or deployment. Out of date documentation. Everything.

You can create well written issues that follow a template with expected and actual behaviors, screenshots, logs, stack traces, possible fixes, likely culprits, etc.. If your repo does not have a template for issue, propose one.

Write issues in a way to make them easier to fix for everyone. Your group can use your notes to rework an API or the user experience. You're also working to streamline future contributions for newcomers.

0.2. Knowledge Base

As your understanding of the project increases and you touch more and more parts, you can maintain a sort of knowledge base. It is highly likely that this knowledge base will serve as the project documentation if it has none.

1. Attention

1.1 Taking meeting notes:

Many meetings. Few actions. Everybody ends up talking about the same things and issues drag on forever. You can take notes and review them later. Write them up and send them to everyone. Check out minutes of meetings.

You can write the gist of what's said, and the action that must be taken, by whom, and when.

Taking these notes will help mitigate your distraction during the meeting as you can review them at your rythm.

# Minutes of Meeting
--------------------

## Date: 2019-03-25
## Place: BIGCorp HQ. City, State.

## Participants:

### BIGCorp:

- John Doe (jd)
- MeMyself I (mmi)

### OtherCorp:
- Dilbert (db@othercorp.com)
- Dogbert (dg@othercorp.com)

## Topics:

- Scheduled information sending
- Information flow
- Architecture for Project X

## Details:

OtherCorp has raised some issues for the timeline of Project X...
Blah blah blah.

## Actions:

### BIGCorp:

- [ ] @bc: Send project X estimates by 2019-03-28
- [x] @bc: Send invoice and cheque for offices remodeling
- [ ] @mmi: Add different schemes for user authentication
- [ ] @mmi: Finalize migrations so we take into account user's timezone

### OtherCorp:

- [ ] @oc: Expose API end points for user's identity verification
- [ ] @oc: Cache the results of the most common queries

2. Skills

Understand the business value for the customer (what value is your code bringing to the customer, what are they trying to achieve).

Daily improvements. Reading good books and implementing what they contain. Writing the best code you can write. Reading the best code you can find. Consistent, continuous, relentless, improvement.

If you can be better than you were when the day started, and do that daily, good things may happen.

Constantly transfer the quality gains to the projects you're involved in (better documentation techniques, better patterns, less complexity, etc.)

Help others write better code by setting the example. Mentor newcomers to the project. Help write tools for everyone to use.