Coding is all the rage nowadays. No surprises here: it pays well, is in high demand, and is easy to pick up from the comfort of your home. Sounds great, if it was not so confusing.
Software developers keep talking about all these meetings, reviews, bug fixing, documentation… whilst you as a newbie might’ve thought that being a coder is about writing code. Well, it is that, too, but the responsibilities of an average developer go beyond that. But don’t panic! In this article, you’ll discover the daily routine of Java developers. That way, you’ll know if becoming one is right up your alley.
Let’s check out typical tasks of a Java developer on a project. But first of all, let’s set a baseline and define what Java developers are there in the programming world, from the perspective of their experience and skill sets.
It goes without saying that the following categories are quite smudgy. As a programmer you can be Middle/Senior as a highly skilled specialist in a narrow development, or a T-shaped specialist (with skills from different areas). Still, it’s good to know the general rules.
The junior position is a stepping stone, the beginning of your journey as a Java developer. At that stage of your career, you probably haven’t worked on a commercial product.
As a junior, you’ll be fixing minor bugs and working on existing features. Chances are, the company will also attach a senior developer to you who will act as your mentor. A mentor would be the one whom you address all your questions, concerns, and confusions. If you think that this sounds more like studying than actual work, you’d be correct. Indeed, the junior developer’s footprint on the released product is minimal. That does not mean that you should not take your responsibilities seriously! By performing well at this level and demonstrating a can-do attitude, you’ll become a middle developer in no time!
As evident by the title, middle developers are halfway between juniors and seniors. They are neither clueless greenhorns nor code ninjas that can solve problems by staring at them. Juniors become middles once they show the mastery of the frameworks and tools that the company uses (colloquially called “stack”) and that you are competent enough to independently finish small and middle-sized tasks without the mentor’s constant supervision. How long it will take you to get that coveted promotion is hard to gauge — it all depends on your goals and the company’s criteria.
Regardless of when you’ll become middle, your responsibilities will increase, and there will be less hand-holding. Writing tests, maintaining documentation, iterating upon existing code, taking the initiative to devise efficient solutions for the problems, sometimes even mentoring junior colleagues — these are some of the many new expectations that you will have to fulfill. Congratulations, you are now a fully-fledged member of the team!
Senior devs are the cream of the crop — they define the functionality and the scope of the project. They always see the task in a big picture mode and that makes them crucial contributors to the project.
As they usually understand the project’s scope and how all bits of the program interconnect, senior devs gain a few unique responsibilities. These include reporting the project’s progress to the upper management and clients, discussing the business end of the software development, and ensuring that the business and developing process work in cohesion.
Keep in mind that there is no universal certification that makes a developer a junior, middle, or senior. A senior from one’s company might be middle elsewhere. It all comes down to the company’s criteria. With that said, let’s now take a look at the responsibilities shared by all Java developers.
Let’s not dive deep into responsibilities of a Junior developer in their first days / months on the project and focus on the daily tasks of an experienced Java developer, whom you can become pretty fast, if you put in some effort. This things-to-do list is vast and requires hard and soft skills.
No matter how complex or trivial the task is, all solutions begin their lives at the design stage. Coding is about complex logical problems that do not have predefined solutions. It’s up to you to devise fast and efficient solutions. You might stumble at the beginning, either relying on slow solutions or copying algorithms that you do not understand to look more intelligent. You will have to find balance, and that can only come due to practice. It is okay to fail as long as you are going to remain open-minded and receptive to criticism. Being stubborn is one of the worst traits that an aspiring software developer might have.
Once you have settled on the initial solution, it is time to make it a reality. Efficiency is the name of the game in the coding world, and workflow ain’t an exception. All software companies use an application to assign tasks and track progress, the most popular one being JIRA. Your team leader will assign tasks to you most of the time. Ditto for time estimates, although it is a more flexible ordeal. You can argue for altering an estimate if you believe that the task demands less/more time.
Don’t fret too much if you fail such a “deadline.” They are called estimates for a reason, and the more tasks you finish, the better your assessment of the required time will become. Also, keep in mind that the task is not finished after you mark it as such. What comes next is a process of testing, code review, and potential rewrites.
Uh-oh. “Everything worked fine on my PC,” but the code reviewer points out that your code failed a few tests. Tests? Yeah, tests. That you should have written before. I am not saying that you did not, but it is a task that not many developers enjoy doing. Thus, they might try to dodge these responsibilities as often as possible. While writing tests might feel like mundane chores, they are a necessity that ensures that programs run smoothly. Commercial applications are immense, and it is not feasible to manually check for every potential point of failure that your functions will have. Hence, tests.
So don’t slack and write your tests.
Writing new functionality is not everything that devs have to do. Fixing bugs (caused by you or someone else) is another routinely assigned task that you’ll have to wrestle with. Here is how it works: Quality Assurance (QA) Engineers check the code for bugs by running a series of automated tests. Once they find these errors, they create a task in JIRA with the bug’s description and steps to reproduce it. An assigned dev then spends some time figuring out the root issue behind the bug and tries to fix it.
How much time it’ll take depends on many factors: the developer’s skills, whether they wrote that part of the code, and the obscurity of the bug in question. Sometimes, it can be as simple as “someone forgot to put a semicolon somewhere.” Other times, a bug can be so elusive that you will have no other option but to send the ticket back to QA because you cannot reproduce it. As with everything else in the world of Java — you guessed it — it becomes easier with experience.
Remember that feeling of dread, getting your essay back glowing red from all the teacher’s remarks? Guess what, this feeling is back, coding edition! Yep, once you submit your code, it won’t get pushed to the main branch without a review from your supervisors. You will usually go through any issues together, using code review tools.
Highlighted issues can range from some obscene errors in logic that must be fixed before code will get greenlit to something inconsequential as suggestions on more efficient solutions. Although, you’d be wise to heed the latter kind of comments as well, as it is an easy way to improve your skills.
Everyone has recognizable handwriting, and the same is true for their coding style. Indentation, methodologies, and approaches blend into a beautiful mess that requires regular maintenance. Companies conduct periodical code analysis, looking at parts of code to figure out its shortcoming and how to improve them. A common practice is to review the code at the end of the development process. By that point, the dev team has a better picture of what they had to do than initially. Thus, they can improve upon the existing code while it is still fresh in their memories.
Refactoring is like applied code analysis. Commercial software can be maintained and kept up to date for years. As developers’ practices and knowledge improve, they realize that old code does not hold up against modern standards. Enter refactoring, a process of rewriting the existing code from scratch without changing how it functions.
Essentially, imagine a messy and dirty office desk. Refactoring is akin to tidying the desk up. By the end of it, it would be the very same office table, although much easier to navigate and a lot more pleasant to look at.
Not all companies hire a technical writer — an employee who creates and maintains the documentation about the product’s functionality and code. In such a scenario, it would be up to you to document all the functionality that you introduce into a project. You will probably use tools like Confluence to collectively share and maintain the project’s documentation.
It might not be the most exciting endeavor, but in the future you will thank them when they’ll have to do some work on an old project, and they’ll have a concise description of the project’s functionality. Likewise, whenever you are first assigned to a new project, checking out the documentation is the best thing you can do, as it’ll contain answers to many of your questions.
Traditionally, every morning begins with a stand-up: the team gathers in a circle (or in a Zoom call, if working remotely) and talks about what they did yesterday and what they are planning to do today. Stand-ups keep everyone up-to-date with the project’s status. They also streamline team leader’s decisions on whether they need to alter the tasks’ priority in any way.
The number of meetings and calls throughout the day will depend on your current task and your seniority. You might have meetings with QAs so that they can demonstrate how to reproduce a particularly intricate bug. If you are a senior developer, you might be asked to conduct a technical interview with a potential hire. The rule of thumb is that the higher you climb in your career, the more meetings you’ll have.
Regardless of whether you end up using any of the resources above, here is one final cheat sheet of the key skills that any aspiring Java developer should have in their arsenal.
1. Core Java:
2. Spring Framework:
4. Testing tools:
5. APIs and Libraries.
6. JVM Internals.
7. Design Patterns and Architectural Patterns.
8. DevOps Tools:
9. IntelliJ IDEA.
11. Build tools:
12. SQL and Databases:
13. Web/App Server:
14. Web services:
1. Communication Skills.
2. Being Open to Learning.
3. Team Work.
4. Work Ethics.
5. Interpersonal Skills.
That seems like a lot of things to do, eh? Well, if these tasks did not dissuade you, you are probably wondering — how can I become a Java developer? There are so many lesson plans, books, and guides that it might be hard to choose a single one. Don’t worry. I have prepared some materials that you can use as a guideline to get you started.
Keep in mind that while reading books and watching videos is always a good thing, the best way to learn coding is by, well, writing a lot of code. So, don’t slack on practice, whether it is doing some fun exercises on the web or writing small applications, whatever strikes your fancy!
1. Choose the course to solidify your Java fundamentals knowledge and get hands-on practice. I advice to choose among online sources, so that you can learn at your own pace:
2. Don’t forget about well-structured theory. Read Java tutorial for beginners (besides, it’s free):
3. Read professional Java-related blogs:
4. For a change of pace, watch Java videos on YouTube, like:
5. Join discussion boards where you can ask specific questions:
Becoming a Java developer is not an easy task, but you will be aptly rewarded for sticking with this path. It is a profession that offers many growth opportunities, and it will keep you engaged with the variety of tasks that you’ll have to do each day.
Even if you figure out that it is not for you, after all, there is no hurt in trying out. Who knows, maybe becoming a software developer is something that you have been looking for all these years!