Five Things I Tackled Daily
It’s been a couple of years since I’ve written code professionally, but I still think about my days as a software developer. I have to say that there are more things than you think that go into being a competent software developer. Here was my list of daily habits.
Review PR’s
When you’re reviewing code, it’s important to keep in mind that there are a number of different ways that you can do this.
I’m a big fan of using Github and its pull requests. This allows you and your team members to see any changes before they get merged into master branch or main line of development. You can even comment directly on specific lines within each file changed so it’s super helpful when working with other developers.
The way I see it, reviewing code is all about improving yourself as a developer by catching bad practices and bugs before they become problems for other users or even worse — security vulnerabilities. When you’re reviewing someone else’s work on their PRs (pull requests), there are certain things that should be pointed out right away, such as:
- Security vulnerabilities: the first thing to look out for are any potential security issues. If there’s an SQL injection vulnerability, then this needs to be addressed immediately because it can lead to someone stealing sensitive information from your database.
- Wrong Result: Does the code generate the expected result? It can be completely syntax free, but if the developer misunderstood the task, it’s a bug.
- Syntax Errors: I’m honestly still shocked that developers submit their code with syntax errors. Do you honestly believe that it’s going to work if it’s merged? Fix syntax errors because they are the easiest to fix.
When you’re reviewing other people’s code, it’s important to make sure that their changes don’t break your project. If they do, then you need to be careful about merging them into master because this could cause problems for everyone else on the team. This is why pull requests are so helpful when working with other developers.
Prioritizing and Assigning Tasks
The first step in developing prioritization skill is understanding that it’s a skill. It takes practice, but once you learn how to prioritize tasks, it becomes second nature. If you want to get better at prioritizing, here are some tips:
- Prioritize based on importance; don’t just assign tasks by their order in the list of tasks or by what’s most urgent (that could lead to confusion).
- Prioritize according to how much time/effort required and how important each task is relative to others.
- Make sure everyone assigned a task understands what their responsibilities will be before beginning them so everyone knows what expectations they have for themselves as well as those around them
Lead developers will take it upon themselves to make these prioritization efforts in order for the project to run smoothly. Tasks are assigned to individuals based on their experience.
Verifying whether the task is complete and unambiguous is part of the process. If it’s missing key components, like acceptance criteria, the task should be deprioritized in development and prioritized with the BA and/or PM.
Project Based Stand Ups
There’s the all-encompassing standup that many companies do where each developer goes through their tasks, blockers, etc. These are great if the developers are each working on one project. Once developers take on more projects, it’s more efficient to have project-based stand-ups. This usually occurs in software development agencies. They might have more work coming in than developers. Developer time then needs to be subdivided.
Just like regular stand-ups, project based stand-ups should take 10–15 minutes max. This is the time to review what’s being worked on, redefine priorities, and voice any blockers. Anything that takes more than a minute or so to solve should be taken offline, but it should be voiced during that call.
Documentation
Documentation is important, and it’s a good way to communicate your decisions. It can help you with:
- Communicating your ideas and concepts with other developers on the team.
- Communicating why certain features were implemented, or rejected from the product release.
It’s also a great way to document decisions and requirements. As part of my daily routine, I’d go through each change I made and write down why I made that change. This helped me track my progress so if something went wrong with the code later on, it gave me more context about what happened.
This is the one topic that I wanted to stay away from since I know how people feel about documentation, but it’s usually code documentation that they’re referencing, so there’s a difference. As a side note, I’m hugely in favor of documenting the logic. What path must the code take in order to generate a certain result. This can be eliminated with a competent staff, but I’ve seen such disasters that I wished someone would have documented it before I needed to start digging through it. Once I figured out how the code travels through 3 different obsolete JavaScript libraries, I document it.
Mentoring Junior Developers
Mentoring is a great way to give back to the community, share knowledge with others and build relationships. It’s also a great way to learn new things.
Junior Developers need guidance, a lot of it. Aside from help with code, they need guidance in learning how to think about solving the problem. This is where a senior developer can really shine. They’ll be an instrumental part of the junior developer’s learning journey.
If your organization doesn’t have junior developers, you can join an organization like CodeMentor or Stack Overflow, where you’ll be able to connect with people who are looking for one-on-one help on specific topics.
Conclusion
There are a lot of other things you’ll do day to day. It’s important to have a good overview of the tasks you need to do every day since it is important for staying focused and productive. This list isn’t exhaustive; these are just a few things I did daily.