The process described below attempts to optimize reading quality books and enjoying the reading experience. As such, it promotes book exploration (discovery of new books) and reading books which have a high rating according to your own taste. Books which receive lower ratings (compared to other books) are moved down the reading priority list and will not be read until books that have higher priority (i.e., rating) either are finished reading or their rating decreases such that other books are now high priority.
- Pick highly read books (use a site like goodreads to identify those books).
- When reading a book, record the page you start and stop reading on, the time you start and stop reading and emit a rating for what you've read.
- You can decide to optimize whether you want to optimize per page rating or per duration rating, that is, get the most value per page or by time spent reading.
- Add new books to your reading list regularly. Those books are considered as having the highest priority and are then added to the prioritized list of books according to its rating.
- When not reading a new book, read the books in order of priority and by interest at the time of reading.
- From time to time you may look at your list of prioritized books and decide whether the books with the lowest priority should ever be finished. In some cases it is reasonable to decide that certain books will never be read completely.
- As an alternative approach, one can use multi-armed bandits algorithms to decide which book to read next. Given that we can convert multi-armed bandits problem into the problem of selecting which book to read next given a sequence of readings and associated rating ("rewards"), the various algorithms (such as Epsilon-greedy or UCB1) will provide us with the next book we should read.
- Interestingly enough, an algorithm like UCB1 will promote reading books we've never read first over reading books we've already started reading.
- Read partially any book for which you haven't given any rating
- Rate what you have read on a 1 to 5 scale, 1 being very bad and 5 being very good (see book rating)
- Compute the weighted rating of the book (the sum of rating times # of page associated to the reading divided by the total # of pages read so far for the book)
- Sort books by weighted rating (descending), then average estimated amount of time left to complete (ascending)
- If you have books that you haven't read yet, go back to the first step. If not, then pick the book at the top of the list computed in the previous step, then continue from step 2
- It's better to read a good book than to finish a bad book
The onboarding process described here is specific to a software engineer joining a tech company. While some/most of the items may still apply to any job where you mainly work from a computer, the assumption will be that you develop software as an individual contributor.
- Setup laptop
- Access to slack
- Access to zoom
- Setup calendar reminders
- Initial meeting with buddy
- Access to git central repository
- Installation of development tools/languages
- Request software licenses
- Access to CI/CD
- Find where task management is done
- Find the documentation to build projects
- Connect 1 on 1 with each member of the team
- Meet with manager 1 on 1
- Define a 30-60-90 days plan with manager
- Verify access to various systems (SSO, code repository, insurance company, payroll company, etc.)
- End of week meeting with buddy
- Setup and run the one step build process
- Determine how are features/tasks prioritized, who prioritizes features/tasks
- Review the team documentation
- Review team practices/processes documentation (code style, code review, standups, planning, retrospective, demos)
- Review common vocabulary, terminology, glossary documents
- First PR + code review
- Review the career ladder of the position
- Review user definition, use cases, requirements
- Read prior team meetings notes
- Identify how deployments are done
- Review the team roadmap
- Determine where I can have the biggest impact
- Determine a timeline where I'll have reached my 80/20 at the company
- Determine the maturity of existing projects
- Determine how fast can we iterate on certain aspects given the team/company composition
- Identify the core/principal/staff contributors and their contributions
- Review the architecture of the system
- Review the database architecture
- Learn about "how we got to this point"
- Determine whether the product is a monolith or micro-services
- Identify which (3rd party) tools are used by the team/company
- Determine the portfolio of STARS situations of the team/company
- Determine a rough estimate of the number of people in the different organizations
- Connect 1 on 1 with important collaborator in other teams
- End of first month meeting with buddy
- First month performance review with manager
- Informal 360-degree review with manager and peers on adaptation
- Month 1 job satisfaction review
- Team interaction diagram
- Month 2 job satisfaction review
- Month 3 job satisfaction review
- Decide what habit you want to have and record why you want this habit
- Start with the smallest amount of effort possible
- Increase the amount of effort regularly until you reach the desired amount of regular effort
- Track your habit in a habit recording system such as Loop Habit Tracker
- Review on a regular basis (monthly) whether you want to keep this habit or not
- If you decide not to keep the habit, record why you decided to drop the habit such that if you decide to pick it up again, you can determine whether you might end up dropping it again.
- It's not a problem if you miss doing your habit, just make sure to do it when you're supposed to
- Daily planning
- Daily review
- Eat/Drink
- Shower
- Wash dishes
- Cook
- Exercise
- Read
- Watch TV shows
- Floss
- Brush teeth
- Weekly planning
- Weekly review
- Wash clothes
- Clean apartment
- Buy groceries
- Monthly planning
- Monthly review
- Pay bills
- Yearly planning
- Yearly review
- Daily planning at 10 am
- Weekly planning on Mondays
- Monthly planning on the first of the month
- Pay credit card on the first of the month
- Google Keep
- Google Calendar
- Google Mail
- Slack
- Daylio
- Notion
Recognizing processes to follow
History / Edit / PDF / EPUB / BIB / 2 min read (~251 words)Given a library of processes, how can you determine which process you should be following?
Make a list of all the processes you have. Link to all the procedures to follow in each case. Some processes you will use so frequently that you will learn them.
Processes have starting points, that is, a trigger that initiates them. For example, if you have a process for code reviews, the starting point is the creation of a pull request by someone else. Another trigger might be the beginning of a new project. You should look for and recognize those triggers. If possible, when you document your processes, indicate what will trigger the instantiation of one of these projects.
Try to frequently look at the list of triggers and think about what you are working on or will be working on. This will allow you to catch processes that should have been started and followed, as well as let you prepare for processes that are about to start.
As you accumulate more and more processes, you will observe that there is a hierarchical organization to them. As one process starts, you can already prepare a list of processes you may have to follow soon.
You will also observe that the completion of a process often will lead to the start of another one. Once you've established enough chains (sequences of processes), it will be easier to identify and do the processes.
Systematically apply processes
History / Edit / PDF / EPUB / BIB / 2 min read (~372 words)How can I be systematic in applying processes?
The first step is to always make your processes explicit. Write the various steps you go through while doing something. First, simply write down those steps as you do them. Then indicate the dependencies between the steps. You may notice that some steps can be done earlier in the process if all their dependencies are already completed.
As you write down more and more of your processes, make sure that you can easily refer to them. If possible, keep them in a centralized location where it is easy for you to edit them. In my case, I write my processes in this blog.
When you begin doing something which you've never done before, create yourself a document and write down the steps you are doing as you do them. Once you are done with the task, save your document.
When you begin doing something for which you already have a process in place, open up your process document and quickly glance at it. Start going through the process without using the document and jot down what you do. After you are done, look at what you did and compare it against the existing process. Is it the same or has something changed? Did you forget to do something? Did you do something new? Did you change the order of some of the steps? Apply the changes you think are useful to your process and repeat this discovery phase a few times.
After you've established a process, you can simply open the process document and follow it. If you notice that some steps are still missing, do add them to the document. If you version control your processes, you will be able to observe how it evolves over time.
One benefit of making your processes explicit is that it allows you to stop doing them for an extended period of time. When you need to do them again, you can simply look at them again and know what you need to do. It is also beneficial if you work in a team where you could delegate some of those processes to other people.