How can I effectively and consistently add habits into my life?
I use the Loop Habit Tracker (an android app) to track any new habit I want to have and keep. Its purpose is two-fold: to remind me through notifications that I need to do something and to observe how consistent I am with the habit.
When adding new habits, I've found I was more successful by creating transition habits, that is, start with something that is easily achievable and is similar to the habit I want to have, then slowly transition the habit to be closer and closer to the habit I want to have. An example of this might be that I want to do 20 minutes of jogging daily, but since I've never done jogging consistently in the past, I should start with 1 minute instead of 20 and do it consistently. After a week of consistently jogging 1 minute per day, I can increase the habit to be 2 minutes. Each week that goes by the amount of jogging that is done is increasing while the habit is in its formation phase.
It may take up to 20 weeks to do 20 minutes consistently every day, which is preferable to me to trying to do 20 minutes of jogging right from the start and giving up after a few times because my body is not accustomed to such effort.
This same metaphor can be applied to mental efforts. If you're not used to spending hours of focused effort on a task, trying to do it right away is likely to be very difficult. But if you slowly transition from doing none of it, to doing it a little bit, then more and more, until you reach your target, it will make something that initially appeared impossible manageable.
As you add more and more habits into your life, it may become difficult to keep doing all of them regularly without missing them. That is why an application such as Loop Habit Tracker will help you remember to do the habits you want to have.
Do you need a tech lead in your team?
Let's start with definitions of the tech lead role.
A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.
- Guiding the project technical vision;
- Analyzing risks and cross-functional requirements;
- Coaching less experienced people;
- Bridging communication between stakeholders and the team.
- Lead with company values
- Deliver value to customers
- Keep the dream alive
I am of the opinion that the distribution of responsibility is likely the best way to get resilience in your system. But with it comes the cost of delays before eventual consistency.
Thus I am more likely to adopt a position where having or not a tech lead will depend on the situation of your team.
Do you need to make quick decisions? Either have a tech lead for that or limit the amount of time allocated for a group of individuals to make decisions.
Do you need accountability? Either have a tech lead that is accountable or have important decisions assessed as a group and the results of the decision written with the name of those that participated in that decision.
Do you need to have a technical vision? Either have a tech lead responsible for defining that vision with the team or have the team work as a whole to define this vision.
Tech leads should have a high-level overview of the pieces that need to be built and an idea of how to get there and when. As individuals, this would require coordinating between individuals with different opinions about those topics.
I work in AI, and this problem makes me think of having a single model (tech lead) vs an ensemble model (group of contributors). If your single model generally predicts the same thing your ensemble model would predict, then the single model is more efficient. On the other hand, if there's no single model that can perform as well as the ensemble, then you should go with the ensemble model.
How do you document a process?
A process is composed of a few things: inputs (dependencies), outputs and the steps to transform inputs into outputs.
Generally a new process will be created from a need (an output to be produced). For example, a client will come to you and ask to have software that does Y. Your output in this case as a software company is software that does Y. For the customer, the process they need you to develop is one where X (some unknown set of inputs) will be transformed to produce Y.
As a software developer, your task is two-fold.
First, you must develop a process for yourself to take client requirements (your input X) and convert them into software (your output Y), which means figuring out what needs to be done to go from X to Y (the transformation steps). Examples of those steps are requirements gathering, specification, design, architecture, implementation, testing, debugging, deployment, maintenance.
Second, you must develop a process for your client's requirements, that is, one that converts some input information into their desired ability to produce Y. Examples of steps that would be in this process are uploading document A, B, C, processing the documents to extract specific information, produce report D.
When documenting processes, the steps will themselves become processes, that is, they will have a set of inputs and a set of outputs. A process will generally evolve into a complex graph of inputs, processes and outputs.
Processes are also generally accomplished by someone or something. In process modeling we refer to those as roles. Examples of roles are user, customer support agent, clerk, engineer, analyst, software system.
Here's a very simple template that you can use to define your processes
- Inputs: What do you need for the process to take place?
- Processes: What actions are taken on the inputs to transform them into outputs?
- Outputs: What is produced when the process is completed?
- Roles: What roles are required to accomplish the actions of the process?
- Average duration: How long is a process taking to complete in general?
- Mandatory/Optional: Is this process mandatory or optional in the accomplishment of the higher-level process?
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.
What is the superficial loss rule applied to stocks and how does it impact me?
The superficial loss rule states:
A superficial loss can occur when you dispose of capital property for a loss and both of the following conditions are met:
- You, or a person affiliated with you, buys, or has a right to buy, the same or identical property (called "substituted property") during the period starting 30 calendar days before the sale and ending 30 calendar days after the sale.
- You, or a person affiliated with you, still owns, or has a right to buy, the substituted property 30 calendar days after the sale.
What this effectively does is that it prevents you from selling at a loss and rebuying the same stock within a 30 days period for the purpose of tax harvesting during that year. This however does not prevent you from claiming the loss when you finally sell the stock.
It is not clear to me how this applies when you have different types of accounts. As far as I understand it, you cannot claim losses on a TFSA account, it is tax-free. The tax impact on an RRSP account appears to only be calculated when you withdraw your money from the account so I would expect it to be a very uncommon occurrence. However, it is not clear whether the accounts interact with each other, that is, if I sell some XYZ shares at a loss in my taxed account, then buy some XYZ shares in my TFSA/RRSP account, will the superficial loss rule apply? This would mean that I would only be able to claim the loss when buying and selling the same asset again. Based on this last statement, I would consider that accounts do not interact with each other, meaning that buying a stock you sold in your taxed account in your TFSA/RRSP account would not trigger the superficial loss rule.