A day in the life of a Software Engineer

The day begins like any other day, I arrive at work at 8:30 am and prepare my breakfast. This usually consists of a hot cup of coffee and a bowl of oats. After breakfast, once settled at my desk, I open up my laptop and plug it into the dock. There are a couple of applications I use daily.

These applications include GIT bash, Dbeaver, PHPStorm, Powershell (Command line shell), Smartgit, Outlook, Google Chrome, and Slack. A few of which will be mentioned in this article. Slack is a powerful communication application that my company uses as its primary means of communication.

I open up slack to generally find several notifications in the main channels and a few direct messages here and there. By now it’s 8:45 am and time for stand up. Stand up is an agile practice to see how a team is doing throughout their sprint and performed daily. A sprint is a duration of time given to a team to complete different sets of tasks and features.

Luckily, my team holds our stand up outdoors which I have found to help lighten the mood and is also a nice break from the office. This time is dedicated to sharing what each member of the team has planned for the day and if they need help completing certain tasks.

The company I work for is called ezyVet and provides Veterinary Practice Management Software used all over the world. ezyVet is now considered a “mature startup” with offices in Dallas, London, and Auckland. ezyVet is a sass (Software as a Service) company and is web-based, meaning it is hosted in the cloud and does not need to be installed on your computer for you to use it.

Back at my desk, I look at my JIRA board. JIRA is a proprietary issue tracking product used to help companies manage their work. I have created a special filter in JIRA that displays work assigned to me, categorizing my work from ones I have in progress and issues that are available to be started.

I’ve gotten into a habit of sending myself daily reminders which encourage me to write down three things every day — what I’m grateful for, what I’m going to focus on and something I’m going to be letting go of. I enter it into slack which links to an application I’ve created to store my entries each day.

Once I have completed this, I pick up my work where I left off yesterday. Being a developer is all about problem-solving, whether big or small we try to achieve an optimal solution for every problem we encounter.

The ezyVet codebase has over three million lines of code, with about 30 developers working off the same codebase. Along with finding solutions, you have to also think about how your solutions work with already existing code and possible regressions. Regression in programming occurs when a proposed solution breaks another part of the functionality in the code.

The problem I’m working on today is a front-end problem. What the user does not see is referred to as the back-end and what the user sees is referred to as the front-end. You have front-end developers, back-end developers and then me, a Fullstack developer being able to work on both front-end and back-end problems.

The issue I am trying to solve today is why a button is enabled when it shouldn’t be. To give it more context, we have medication records and as a vet user with the correct permissions, you are able to refill a medication. The problem is that if a product that is associated with the medication is no longer active, the refill button is enabled when it should not be.

GIT is a distributed version control system that allows many developers to work on the same code base by keeping track of everyone's changes. GIT bash CLI is a command-line interface for this software and the Command-line is an interface provided for users to directly type commands to the computer’s operating system.

Using GIT bash’s CLI (Command-line interface), I change my branch to match what the client’s software version is on. Then I open up my ssh client (Powershell) which is a software program using a secure shell protocol to connect to a remote computer. We also use Vagrant in conjunction with Powershell that helps with building and maintaining our virtual machines. A virtual machine is basically an emulation of a computer system. Vagrant helps us run our VM’s which run our software. This ensures that we are developing in the closest environment to that of our clients.

I run a command which imports a client’s site’s database to my local machine which I have just initiated via Vagrant on my ssh client.

Voila! I now have a local machine that matches the client’s and can now start investigating in order to diagnose the problem. The first thing you want to do during the investigation process is to replicate the issue locally. This will give you more information on whether this is a code problem or perhaps a user configuration problem.

I navigate my way to the patient record in the system and select the medication tab. I create a medication with a product that is active and the refill button is enabled. I then disable the product and the refill button still remains enabled. Step one is now complete as we have successfully replicated the issue. Now we try to locate the reason behind the button still being enabled.

Handy tip: You can find the logic by matching it to what is shown on the web page. For example, if you were looking for what the submit button did when submitting a form, you would search for fields on the form to match the back-end but the key is to make your search unique as possible because there can be many places in the code that will have the exact same text.

