What are the typical responsibilities of a Java developer? After all, you need to understand what you are getting yourself into and what you will end up doing, right? Today I would like to talk about ten vital tasks that a Java developer performs.
But first, let's get acquainted with a tool called Jira. Or refresh your memory of it, if you are already familiar with it.
is a tool for organizing human interactions, although in some cases it is also used for project management.
In other words, a project is broken down into small tasks that are described in this tool. These tasks are assigned to the developers, who are responsible for their implementation. A task could be, for example, adding some functionality.
As a task is performed, developers and other specialists add comments about who did what and how much time they spent. This is done for time-tracking purposes — to know how much time was spent on what tasks.
Ideally, this is done once a day: Before you leave your desk in the evening, you indicate how much of your 8 work hours you spent on various tasks. There is much more to Jira's functionality than what is described above, but this will be enough for an initial understanding.
So what are the responsibilities of a Java developer?
1. Designing new solutions
Before you create and implement something, you need to conceptualize it, right?
As I said before, this could simply be a task in Jira that gets assigned to you, so you work to design a new solution, recording in Jira how much time you spent and on what.
This work could also happen during a discussion on a team conference call: everyone can express their opinion and propose the approach that they consider best. And here I would like to note a few points.
First, software development is a very creative profession, since you need to use standard tools to come up with novel ways of solving problems.
One task can often have many different solutions. Accordingly, everything depends on the developer's creativity, which is heavily influenced by their accumulated knowledge and experience.
You can show off all your creativity and genius here, but the important thing is not to overdo it. If you do, the code will become too complex and unreadable. As a result, after you leave, no one will fully understand what you coded and how it works.
And they will have to rewrite everything from scratch.
And they may reminisce about you.
More than once.
And it is unlikely that there will be warm, kind words spoken.
Do you need that?
Second, a developer must retain psychological flexibility in the sense that you should not cling to a single solution and become closedminded to others. As if you have to do something in only one way and there are no other options.
You might fall into this trap for various reasons. For example, suppose you want to prove that your point of view is correct. Or perhaps you've already designed and implemented your own familiar solution — of course, you wouldn't want to admit that it is not the best. These situations can make you fairly blind.
In fact, you need to be able to admit your mistakes and be always open-minded, even if you have to remove functionality that you are proud of and have been coding for more than a week.
I remember how a coworker brightened everyone's day once by leaving this time-tracking comment in Jira:
"I removed my stillborn feature.
2. Writing new functionality
This step — implementing new functionality — follows logically after the previous one.
All work involved in a project is divided into tasks in Jira, which are then dished out to developers based on their workload. There are different approaches to this process, known as "methodologies," which you can read about in more detail in this article on CodeGym
As a rule, tasks have an estimate
, which is the predicted time required to complete them. It is set either by you, the developer when you receive the task, or by the team lead, or during planning, collectively by the development team.
This time guess is very rarely accurate, since so many different factors affect software development. For example, whether a programmer is familiar or unfamiliar with the relevant technology, his or her overall experience, various unforeseeable pitfalls, etc. So, if you don't hit all your time estimates when coding, it's not the end of the world.
These are just general estimates.
That said, no all projects require time estimation. Personally, I find it much easier to live without it, especially when the PM isn't pestering me a couple of times a day with the question "where are your time estimates?"
So, you get a task, write the necessary functionality, push it into the main branch in GIT, and then set the task status to "Ready for review
" in Jira and pray that your code changes don't get returned for revision along with comments.
3. Writing tests
The reviewer, i.e. the person who checks your code, likes the functionality you implemented, but she has a question for you: where are associated tests? So she sends the task back to you for revision.
Tests are an essential part of any Java application. By running tests, you can immediately identify places where the application doesn't work correctly.
For example, a developer makes some changes in one part of the system, which results in changes in behavior in another part, but he didn't notice this while coding. By running the tests, he will be able to see that certain tests failed, meaning they didn't produce the expected results. This tells him that something is broken somewhere else in the system. Knowing this, he won't commit the breaking changes to the server, and will instead continue working on debugging his code.
Yes, rather few developers love writing tests, but there is no denying the benefits they bring to software development. Clients themselves often indicate the level of test coverage they want to maintain (for example, 80%).
That means that you need to know the various types of tests
and be able to write them.
Java developers mainly write unit tests and integration tests, while the more extensive (end-to-end) tests are handled by QA and test automation experts.
4. Finding and fixing bugs
This is also a very common, frequent task for Java developers. The main job of QA and test automation experts is to catch bugs. In other words, they look for places where the program behaves incorrectly, then they create tasks in Jira and assign them to someone. For example, to a team lead, who, in turn, decides which developers to assign them to, depending on their workload and familiarity with the relevant parts of the system.
After that, the assigned developer hunts down the root cause of the bug, spending hours in a debugger
, using the bug description provided by the QA experts to reproduce the conditions where the bug occurs.
Once the developer finds the bug and fixes it, he sends the fix for review. Sometimes the developer is unable to reproduce the bug, so he sends the task back to the QA expert along with an explanatory comment.
It seems like it shouldn't take very long to find and fix a bug, but there are some nuances. It all mainly depends on how well acquainted the developer is with this section of the code, and on his experience and theoretical knowledge. Sometimes a bug can be found and fixed in 20 minutes, and sometimes it can take three days.
This means that this type of task is especially difficult to estimate in advance, unless the developer, upon reading the description, immediately understands the what, where, and how of the bug. 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 should be sent for review. If it passes the review, then it goes into the main branch. If not, it is returned to the developer with comments that need to be addressed. Of course, you understand that your code is all checked by fellow developers, not by some high power.
That said, not everyone is allowed to perform code reviews — only the most experienced developers hardened by real-world practice, who can tell the difference between good code and bad code.
Code reviews are usually performed using a helper tool such as Crucible
. Reviewers go through the code and, if necessary, leave comments about certain lines.
There can be various kinds of comments. For example, some are critical. If they are not addressed, then the reviewer will not allow the code to be committed. Other comments are, say, simply remarks about the chosen approach. These the developer can listen to, take note of, or ignore.
A team can create its own rules and procedures for code reviews, agreeing about what is worth paying attention to and what not, what timeframe should be allotted for completing a code review, etc.
Experience alone is not enough to conduct a review: you still need to grow a lot in your technical skills and to read various books (for example, "Clean Code").
6. Code analysis
Since several people who think differently write code for the project simultaneously, their code and approaches will be different. And over time, everything gradually turns into a mess.
To improve the code, sometimes tasks are created to, say, analyze a certain module or the entire application, find and take note of shortcomings, and later create a refactoring task based on this analysis.
Such analysis also helps in situations where, when development began, the team couldn't see some simpler, more concise solutions, but they see them now. For example, logic is often duplicated in some methods. Accordingly, it can be extracted into a separate method, which can then be reused many times. Or perhaps a class has grown too bloated, or some code has become difficult to maintain or outdated, or...
Analysis tasks help to improve the quality of the code and the application. That said, for me, analyzing a large amount of code can be boring.
7. Refactoring code
The next part of code analysis is refactoring. Code can be outdated, obsolete, poorly written, hard to read, and so on. You should always strive for perfection (although it does not exist) and for the up-to-date code, removing anything superfluous, because the superfluous only leads to confusion and interferes with the ability to see what the code is doing.
It goes without saying that you are unlikely to see these tasks at the beginning of a project: you encounter them at later stages of development when the application is being polished and brought to perfection.
Here, it may be appropriate to consult with coworkers about what they would do and what pitfalls they see.
At their heart, such tasks are similar to developing new functionality. For example, suppose you receive a task to edit some functionality without changing its behavior. To do this, you delete the old code, write your own, and check the tests. If you did everything right, then without making any changes to the tests, they should all pass as before.
After everything in the code is as it should be, we send it for a review, and go sip some coffee :)
8. Writing documentation
Imagine that you are a new developer on some long-term software development project. You need to familiarize yourself with the code base or perform some specific task, for example, diagnose a bug.
How will you navigate the project?
Pester your teammates every five minutes?
And what if they are busy or it's the weekend, what then?
This is precisely why we have documentation — so that a person who is not familiar with the code can come in, find the relevant page, and quickly figure out what's going on in the part of the application that interests her. But someone has to create the documentation, haha.
If a project has documentation that developers must support, then when they implement new functionality, they describe it and update the documentation along with any code changes or refactoring.
You can also have situations where a separate employee — a technical writer — is hired to write, maintain, and supervise the documentation. If such a specialist is available, the life of ordinary developers is a little easier.
9. Various meetings
A lot of developers' time is spent in various meetings, negotiations, and planning. The simplest example is the daily stand-up meeting, where you need to report what you did yesterday and what you are going to do today.
In addition, you will need to have one-on-one phone calls, for example, with testers, so they can demonstrate/explain the nuances of reproducing a bug, or discuss the subtleties and requirements with a business analyst or talk about organizational issues with a PM.
This means that although a developer may be an introvert who prefers solitude, she still needs to be able to find a common ground with other people (well, at least a little).
The higher a developer's rank, the more time she needs to spend on communication and the less time writing code. A dev lead can spend half, or even more, of his workday on conversations and meetings alone and may write code less often (possibly causing him to lose a little of his coding prowess).
But if you just love talking, you could, as a team lead, transition into management and completely forget about writing code, instead, you would spend all day communicating with various teams, customers, and other managers.
10. Conducting/passing interviews
If you work for an outsourcing or outstaffing company, you will often need to go through external interviews, where you'll need to "sell" yourself to the client (you may be interviewed by someone working for the client), as well as internal ones to climb the ranks within the company.
I would call this a good opportunity for growth because the frequent interviews will force you to keep your knowledge sharp: you won't get rusty and soft. After all, if you get soft in IT, you can completely fall out of the field.
As you become a more experienced developer, you will be able to find yourself on the other side of the table, conducting interviews rather than passing them. Believe me, you will be very surprised when you look at it from this position, because asking the interview questions can be scarier than responding to them. You need to have your own interview strategy, a list of questions, and time to ask questions on all the necessary topics in one hour.
And after that, you are responsible to provide feedback that will influence the hiring decision and whether the candidate receives a long-anticipated offer or promotion. Or, you might allow an obviously weak candidate to get a position that she does not qualify for, and then you may be asked, "how could you allow her to be hired at all with that level of knowledge"?
So, when you're in the hot seat during an interview, keep in mind that the person in front of you is also facing a challenge and may be stressed out.
Any interview is stressful for both the candidate and the interviewer.
We'll probably end right here.
Thanks to everyone who read this article. Leave a like and keep on learning Java :)