How is being a R&D developer different than being a developer?
R&D developers are not focused on shipping. While most developers will work as hard as possible to ship whatever they are building to their customers so that they can get paid, R&D developers focus on delivering answers to questions asked by their clients. This focus on intangible deliverables will frustrate many developers.
Because R&D developers focus on answering questions and not building products, it is very common that code written will not make it in production. If it does, then it will generally be a catastrophe.
Code quality and maintenance are not considered a priority because code is expected to be abandoned once the questions have been answered and the solution has been proven useful.
R&D as it implies, is about finding solutions quickly to problems (research), building a solution (development) and demonstrating the value of the solution. This process is a lot more iterative than building software with (somewhat) clear requirements from the start. Given the novelty of what gets built, it is critical to get feedback early and to act on this feedback. This means that the development horizon (how far ahead things are planned) is very short. As such, you are unlikely to be able to say on what you will be working next month.
Regular development is about applying existing solutions to clients problems. R&D is about finding those solutions and turning them into mainstream solutions.
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.
Source: https://www.thekua.com/atwork/2014/11/the-definition-of-a-tech-lead/
- Guiding the project technical vision;
- Analyzing risks and cross-functional requirements;
- Coaching less experienced people;
- Bridging communication between stakeholders and the team.
Source: http://vvgomes.com/we-dont-need-tech-leads/
- Lead with company values
- Deliver value to customers
- Keep the dream alive
Source: https://hackernoon.com/whats-the-role-of-a-tech-lead-7725b47104b7
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.
- https://www.thekua.com/atwork/2014/11/the-definition-of-a-tech-lead/
- https://www.thekua.com/atwork/2015/06/tech-lead-circles-of-responsibility/
- https://www.thekua.com/atwork/2014/10/do-we-need-a-tech-lead/
- https://hackernoon.com/whats-the-role-of-a-tech-lead-7725b47104b7
- http://vvgomes.com/we-dont-need-tech-leads/
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?
Recognizing processes to follow
History / Edit / PDF / EPUB / BIB / 2 min read (~329 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.