We now have figured out that this is a code issue and we are able to find it using unique elements on the page.

There are different properties available for alteration on different types of elements on a web page. Several elements include:

• Buttons
• Text Fields
• Text

These elements include a property, “alt text” which is the text that appears when you hover over the element. For this problem, we will be using the “alt text” property highlighted above on the refill button to find the specific medication form and then further narrow the search down by looking up the title of the refill button “Refill”. This web page element should only give us one result and we immediately find it. We have now found the programming logic and it becomes obvious why there is a problem right away. The reason is that there is no logic around the button to disable it if the associated product to the medication is not active in the database.

All we need now is a simple if condition to check the product’s active status and set the disable property of the button to true. An If Condition is exactly what it says. If the logic meets a certain condition, we want to do something. If it doesn’t it will not do anything. Our if condition is below:

if (product is disabled) {
    disableRefillButton = true;
}

Along with this front-end solution, it is important to verify that the back-end also supports this functionality. We search through the code to find that it does not so we add it in as well, fixing this problem.

A function in programming is a named section of a program that is responsible for a specific task. An example of a function is shown below.

public function validate() 
{
    if (product is disabled) {
        throw Exeption("You are not able to refill medication for a 
            product that is disabled.");
    }
}

Public is an access modifier that defines the level of accessibility of this particular function throughout the program. Public means that this function is accessible at all levels of the program.

An exception is an event, which happens during the execution of a program. In this function, we check if the product is disabled using an if condition and then throw an exception which displays an error message. The error message tells the user that the button is disabled due to the medication product not being active.

Since we have now solved the problem, we can submit a merge request. A merge request is a request for your code solution to be merged into the main code base which is live on the client’s site.

We will be using GIT as mentioned earlier to submit my merge request.

All done! Now my solution is in a Peer Review status which means that it is open for any of the developers to comment on. This helps ensuring the code put in production is at its best quality and anything concerning has been looked at. After it has been reviewed, QA testing will commence and once it has passed the test, it will become ready to merge and put into production.

QA is also known as quality assurance, which is the process of checking that the solution has not broken main functionalities in the system as well as ensuring that the quality is kept throughout the entire software. It is a great way to prevent mistakes and defects in code which haven’t been caught during the code reviewing process.

It is lunchtime now and I step away from my computer and quickly grab something to eat. It’s Tuesday, which usually means we have sushi but today we’re having sandwiches instead. I often have my lunch in the communal lunch area or outside if it’s a sunny day. We also have board games at the office, as well as a ping pong table, arcade machines, and an air hockey table set up just outside the lunchroom.

After lunch, we prepare for refinement which usually takes about an hour. Refinement is another agile practice where the Product Owner and the scrum team come together to discuss different issues.

A Scrum Team is a collection of individuals working together to deliver the requested product changes, deliver new features and fix existing issues. Scrum is an agile process framework for managing complex knowledge work with an initial emphasis on software development.

In more detail, the scrum team decides on a value to allocate to the issue which encompasses the effort needed to get the issue resolved for the client. The Product Owner is responsible for maximizing the value of the product by assigning the scrum team’s sprint tickets that need to get done from the most high priority to the lowest.

It’s now almost 2:30 pm and it’s developer ticket time. Developer ticket time at ezyVet is when a member of the support team and a member of the development team sit down for half an hour to discuss issues that are difficult to replicate or that are easy to fix within the allocated time. I make my way to the support area and someone is already waiting for me. They ask me questions and I try to answer them. If the support member cannot replicate the issue but believe it is a code problem, I help them take a deeper look by looking at the code. If it is a data issue I can quickly resolve, I action it during this time.

After developer ticket time I realize I don’t have any other responsibilities for the day, so I spend my remaining time looking for another problem I can work on tomorrow. I look at my JIRA filter to check for unassigned issues that are available to be started and similar to the first half of the day, we repeat the steps needed to replicate the issue and go from there.

At 5:30 pm my day is finished, I pack up my things and leave for home. Every day is different depending on the individual as well as the arising problems, but this is what you would typically expect from a day in the life of a Fullstack Software Engineer.