What is the day in the life of a software engineer like?

To add to the specific bits that Brian touched on (figure out what to build, figure out how to build it, write code to build it, review other people's code)... Other things that you'll be doing:

• write documentation (some of this is in the figure out how to build it section, some of it is later)


• fix bugs (often will require a small amount of code and a large amount of time)


• mentor newer employees on how to write code, or do any of the above things


• interview candidates (usually technical interviews)


• lot of other less software-specific red tape-y things

The percentage of your time that gets allocated to each type of task depends on the company, your seniority/experience/ability, where in the project lifecycle your team is, etc.

And yea... software engineer vs. web developer mostly comes down to what title the company wants to use for the job. It's basically the same thing (caveat being that there are obviously some software jobs that don't involve web much, and thus couldn't be called 'web developer'). So don't sweat the difference between the two while you're still in undergrad, it won't matter much.

Hi!

A day in the life of a software engineer and a web developer are actually quite similar. You'll work with people to determine the features of the product or service you're going to build. You'll turn those requirements or features into a real program by writing code. You'll often have a chance to review the code that other people write, and you'll get their feedback and critique of your work as well, so you can grow and get better.

There are lots of web developers who would call themselves software engineers, because so many complex applications live on the web. Facebook, Twitter, Uber, and more all employ software engineers. So does Tesla. So do your banks, insurance companies, hospitals, and a lot of other places.

As an aside, I've done a lot of different types of software development, but I personally love making things for the web. But the things I mentioned above happen in every case.

Either way, you can't go wrong, because you'll be able to point to the thing you coded and say "I helped make that happen." And if you're really lucky, you can say you built something that helped a lot of people.

"Software Engineering", as opposed to "Computer Programming" is typically a group endeavor. Teams of people are required to develop, test, deploy and maintain the product. A lot of work by a lot of talented people is required to ensure these teams work and work well together.

I'm a principle level software engineer and technical lead, which means basically that I lead a small team of software engineers and also carry (in theory) a full engineering load.

In a typical week I do the following:

• Have two "scrum" meetings with the team, my lead, the Program Managers (in my company the PM's are the people who plan the features we will implement), and sometimes the technical writers, and Architect for the area my team works in, to track our progress against the sprint goals. My team works in two week "sprints" - periods of time in which we do fixed, pre-planned amounts of work.
• One "sprint planning" meeting with my lead and the PM to decide the work we will take on in the next sprint or discuss the current sprint.
• A brief 1:1 with the Program Manager to check in and get any updates.
• A 1:1 with my lead, to check in.
• I check in with my team members. One of them is a new hire so I try to meet with him at least once a day, to check in and answer questions.
• Additionally we have monthly "roadmap planning" meetings where my lead, the PM and I look ahead at the tasks we have planned for the year, and figure out what we will try to accomplish in the upcoming month.
• I attend a "release review" meeting in which we review the new code and features that are being deployed this week.

Outside of the weekly schedule

• I work with customer support and my lead to prioritize new issues that have arisen; sometimes we modify the sprint schedule so we can take on high priority items.
• I work with support to help them with issues they are having with customers and to request additional information from customers in the case where we need it to fix a bug. Occasionally I take customer calls, particularly in cases where we need detailed information, typically about bugs we are trying to fix.
• I monitor the progress of my team against our sprint goals and provide reports to the leadership.
• Every few months I have a "Guardian rotation" where I am responsible for monitoring the performance of the functionality my team is responsible for. I do this via tools that aggregate the massive amounts of data we collect from our product. I look for anomalies that could indicate problems in the system that are too low level for our higher level alarms to catch, or possibly that one or more of our customers are under attack. When appropriate I have support get in touch with them to followup.
• Once or twice a year I have an "escalation rotation", where I leave my team for two weeks to work on a special team that deals with super high priority issues that cannot wait to be dealt with in the normal course of events.
• I answer questions and assist other developers and testers in areas where I have more knowledge of the product than they do.
• I participate in design reviews where we discuss the implementation plans for complicated or risky new features. Sometimes I write documentation, both internal and user facing, and review user facing documentation that is going out for features that I implemented.
• I perform "code reviews" were I review changes going into the product and suggest changes where appropriate. This can take up to an hour (or more) a day of my time, depending on the breaks.

In toto these tasks take up around half of every workday. Additionally

• I actually do do computer programming. I design and implement new features, and fix bugs, according to the roadmap and sprint schedule. Since I am more senior I often get the harder and more interesting problems. Rank hath privileges. I also write code to test the new features I have written, and sometimes work with our QA engineers if they will be testing the code. The general rule of thumb is I spend about as much time writing test code as I do writing functional code.

I sometimes joke with people that its surprising how little actual computer programming software development engineers do.

I work hard and I work long hours, but make no mistake:

I ABSOLUTELY LOVE IT.

I cannot think of a more interesting or challenging process that I could be part of than this. I love every part of it from solving the technical problems, to understanding how what I'm doing fits in to the company's strategic goals and the customers needs, to working to help keep the machinery that makes it all happen going.

I also get a great deal of fulfillment from providing a worthwhile service to our customers in the free market and from knowing that our customers and investors think enough of the work that I and my colleagues do to put their money down for it. I do my best to make sure that was a wise decision on their part.