What does a Software Engineer do in the day?
Much of our modern life can be done mostly on our phones. Apps provide us with the means to perform tasks such as banking, money transfers, getting a transport, ordering food, etc. The people who build and maintain these apps and other software critical for the proper functioning of these apps can mostly be classified into two categories: Developers and Software Engineers.
For many of us, we may be wondering what do Developers and Software Engineers actually do during the day when they are not spending time with their friends, family or on their hobbies.
With that, I will attempt to shed some light…
Collaboration and communications
In a stereotypical manner, most of us working as Developers or Software Engineers are introverts. We generally hate small talks and may not partake in any events that has a lot of people. Our social circles are small.
However, it does not mean that we completely shut ourselves off from the world at work. Building a piece of software is actually a complex task that requires coordinations between the different stakeholders and your fellow colleagues. To ensure that everyone is on the same page about what features are needed or not needed, what is urgent, or what is not working, we actually have meetings to talk about things. Sometimes, the meeting can be between two person either in person (or virtually these days due to the shift in working style caused by the pandemic) or with a group of people.
These days, most software project are managed and built with Scrum, a project management framework that encourages self-organising teams and frequent communications.
With that said, Scrum prescribed 3 major roles. Software engineers typically fall under the “Developer” role within Scrum. In addition, Scrum defines a workflow consisting of 5 major events that team will conduct or partake in as they worked on building the software.
The team will participate and engage in Sprint Planning. During this Scrum event, the team gets together to discuss what is the end goal of the Sprint and what are the tasks they should take into the Sprint to build the Sprint Backlog that will help them reach the goal. A key member of the team, the Product Owner, determines what tasks are important and will discuss with the developers. They will also set the Sprint Goal before starting the Sprint.
Following the Sprint Planning is the actual Sprint, a time-boxed development event that is typically between one week to one month long with two weeks being the most common. During this time, the team will develop the software and have a daily Scrum meeting to update the Sprint Backlog, discuss impediments and update the Sprint plan.
At the end of each Sprint, the team will conduct a Sprint Review. During this time, they evaluate whether they have achieve the Sprint Goal they set out at the beginning, present the completed work to the stakeholders and collect feedback. The feedback will then be used to improve on the product or to create new backlog items to be picked up in the next Sprint.
After which, they will partake in Sprint Retrospective. During this time, they will reflect and share with the team on the good, the bad and what could be improve for the next sprint.
The whole Scrum team (Product Owner, Developers, Scrum Master) will also be involved in a Scrum event called Backlog Refinement. This event is an ongoing process during which the team will ensure the Product Backlog is up-to-date, prioritised and ready for the next sprint.
Researching, designing and writing codes
During the development period, there are also other tasks that an engineer might do depending on the situation such as:
- Read up on software or library documentations
- Research and try out what others have done
- Designing software modules and components
- Reading and writing codes
- Debugging broken code or testing software
If we assume a software engineer works 8 hours a day for 5 days, and break these activities down by the average amount of time spent per week, only around 40% of time is probably spent on reading and writing codes.
The Scrum activities mentioned above would probably take up around 20% of the time. The rest are actually spend on reading and writing documentations, designing software components, engaged in discussion with fellow colleagues and debugging broken code.
If the engineer is a team leader or a senior engineer, then they would also spent some of their working time reviewing codes written by junior engineers, mentoring them, and engaged in meeting with other stakeholders.
In some cases, the engineers may choose to take the initiative to conduct Dev Exchange, which can take many forms such as Pair Programming, code review, brain storming sessions and even mini-workshops.
Handling production issues
As much as we strive to deliver quality software product through testing, automating deployments, establishing release plans and reviewing codes (not in any particular order), software errors or bugs will still appear. In some cases, bugs might even cause data to be corrupted and requires restoration from backup or manual patching.
When such things happen, software engineers will have to be there to investigate and fix the issue. If the software is mission critical, then software engineers may be placed on shift work to deal with production issues immediately. These shift can last anywhere between 8 to 12 hours. Alternatively, they may look at their company’s internal issue tracker system for bugs or issues raised by the customer. If the company is small enough, the engineers may instead get email directly from their customers.
