If you're studying to become a professional software developer, you might be wondering what a software developer does everyday on the job.
In this article, I will talk about the typical day of a software developer and what to expect on the job.
Main Responsibilities of a Software Developer
As a software developer, your main responsibilities will include fixing bugs in the codebase, building out new features, writing tests for the applications, writing documentation, performing code reviews, and participating in team discussion meetings.
Very experienced developers, like software architects, will be responsible for the higher level technical and architectural decisions for the software applications.
Let's take a look at each of these responsibilities in greater detail.
Debugging Codebases and Fixing Bugs
When you first start out as a software developer, one of your main responsibilities will be to work on small bug fixes and debugging small errors in the codebase.
There will be a list of tickets (issues) that will break up the work into manageable pieces, and some of them will include bugs in the application.
You will pick up some of the small ticket items which will help you learn the codebase. It is standard as a junior developer to spend the first couple of months ramping up with a codebase and with the new job in general.
Just make sure to ask plenty of questions and try to pair program with other developers on the team. Working with other developers will help you learn new techniques and grow faster.
I have learned a lot from my coworkers, and most of the time a fresh pair of eyes have helped me see the problem in a different way.
Building New Features
As you start to become more comfortable with the job and gain more experience, you will start to be given more responsibility with the codebase. This is where building out new features comes in.
Features are essential components of the software product. This type of work will take longer than small bug fixes and give you an opportunity to contribute more to the project.
This will also provide you with the opportunity to work on more complex problems and grow more as a developer. The first feature I worked on was to implement a light/dark theme for the company website.
I spent time thinking about the best approach on how to implement this feature for our existing codebase. Then I went about implementing my solution and testing out the website.
The final phase was to go through code reviews and update the website documentation to include the new feature.
The whole experience taught me how to build out solutions that were maintainable and scalable that would work well with the existing codebase.
Writing Tests for the Applications
One important element of software applications is ensure that they work they way they are supposed to work. This is where testing comes in.
Software developers are responsible for writing different types of tests like unit tests, integrated tests, functional tests and more. They might also engage in manual testing which includes the developer going through the application with a set of test cases and ensuring it is working the way it is supposed to.
One of my first experiences with testing came in the form of smoke testing and writing manual test guides for a couple of our apps. Smoke testing is where the developer will go through the application and ensure that basic functionality is intact.
Writing test guides involves the developer going through all of the features of the application and creating test cases. These test cases involve writing down the exact steps a user should go through and the expected outcome.
The first time I had to write a manual test guide, I didn't realize how specific I needed to be in writing out each step. But once I wrote a few test cases, the process started to make more sense and it became easier to write these manual test cases.
If you are interested to learn more about testing, then I suggest you read this helpful freeCodeCamp article.
Writing Documentation
Documentation is an important part of any software application. It is important to document the main features of the application as well as all of the steps required to run it locally for developers.
Whenever you join a new project, and you notice anything confusing or missing about the documentation, make sure to bring it up with the team. That would be a good opportunity to update the documentation.
Sometimes when you are working on a project and the team is busy with meeting deadlines, documentation can sometime fall behind. When things calm down a bit, make sure to revisit the documentation and make sure it is up to date and accurate.
Performing Code Reviews
Building software is a team activity, and it important that everyone on the team has their code reviewed by their peers. When you have made changes to the codebase you will create what is called a pull request.
That pull request represents the changes you want to add to the codebase. You will then request a review from team members and they will look over your code and provide feedback.
It is important to view the feedback as constructive, because your team is just trying to help catch issues and make suggestions on how to optimize your solution.
It is also important to provide constructive feedback and ensure that everything in the pull request fixes the issue or meets the requirements of the new feature.
To learn more about the code review process, please read through this helpful freeCodeCamp article.
Participating in Team Discussion Meetings
There are a lot of moving components that go into building software products. It is important that the entire team is on the same page during the entire application process.
The goal of these meetings is for each team member to share status updates with the team and share any blockers that are preventing them from moving forward on the project. If you are newer to software development, it can be intimidating to participate in meetings.
You might also feel overwhelmed with some of the discussion and all of the new terminology being used in the meeting. Just try to ask questions and remember that it takes a while to understand all of the ins and outs for the software process.
My natural inclination is to be more reserved in meetings, but I have made more of an effort to speak up and ask questions on what I don't understand. Sometimes you will learn that other people had the same question and were glad that you asked that question.
Try your best to actively participate in meetings and share your input on the project and ask questions on what you need help with.
Conclusion
As you can see, there are a lot of components to building out software products. Your days won't be spent writing code 8 hours straight.
Instead, your days will be filled with meetings, pair programing sessions, debugging code, reading documentation, writing documentation, and testing software.
I hope you enjoyed this article and have a better understanding what it is like to be a software developer. Best of luck on your software journey.