Organization of the work of a single programmer
The author of the material, the translation of which we publish today, says that the majority of programmers work in teams. However, at a certain stage of the career, the developer may need to work alone. The main volume of approaches to the organization of work on software products is designed specifically for use in teams. These approaches are expressed in the rules adopted in organizations. Such rules streamline work, help programmers to do their work efficiently and quickly. Something similar would be very useful to those programmers who work on their own.
How to be the one who works alone? What to focus on, trying to build a clear and effective workflow? What principles and rules to follow? We offer to look for answers to these questions together.
Here I, speaking of "lone programmers", mean all those who work in an informal, unstructured environment. This can be either a single programmer or a small group of people who are involved, say, in their free time, with some kind of project. Here are some examples:
All these examples are united by the fact that the work of programmers engaged in something similar is usually not regulated by a certain set of rules, such as usually exist in companies.
The rules, in applying them to the independent work of programmers on certain projects, are important for several reasons. Consider them.
A programmer whose independent work is well organized may well join a certain team. In this case, the chances of him becoming a valuable member of such a team are very high. Namely, we are talking about the following:
As a result, a lone programmer who rationally organizes his work, in any case, is a winner.
Software development is not only the process of writing code. There are many details here that are responsible for turning the idea into a ready-made project, and then keeping it in working condition. The introduction of advanced software development techniques into your personal workflow will help a lone programmer to confidently follow the goal for which the project is being created, and avoid situations where it seems that everything has turned out to be so confusing that it is not clear where to go next.
If you, like me, love programming, you will always be tempted to, starting a new project, immediately, without thinking, rush into the abyss of writing code. But experience tells me that if I have some kind of high-level work plan, then this, without harming the flexibility that individual development differs in, helps to avoid a lot of trouble of a different scale.
Let's talk about advanced software development techniques.
âWorkflowâ is a sequence of steps that need to be taken in the process of transforming an idea into a finished product. Here are a few questions, the answers to which should be given by the rules governing the process of working on a software product:
Why all this to regulate, to drive into some kind of framework, if it may well seem that work on projects will go much faster without some specific workflow? Isn't it easier to imagine the whole âworkflowâ in this form: âjust write the code and send it to the master branchâ? In fact, as the complexity of the project grows, it turns out that the presence of clear rules simplifies the definition of what needs to be done in the work on this project, and, accordingly, without much hesitation allows you to focus on these matters. When working in a team, the workflow becomes a kind of pipeline that improves the efficiency of the work of each team member.
Let's talk now about how to organize the process of working on a software product.
Here you can use the mechanisms of the platforms on which you place the code - GitHub, Gitlab, BitBucket, and others. Tasks help to track error messages, requests to add new features to the product, to organize information about important project changes. It should be noted that when you enter the title and description of the problem, it forces you to clearly formulate thoughts and clearly describe the problem and possible ways to solve it. The idea of ââusing tasks can be developed by implementing a task management tool like Trello or GitHub Projects into your workflow.
Task
Many developers prefer to send changes, using push requests, directly to the main branch of their project, called master. However, the approach to making changes to the project code using pull requests has some important advantages. Firstly, such requests facilitate the analysis of changes concerning the introduction of a certain new possibility into the project or the correction of an error, and how they, after merging with the main code base, will affect it. In addition, if pull requests are related to tasks from the task tracker, using them makes it easier to understand how the project develops, eliminating the need to figure it out while reading the code.
Pull request details
A recommendation regarding the execution of reviews of your own code may sound strange, but despite this, developers should analyze their own code as if someone else had written it. Some programmers are advised to make a pull request, get distracted for a while, and then, before including it in the code, check it. Performing code checks that are performed outside of the usual for a programmer's environment in the form of his IDE, allows you to look at the code with a rather fresh look. This helps to find errors and detect in the code something that under normal conditions can be ignored. Code reviews, moreover, force the developer to ask himself various questions: âWhy was this feature implemented in this way? What can be done wrong here? Is there a better way to solve this problem? â
Try to make commits as if you are working in a team. Namely - avoid too large commits, try to ensure that commit messages clearly and clearly describe their meaning. Just as in the case of code reviews, writing quality commit messages forces the developer to carefully consider their actions, asking themselves questions like the following: âWhat am I trying to achieve with this commit? How am I trying to achieve this? â
There are situations in which you can afford to retreat from the rules. For example, you can decide that, in order not to slow down the work because of trivialities, you can make a push request directly to the master branch without making any extra changes to the code (like typos correction).
Regardless of what rules will underlie your workflow, the most important thing is that everything you do would be done deliberately, and not by coincidence. Successful projects do not arise by themselves: they are created with love and care. Actions performed deliberately imply certain periods of analyzing the situation, analyzing complex cases and thinking about how, for example, with what tools and with which you can cope.
Implement the principles of DRY , SOLID and FIRST . Create programs from small, encapsulated, atomic components suitable for reuse. Keep these components up to date, collect them in collections using appropriate platforms, like Bit . All this will help you improve the speed and quality of work.
Documentation ... For many, this is a sore point. The fact that software projects need documentation, they know very many. Those who write good documentation are already much smaller, and even fewer those who like to do it. After the next fascinating stage of writing code is completed, the need to document it often becomes a task that you just want to forget about. How, in the form of ordinary texts, to express all the intricacies of the program code?
And by the way, here it is appropriate to ask the question of why all this is needed. The fact is that people tend to make mistakes. We can forget about something. We have bad days. Or, working on a project, we can just go to work on something else. Documentation allows you to capture knowledge about the code, which, otherwise, will be tied to a certain person. Documenting the code also helps developers see the code in more general terms than is available when writing it, and more clearly understand the objectives of the projects.
The following ideas will help you write good documentation.
Here, what we call âcommunicationâ applies mainly to situations where a project is developed by a small team or made to order.
Why do you need it? The fact is that transparency of work leads to increased responsibility of its performers. When you know that you have to tell someone (a member of the team or the customerâs representative), it makes you more attentive to what you are doing. That is why many companies practice short meetings where employees report on their work.
In addition, often a certain team member is faced with a problem, difficult for him, which can be easily solved by simply discussing it with a client or with another team member. I had already gone astray, recalling the cases when I really lowered my hands, trying to understand why what I wrote does not work. And the reason for this was that another team member made changes to the project that interfered with the work of my code. In order to understand this, it was enough to bring the problem to public discussion.
Here are some guidelines for communicating with customers and with members of programmer teams.
In general, it should be noted that you should try so that the interaction between all interested parties would be organized conveniently and simply, so that, so to speak, the âfeedback loopâ would work without delays. It helps to organize a healthy and productive work environment.
Monitoring software development is a very important issue. Computers are prone to crashes. Errors occur during the deployment of projects. Oversight of the developers lead to the fact that programs that seem to have passed all possible checks and successfully entered into service, fall with exceptions. That is why the developer and need to take care of the monitoring system programs. This will facilitate the solution of problems that may arise at different stages of the product life cycle. The program monitoring data is one of the parts of the aforementioned âfeedback cycleâ. Monitoring gives the programmer a connection with reality, with the environment in which his programs work.
Here are some guidelines for monitoring program behavior:
Monitoring application activity and tracking their performance indicators can take many forms. In its simplest form, this can be the output of data on the program's work using the console.log () command, saving this information in text files and manual analysis of such files. Monitoring can be a fairly advanced system, which includes specialized tools like Sentry, Bugsnag and Elastic APM. The main thing - to choose what suits you, and consistently use it.
You are watching, but not observing, and this is a big difference.
Arthur Conan Doyle, "The Scandal in Bohemia"
What is discussed in this section can be considered both an independent recommendation and an approach to using the other recommendations given here. The fact is that there is no universal formula for organizing work on a software product. Different people develop programs differently, use different methods of monitoring, document the code differently, and so on. That is why, whatever the rules for working on programs that you have chosen, it is important to always ensure that the project is supervised, that conclusions are drawn from the results of observation, and that in the end all this leads to improvements in programs.
Monitoring a program implies a critical analysis of its behavior, or, say, its performance indicators. Watching the program, you build connections of what you see with what you know about the system, coming to a logical conclusion about what is happening. The one who works alone is usually deprived of the opportunities for analyzing programs that are used in organizations (such as A / B tests or research of the target audience). As a result, he has to collect hints about the life of his program from âinformalâ sources, such as user comments, problem reports in task trackers, and application logs.
After the completion of the next stage of monitoring the program, it is time to draw conclusions and improve it based on these conclusions. Then follows the next stage of observations, followed by the next iteration of the analysis of the collected data and the improvement of the program. But work on the program is more than âobservation - analysis - improvementâ.
Consider a conditional example. Suppose I have a program that displays a list of some objects and the time they were created. True, my program uses UTC-time. As a result, many of its users see time information that seems to them to be wrong.
In order to fix this, I decided to add an explanation to the output timestamp as a UTC string. As a result, for example, what used to look like 5:30 pm will now look like 5:30 pm UTC. This approach worked, it became more convenient for users. But I finally realized that users would still translate this time during their time zone. Why load them with extra work? These reflections led to the fact that I added to the program a function for automatic time conversion. So working with her has become much more convenient.
Later, after talking with users, I realized that the most important thing for them was to understand the age of objects, rather than to know the exact time of their creation. Having made this observation, I updated the program so that it would show the age of the objects, and not the time of their creation. Now the time stamps looked like "5 minutes ago" or "2 hours ago." Although the program did not show the exact information about the time of creating objects, what turned out as a result turned out to be much simpler and more convenient for the users of this program.
The same approach applies to any other software projects. It should be noted that here we are not talking about some rigid and binding rules. Choosing for yourself certain approaches to streamlining the process of working on programs, you yourself evaluate their performance, and then use only those that are suitable for you, in the form that suits you. As you see, here we also see an iterative process, which we have just talked about when applied to program development.
Ideally, if we talk about a structured software development environment, in such an environment we can distinguish several important roles - from the customer of the product to its developer. People (or groups of people) playing these roles interact, which leads to the appearance of the finished product. But, working alone, you combine many similar roles (it is possible that we are talking about all such roles), which gives you the freedom to organize work exactly the way you want it. It is best to use this freedom in order to create a structure that will allow you to work more efficiently. To create such a structure, you may well have to make quite a bit of effort, and I guarantee you that you will like the results of its creation and use.
Dear readers! How do you organize your work in situations where you have to play the role of a "single programmer"?
How to be the one who works alone? What to focus on, trying to build a clear and effective workflow? What principles and rules to follow? We offer to look for answers to these questions together.
About lone programmers
Here I, speaking of "lone programmers", mean all those who work in an informal, unstructured environment. This can be either a single programmer or a small group of people who are involved, say, in their free time, with some kind of project. Here are some examples:
- Development of an open-source project, such as a package or some kind of library.
- Someone's personal project, which can be both commercial and free.
- Freelance.
All these examples are united by the fact that the work of programmers engaged in something similar is usually not regulated by a certain set of rules, such as usually exist in companies.
Why does a lone programmer care about rules?
The rules, in applying them to the independent work of programmers on certain projects, are important for several reasons. Consider them.
âPersonal rules and possible teamwork
A programmer whose independent work is well organized may well join a certain team. In this case, the chances of him becoming a valuable member of such a team are very high. Namely, we are talking about the following:
- If he has joined a team that follows the same rules as he does, then he will not have to waste time trying to gain insight into organizational issues. He, literally from the first day, will be ready for productive work.
- If he became part of the team, the rules adopted in which are different from what he was used to, he would not have much time to learn these new rules. After all, he, who is accustomed to rationally organizing his work, is guided by certain general ideas, which are probably similar to those that underlie the rules of the team. As a result, he will be able to quickly reach a high level of labor productivity.
- If he is in a team where there are no rules at all, then, depending, of course, on the team, he can offer her his own vision of the organization of the work of programmers, which may well improve the work of such a team. If members of a poorly organized team refuse to change something, then this is a reason to think about leaving such a team.
As a result, a lone programmer who rationally organizes his work, in any case, is a winner.
âRules and professional level of programmer
Software development is not only the process of writing code. There are many details here that are responsible for turning the idea into a ready-made project, and then keeping it in working condition. The introduction of advanced software development techniques into your personal workflow will help a lone programmer to confidently follow the goal for which the project is being created, and avoid situations where it seems that everything has turned out to be so confusing that it is not clear where to go next.
If you, like me, love programming, you will always be tempted to, starting a new project, immediately, without thinking, rush into the abyss of writing code. But experience tells me that if I have some kind of high-level work plan, then this, without harming the flexibility that individual development differs in, helps to avoid a lot of trouble of a different scale.
Let's talk about advanced software development techniques.
Adhere to the rules describing the features of the workflow
âWorkflowâ is a sequence of steps that need to be taken in the process of transforming an idea into a finished product. Here are a few questions, the answers to which should be given by the rules governing the process of working on a software product:
- When it is decided to make a change in the product - what is the order of its implementation?
- How is the transfer of new versions of the product to users?
- How are changes made to the product tracked?
- How is the monitoring of error messages and problems encountered by users organized?
- How is the process of planning new product features?
Why all this to regulate, to drive into some kind of framework, if it may well seem that work on projects will go much faster without some specific workflow? Isn't it easier to imagine the whole âworkflowâ in this form: âjust write the code and send it to the master branchâ? In fact, as the complexity of the project grows, it turns out that the presence of clear rules simplifies the definition of what needs to be done in the work on this project, and, accordingly, without much hesitation allows you to focus on these matters. When working in a team, the workflow becomes a kind of pipeline that improves the efficiency of the work of each team member.
Let's talk now about how to organize the process of working on a software product.
â Use task trackers
Here you can use the mechanisms of the platforms on which you place the code - GitHub, Gitlab, BitBucket, and others. Tasks help to track error messages, requests to add new features to the product, to organize information about important project changes. It should be noted that when you enter the title and description of the problem, it forces you to clearly formulate thoughts and clearly describe the problem and possible ways to solve it. The idea of ââusing tasks can be developed by implementing a task management tool like Trello or GitHub Projects into your workflow.
Task
âUse pull requests
Many developers prefer to send changes, using push requests, directly to the main branch of their project, called master. However, the approach to making changes to the project code using pull requests has some important advantages. Firstly, such requests facilitate the analysis of changes concerning the introduction of a certain new possibility into the project or the correction of an error, and how they, after merging with the main code base, will affect it. In addition, if pull requests are related to tasks from the task tracker, using them makes it easier to understand how the project develops, eliminating the need to figure it out while reading the code.
Pull request details
â Perform reviews of your own code
A recommendation regarding the execution of reviews of your own code may sound strange, but despite this, developers should analyze their own code as if someone else had written it. Some programmers are advised to make a pull request, get distracted for a while, and then, before including it in the code, check it. Performing code checks that are performed outside of the usual for a programmer's environment in the form of his IDE, allows you to look at the code with a rather fresh look. This helps to find errors and detect in the code something that under normal conditions can be ignored. Code reviews, moreover, force the developer to ask himself various questions: âWhy was this feature implemented in this way? What can be done wrong here? Is there a better way to solve this problem? â
Maintain a meaningful history of the development of the project in the repository
Try to make commits as if you are working in a team. Namely - avoid too large commits, try to ensure that commit messages clearly and clearly describe their meaning. Just as in the case of code reviews, writing quality commit messages forces the developer to carefully consider their actions, asking themselves questions like the following: âWhat am I trying to achieve with this commit? How am I trying to achieve this? â
There are situations in which you can afford to retreat from the rules. For example, you can decide that, in order not to slow down the work because of trivialities, you can make a push request directly to the master branch without making any extra changes to the code (like typos correction).
Regardless of what rules will underlie your workflow, the most important thing is that everything you do would be done deliberately, and not by coincidence. Successful projects do not arise by themselves: they are created with love and care. Actions performed deliberately imply certain periods of analyzing the situation, analyzing complex cases and thinking about how, for example, with what tools and with which you can cope.
Create components and modules suitable for reuse.
Implement the principles of DRY , SOLID and FIRST . Create programs from small, encapsulated, atomic components suitable for reuse. Keep these components up to date, collect them in collections using appropriate platforms, like Bit . All this will help you improve the speed and quality of work.
Write documentation
Documentation ... For many, this is a sore point. The fact that software projects need documentation, they know very many. Those who write good documentation are already much smaller, and even fewer those who like to do it. After the next fascinating stage of writing code is completed, the need to document it often becomes a task that you just want to forget about. How, in the form of ordinary texts, to express all the intricacies of the program code?
And by the way, here it is appropriate to ask the question of why all this is needed. The fact is that people tend to make mistakes. We can forget about something. We have bad days. Or, working on a project, we can just go to work on something else. Documentation allows you to capture knowledge about the code, which, otherwise, will be tied to a certain person. Documenting the code also helps developers see the code in more general terms than is available when writing it, and more clearly understand the objectives of the projects.
The following ideas will help you write good documentation.
- Understand that your documentation is not something like a book. Documentation should not be a model of high literary art. No one will evaluate it in terms of its artistic merit. Do not try to explain everything in it. Strive to make it clear and understandable. Sometimes literally a couple of sentences are enough to describe something.
- Writing documentation before writing code. Document the interfaces of your modules, describe how they work in terms of an external observer. Such documentation will play the role of technical requirements for the product and will assist you in the development process.
- Writing documentation after writing code. Here, again, it is worth adhering to the position of the âbystanderâ. What is important in the described code snippet? What you need to know about how to use it (or to contribute to its development?). The specifications specified by the documentation created prior to writing code may change during the development process. Therefore, it is important to check such documentation for compliance with the real situation after the work is completed.
- Writing documentation in the process of writing code. This documenting approach basically applies to something like comments being added to the code during the development process. There is a lot of material on this topic, so here I will not go into details.
- Documentation and "modules". All the above principles apply to modules. Here the term âmoduleâ is used in a rather broad sense. This may be a function, a class, a new feature, a change in the behavior of the program, in fact, a certain program module, or the entire project. If documenting such âmodulesâ seems too difficult for you, try breaking them up into smaller pieces. Or, if you find it easier to think in more general categories, consider writing documentation for larger blocks of the project.
Communicate with customers and those involved in product development
Here, what we call âcommunicationâ applies mainly to situations where a project is developed by a small team or made to order.
Why do you need it? The fact is that transparency of work leads to increased responsibility of its performers. When you know that you have to tell someone (a member of the team or the customerâs representative), it makes you more attentive to what you are doing. That is why many companies practice short meetings where employees report on their work.
In addition, often a certain team member is faced with a problem, difficult for him, which can be easily solved by simply discussing it with a client or with another team member. I had already gone astray, recalling the cases when I really lowered my hands, trying to understand why what I wrote does not work. And the reason for this was that another team member made changes to the project that interfered with the work of my code. In order to understand this, it was enough to bring the problem to public discussion.
Here are some guidelines for communicating with customers and with members of programmer teams.
- If you encounter an unexpected problem - let the team members or the client representative know about it.
- Regularly inform the client about the progress of the project. In this case, try to ensure that this information would not be tied solely on technical issues.
- Tell your team about changes to plans.
- Try to create a comfortable environment for communication, which, for example, allows any member of the team to quickly learn about what someone else is doing. You can do this by using a variety of tools, say - it could be WhatsApp, email, Slack, or anything else that suits your situation.
In general, it should be noted that you should try so that the interaction between all interested parties would be organized conveniently and simply, so that, so to speak, the âfeedback loopâ would work without delays. It helps to organize a healthy and productive work environment.
Organize a monitoring system
Monitoring software development is a very important issue. Computers are prone to crashes. Errors occur during the deployment of projects. Oversight of the developers lead to the fact that programs that seem to have passed all possible checks and successfully entered into service, fall with exceptions. That is why the developer and need to take care of the monitoring system programs. This will facilitate the solution of problems that may arise at different stages of the product life cycle. The program monitoring data is one of the parts of the aforementioned âfeedback cycleâ. Monitoring gives the programmer a connection with reality, with the environment in which his programs work.
Here are some guidelines for monitoring program behavior:
- Save logs and results of automatic code analysis. Feel free to use console.log () where you need it. Better to log in too much information than too little. However, try to find a "middle ground" so that the logs of your programs would not contain unnecessary details about their work. This will make it easier to search important information in the logs.
- Find out where your application logs go, and set up mechanisms that allow you to conveniently work with them. In the role of the above-mentioned "mechanisms" can be anything, from logging in to the server using SSH and viewing fresh events recorded in the log, to something like using the ELK stack. The most important thing is to know about where the application logs are, generated by the console.log () commands or by any other means.
- Do not ignore exceptions. Although any developer should strive to ensure that his application would be stable, that is, he could recover from an error, âget ridâ of unexpected exceptions, simply âlockingâ them in some kind of catch block would be wrong. It is much better to log information about unexpected exceptions. For example, if you are accessing some kind of API to load certain data created by a user (say, tweets), you should be ready to handle error 404. But you should log those errors that you do not process. I have been in a situation where, without logging information about unexpected errors, I simply did not know that I had exhausted the limit of calls to one system. This led to the fact that access to the appropriate API of my program was closed.
- Check the logs. Checking the logs generated by the results of the applications can be organized either manually or using some means for their automatic analysis. One day, without worrying about controlling the logs, I fixed a small problem in the program and continued to calmly go about my business. As it turned out later, my correction was inoperative. Since then, I have been attentive to checking application logs after their deployment, which allows me to verify the correctness of their work.
Monitoring application activity and tracking their performance indicators can take many forms. In its simplest form, this can be the output of data on the program's work using the console.log () command, saving this information in text files and manual analysis of such files. Monitoring can be a fairly advanced system, which includes specialized tools like Sentry, Bugsnag and Elastic APM. The main thing - to choose what suits you, and consistently use it.
Watch the project, draw conclusions from the results of observations, and improve it
You are watching, but not observing, and this is a big difference.
Arthur Conan Doyle, "The Scandal in Bohemia"
What is discussed in this section can be considered both an independent recommendation and an approach to using the other recommendations given here. The fact is that there is no universal formula for organizing work on a software product. Different people develop programs differently, use different methods of monitoring, document the code differently, and so on. That is why, whatever the rules for working on programs that you have chosen, it is important to always ensure that the project is supervised, that conclusions are drawn from the results of observation, and that in the end all this leads to improvements in programs.
Monitoring a program implies a critical analysis of its behavior, or, say, its performance indicators. Watching the program, you build connections of what you see with what you know about the system, coming to a logical conclusion about what is happening. The one who works alone is usually deprived of the opportunities for analyzing programs that are used in organizations (such as A / B tests or research of the target audience). As a result, he has to collect hints about the life of his program from âinformalâ sources, such as user comments, problem reports in task trackers, and application logs.
After the completion of the next stage of monitoring the program, it is time to draw conclusions and improve it based on these conclusions. Then follows the next stage of observations, followed by the next iteration of the analysis of the collected data and the improvement of the program. But work on the program is more than âobservation - analysis - improvementâ.
Consider a conditional example. Suppose I have a program that displays a list of some objects and the time they were created. True, my program uses UTC-time. As a result, many of its users see time information that seems to them to be wrong.
In order to fix this, I decided to add an explanation to the output timestamp as a UTC string. As a result, for example, what used to look like 5:30 pm will now look like 5:30 pm UTC. This approach worked, it became more convenient for users. But I finally realized that users would still translate this time during their time zone. Why load them with extra work? These reflections led to the fact that I added to the program a function for automatic time conversion. So working with her has become much more convenient.
Later, after talking with users, I realized that the most important thing for them was to understand the age of objects, rather than to know the exact time of their creation. Having made this observation, I updated the program so that it would show the age of the objects, and not the time of their creation. Now the time stamps looked like "5 minutes ago" or "2 hours ago." Although the program did not show the exact information about the time of creating objects, what turned out as a result turned out to be much simpler and more convenient for the users of this program.
The same approach applies to any other software projects. It should be noted that here we are not talking about some rigid and binding rules. Choosing for yourself certain approaches to streamlining the process of working on programs, you yourself evaluate their performance, and then use only those that are suitable for you, in the form that suits you. As you see, here we also see an iterative process, which we have just talked about when applied to program development.
Results
Ideally, if we talk about a structured software development environment, in such an environment we can distinguish several important roles - from the customer of the product to its developer. People (or groups of people) playing these roles interact, which leads to the appearance of the finished product. But, working alone, you combine many similar roles (it is possible that we are talking about all such roles), which gives you the freedom to organize work exactly the way you want it. It is best to use this freedom in order to create a structure that will allow you to work more efficiently. To create such a structure, you may well have to make quite a bit of effort, and I guarantee you that you will like the results of its creation and use.
Dear readers! How do you organize your work in situations where you have to play the role of a "single programmer"?
Source: https://habr.com/ru/post/436008/