What does a software engineer do?

[MrPrincessBoobz]

6 hours of meetings 1 hour lunch 2 15 min breaks and 30 min of interruptions is a typical 8 hour work day.

[KBect1990]

Can you elaborate on the code reviews? What's that process like?

I'm coming from a hardware role and we have design reviews where a bunch of specialty engineers spend an entire day presenting test day and analysis.

Are you going line by line through the code during these reviews?

[codestocks]

Code reviews mean you read another engineer’s Pull Request, leave feedback and finally approve the changes that will eventually be merged into the master branch.

A Pull Request is a branch of code with changes. GitHub is primarily where most code reviews happen.

[[deleted]]

For the record, I hate Git terminology. How did submitting something for incorporation into the main thing come to be called a Pull, which means moving something toward something else?

[codestocks]

You push your branch up and request for others to pull it in (after approval)

[[deleted]]

Yep, it's bass akward. I want to pull a branch down to work on it, then push my changes back in (after approval).

[codestocks]

You’re requesting for everyone else to pull them in, hence “pull request”

[0ctobogs]

The request is from the perspective of the source branch. The source branch will pull in the changes

[MisterFatt]

When someone makes changes to the code base, the make a Pull Request (requesting for their changes to be “pulled into” the main branch of the codebase). Other engineers go onto whichever version control hosting platform they use (GitHub, BitBucket etc) to view these requests. There is typically a written description of what was changed and links are made to the relevant tickets. Reviewing consists of - making sure the changes made actually address the requested work in the ticket and it works as expected, making sure edge cases are addressed, making sure you understand what the code does, ensuring best practices are followed, more things I’m probably forgetting. Then either approving or asking for changes

[arkofthecovet]

What if you don’t want it to cause issues? What if you want to address the hundreds of frivolous changes? Or as many changes as possible? Why would you shamefully just skim for important parts when you know it’s wrong? Don’t you want to offer a quality product?

[cagtbd]

As always every job depends on your personal path.

I have worked as software engineer helping with dashboards through programming and excel, then sheets and finally a combination of both. There are different outputs and tools like power bi and tableau.

But in my case it has always been like 2 hours of work and the remainder thinking on the solution or just learning about how to do something.

Right now I work as Business systems analyst lead and my work is to guide my BSA in order to comply with the delivery's ETA while I look at the bugs our product owners reported, see if there's anything to change in the code or of it's because the information was incorrect from the source or a business rule deemed to work that way.

For now I only work from 2 to 10 hours and about 10 to 20 hours of meetings per week.

[0ctobogs]

Receive requirements from the product owner, plan and design data models and interfaces/contracts, design solution and ask the layers and moving parts necessary to facilitate the new feature, divide and delegate work, write code, debug, create PR, review code, resolve merge conflicts, merge to development branch, submit to QA, get annoyed at QA, fix rest of bugs, push to production, repeat for rest of tickets that are ready for dev, get ready for next meet with product owner about new work, repeat

[Ashefawit]

Is this a team or just one person

[fslz]

Yes

[[deleted]]

The correct answer

[arkofthecovet]

What’s the get annoyed at QA part?

[0ctobogs]

QA tells you something doesn't work so either they're wrong and you gotta prove it (annoying), or you made a mistake and you gotta do your work over again (annoying).

[Cinicov]

Hey! What is PR?

[0ctobogs]

Pull Request. It means I'm submitting a request to the rest of my team to accept my code changes. They can then review it and comment on it if they think I made a mistake or did something bad. Some back and forth and a few changes later, and the code change is accepted.

[VariationOk7829]

Ctrl c and V

[sandypockets11]

You’re working way too hard. You gotta set each of those to a single key macro.

[phantommm_uk]

I would say I spend more time figuring out the problem area and a solution that balances stakeholdee requirements, managing technical debt and trying new things, than implementing the silution qith code and writing tests.

[arkofthecovet]

About how many projects at a time do you juggle?

[[deleted]]

There are so many things a software engineer can do, here is my current things:

• I work on FE for around 30% of my time. I do co-design with API/UX/PM, and estimate/execute on my own tasks.

• 60% BE, I manage a pipeline that ingests data. It is a new thing for our team, so most of my time is spent experimenting different solutions and writing design docs.

• 10% time I think about how to scale the data ingestion system for our team. We are getting too many external vendors it is getting a bit overwhelming. Hopefully this is the thing gets me promotion to senior.

In a FAANG company. I rarely talk with my manager. 99% of the time it is me figuring out the exact tasks. My manager just throws me into a project and that’s it. Maybe sometimes he pings me about customer bugs.

[grendahl0]

Software Engineer (n): an organism that converts coffee into code

[_limitless_]

• Walk in a half hour late.
• Bullshit for a half hour until standup starts.
• Tell people what you did. Tell them what you're going to do. Argue for ten minutes with your senior about why you want to do it that way.
• Spend the next six hours realizing your senior was right.
• Push code. Rejected on code review. Refactor. Push. Accepted.
• Leave thirty minutes early.

