Describe the day in the life of a software engineer.

Hi Jessica!

Great question! I'm relatively new to the software engineering world, so I know best what it's like to just be starting out. Hope my experience is helpful :)

The first thing I'd say is that my job is really project-focused. I tend to be working on one "feature" at a time, and I'll take that feature all the way from being an abstract idea to it actually being out in the real world before starting on my next project. On average, I probably spend about 85% of my time working on things directly related to my feature and the other 15% on things related to helping other people with their projects.

When I am working on my feature, I am usually doing one of three things.

First, I might be thinking about what my feature is supposed to do and/or what it is supposed to look like. Normally, these kinds of decisions are made mostly by other people -- like product managers or designers -- but I get to give input, too. This kind of work can involve sketching out little diagrams on paper or on a whiteboard.

Second, I might be thinking about how I want to best structure my code to achieve those functionality and design goals. There are often many ways to do the same thing when you are coding, and so I spend a lot of time at this step trying to figure out which way makes the most sense. This kind of work can involve looking through our codebase to see how people have done it in the past or asking people who are experts in certain particular areas.

Lastly, I might be actually writing and debugging the code that I thought out in the previous step. This step is often the most time consuming and it's what I spent most of my day doing. This kind of work can involve writing code, running it in our development environment (a place we can test code without affecting the real website), and then trying to see where things went wrong. As I've grown in my career, I've been able to make this step take less time by spending more time on the previous steps -- I've spent a lot of time re-writing code because we changed the functionality or design after I started coding.

When I am *not* working on my feature, I am usually helping other people via our code review process.

In order to be able to "push" a new feature to the real website, you get must sign-off from other engineers that your code does what you say it does, meets certain style guidelines, and -- most importantly -- will not break anything. You get this approval by asking other engineers to do a "code review" of your code. In this process, they look through the changes you made and can leave comments or suggestions. Once they are satisfied -- often after a few rounds of back and forth -- they will approve your changes and you can release them out in the world.

To summarize, I spend most of my day working on the design or coding of my own project, but I also devote a fair amount of time helping other people with their projects. Being earlier in my career, I spend more time coding than more experienced people, who spend more of their time thinking about how things should be.

Hope that helps!

This answer will vary wildly based on the industry, company, specific team, type of software being developed, age of the project (new projects are very different from maintaining older software), how tenured you are (newer software engineers have different job duties than more experienced software engineers a lot of times), etc.

But the general job duties:

• Figuring out what code to write (getting requirements, understanding the problem space, maybe actually talking to customers, though you might have someone who does that for you if it's a big enough company, etc)
• Actually writing code (programming)
• Testing code, building test harnesses, etc (less common now, but sometimes testing is a separate job role)
• Deploying code into production (or maybe there's other people who do this for you)
• Fixing bugs
• Dealing with other production issues (things break which aren't necessarily code bugs, but still need manual attention to fix)
• Dealing with non-production issues that still cost you overhead. This might be explaining to other software engineers at your own company how to use stuff you built, or any other large number of ancillary problems/duties that come up.

Note that "figuring out what code to write" starts out as a smaller part of your job, but eventually balloons to take more of your time. It also may include a lot of writing documents, meetings to convince other people what needs to get done and how to do it, etc.

Hello there!

 Software engineer plays different roles based on the industry as well as experience.  And work type varies depending on the which part of software development life cycle you are in. You can be a designer, developer, tester, deployment manager or maintainer.. or a combination of those. Many company encourages to have a combined end to end role under the "DevOps" culture.

When you are starting your career, in most cases some one will assign  very specific task - to develop code that will take a set of input and produce a set of output. You may also get task to fix some code that may not be working as expected.

A basic task list for a developer will be 1. "check out code from repository",  2. "Modify or create new function", 3. "Compile/build your code", 4. "deploy in your sandbox/test environment", 5. "do basic testing (called unit testing)", 6."Push your code for fully integrated build along with all other components of the product", 7. "Let integration test (manual or automatic) verify over all functionality of product", 8. "Fix any issue came from step 7 by repeating 1-6"

If you are in quality assurance, you may test code written by another developer using different tools.. Many QA engineers also spend time automating testing so that quality check can happen automatically.

In most software engineering jobs, internet is your friend.. you get to research, test different solutions, learn new software. Many problems are already solved to some extent by some other person and that'll give a good starting point for you.  The most important thing is to understand what key words you have to search for to get the solution you are looking for.