What are the typical responsibilities of a Java developer? After all, you need to understand what you are going for and what, in the end, you will do, right? Today I would like to talk about the ten main tasks that a Java developer performs. But first, let's get acquainted with a tool like Jira. Or let’s refresh our memory if it’s already familiar to you. Jira is a user interaction tool, although in some cases it is also used for project management. In other words, project development is broken down into small tasks that are described in this tool. These tasks are assigned (assigned) to developers, who will be responsible for their implementation. By tasks we mean, for example, adding some functionality. As progress progresses, developers and other specialists add comments about who did what and how much time they spent—they track time. This is done in order to track the time spent: how much was spent and on what. Ideally, this is done once a day: in the evening before leaving, you track your 8 hours to the tasks on which you spent them. The functionality of Jira is much broader than described above, but this will be enough for an initial understanding. So, what are the responsibilities of a Java developer?
1. Development of new solutions
Before you create and implement something, you need to come up with it, right? Like I said, it could just be a Jira task that will be assigned to you, and you will work to develop a new solution, noting in Jira how much time you spent and on what. This could also be a discussion on a group team call: everyone will be able to express their opinion and propose the approach that they consider best. And here I would like to note a few points. Firstly, the developer profession is a very creative field, since you need to come up with unique ways to solve problems using standard tools. Often, one problem can have many different solutions: accordingly, everything depends on the “creative spirit” of the developer, the accumulated knowledge base and experience. Here you can show all your creativity and genius, but the main thing is not to overdo it: in this case, the code will become too complex and unreadable and as a result, after you leave, no one will fully understand what it is and how it works. And you will need to rewrite everything from scratch. And they may remember you. And more than once. And these are unlikely to be warm, kind words. Do you need it? Secondly, the developer must be flexible in the sense that you should not get stuck in one solution and become closed to others. Like, you need to do only this way and nothing else. This can happen for various reasons: for example, you want to prove your point of view, or you have already developed and implemented your solution, which you are pretty attached to and, of course, do not want to admit that it is not the best. This can pretty much blind you. In fact, you need to be able to admit your mistakes and always be open to new things (“open-minded”), even if you have to remove functionality that you have been writing for many weeks and of which you are very proud. I remember how once the mood of the whole day was made by someone’s time track in Jira with the comment: “I deleted my stillborn functionality. I cried”
2. Writing new functionality
This is a logical step following the previous one - the implementation of new functionality. All work on the project is divided into tasks in a jira, which the developers receive as they work. There are different approaches to this issue - “methodologies”, more about which you can read in this article on JavaRush . As a rule, tasks have an “Estimation” - the predicted time spent on completion. It is set either by you yourself when you take on the task, or by the team lead, or during planning the developers together estimate it. This time is very rarely guessed accurately, since many different factors influence development. For example, is the programmer familiar or unfamiliar with this technology, what is his general experience, various pitfalls that may become visible already during development, etc. Therefore, if you don’t meet this deadline when developing functionality, nothing bad will happen. These are just general estimates. But again, not all projects have task estimates and, as for me, it’s much easier to live without it, especially when the PM doesn’t poke you in the side a couple of times a day with the question “Where are the estimates?” Accordingly, you take a task, develop the necessary functionality, upload it to a common branch in GIT , and in the jira change the status of the task to “Ready for review” , that is, ready for viewing (checking) and pray that it is not returned to you with comments on revision.
3. Writing tests for functionality
The person checking your code - the reviewer - liked the functionality you developed, but he has a question: where are the tests for it? And he returns the task to you for revision. Tests are an important part of any Java application. By running them, you can immediately catch where the application is working incorrectly. For example, a developer made some changes in one part of the system, which led to changes in behavior in another, and did not notice this during development. By running the tests, he will be able to see the failed (those that did not work correctly) tests. This will tell him that something is broken in another part of the system. Therefore, he will not upload breaking changes to the server, but will continue to refine his solution. Yes, of course, few developers love tests, but there is no denying the benefits they bring to the application. Often clients themselves specify what level of test coverage should be adhered to (for example, 80%). Therefore, you need to know different types of tests and be able to write them. Java developers mainly write unit tests and integration tests, while AQA (automation testers) deal with more extensive (end-to-end) tests. You can read more about them and other representatives of IT professions in my review .
4. Finding and fixing the bug
This is also a very common and frequent task for a Java developer. The main task of QA and AQA is to catch bugs. That is, they look for places where the program behaves incorrectly, create issues in Jira and blame it on someone. For example, a team lead, who in turn decides which developer to assign this to, depending on their load and familiarity with this part of the system. After this, the developer searches for the bug, spending hours in the debugger , using the description of the problem by QA specialists to repeat the situation in which the bug occurred. Next, the developer finds a bug, fixes it, and sends it for review. Well, it is possible that the developer could not reproduce the bug, and he returns the task to the QA specialist back with a comment about it. It seems like it won’t take that long to find and fix the bug, but there are some nuances. Everything depends primarily on the developer’s familiarity with this section of code, experience and knowledge of theoretical issues. Sometimes a bug can be found and fixed in 20 minutes, and sometimes it can take three days. Accordingly, this type of task is especially difficult to evaluate in advance, unless the developer, after reading the description, immediately understands what, where and with what went wrong. In this case, he will be able to guess the time more or less accurately.
5. Code review
As mentioned above, as soon as you complete a task, it needs to be sent for review, and if it passes it, it goes into the general thread, if not, it will be returned to the developer with comments on what needs to be corrected. It is clear that all this is checked not by some higher powers, but by other developers. But not all developers are allowed to become reviewers, but only the most experienced ones, who have practice behind them and can distinguish bad code from good. Code review is usually done using an auxiliary tool, for example, Crucible . Reviewers review the code and, if necessary, leave comments under some lines. Comments can also be of various types. For example, critical ones, without correction of which the reviewer will not pass the code, and others are more likely just comments about the chosen approach, which the developer can listen to, take note of, or ignore. The team can create its own procedure and rules for conducting reviews, agree on what is worth paying attention to and what not, within what time frame the code review should be carried out, etc. To conduct a review, experience alone is not enough: you still need to develop a lot in a technical direction, read various books (for example, “Clean Code” ). If you are interested in the nuances of conducting a code review according to Google, I advise you to read this article .
6. Code analysis
Since the project is written simultaneously by several people who think differently, their code and approaches will differ. And over time, everything will gradually turn into mush. To improve code, sometimes you create tasks to analyze, perhaps a particular module or the entire application, to find flaws and flag them, and later create a refactoring task based on these comments. The analysis also helps in situations where some simpler, shortcuts were not visible from the beginning of development, but they can be seen now. For example, the same logic is often repeated in some methods and, accordingly, it can be moved into a separate method and reused many times. Well, either some class has become painfully bloated, or some code has become difficult to maintain or outdated, or... Analysis tasks help improve the quality of the code and application. Although, in my opinion, analyzing a large amount of code can be a boring task.
7. Code refactoring
The next part of the analysis is code refactoring. It may be outdated, no longer needed, poorly written, difficult to read, and so on. You should always strive for perfection (although it does not exist) and for up-to-date code, removing everything unnecessary, because this only confuses and prevents you from seeing the essence of the functionality. It goes without saying that you are unlikely to see these tasks at the beginning of the project: they occur only at later stages of development, when the application is polished and brought to perfection. Here, it may be appropriate to consult with colleagues about how they would do it and what pitfalls they see. The essence of such tasks is similar to the development of new functionality. For example, you receive a task to edit some functionality without changing its behavior. To do this, you delete the old one, write your own and check the tests. If you did everything correctly, without making changes to the tests they should work as before. After everything is settled in the code, we send it to review and go have coffee))
8. Writing documentation
Imagine that you are a new developer on some project that has been in development for a long time. You need to familiarize yourself with it or perform some specific task, for example, catching a bug. How will you navigate the project? Pull your team members every five minutes? And if they are busy or on the weekend, what then? This is why documentation exists, so that a person unfamiliar with the functionality can go in, find the right page and quickly understand what the part of the application that interests him does. But someone must also fill out the documentation ^^ If the project has documentation that the developers must support, when implementing new functionality they describe it, and with various changes and refactorings they update the documentation. Situations are also possible when a separate specialist, a technical writer, is hired to write, support and control documentation. If such a specialist exists, it makes the lives of ordinary developers a little easier.
9. Participation in various rallies
Developers spend a lot of time on various meetings, negotiations, and planning. The simplest example is “daily meetings” (daily meetings), where you need to tell what you did yesterday and what you are going to do today. In addition, you need to have a one-on-one call, for example, with a QA specialist, so that he can show/explain the nuances of reproducing the bug, or discuss the nuances and requirements with a business analyst, or organizational issues with a PM. Therefore, even though a developer may be an introvert who prefers solitude, he must still be able to find a common language with other people (well, at least a little). The higher a developer's rank, the more time he needs to spend communicating and less time writing code. A developer-team lead can even spend half, or even more, of his working time on conversations and meetings and writing code less often (this can lead to losing a little grip). But if you are also someone who likes to talk, you can easily develop from the position of team lead into the managerial side and completely forget about code, communicating all day long with various teams, customers and other managers.
10. Conducting/passing an interview
If you work for an outsourcing or outstaffing company, you will need to undergo frequent external interviews, when you need to be “sold” to the client (then you can be interviewed by a person from the client’s side), and internal interviews, to increase your rank within the company. I would call this a good factor for development, since due to frequent interviews, your knowledge should always be in shape: you will not get rusty and relax, because if you relax in IT, you can completely fly out of the field. When you become a more experienced developer, you will be able to visit the other side: not passing, but conducting interviews. Believe me, you will be very surprised if you look at it from this perspective, because conducting interviews can be scarier than passing. You need to have your own interview strategy, a list of questions, and have time to ask questions on all the necessary topics in an hour. And after that, you are responsible for feedback, because relying on it, a person may or may not receive such a long-awaited offer or promotion. Well, and vice versa: you can miss a frankly weak candidate for a position for which he does not correspond, and then you may be asked: how did you even miss him with such a level of knowledge? Therefore, when going through an interview, keep in mind that the person opposite you is also having a hard time, and he may also be experiencing stress. Any interview is stressful for both the candidate and the interviewer. Perhaps we'll end here. Thanks to everyone who finished reading: like and learn Java ^^
Secondly, the developer must be flexible in the sense that you should not get stuck in one solution and become closed to others. Like, you need to do only this way and nothing else. This can happen for various reasons: for example, you want to prove your point of view, or you have already developed and implemented your solution, which you are pretty attached to and, of course, do not want to admit that it is not the best. This can pretty much blind you. In fact, you need to be able to admit your mistakes and always be open to new things (“open-minded”), even if you have to remove functionality that you have been writing for many weeks and of which you are very proud. I remember how once the mood of the whole day was made by someone’s time track in Jira with the comment: “I deleted my stillborn functionality. I cried”
Therefore, you need to know different types of tests and be able to write them. Java developers mainly write unit tests and integration tests, while AQA (automation testers) deal with more extensive (end-to-end) tests. You can read more about them and other representatives of IT professions in my review .
Code review is usually done using an auxiliary tool, for example, Crucible . Reviewers review the code and, if necessary, leave comments under some lines. Comments can also be of various types. For example, critical ones, without correction of which the reviewer will not pass the code, and others are more likely just comments about the chosen approach, which the developer can listen to, take note of, or ignore. The team can create its own procedure and rules for conducting reviews, agree on what is worth paying attention to and what not, within what time frame the code review should be carried out, etc. To conduct a review, experience alone is not enough: you still need to develop a lot in a technical direction, read various books (for example, “Clean Code” ). If you are interested in the nuances of conducting a code review according to Google, I advise you to read this article .
Here, it may be appropriate to consult with colleagues about how they would do it and what pitfalls they see. The essence of such tasks is similar to the development of new functionality. For example, you receive a task to edit some functionality without changing its behavior. To do this, you delete the old one, write your own and check the tests. If you did everything correctly, without making changes to the tests they should work as before. After everything is settled in the code, we send it to review and go have coffee))
The higher a developer's rank, the more time he needs to spend communicating and less time writing code. A developer-team lead can even spend half, or even more, of his working time on conversations and meetings and writing code less often (this can lead to losing a little grip). But if you are also someone who likes to talk, you can easily develop from the position of team lead into the managerial side and completely forget about code, communicating all day long with various teams, customers and other managers.
Perhaps we'll end here. Thanks to everyone who finished reading: like and learn Java ^^
GO TO FULL VERSION