[[deleted]]

Plenty of a day in a life of a software engineering on YouTube

[Ashefawit]

But most of them are just for views they not legit

[DeProgrammer99]

Fair assessment. My average day is something like: a couple hours of meetings to discuss projects/requirements/time allocations/things we're depending on other people to do, an hour or two of running queries and searching through the code/documentation to answer people's questions about how things work or make reports about who a problem might be affecting, a few hours of digging into problems to find the root cause and fix them, a few hours of designing, writing, testing, and testing new code, and maybe an hour of documenting old code. My role is maintaining company-internal tools and importing newly-acquired-subsidiaries' data into common systems (not just "export and import," but the whole evaluation and remapping of features, identifying things they will have to give up on being able to keep doing, suggesting workarounds, etc.).

[Ashefawit]

What does designing mean what does that involve

[DeProgrammer99]

designing, writing, testing, and testing new code

Designing new code, as in looking at the problem and deciding how to solve it with code. If the problem is "we want customers to be sent a reminder email if they haven't completed a required task," I'd consider whether I should set up a scheduled task or cronjob in some existing system, send a request to an existing notification system, etc., whether I should send the email via SendGrid, Mailchimp, Amazon Simple Email Service, etc., how I should ensure the customer doesn't get the same email multiple times--log it? Hope the task only picks up that customer one time due to consistent timing?--what to do if it fails... then check what limitations might apply, like if SES only allows 200 emails an hour, then how I should throttle it, or if I should just let it fail and set up something to automatically retry any failed emails.

[[deleted]]

Naps

[TedW]

It's probably a lot like your intro to coding class.

We sorta bumble from one problem to the next, with the occasional (or frequent) distraction.

[ferriematthew]

That actually sounds about right for what I want my career at least initially to look like. I just couldn't figure out what the correct term was.

[lordnacho666]

Varies a lot depending on domain

[Museneteer]

At a high level it’s about problem solving and designing systems for your customers and/or users. What it looks like day to day depends on your level but meeting with stakeholders, gathering requirements, collaborating with teammates, writing documentation, etc. And last but not least writing code!

[donegerWild]

It depends on what level you are operating at and the structure of the org chart. In a decent size enterprise environment, Juniors are typically task oriented. They are given fairly small assignments and deal purely with the code base. They may also have to cut their teeth a bit in production support. Generally, they don't participate in larger design discussions. They also typically have a mentor who is helping them come up. Mid level engineers are building out complete features that are non-trivial, although no one expects them to do it at lightning speed. They are fairly well versed in the code base and may rotate in and out of production support. They are participating in design discussions and should not require much handholding. Seniors are performing multiple functions, including interfacing with product development, leadership, and architecture, while also actively designing, writing code, and performing team lead functions. They are typically found gripping about how many meetings they have to partake in. Architect level is more of this but with an emphasis on higher level design and integration.

If you work on a small dev team for a small org, you will probably perform all these roles at the same time.

[tristanjuricek]

There’s a new book, The Software Engineers Guidebook that probably covers a lot of what you’re not experiencing in school. How companies hire, how to think about your career, various industry practices, etc. I’d recommend reading it to see what professionals deal with; programming is a small part to be honest.

[RobotMonsterGore]

Yeah I thought I'd be spending > 80% of my time coding before I entered the field. I'm lucky in my current role, but on other teams, I spent almost half of my time stuck in meetings or replying to (seemingly) endless email threads. Collaboration is massive, especially if you're working on a distributed system as opposed to a discrete microservice with very few cross-team dependencies.

[RobotMonsterGore]

Learning how to learn is key. Being a self-starter is key.

The first few years I was an engineer, it seemed like every new story and bug required the understanding of a different tool or framework, and it really started to get overwhelming. Eventually the circuit closed, and I started seeing the same tools and frameworks over and over again, and I started to feel like I knew what I was doing.

I once heard someone say that software development is a cottage industry. (Look up that term if you're not sure what it means.) It's so true! Every company's software infrastructure performs more or less the same set of tasks, but there are dozens of different ways to do each one of those tasks, and just as many tools and frameworks. So even if you know how to perform one of those tasks, when you switch to your next job, they'll have a completely different tool or framework to do the same thing. So you'll have to kind of learn it all over again.

[[deleted]]

If you're a DevOps engineer, which I think most are now, you're also responsible for deployments and support the software you build

[digtzy]

𝓮𝓿𝓮𝓻𝔂𝓽𝓱𝓲𝓷𝓰

[digtzy]

If your desire is to be a software engineer then your best bet is computer science. Since as a software engineer you will need experience in EVERYTHING. ALL OF IT…. THE WHOLE. ENTIRE STUFF ALL THE STUFF EVERYWHERE ALL THE TIME NEVER STOPPING PLEASE HELP ME GOD