3 answers
Taylor
Student
Turner, Maine
3
Questions
Asked
575 views
What does A typical day as a Software Developer, Applications look like?
#technology #software #computer-software
Login to comment
3 answers
Mickael Rosenberg
Software Engineer
261
Answers
Bellevue, Washington
Updated
Mickael’s Answer
Hi Taylor,
It really depends the company your are working on and your position.
I am working for Dell as a Principal Software Engineer (meaning I've been working for a while) and as a developer (not manager), my day to day looks like this:
- See if support engineers need my expertise to help solving customers' hot issues.
- Work on the task I am assigned to. This task can be:
-- Analyze (or review someone else's analysis) a defect to find the cause and make sure all information are filled up properly for the next person to work on. Usually that includes identifying root cause of the problem, find when the problem has been introduced, and all we need for bug tracking and continuous improvement.
-- Fix a defect that was found by testers or customers (could be the follow up of the previous task)
-- Continue working on a new feature
-- Update documentation
-- Write tests
- Answer questions from management and/or support about the product. These can be meetings or simply e-mails.
- Mentor younger/less experimented coworkers to help them do their job
- Review colleagues' work
- Collaborate with my extended team
- [Sometimes] Follow some training either mandatory by Dell or simply to improve or refresh a skill that I need for a coming project.
When you are less experienced, you mostly focus on these parts:
- Work on the defect or feature you are assigned on
- Review colleagues' work
- Attend your mandatory trainings
There is also a ton of discussions with team members because multiple brains are better than one. If you are working on some problems and the solution is not obvious, or there are multiple solutions, it is always good to discuss them with other team members and get their feedback. You could consider this part of "Review Colleagues' work" though the work is not really there yet.
Of course, if you work on your own, all of this goes away and your day to day will look like:
- check feedback from customers
- assign priorities to defect / features
- work on top priority one
It really depends the company your are working on and your position.
I am working for Dell as a Principal Software Engineer (meaning I've been working for a while) and as a developer (not manager), my day to day looks like this:
- See if support engineers need my expertise to help solving customers' hot issues.
- Work on the task I am assigned to. This task can be:
-- Analyze (or review someone else's analysis) a defect to find the cause and make sure all information are filled up properly for the next person to work on. Usually that includes identifying root cause of the problem, find when the problem has been introduced, and all we need for bug tracking and continuous improvement.
-- Fix a defect that was found by testers or customers (could be the follow up of the previous task)
-- Continue working on a new feature
-- Update documentation
-- Write tests
- Answer questions from management and/or support about the product. These can be meetings or simply e-mails.
- Mentor younger/less experimented coworkers to help them do their job
- Review colleagues' work
- Collaborate with my extended team
- [Sometimes] Follow some training either mandatory by Dell or simply to improve or refresh a skill that I need for a coming project.
When you are less experienced, you mostly focus on these parts:
- Work on the defect or feature you are assigned on
- Review colleagues' work
- Attend your mandatory trainings
There is also a ton of discussions with team members because multiple brains are better than one. If you are working on some problems and the solution is not obvious, or there are multiple solutions, it is always good to discuss them with other team members and get their feedback. You could consider this part of "Review Colleagues' work" though the work is not really there yet.
Of course, if you work on your own, all of this goes away and your day to day will look like:
- check feedback from customers
- assign priorities to defect / features
- work on top priority one
Thank you Mickael!
Ben Gof
Finance
29
Answers
Wayne, New Jersey
Updated
Ben’s Answer
I have worked with developers in the past as a stakeholder and have also done some programming myself as I have been self learning Python and helped automate a couple of reports our team uses. A typical day will depend on where in the software development you are during that time period. So I'll provide a brief description of what a Software developer does in general.
As a developer, you start off by meeting with the stakeholders and asking them what they are asking for or what are they trying to solve. This may take several meetings and meeting with several people on that team to try and get as much information as possible. Once you understand the requirement, you would then try and determine what would be the best way to develop that program. From what I have seen, the developers start to create the new program in stages and continue to meet with the stakeholders along the way to ensure what they are building is satisfying the requirement or to ensure the requirements haven't changed.
Once the initial model is built, it will go into what is known as UAT(User Assisted Testing). This is basically a trial with a limited group from the stakeholder team so they can assess the model and identify errors and opportunities for improvements. Most developers will tell you that their program worked great in development only to experience a lot of bugs once it goes into production. So the UAT trial helps to catch those bugs early. So once the code is written and the product is in UAT trial, there would be consistent tweaking of the code along the way to correct errors. There is also consistent tweaking of the code to adjust for changes. For example, perhaps the source code your pulling data from has changed, so your code would need to be updated accordingly.
Once the errors are corrected in the UAT trial, the program would then be submitted to be published or rolled out. In the early stages of the rollout there is still high visibility to ensure that the end users know how to run the program that was created and to ensure it is working without issues.
To summarize, it depends on what stage in the development your in as to what a typical day would look like. In general, a typical day would involve coding, meeting with the stakeholders, meeting with your own team to brainstorm ideas and more coding. Developers will tell you that there is a sense of pride as they "built something" that adds tremendous value. In my opinion this is an excellent career choice as there is always a demand for developers and the work day varies and is always interesting.
As a developer, you start off by meeting with the stakeholders and asking them what they are asking for or what are they trying to solve. This may take several meetings and meeting with several people on that team to try and get as much information as possible. Once you understand the requirement, you would then try and determine what would be the best way to develop that program. From what I have seen, the developers start to create the new program in stages and continue to meet with the stakeholders along the way to ensure what they are building is satisfying the requirement or to ensure the requirements haven't changed.
Once the initial model is built, it will go into what is known as UAT(User Assisted Testing). This is basically a trial with a limited group from the stakeholder team so they can assess the model and identify errors and opportunities for improvements. Most developers will tell you that their program worked great in development only to experience a lot of bugs once it goes into production. So the UAT trial helps to catch those bugs early. So once the code is written and the product is in UAT trial, there would be consistent tweaking of the code along the way to correct errors. There is also consistent tweaking of the code to adjust for changes. For example, perhaps the source code your pulling data from has changed, so your code would need to be updated accordingly.
Once the errors are corrected in the UAT trial, the program would then be submitted to be published or rolled out. In the early stages of the rollout there is still high visibility to ensure that the end users know how to run the program that was created and to ensure it is working without issues.
To summarize, it depends on what stage in the development your in as to what a typical day would look like. In general, a typical day would involve coding, meeting with the stakeholders, meeting with your own team to brainstorm ideas and more coding. Developers will tell you that there is a sense of pride as they "built something" that adds tremendous value. In my opinion this is an excellent career choice as there is always a demand for developers and the work day varies and is always interesting.
Walt Smith
IT Director
28
Answers
Richmond, Virginia
Updated
Walt’s Answer
These days most of the software engineers in my organization work remotely, so a typical day starts with opening your laptop and signing into a remote conferencing session in a product like Teams or Zoom. The first meeting of the morning will be an agile stand up meeting for your development team. In this meeting, every engineer gives a short update to their teammates, saying what they worked on yesterday, what they are working on today, and any impediments or help they need to make progress.
Later in the morning, an engineer might get their code from the source control system (we use GitHub) and work on it on their laptop. They might instant message with teammates to solve problems and to lend a hand to others. When they finish some code and have unit tested it themselves, they will check it back into GitHub and tell their team lead that it is ready for QA. That sets off a whole process of other people on the QA team testing the software in different environments and getting it ready to go to production.
In our organization, every two weeks, there will be a meeting for the team to demonstrate their progress to their customers and get feedback on whether the product is headed in the right direction. Engineers get to participate in this meeting and show off the work they have been doing on the products.
About every ten weeks, all of the development teams will get together with customers, stakeholders, and others to discuss what they will be doing for the next ten weeks. We call that PI planning. There are also sessions called Grooming, where we make sure that every product feature that we are working on is well thought out and has a good technical design.
Engineers also meet with their managers regularly just to check in and make sure the engineer is happy and contented, and is doing work that challenges them and keeps them fully engaged with the team and the company.
There is regular training in the form of video conferences and on-line training modules. This training might be technical, or it might be something related to company policies such as diversity and inclusion, or cyber-security.
Lastly, engineers often get called into unplanned conference calls to do things like troubleshoot problems with existing software, or talk to a stakeholder about a concern or opportunity to improve the software.
There's more, but you get the idea. Every day is different, but every day has a beat to it that makes it fun and interesting.
Later in the morning, an engineer might get their code from the source control system (we use GitHub) and work on it on their laptop. They might instant message with teammates to solve problems and to lend a hand to others. When they finish some code and have unit tested it themselves, they will check it back into GitHub and tell their team lead that it is ready for QA. That sets off a whole process of other people on the QA team testing the software in different environments and getting it ready to go to production.
In our organization, every two weeks, there will be a meeting for the team to demonstrate their progress to their customers and get feedback on whether the product is headed in the right direction. Engineers get to participate in this meeting and show off the work they have been doing on the products.
About every ten weeks, all of the development teams will get together with customers, stakeholders, and others to discuss what they will be doing for the next ten weeks. We call that PI planning. There are also sessions called Grooming, where we make sure that every product feature that we are working on is well thought out and has a good technical design.
Engineers also meet with their managers regularly just to check in and make sure the engineer is happy and contented, and is doing work that challenges them and keeps them fully engaged with the team and the company.
There is regular training in the form of video conferences and on-line training modules. This training might be technical, or it might be something related to company policies such as diversity and inclusion, or cyber-security.
Lastly, engineers often get called into unplanned conference calls to do things like troubleshoot problems with existing software, or talk to a stakeholder about a concern or opportunity to improve the software.
There's more, but you get the idea. Every day is different, but every day has a beat to it that makes it fun and interesting.