What does one or a few types of typical days look like for you if you're a software engineer?

There are definitely different days and it varies by company and production methodology, of course. I'll give some general examples!

Typically, a software project's features are broken down into smaller tasks by the management team and leads, which include specific milestones that groups of smaller tasks build up to. Beta is an example of a typical milestone.

Often, a lead gives tasks to individual engineers, based on what the goals are for the current milestone. So on a particular day, you might come in and assess what the highest priority task is on your list and get started coding it. Some tasks might actually span multiple days, in which case you'd give updates to your lead as they check in with you.
You'll also need to collaborate with the rest of the team. Modern software is never a one-person job, so be prepared to communicate and work closely with other engineers.

Your team might also have code review days, in which everyone looks over your code as a group and gives feedback about how you can code more efficiently, etc.

Throughout production, you are also likely to have bug-hunting days, in which your day is dedicated to fixing problems with the software. Sometimes you may be using the software over and over again to see if your fix worked or if anything else broke in the process. Most teams have dedicated quality assurance testers, but the engineers often join in at key points to help ensure the best product goes out in the end.

So while your primary job may be coding, you might also end up with reviews, meetings, bug-hunting, and QA days, to name a few.

It's also important to note that the milestones are often on hard deadlines, so if things fall behind, engineers may work extra to meet the milestone regardless, depending on the company and product.

Overall, expect the standard federal allotment for meals and breaks.

I have had various roles on teams, some have been individual contributor roles (meaning I only had to worry about getting my own individual work done) and some have been leadership or management roles (where I was responsible for entire groups work getting done). This is mostly a description of a general day in the individual contributor role:

Get in the morning and catch up on emails or any tasks left over from yesterday that you need to follow up on, 10-30 minutes on this usually.

You will have some kind of daily team meeting (common names for said meeting are SCRUM, stand up, or daily review), this meeting can happen at the beginning or end of day (typically I've always had them in the morning hours). This is not with your whole team, unless your team is very small, and consist of 5-10 other devs/artist/designers/managers working on some project(s) along with you. The purpose of this meeting is to discuss and track progress against goals: how many of the previous meeting's goals were met and what the new goals are going to be. A goal for a software engineer could be to take a specification for a feature and turn it into an implementation strategy (more on that in a min) or to finish coding some aspect of a feature ("when you shoot an enemy they explode") for example. This is a critical part of your day, software development requires planning a schedule and sticking to it to deliver functional software within known estimates.

After that its about executing against your goal and, in general, there are three states you will be in (they are not exactly linear but its easier to explain that way)

1. 
   

   Starting a new project: This answers your first question about where what you are suppose to code comes from. A specification will be completed by a product owner (a designer or other team member or even you), this is some kind of document (power point, word doc, etc) outlining the way the software is suppose to work usually from an "end user" point of view (the customer using the software). If you were making a shopping website this might be a document explaining how users add items to their cart and checkout for example. You will review this spec, by yourself or in a group, so that you understand the what the product owner wants to accomplish and work with them to make sure what they are asking for is possible. You will then be responsible for taking that specification and turning it into an implementation strategy. You will need to answer questions like "What new code will I be writing? What old code will I reuse?", "Will I use already built technologies or code libraries?", and "What dependencies do I have on art (or other disciplines)?" among many others. Depending on the complexity of and size of the project this could take multiple days. You will usually collaborate with other engineers (including your lead engineer who will need to sign off on your plan). The whole goal is to create a plan detailed enough to give reasonably accurate time estimates for how long it will take to code something so schedules can be made. You might also be required to present your plan to other engineers.

   
   


2. 
   

   Working against a tech plan to finish a project: Following getting your tech plan together you will just be working against those tasks day after day. This is coding, testing your code, adding art, coordinating with other team members like art and QA; everything you need to make the specification into a functional piece of software happens here. This is also the time where during your daily meeting your progress will be tracked and scrutinized. If anything takes longer than expected or work that was unaccounted for is discovered this is when new plans and deadlines are made. Depending on the size and complexity of a project this could take a few days, a few weeks, or a few months.

   
   


3. 
   

   Integrating your work back into the over all project the whole team is working on: At this point you have a functional piece of software that does what the specification calls for. What I am about to say now is not best practice for developing software but for ease of explanation I'll assume this all happens at the end (I expect these things to all be happening frequently during step number 2 when I'm running the show). You will be required to present your code to another engineer and do a code review. In this process the other engineer reviews the code you have written along with you, line by line, while asking clarifying questions and providing feedback to improve the code. Based on their feed back you go back, make the changes, test them and get them reviewed again. This process is repeated over, and over, and over until the reviewer has no more feedback. Your code will then be tested by QA and when they confirm its bug free and meets the specification requirements you will submit you new code back to the project as a whole.

   
   

After that you get ready for your next project and it all stars over again :)

As for the breaks and what I do besides coding. Direct work related materials would include researching new technologies I need to use or reading documentation, giving code reviews, and attending meetings to discuss designs or new projects before a specification is written to provide early feedback.

Not directly related to work is the usual stuff. I get lunch with people. Go grab coffee or a drink. Chat about video games. Take a break to play a game maybe. Or some times just go for a quick walk to clear my head and think something over. Sitting in front of the computer all day is not the best way to be productive and I encourage people to do what keeps them productive.

At the end of the, hitting your dead lines is what matters.

Typical work days for a Software Engineer would be as follows -

1. 
   

   Collect and understand the requirements
   You need to gather the requirements from Product managers (if you are working for a product development team), discuss the requirements, suggest them any changes, and finalize the requirements. You might not always get the requirements (work to be done) in an email, however, your manager or mentor might communicate to you via email asking for some work (small) to be done.

   
   


2. 
   

   Design the product or feature
   You would participate in designing the work along with other engineers and architects. Present it to managers and architects for approvals. They might suggest you to change the design. In that case, you go back to drawing board (typically a white board) with your team and incorporate the feedback and present it again, if necessary.

   
   


3. 
   

   Plan the work
   The work to be done could be medium to large scale if it involves design. Otherwise, it would just needs coding. Nonetheless, you will break the work into various phases and steps and start coding for them. Once you think you are done with coding, you test it by yourself.

   
   


4. 
   

   Testing
   Normally each team will have a QA (Quality Assurance) engineer to test the work done by the Software Engineers. He/she will test your work. If it works according to the specifications, he approves it, otherwise, he will let you know what and why is it not working. You then fix it and make it available for testing.

   
   


5. 
   

   Deploy your work in production.
   Different companies follow different processes for releasing work (code) to production. You have to follow the process as your code is going to be deployed on Production.

   
   

These are typical steps to follow, however, each company has its own process, which is similar to above. Good Luck !!