7 answers
Devin
Student
Limestone, Maine
1
Question
Asked
1292 views
What is your daily routine as a Software Developer?
#Software Developer #technology
Login to comment
7 answers
Polina Vorozheykina
10
Answers
Updated
Polina’s Answer
I work in a customer centric company, so my experience stems from that. The experience tends to vary day to day and is highly affected by what I am working on at the moment. As a software engineer, your role would most likely be multifaceted - you will have responsibilities to write code, design project, communicate with other teams, maintain existing systems, etc. Depending on the day, demands of the team and your customers, you are likely to have different communication demands and different focus levels during the day.
Shabeeb Shah
Software Engineer
1
Answer
Phoenix, Arizona
Updated
Shabeeb’s Answer
We work based off a queue of tickets that say what needs to get done so we always know what needs to be worked on. Usually our team starts our day with a stand up meeting where we talk about what we got done and what we will continue working on for the day. Ideally most of the day is left up to an individual or a group of developers to code and test the features that they are working on. That can vary from time to time though as some days you'll need to meet with different stakeholders to get feedback.
In general, you're likely to find many companies have some sort of flavor of the Agile Methodology that works best for their team. The process can boil down to a system of collecting requirements from customers, planning out the work that the team will accomplish over a set period of time (usually 1-2 weeks), developing and testing your code along with your teammates, and finally shipping and demonstrating the work that was completed. This basic process will continue as your requirements change and what work remains.
Ultimately it comes down to what kind of product that you work on and what kind of company you work for. They type of audience you have and product you work on largely influences how the non-coding aspects of your work day will go.
In general, you're likely to find many companies have some sort of flavor of the Agile Methodology that works best for their team. The process can boil down to a system of collecting requirements from customers, planning out the work that the team will accomplish over a set period of time (usually 1-2 weeks), developing and testing your code along with your teammates, and finally shipping and demonstrating the work that was completed. This basic process will continue as your requirements change and what work remains.
Ultimately it comes down to what kind of product that you work on and what kind of company you work for. They type of audience you have and product you work on largely influences how the non-coding aspects of your work day will go.
sokly doeurk
NOC at cellcard
1
Answer
Phnom Penh, Cambodia
Updated
sokly’s Answer
How to develop the best quality software with low cost? Explain it based on your experience?
James Hicks
Tech Expert
1
Answer
Updated
James’s Answer
Great question, working as a Developer has much more than just looking a computer screen all day. Often one must have meetings with users to understand what is desired and how to best service them. Technology is around use all day of our lives, so being able to make a users experience easier is always good.
James recommends the following next steps:
Amy Zuerndorfer
Software Platform Architect
3
Answers
Raleigh, North Carolina
Updated
Amy’s Answer
Each day can be different! Of course a major part of the Software Developer role will be coding and developing the functionality. Other aspects could be meeting with users and the business development team to understand the requirements, testing and deploying code, and presenting the great work accomplished to an audience. However, each company and project team can follow their own unique process so it is important to stay flexible. The agile methodology is an industry standard, so it is likely you will come across this development method in your future.
Amy recommends the following next steps:
Issac John
Tac Enginner
2
Answers
Bengaluru, Karnataka, India
Updated
Issac’s Answer
Hi devin ,
I work as a remote developer for a small start up in india
personally i like being a remote developer and i can work any time i want to, as long as i'm able to finish the task and not cause probeems to other developers who are working remotely..
Nathan Weddle
Lead Software Engineer
3
Answers
Portland, Oregon
Updated
Nathan’s Answer
I have been working in software development for over twenty years. Your day really depends on the company you work for, but I can explain what mine is like.
I work for a Software as a Service company, and our customers are other software developers and technologists.
Every day we start with a stand up meeting. During the meeting each developer says what the did the day before and what they are working on today. Also, if there are any dependencies or anything blocking us from doing our work, we talk about it.
After that I work on the Story I am assigned. A Story is a description of the functionality I need to code. To complete a story, I may have to change existing code and/or write new code. Usually I spend some time looking at the code if I am not familiar with it. I then think about how I am going to solve the problem. Most stories tell me what I need to do, but not how to do it. Once I have an approach to solving the problem, I will start coding. Its not uncommon to "refactor" my new code during this process. That means I write it the first time, and then realize it would be better if I wrote it a different way. After the coding is done, I write more code to test the new code. Yes, software developers write code to test their code. This takes up about half our time, or maybe even more. I need to verify the new functionality works, and also that I didn't break any existing functionality.
I then submit submit my code for peer review in the form or a Pull Request on Git Hub, which is a source code management tool. My team members review my code and note any changes or issues with the code. I then make those changes or discuss them with my team mates. Once a team mate approves my code, I merge the pull request into the master branch of code and deploy it to a staging environment. This is where we can test the code again in an environment that mimics the actual Production environment our customers use. Once I am satisfied the code is working, I deploy it to the production environment, where it is used by our customers.
I don't go to a lot of meetings but there are some. Sometimes I need to discuss a Story with another team. It's common for multiple teams to work on one piece of functionality. Sometimes one team will work on the user interface and another team works on the backend code that saves data to a database. Or you may have meetings to plan for upcoming work. Another common meeting is a retrospective where the team reviews what went well and what did not go well during the past couple of weeks. We may change how we go about our work if we identify a problem with the previous work.
It's also common at my employer to handle customer support issues that arise. So I may have to investigate a problem a customer reported and figure out if there is a problem with the code, or a problem with how the customer is using the software.
I work for a Software as a Service company, and our customers are other software developers and technologists.
Every day we start with a stand up meeting. During the meeting each developer says what the did the day before and what they are working on today. Also, if there are any dependencies or anything blocking us from doing our work, we talk about it.
After that I work on the Story I am assigned. A Story is a description of the functionality I need to code. To complete a story, I may have to change existing code and/or write new code. Usually I spend some time looking at the code if I am not familiar with it. I then think about how I am going to solve the problem. Most stories tell me what I need to do, but not how to do it. Once I have an approach to solving the problem, I will start coding. Its not uncommon to "refactor" my new code during this process. That means I write it the first time, and then realize it would be better if I wrote it a different way. After the coding is done, I write more code to test the new code. Yes, software developers write code to test their code. This takes up about half our time, or maybe even more. I need to verify the new functionality works, and also that I didn't break any existing functionality.
I then submit submit my code for peer review in the form or a Pull Request on Git Hub, which is a source code management tool. My team members review my code and note any changes or issues with the code. I then make those changes or discuss them with my team mates. Once a team mate approves my code, I merge the pull request into the master branch of code and deploy it to a staging environment. This is where we can test the code again in an environment that mimics the actual Production environment our customers use. Once I am satisfied the code is working, I deploy it to the production environment, where it is used by our customers.
I don't go to a lot of meetings but there are some. Sometimes I need to discuss a Story with another team. It's common for multiple teams to work on one piece of functionality. Sometimes one team will work on the user interface and another team works on the backend code that saves data to a database. Or you may have meetings to plan for upcoming work. Another common meeting is a retrospective where the team reviews what went well and what did not go well during the past couple of weeks. We may change how we go about our work if we identify a problem with the previous work.
It's also common at my employer to handle customer support issues that arise. So I may have to investigate a problem a customer reported and figure out if there is a problem with the code, or a problem with how the customer is using the software.