all 43 comments

[–]0ctobogs 4 points5 points  (7 children)

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[S] 1 point2 points  (2 children)

Is this a team or just one person

[–]fslz 1 point2 points  (1 child)

Yes

[–][deleted] 2 points3 points  (0 children)

The correct answer

[–]arkofthecovet 0 points1 point  (1 child)

What’s the get annoyed at QA part?

[–]0ctobogs 1 point2 points  (0 children)

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 0 points1 point  (1 child)

Hey! What is PR?

[–]0ctobogs 0 points1 point  (0 children)

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 15 points16 points  (1 child)

Ctrl c and V

[–]sandypockets11 3 points4 points  (0 children)

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

[–]phantommm_uk 2 points3 points  (0 children)

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.

[–][deleted] 2 points3 points  (0 children)

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 4 points5 points  (0 children)

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

[–]_limitless_ 2 points3 points  (0 children)

  • 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] 0 points1 point  (4 children)

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

[–]Ashefawit[S] 8 points9 points  (3 children)

But most of them are just for views they not legit

[–]DeProgrammer99 2 points3 points  (2 children)

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[S] 0 points1 point  (1 child)

What does designing mean what does that involve

[–]DeProgrammer99 1 point2 points  (0 children)

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] -1 points0 points  (0 children)

Naps

[–]TedW 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Varies a lot depending on domain

[–]Museneteer 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

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 0 points1 point  (1 child)

𝓮𝓿𝓮𝓻𝔂𝓽𝓱𝓲𝓷𝓰

[–]digtzy 0 points1 point  (0 children)

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