What is your daily routine as a Software Developer?
#Software Developer #technology
7 answers
Polina’s Answer
Shabeeb’s Answer
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’s Answer
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’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’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’s Answer
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.