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 (before or after the transaction) 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's important to note that there is interactions between non-registered and registered accounts. Buying the stocks in one account and selling in another account will still be considered as if they were under the same account. The most important thing to understand is that if you have stocks in your registered accounts (TFSA/RRSP), that you buy/sell in these accounts within the 30 days window in a non-registered account, you will not be able to claim your adjusted cost base. This will result in a permanent loss of this taxable loss. As a simple advice, in other words, do not trade the stocks you have in your TFSA/RRSP in your non-registered accounts. It will simplify your life.
Why do I avoid reading books sometimes?
The most common reason for me to avoid reading a book is that I see reading as an investment. I can't spend only 5 minutes reading a book there and there. I need to focus on reading for at least 15 minutes, otherwise I cannot enjoy the story or understand the technical book I'm reading.
This creates a problem. For me to read, I need to have enough time to read for at least 15 minutes. 15 minutes is a considerable amount of time to allocate vs no time allocation to simply browse content online. Thus a barrier is created, making it harder to read books.
Similarly, there are times where I don't want to read a book because I want to process a unit of the story or a chapter of the book in one reading. It is similar to not wanting to start a tv show episode knowing that you might stop watching it in the middle. I don't like that.
Reading technical books is mentally draining. Sometimes I'm simply brain dead and reading books is simply not possible.